Ruby On Rails Under Attack

The bad news: A critical flaw affecting the Ruby on Rails Web application framework is being exploited in the wild. The good news: The vulnerability was patched in January. However, there are those out there who have apparently failed to apply the patch for CVE-2013-0156.

"It's not surprising in the slightest that many people have not patched the exposed vulnerability of Ruby on Rails," says Tod Beardsley, Metasploit engineering manager at Rapid7. "Rails has a generally good reputation and an infrequent security patch schedule; therefore, people aren't used to worrying over it like they might be with other software packages. Rails developers, in particular, are typically not IT operations people and are usually unconcerned with the security of Rails itself; they are typically Web application developers and may or may not pay attention to security mailing lists."

Reports of an exploit targeting the issue surfaced on discussion boards in recent days, and security researcher Jeff Jarmoc outlined how the exploit works. According to Jarmoc, the exploit adds a command to crontab and executes commands, downloading and executing a C source file from a remote server. The malware then connects to an IRC server, joins the #rails channel, and awaits commands. The command-and-control servers are all down.

"Functionality is limited, but includes the ability to download and execute files as commanded, as well as changing servers," Jarmoc blogged. "There's no authentication performed, so an enterprising individual could hijack these bots fairly easily by joining the IRC server and issuing the appropriate commands."

"In short, this is a pretty straightforward skiddy exploit of a vulnerability that has been publicly known, and warned about, for months," he wrote.

The vulnerability at the center of the attacks was discovered in the JSON code for Ruby on Rails 3.0 and 2.3, and can be exploited to allow attackers to bypass authentication, inject arbitrary SQL commands, execute arbitrary code, or cause a denial-of-service condition.

If the application owner cannot upgrade or patch, the application itself can be harden to prohibit XML parameters or prohibit the parameter conversions that caused the particular problem -- YAML and Symbol, explains Qualys CTO Wolfgang Kandek.

"We have seen a great adoption rate for Ruby on Rails, and unfortunately not all of its users keep a close eye on vulnerabilities for that software," he says. "Small companies without dedicated security teams and hobbyists are probably the biggest sinners here -- they are focused on programming an Internet-connected service or site, but are not really looking at all the underlying system administration tasks, such as keeping OS and the rest of the software stack updated."

Rails developers tend to lock in on certain "known good" versions of Rails and actively resist updating without significant testing effort, says Beardsley.

"This brings stability to the underlying Web application since changes to Rails may bring API changes along with it, which can break functionality," he explains. "However, it's a bad habit to have when it comes to security patches. Rails patches are publicized primarily through a dedicated Google Group. While this particular vulnerability announcement has netted 74,000 views so far, the typical post to this low-traffic group sees anywhere between 2,000 and 15,000 views."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.