Recent breach at Blockchain.info -- Android App did a stupid.

[Grand_Voyageur]

=snip=
The result was that all of those clients generated the private key corresponding to 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F and sent bitcoins to it.

And somebody who noticed a whole lot of coins accumulating at "his" address, spent them. 
=snip=

This "someone" really got a winning lottery ticket. 34+BTC are really some nice bucks.

I suspect there are several such someones and they must basically be in a race to see who can spend first when money appears in their address.

So, if all were racing to scam others...we can even say no one got scammed.  
Quite a mess...I could never trust a lone satoshi to Blockchain.info after such performance. They totally FUBAR their business.

[Cryddit]

After digging some more and understanding what actually went wrong (and discovering some of the decisions that led to the failure along the way)  I've updated the article at

http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

This "Cybernetic Entomology" series of articles is about breaking down bugs and showing how they came about - and after analysis, giving some basic observations about how not to get bitten by the same bad decisions that led to those bugs. 

[altcoinex]

Perhaps in their need for an android developer they hired an experienced mobile developer but one who did not come from a sufficient security background nor have proper experience with cryptography or bitcoin(and perhaps absent a bit of common sense in relation). Capable of producing the application but not able to provide the necessary security considerations.  I always assumed they would have their security team approving any code that's rolled out though -- and would imagine at least a few of their staff to be in the role of security analyst. I wonder how differently things ran security procedure wise when Andreas was with them.

[tspacepilot]

Stay away from GreenAddress too- I've been using them and when I really needed access to my funds their wallet was unavailable for hours (I had a 2-of-2 multisig setup, should've used a 2-of-3)

I don't know if there's a mobile I can recommend at the moment, maybe I'll go for a commercial wallet

If you need a mobile wallet, why not use Andreas Schildbach's Bitcoin Wallet for Android.  I've been using it for years and never had a problem.  You're responsible for your own private keys, no third parties.  Completely open source, you can download it from fdroid instead of the play store if you want to support FOSS on android.

[teddy5145]

This is ridiculous, maybe its time for us to move to another wallet 
Luckily i never use btc wallet on my phone, i only use my pc for opening my wallet 

[virtualx]

 http://www.theregister.co.uk/2015/06/01/blockchain_app_shows_how_not_to_code/
  http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/
  http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

Short version of the story:  They were getting "Random" numbers over HTTP (WRONG!) from a third-party (WRONG!) to initialize a PRNG and generate keys (WRONG!).  

The third party - random.org in this case - discontinued its HTTP service because, well, random numbers over HTTP is WRONG!

But the clients Blockchain.info had deployed for Android didn't parse the response to see whether it was an error message; they just read the "301 service permanently moved" error message and treated it as a "random" number.(WRONG!)

This left all those Android clients initializing their key generators with the same not-very-random number.   And for some of them, where the sole other source that they attempted to use failed, that was the ONLY initialization.  

The result was that all of those clients generated the private key corresponding to 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F and sent bitcoins to it.

And somebody who noticed a whole lot of coins accumulating at "his" address, spent them.  

" There are more ways to get security wrong, Horatio, than dreamt of in your philosophy. "

I expected they would take security more serious. If this is serious it's just unbelievable. Random numbers over either HTTP or HTTPS is not a good idea.

Damn. This is ridiculous. Why did they need to call random.org ?

To get increased randomness.

Right, but that is patentenly ridiculous (imo).  If you have a device with a radio, a gyroscope, a wifi-antenna, a java-random-number generator (that was recently hardened for use with crypto) and then you decide to make a call to a website to get a random number, that seems nuts.

True. They could just do like Bither do.

What's even more nuts is that they weren't getting back a random number but an error page and somehow they weren't even looking at that.  It's pretty shocking.

The worst thing they were not using HTTP to make the webservice call to random.org. On Jan 4, random.org started enforcing HTTPS and returning a 301 Permanently Moved error for HTTP. So from that day onwards, the entropy has actually been the error message which turned into bytes instead of the expected 256-bit number. Using that seed, SecureRandom generated private key for 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F. When will they learn?

This is a beginner progamming bug. They shouldn't have made it especially when money is at stake. Do you not think it was one of the programmers who put it there on purpose?

