End Point

News

Welcome to End Point's blog

Ongoing observations by End Point people.

Use Metasploit to Verify Rails is Secured from CVE-2013-0156

On January 8th, 2013 Aaron Patterson announced a major security vulnerability on the Rails security mailing list, affecting all releases of the Ruby on Rails framework. This vulnerability allows an unskilled attacker to execute commands remotely on any unpatched Rails web server. Unsurprisingly, it's getting a lot of attention; Ars Technica estimates more than 200,000 sites may be vulnerable. With all the hype, it's important to separate the facts from the fiction and use the attacker's own tools to verify your site is secure.

Within 36 hours of the announcement of CVE-2013-0156, the developers at Rapid7 released a metasploit exploit module. Metasploit lowers the barriers to entry for attackers, making the whole process a point and click affair with a slick web GUI. Fortunately, the Rails security team has provided many easy to implement mitigation options. But, how do *know* you've really closed the vulnerability, particularly to the most automated and unskilled attacks? No better way than to try and exploit yourself.

It's best to scan your unpatched site first so you can be certain the scan is working as expected and you don't end up with a false positive that you've eliminated the vulnerability. Here is the quick and dirty introduction to running Metasploit, and executing a scan:

UPDATE: I've changed the Metasploit instructions here a bit to include setting the VHOST option. Teammate Steph Skardal was using these instructions and together we found that without a VHOST set, the RHOSTS are resolved to an IP address. It's worth checking your Rails logs to verify a request is being received and processed. If you don't see anything there, check your nginx or Apache (or whatever) access logs for any possible 301 redirects.

git clone git://github.com/rapid7/metasploit-framework.git
cd metasploit-framework
./msfconsole
use auxiliary/scanner/http/rails_xml_yaml_scanner
set RHOSTS mycompany.com
set VHOST app.mycompany.com
set RPORT 80
set URIPATH /rails_app
set VERBOSE true
show options
run
[+] mycompany.com:80 is likely vulnerable due to a 500 reply for invalid YAML
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

If you don't get back a "likely vulnerable" message, it's probably because you're still running Ruby 1.8.7. As of this writing the metasploit module exploit states:

The technique used by this module requires the target to be running a fairly version of Ruby 1.9 (since 2011 or so). Applications using Ruby 1.8 may still be exploitable using the init_with() method, but this has not been demonstrated.

It's only a matter of time before Ruby 1.8 becomes supported, but this does give some folks a bit more time. Now let's review the mitgation strategies provided by the announcement to show you just how easy it can be to secure yourself.

Disabling XML Entirely

The nature of the vulnerability is in parsing XML in request parameters. If you don't parse XML, you should disable XML parsing entirely by placing one of the following snippets inside an application initializer.

# Rails 3.2, 3.1 and 3.0 
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) 
# Rails 2.3 
ActionController::Base.param_parsers.delete(Mime::XML) 

Removing YAML and Symbol support from the XML parser

I couldn't say it better than Aaron than myself, so I'll give it to you straight from the announcement:

If your application must continue to parse XML you must disable the YAML and Symbol type conversion from the Rails XML parser. You should place one of the following code snippets in an application initializer to ensure your application isn't vulnerable. You should also consider greatly reducing the value of REXML::Document.entity_expansion_limit to limit the risk of entity explosion attacks.
The entity_expansion_limit recommendation is not strictly part of CVE-2013-0156, but should be implemented as well to limit your exposure to entity explosion attacks.

To disable the YAML and Symbol type conversions for the Rails XML parser add these lines to an initializer:

#Rails 3.2, 3.1, 3.0 
ActiveSupport::XmlMini::PARSING.delete("symbol") 
ActiveSupport::XmlMini::PARSING.delete("yaml") 

#Rails 2.3 
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol') 
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml') 

Removing YAML Parameter Parsing

While it's *much* less common to parse YAML in request params than XML, Rails does support this, but not by default (except in version 1.1.0!). There is no fix for YAML params injection, so it must be disabled . The methods for doing this differ in Rails among rails versions.

# Rails 2.x: find and remove all instances
ActionController::Base.param_parsers[Mime::YAML] = :yaml

# Rails 3.x: add to initializer
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::YAML)

# Rails 3.2, 3.1, 3.0: add to initializer
ActiveSupport::XmlMini::PARSING.delete("symbol")
ActiveSupport::XmlMini::PARSING.delete("yaml")

# Rails 2.3: add to initializer
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol')
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml')

Go Check your Site!

As you can see, with just a few lines of code, any site can manage their exposure to this risk. I strongly urge you to read the security announcement and avoid the hype. Then go patch your site!

6 comments:

Jon Jensen said...

Thanks for getting this PSA out so quickly, Brian. It's nice that you made it so easy for someone to confirm likely vulnerability before making changes.

Ed Ruder said...

Do you mean to suggest that you *remove* the line that *deletes* the YAML parser?

Brian Buchalter said...

@Ed,

Rails supports parsing YAML and Symbol types in XML parameters by default. If you cannot upgrade Rails, patch, or disable XML, it is best to disable the YAML and Symbol type conversions for the Rails XML parser by *adding* lines referenced in the "Removing YAML and Symbol support from the XML parser" section.

Rails also can parse YAML parameters, but it is not enabled by default. Scan your code for the lines in "YAML Parameter Parsing" section and *remove* them.

Hope this clears up any confusion. It's worth reading the original announcement a few times; I know it wasn't immediately clear to me either, but fortunately, the remedies are truly easy to implement.

cw said...

@Brian - Thanks for this write up, it was helpful to see how to use metasploit to test to confirm vulnerability and that the patch had removed vulnerability.

However, I am with @Ed on fixing the YAML vulnerability. You want to *add* this line, not remove it as your instructions state:

ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::YAML)

The line you want to search for to make sure you didn't turn on YAML parsing is:

ActionController::Base.param_parsers[Mime::YAML] = :yaml

If you do have this option set, you want to *remove* this line.

Source: Aaron Patterson's CVE post (https://groups.google.com/forum/#!msg/rubyonrails-security/61bkgvnSGTQ/nehwjA8tQ8EJ)

Brian Buchalter said...

@Ed, @cw you're right! I misunderstood Ed's original comment. Thank you for diligently reading the original announcement and helping improve the PSA.

natnebuer said...

Thank you so much for providing a guide on how to test the patch. =)

I have spent at least half a day figuring how to patch ( since its my first time patching ) and also to make sure that I am actually doing the right thing.