Rails - Guard, Brakeman, and Bundler-Audit

Thanks to the efforts of Justin Collins (@presidentbeef - Brakeman)  and Hal Brodigan (@postmodern_mod3 - Bundler-Audit), Rails developers (and Sinatra) can use these two tools in tandem with Guard to protect their applications while under development. For those who aren't familiar, Guard was designed to run while you are developing, when you save a file it triggers Guard to run whatever tests you've specified in your Guardfile.

The following video depicts this.

Bundler-Audit -> Auditing your RubyGems

Ruby applications that utilize a Gemfile/Gemfile.lock, file(s) that contain the list of ruby gems an application should use along with their respective version number, can now be audited to determine if those libraries are vulnerable.

Credit to postmodern for developing the auditing gem and also to RubySec for creating the ruby-advisory-db, a community maintained database of Ruby gem vulnerabilities for which bundler-audit is built on top of. 

So to install this - 

gem install bundler-audit

to run it, navigate to the directory where the Gemfile.lock is stored:

bundle-audit check

If the application is using a vulnerable version of a gem, the output will look like...

Thanks,

Ken (@cktricky)

Quick way to view ruby gems

This post is a very short and very simple tip for easily opening a ruby gem up for closer inspection.

When reviewing a Rails or Sinatra application (code review), it sometimes becomes necessary to view the libraries (ruby gems) that an application is including and using. Instead of navigating to the ~/.rvm/gems/<version>@<gemset name>  directory (or wherever else the gems are stored) and opening them with your text editor of choice, you can instead leverage the power of bundler.

For your *nix based systems that leverage a bashrc, bash_profile, etc.

open your ~/.bash_profile file (or whatever the appropriate bash file is)

add this line export BUNDLER_EDITOR=mate

I chose "mate" because I use TextMate. Otherwise, just link to the appropriate editor executable.

(exit and save bash_profile)

type: source ~/.bash_profile

Then, navigate to an app that contains the Gemfile, and switch to the gemset or ruby version where these gems are contained, and choose a gem that you want to open...

bundle open <gem name>

That's all there is to it.

Ken (@cktricky)

Next Level Testing

We've been having a good time doing intensive, month long or longer APT simulation tests for people, acting like malicious insiders, using hardware implants, 0days, human enabled malware, etc. Lately, however, we've been playing around with a new type of testing to take things to the next level. This testing has two basic components:

• Reverse Engineer Testing
• Network Forensics Testing

The basic idea is to exercise your RE and packet ninjas even harder to make them strong.

On the RE side we create progressively more difficult malware for them to analyze. Here is an example of a ramp up path for this kind of test:

1. Basic packed binary
2. Challenging packed binary
3. Staged unpacker with memory checksums
4. Binary with analysis detection
1. Virtualization detection & retaliation
2. Dynamic analysis tools detection & retaliation
3. Debugger detection & behavioral changes
1. Multiple and increasingly difficult debugger detection from IsDebuggerPresent() to execution timers
5. Strong crypto, slack space and other binary tricks
6. Phantom routines & dead ends in the code
7. Exploits against analysis tools

Essentially we infect your systems with progressively more difficult to analyze malware (that we develop ourselves and ensure is safe), causing your in-house analysts to stretch, learn new skills, and practice so that when real world malware hits, you are ready to deal with it.

We pen test your reverse engineer.

(Or your sandbox appliance if you have decided to go that route instead).

On the Network Forensic side we ramp up the difficulty of our command and control and data ex-filtration techniques in order to exercise and improve your network security staff's capabilities in the following ways:

• Randomized timing & changing beacons
• Out of band network communications
• Protocol misuse & covert channels
• False flag / false signature packets
• Complex sequencing & esoteric packet based OP codes
• Port knocking type attacks
• Encoding & encryption
• Exploits against network analysis tools

This allows your network forensic analysts to hone their skills looking for anomalous traffic and finding the tricky ways real bad guys hide from detection. It also shows you how effective (or ineffective) your network security appliances such as IDS/IPS are.

All of the tricks and techniques we use for these tests are taken from real world experience in analyzing some of the trickiest malware and the most complex network evasion schemes during incident response events. In addition we throw in some of our own developed methods to keep the analysts on their toes.

This type of testing is most effective as a component to a larger APT simulation but can be done stand alone as well.

At this point in 2013 you probably know what machines on your network need to be patched. You have automated vulnerability scans in place and you have verified and validated scan reports using an exploitation framework. Maybe you've taken that additional step of doing APT simulations to understand your exposure to malicious insiders and sophisticated targeted threats like nation states. However, unless you are testing that final line of defense, the analysts, forensic specialists and anomaly tools, you are still falling behind.

V.

APT PDFs and metadata extraction

One of the modules in our new Rapid Reverse Engineering class is artifact extraction.  For this section of the class the students use a python module we create for doing some artifact/metadata extraction from samples.  One of the more interesting pieces of metadata that attackers leave behind is the software that the malicious file was created with. In this case I was looking at some PDFs.  I then realized that I extract this information for individual samples, but I have never run a test on a large set of known APT malware to see what comes out. So a quick adventure I set out on and wow was I surprised by the information.