[SebastianJu]

 http://www.theregister.co.uk/2015/06/01/blockchain_app_shows_how_not_to_code/
  http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/
  http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

Short version of the story:  They were getting "Random" numbers over HTTP (WRONG!) from a third-party (WRONG!) to initialize a PRNG and generate keys (WRONG!).  

The third party - random.org in this case - discontinued its HTTP service because, well, random numbers over HTTP is WRONG!

But the clients Blockchain.info had deployed for Android didn't parse the response to see whether it was an error message; they just read the "301 service permanently moved" error message and treated it as a "random" number.(WRONG!)

This left all those Android clients initializing their key generators with the same not-very-random number.   And for some of them, where the sole other source that they attempted to use failed, that was the ONLY initialization.  

The result was that all of those clients generated the private key corresponding to 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F and sent bitcoins to it.

And somebody who noticed a whole lot of coins accumulating at "his" address, spent them.  

" There are more ways to get security wrong, Horatio, than dreamt of in your philosophy. "

Ok, thats a real hefty story. Blockchain.info's wallets are seen as very secure since they exist since such a long time but this amount of amateurism is unbelieveable. Random number over http from a third party and then the message is not even parsed in any way. Thats simply only unbelieveable.

Never ever will i think about using a wallet from them. This things shows way too big problems.

Ok, one might think it could have been a third party coder. But even then, they are responsible, they handle the money from others and they showed a real high level of stupidity.

[ranochigo]

 http://www.theregister.co.uk/2015/06/01/blockchain_app_shows_how_not_to_code/
  http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/
  http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

Short version of the story:  They were getting "Random" numbers over HTTP (WRONG!) from a third-party (WRONG!) to initialize a PRNG and generate keys (WRONG!).  

The third party - random.org in this case - discontinued its HTTP service because, well, random numbers over HTTP is WRONG!

But the clients Blockchain.info had deployed for Android didn't parse the response to see whether it was an error message; they just read the "301 service permanently moved" error message and treated it as a "random" number.(WRONG!)

This left all those Android clients initializing their key generators with the same not-very-random number.   And for some of them, where the sole other source that they attempted to use failed, that was the ONLY initialization.  

The result was that all of those clients generated the private key corresponding to 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F and sent bitcoins to it.

And somebody who noticed a whole lot of coins accumulating at "his" address, spent them.  

" There are more ways to get security wrong, Horatio, than dreamt of in your philosophy. "

Ok, thats a real hefty story. Blockchain.info's wallets are seen as very secure since they exist since such a long time but this amount of amateurism is unbelieveable. Random number over http from a third party and then the message is not even parsed in any way. Thats simply only unbelieveable.

Never ever will i think about using a wallet from them. This things shows way too big problems.

Ok, one might think it could have been a third party coder. But even then, they are responsible, they handle the money from others and they showed a real high level of stupidity.

Blockchain.info has a good amount of security breaches since it started. Most of them are due to the developer's negligence and not ensuring the methods used are foolproof. If a person judges the trust based on the age of the product, it would be totally wrong. Even though it is opensourced, the track record should show their efforts put in to secure the customer's funds.

If they used random.org as a process for generating their RNG, they could ask the site to give them updates on the changes made or at least, monitor and debug their software regularly. [Bug existed for more than 5 months]

[Mitchell]

They should fire their android developer(s)  and anyone that was in anyway involved with it. Jesus Christ, this is one serious and ridiculous fuck up.

[SebastianJu]

Blockchain.info has a good amount of security breaches since it started. Most of them are due to the developer's negligence and not ensuring the methods used are foolproof. If a person judges the trust based on the age of the product, it would be totally wrong. Even though it is opensourced, the track record should show their efforts put in to secure the customer's funds.

If they used random.org as a process for generating their RNG, they could ask the site to give them updates on the changes made or at least, monitor and debug their software regularly. [Bug existed for more than 5 months]

I didnt suggest blockchain.info to anyone though that wallet was the wallet that was suggested when someone asked for a online wallet. Its not a wonder when all online wallets left and right got "hacked" and otherwise vanish. I remember things like ultrasecure wallets, best security and all and... hacked. So people tend to suggest blockchain.info because they still were there and they thought they would have fixed problems over time.

