Topic: To All Rails Developers: SQL Injection Flaw Haunts All Ruby on Rails Versions (Read 3466 times)

Bumping with another rails vulnerability announced today: http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-mass-assignment-and-sql-injection

The first reported compromise of a production system was in an industry which hit the trifecta of amateurs-at-the-helm, seedy-industry-by-nature, and under-constant-attack.

Another exploit: CVE-2013-0333

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0333

lib/active_support/json/backends/yaml.rb in Ruby on Rails 2.3.x before 2.3.16 and 3.0.x before 3.0.20 does not properly convert JSON data to YAML data for processing by a YAML parser, which allows remote attackers to execute arbitrary code, conduct SQL injection attacks, or bypass authentication via crafted data that triggers unsafe decoding, a different vulnerability than CVE-2013-0156.

Known Ruby exchanges:  bitcoin-central.net, vircurex?, coinbase

Sir, rails is not a language. It is a framework.

Rails seems to be a popular development language for bitcoin.

It's also possible to run arbitrary Ruby (and thus commands) on the server, take a look at the metasploit module, thanks to the YAML integration.

It's really very serious and leads to complete compromise. It makes me wonder how long blackhats have known about that.

how many different vulnerabilities is the article actually talking about?

find_by_* finders are fine. Also you're mixing up the two vulnerabilities.

What are you even talking about here ?

"The Rails session mechanism allows storing arbitrary Ruby objects, including hashes with symbol keys. Rails provides a variety of session stores, the default being the cookie store which stores session data in a cookie on the client. The cookie data is not encrypted, but is signed with an HMAC [hash-based message authentication cookie] to prevent tampering. The cookie store is fast, does not require any server-side maintenance, and is only meant for session data that do not contain sensitive information such as credit card numbers. Apps that store sensitive information in the session should use the database session store instead. Nevertheless, it turned out that 95% of all Rails apps only ever store the user authentication credentials in the session, so the cookie store was made the default," Hongli Lai of Phusion wrote in an analysis of the problem.

"So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app."

It is my understanding that all unpatched rails apps are potentially vulnerable, regardless of their use of XML.  One of the suggested workarounds if XML parsing was not needed was to disable it in the config.  CVE-2013-0155 is much more severe than the one in the OP (CVE-2012-5664).

Edit: Yep, serious business.

This one is CVE-2013-0155

Only applications that accept XML parameters are vulnerable

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.

Regardless, leaving the "secret key" in a public repo is just fail anyway.

What ?

Don't use deprecated methods!

Bumping with another critical vulnerability. Upgrade immediately!

https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