A lingering security issue in Ruby on Rails that stems from a setting in the framework’s cookie-based storage mechanism is still present in almost 2,000 websites.
Sites using an old version of Ruby on Rails that relies on CookieStore, the framework’s default cookie storage mechanism, are at risk. CookieStore saves each user’s session hash in the cookie on the client side, something that keeps each cookie valid for life. This makes it possible for an attacker to glean a user’s log-in information – either via cross-side scripting or session sidejacking – and log in as them at a later date.
Security researcher G.S. McNamara, who detailed the initial vulnerability on his MaverickBlogging site in September recently spent four days scouring 90,000 sites, running specialized scripts and analyzing data from each domain. When all was said and done, he found 1,897 sites that use old versions of Ruby on Rails (version 2.0 to version 4.0) that do not encrypt its users’ cookie values.
Some of the sites even fail to use SSL after their log-in pages, meaning they are communicating each user’s permanent session cookie without encryption for anyone to sniff and steal.
Most of the websites McNamara found belong to small startup companies but some, such as crowdsourcing site Kickstarter.com, restaurant review site Urbanspoon.com, and the site that belongs to the motion picture studio Warner Brothers (WarnerBros.com) are affected by the vulnerability.
McNamara has reached out to a handful of the sites but with more than 1500 affected, it’s a lengthy list to go through. Kickstarter for example – one of the sites that doesn’t use SSL the entire time a user is logged in – is aware of the issue. Meanwhile sites such as Urbanspoon.com and 500px.com, an online photo community with more than 10 million monthly users, still have not responded to the researcher.
In addition to the sites, McNamara also found a handful of online tools and utilities, applications such as Redmine, Zendesk and Spiceworks that also store user session hashes on the client side. While the last two use SSL as an added layer of security, on Redmine, it’s up to the user to properly configure the software’s security.
While Ruby on Rails moved to encrypt cookies by default in version 4.0, it doesn’t change the fact that users’ information is still at risk. Just because users’ cookies are encrypted and therefore unreadable doesn’t make the cookies useless to an attacker.
“Version 4.0 and beyond still have this problem,” McNamara told Threatpost in an email. “The attacker could save the encrypted cookie and send it to the server to log in as the victim without having to read the contents of the cookie.”
“The encryption does not protect against reusing the cookie after logout,” McNamara warned, comparing an encrypted cookie to a black box that a hacker simply needs to plug into the correct hole to work.
The technical classification for this problem is defined by the Web Application Security Consortium as an Insufficient Session Expiration weakness, basically stating that on sites “the log-out function should… disallow reuse of the session token,” something these sites clearly don’t do.
McNamara points out that anyone looking to see if the Ruby on Rails site they’re visiting is using CookieStore just needs to look for the string “Bah7” at the beginning of the value of the cookies. He adds that a cursory search on SHODAN, the search engine that gained notoriety a few years ago for sniffing out unprotected SCADA devices, reveals 60,000+ vulnerable sites.
NcNamara’s list isn’t exhaustive. In this case it’s only limited to Rails sites, not sites run on Django, another web framework the D.C.-based researcher has also found cookie-centric vulnerabilities in as of late.
To fix the issue McNamara has previously advocated that Rails developers switch to a different cookie storage mechanism, one that stores session information on the server side of the database instead of the client side.
