Use Metasploit to Verify Rails is Secured from CVE-2013-0156
By Brian Buchalter
January 10, 2013
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!
Comments