I ended up with the following pie graph

The sample size was roughly 300+ known APT samples that we have.  It wasn't our whole sample set of PDF's but for starters was a decent size.  List (top 10) looked like this

Acrobat Web Capture 8.0 (15%)
Adobe LiveCycle Designer ES 8.2 (15%)
Acrobat Web Capture 9.0 (8%)
Python PDF Library - http://pybrary.net/pyPdf/ (7%)
Acrobat Distiller 9.0.0 (Windows) (7%)
Acrobat Distiller 6.0.1 (Windows) (7%)
pdfeTeX-1.21a (7%)
Adobe Acrobat 9.2.0 (4%)
Adobe PDF Library 9.0 (4%)

A number of things amazed me about this data. One of them was the lack of opsec on the attackers perspective, and the old versions of software that they are using. From the offensive perspective if you are dealing with targets that have resources to do deep level forensics and operations then every little bit of opsec is needed. It only takes a small amount of data to put together a large piece of the puzzle.

From the defensive position it points out the ability for defense organizations to do some early detection.  I doubt that most organizations are actually keeping track or analyzing what types of clean, business case pdfs come through the front doors.  What do the normal clean pdf's coming through your front doors actually look like?  Are the clean business case PDFs being created by the
"Python PDF Library - http://pybrary.net/pyPdf/" software? This is a piece of software that is no longer maintained. If you have a standard set of pdf's that come through your front doors and they aren't using strange libraries such as pyPDF then it might be time to create a nice little snort signature and alert on it.  I wouldn't recommend blocking at that level (unless you are up for it), but alerting on something simple like that can create extremely large dividends for response/defense teams. Imagine telling your CIO/CISO that you detected and re-mediated APT* attack coming through the front door by a simple snort sig.  

Some of the honorable mentions for that didn't make it into the top 10 are:

Advanced PDF Repair at http://www.pdf-repair.com
Acrobat Web Capture 6.0 (wow that is old)
¦  d o P D F       V e r   6 . 2   B u i l d   2 8 8   ( W i n d o w s   X P     x 3 2 )  *Ya that is the way it show's up

alientools PDF Generator 1.52
PDFlib 7.0.3 (C++/Win32)

I am getting to the point that you must look at data sets and see what type of information you can gleam from them. This idea might be feasible in your organization and it might not, but you as the defender have the ability to determine that for yourself.  

At the end of April (25-26th) we are debuting Rapid Reverse Engineering in New York City with Trail Of Bits http://www.trailofbits.com/training/#rapidre.  Rapid Reverse Engineering is a class designed for helping students learn how to rapidly assess files for incident response scenarios.

Attack Research Training Schedule

We have finalized our training schedule for Attack Research for the year. Below is the schedule for our training's for the rest of the year. We can't promise that more opportunities will pop up but below is a confirmed schedule:

April 16-17th 
Course: Offensive Techniques
Location: Source Boston

April 25th-26th 

Course: Debuting - Rapid Reverse Engineering
Location: New York City at an Attack Research/Trail of Bits training

May 21st-22nd 
Course: Operational Post Exploitation 
Location: Attack Research Headquarters

This is going to be a unique class. As mobile devices are becoming more and more prevalent we will be incorporating this concept into this class. Each student will be getting a Nexus 7 that will be incorporated for use in the class!

June (exact dates TBD)
Course: Rapid Reverse Engineering and Offensive Techniques
Location: London, UK

We are working the details now and will update things when we have new information.  

July 27th-August 1st
Course: Debuting - 4 day version of Tactical Exploitation
                          - 2 day version of Tactical Exploitation.  
Location: Blackhat, Las Vegas
We have seen our Tactical Exploitation class fill up quite fast in the recent years so register early!  

September 23-25th
Course: Offensive Techniques
Location: BruCON 2013

October (exact dates TBD)
Course: Offensive Techniques or Rapid Reverse Engineering
Location: Source Seattle

November 4th-6th

Course: Offensive Techniques AND Rapid Reverse Engineering
Location: Countermeasure
Last year we debuted Offensive Techniques at Countermeasure, and this year we will be adding some new content and delivering that class again. Along with Offensive Techniques we will be teaching our new Rapid Reverse Engineering class. Countermeasure was a fantastic conference and look forward to another round of it. 

For more info on each class visit our training page at www.attackresearch.com, or click on the links to register for the class!

Training Opportunities

We are hosting two training's at the Attack Research Headquarters over the next few months. The first training is our Operational Post Exploitation class which will be January 29th-January 30th.

We have just added Offensive Techniques in February for an available training as well. We will be hosting the training February 26th-February 28th.  More details can be found at our training website.

We are also looking at doing a round of training in the London area in May of this year. Right now we are trying to gauge the interest in this location. If you are interested in taking either Offensive Techniques or Rapid Reverse Engineering in this are please email training@attackresearch.com so that we can gauge interest.

Happy New Year