I mean lets say you want to bring bitcoins near to someone. You cant make him download something if you arent there, its easier to give him the login to a wallet and thats it. Giving bitcoins to a noob would mean risks anyway. No backup, no antivirus and so on.

Too bad. I didnt know that its SOO bad.

[Fabrizio89]

Those are some pretty big fuck ups, I won't trust blockchain.info anymore not even for just transfering something really temporarely.

[altcoinex]

They should fire their android developer(s)  and anyone that was in anyway involved with it. Jesus Christ, this is one serious and ridiculous fuck up.

It may be no co-incidence they have Mobile Developer openings in their Job listings page at the moment. ;]

[altcoinex]

Those are some pretty big fuck ups, I won't trust blockchain.info anymore not even for just transfering something really temporarely.

Every since Andreas left I considered them to no longer be secure... Not that they didn't have an incident or two while he was present.

[Mitchell]

It may be no co-incidence they have Mobile Developer openings in their Job listings page at the moment. ;]

I just checked and you they are indeed hiring a Mobile Developer. I would apply, but I only know Android, so I don't have the required qualifications.

[Cryddit]

One way of looking at this is that these fuckups are going to be made - and hopefully learned from - by people along the way.

With $27 million of money from vulture capitalists, bc.i will likely survive more "opportunities to learn" than most companies can afford.  

They may achieve security before their money runs out. Which, I guess, would put them ahead of the short-lived competition we've seen so far.

As part of my 'Cybernetic Entomology' posts I researched how and why this bug actually happened.

They derived a class with a 'SetSeed' method that _mixed_ input with the RNG state from a native class with a 'SetSeed' method that _replaced_ the RNG state with input.  But on low-memory Android devices that class didn't get registered.  Instead of failing because an important component did not load, they called the 'SetSeed' method of its parent class.

So, the procedure for initializing the RNG --->

whatever its current state is, use SetSeed() to mix it with bits from /dev/urandom (good)
make it "Better" by using SetSeed() to mix with bits from random.org (stupid but probably harmless)

But when you wind up calling the parent class's SetSeed method, instead, this turns into ---->

Replace current state using 'SetSeed' with bits from /dev/urandom (suboptimal but acceptable, except for what they do next)
make it "Better" by replacing that (acceptable) state using 'SetSeed' with bits from random.org (WRONG!)

[dogie]

Almost every excel formula I code contains, the following and that's for mundane stuff. You would have thought their due diligence would have increased for code transmitting $Ms a year.

=iferror(*code*,"YO DUDE YOU FUCKED UP, GO BACK")

[TierNolan]

They derived a class with a 'SetSeed' method that _mixed_ input with the RNG state from a native class with a 'SetSeed' method that _replaced_ the RNG state with input.

If the first thing you do with a SecureRandom object is call setSeed(...), then it is assumed you are providing a proper seed.  

This means that it skips the automatic self seeding as unnecessary.

From the docs.

Code:

If a call to setSeed had not occurred previously, the first call to this method [.nextBytes(...)] forces this SecureRandom object to seed itself. This self-seeding will not occur if setSeed was previously called.

The recommended way to create a SecureRandom object is to call .nextBytes(new byte[1]) right after creating the object.  This will force it to self seed (from OS randomness), since it hasn't been seeded yet.

[subSTRATA]

i remember reading about this issue somewhere, the numbers used were pseudorandom, and lots of people were complaining about it as a result, takes a whole different level of poor planning and testing to achieve something as faulty as that.

[tspacepilot]

I just know about this story, luckily i only use their android app to check my balance
I think i should remove this stupid application from my phone

Blockchain.info should remove / update their app very soon

Has it not been updated since this has been reported (basically everwhere!)?  That's almost more shocking than the original fuckup itself!

[ranochigo]

I just know about this story, luckily i only use their android app to check my balance
I think i should remove this stupid application from my phone

Blockchain.info should remove / update their app very soon

Has it not been updated since this has been reported (basically everwhere!)?  That's almost more shocking than the original fuckup itself!

The app is updated. https://play.google.com/store/apps/details?id=piuk.blockchain.android&hl=en.

Updated
May 28, 2015

I tried it out myself too. It now generates a different address everytime if you are using the latest version.