Bitcoin Forum
July 22, 2019, 09:43:28 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: To All Rails Developers: SQL Injection Flaw Haunts All Ruby on Rails Versions  (Read 3359 times)
jimbobway
Legendary
*
Offline Offline

Activity: 1405
Merit: 1008



View Profile
January 03, 2013, 06:44:26 PM
 #1

Rails seems to be a popular development language for bitcoin.  I think I've been hearing some sql injection attacks lately on some bitcoin websites but here is a story on it.  (I've been accused of being a troll here for talking negatively on rails before):

Quote
All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fixes the flaw, versions 3.2.10, 3.1.9 and 3.0.18.

https://threatpost.com/en_us/blogs/sql-injection-flaw-haunts-all-ruby-rails-versions-010313

Mod: Move this to Project Development.  I put it in the wrong forum.
1563831808
Hero Member
*
Offline Offline

Posts: 1563831808

View Profile Personal Message (Offline)

Ignore
1563831808
Reply with quote  #2

1563831808
Report to moderator
1563831808
Hero Member
*
Offline Offline

Posts: 1563831808

View Profile Personal Message (Offline)

Ignore
1563831808
Reply with quote  #2

1563831808
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563831808
Hero Member
*
Offline Offline

Posts: 1563831808

View Profile Personal Message (Offline)

Ignore
1563831808
Reply with quote  #2

1563831808
Report to moderator
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 03, 2013, 07:19:01 PM
 #2

CVE-2012-5664 for the record

dust
Hero Member
*****
Offline Offline

Activity: 840
Merit: 1000



View Profile WWW
January 09, 2013, 01:08:57 AM
 #3

Bumping with another critical vulnerability. Upgrade immediately!

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

Cryptocoin Mining Info | OTC | PGP | Twitter | freenode: dust-otc | BTC: 1F6fV4U2xnpAuKtmQD6BWpK3EuRosKzF8U
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 09, 2013, 09:52:34 AM
 #4

Bumping with another critical vulnerability. Upgrade immediately!

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

This one is CVE-2013-0155

Only applications that accept XML parameters are vulnerable

notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001


View Profile
January 09, 2013, 09:58:24 AM
 #5

Don't use deprecated methods!

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 09, 2013, 10:01:07 AM
 #6

Don't use deprecated methods!
What ?

notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001


View Profile
January 09, 2013, 10:08:39 AM
 #7

Don't use deprecated methods!
What ?

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.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 09, 2013, 10:24:40 AM
 #8

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.
find_by_* finders are fine. Also you're mixing up the two vulnerabilities.

Regardless, leaving the "secret key" in a public repo is just fail anyway.
What are you even talking about here ?

notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001


View Profile
January 09, 2013, 01:19:02 PM
 #9

I mean the find_by vulnerability is only exploitable if you know the HMAC key for the application that should be kept secret.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
dust
Hero Member
*****
Offline Offline

Activity: 840
Merit: 1000



View Profile WWW
January 10, 2013, 03:38:10 AM
Last edit: January 10, 2013, 06:54:13 AM by dust
 #10

Bumping with another critical vulnerability. Upgrade immediately!

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

This one is CVE-2013-0155

Only applications that accept XML parameters are vulnerable
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.

Cryptocoin Mining Info | OTC | PGP | Twitter | freenode: dust-otc | BTC: 1F6fV4U2xnpAuKtmQD6BWpK3EuRosKzF8U
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 10, 2013, 09:02:52 AM
 #11

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.
Yea, pretty much all Rails apps will accept XML params by default.
Both seem quite severe and I think everyone using Rails should just religiously apply the fixes (which are trivial btw)

Apparently I made it sound like I didn't feel concerned about it, but that's not the case, Instawallet, Instawire and Bitcoin-Central were immediately patched when I received Aaron Patterson's e-mails through the Rails security mailing list (which I encourage every Rails developer around here to subscribe to).

molecular
Donator
Legendary
*
Offline Offline

Activity: 2702
Merit: 1011



View Profile
January 10, 2013, 09:10:53 AM
 #12

Maybe they aren't officially deprecated, but the find_by_* methods are old the old style finders.
find_by_* finders are fine. Also you're mixing up the two vulnerabilities.

Regardless, leaving the "secret key" in a public repo is just fail anyway.
What are you even talking about here ?

Quote from: article
"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."

how many different vulnerabilities is the article actually talking about?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 10, 2013, 10:08:24 AM
 #13

how many different vulnerabilities is the article actually talking about?
If someone knows the HMAC secret and you're using cookie store someone can mess with the data in it, that's a feature.
The vulnerabillity is that it could be used as a vector to exploit an SQL injection vulnerability (didn't read the details, just religiously applied the fixes).

I recommend against using cookie store anyway and switch to Redis/Memcached/ActiveRecord for storing session data.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1008


View Profile
January 11, 2013, 03:50:05 PM
 #14

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.
BasementMiner!
Member
**
Offline Offline

Activity: 109
Merit: 10



View Profile
January 11, 2013, 11:46:52 PM
 #15

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.

While this vulnerability is just as serious, its not related to the one mentioned by OP.
kiba
Legendary
*
Offline Offline

Activity: 980
Merit: 1007


View Profile
January 11, 2013, 11:50:55 PM
 #16

Rails seems to be a popular development language for bitcoin.


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

jimbobway
Legendary
*
Offline Offline

Activity: 1405
Merit: 1008



View Profile
January 12, 2013, 03:56:31 AM
 #17

Rails seems to be a popular development language for bitcoin.


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

My mistake.  I keep on making it.
whizter
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500


View Profile
January 12, 2013, 09:58:55 PM
 #18

This exploit is already being used, bitoins were stolen from Vircurex and Cryptostocks according to http://www.heise.de/newsticker/meldung/Diebe-stehlen-Bitcoins-per-Rails-Exploit-1782688.html

        ███████████████████▄▄▄
        ████████████████████████▄▄
           ████████████████████████▄
    ▄▄▄▄▄▄▄██████████████████████████▄
    ███████████████       ▀▀███████████
        ███████               ██████████
        ███████                ██████████
████████   ████████             █████████
▀▀▀▀▀▀▀▀▄▄▄████████             █████████
        ███████████             █████████
    ████   ████████            ██████████
    ████   ████████           ██████████
        ███    ████       ▄▄███████████
    ▄▄▄▄███▄▄▄▄██████████████████████▀
    ███████████████████████████████▀
████    ████████████████████████▀▀
████    ███████████████████▀▀▀
DIMCOIN   
❱❱❱  facebook  ❱❱❱  twitter  ❱❱❱  Telegram  ❱❱❱
.The Future of Equity on The Blockchain.
jimbobway
Legendary
*
Offline Offline

Activity: 1405
Merit: 1008



View Profile
January 31, 2013, 07:09:20 PM
 #19

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
davout
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


1davout


View Profile WWW
January 31, 2013, 07:59:18 PM
 #20

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
FTR Rails 3.2.x series isn't affected.

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!