Earlier today the Internet Storm Center (ISC) reported, “A SQL Injection Flaw (CVE-2012-5664) was announced last week (Jan 2) in Ruby on Rails, but I think we missed reporting on it...” It added, “However, the hype and hoopla that any site with RoR code on it is vulnerable is just that - the vulnerability being discussed is very specific in nature, but folks hear ‘sql injection’ and (mistakenly as far as I can see) send it to the headline page.”
The irony is that as ISC posted this less-than-urgent warning, Ruby on Rails (RoR) was posting a new one: “There are multiple weaknesses in the parameter parsing code for Ruby on Rails which allows attackers to bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack on a Rails application.” And this one, says HD Moore, Rapid7's CSO and chief architect of Metasploit, is “particularly scary.”
Moore’s immediate reaction was not to develop an exploit and add it to Metasploit; but, he says, since Metasploit itself is developed in Ruby, “We marshaled the troops and released a security update for Metasploit users (2013010901), updated all of our own RoR applications with the workaround, and started digging into the vulnerability itself.”
The RoR advisory warns that, “The parameter parsing code of Ruby on Rails allows applications to automatically cast values from strings to certain data types. Unfortunately the type casting code supported certain conversions which were not suitable for performing on user-provided data including creating Symbols and parsing YAML. These unsuitable conversions can be used by an attacker to compromise a Rails application.”
Researcher Ben Murphy, who says he has undisclosed PoCs, claims “An attacker can execute any ruby code he wants including system("unix command"). This effects any rails version for the last 6 years.” Moore adds, “If this pans out, this would put thousands of production web sites at risk of remote compromise.”
He believes that “The mechanics of this bug allow for at least three different paths for exploitation.” These include triggering a SQL injection flaw; allocating an arbitrary Ruby object to be able to set any instance variables; and instantiating an arbitrary Ruby object to be able to call the "[]=" method with any desired parameters (opening “additional avenues for attack”).
Metasploit has, according to Moore, protected itself. Now it is the turn for all other users to worry: “Stay tuned for more information on this flaw and more than likely a Metasploit module or two in the coming days.”