Topic: Recent breach at Blockchain.info -- Android App did a stupid. (Read 4938 times)

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

I thought the error was only in my android app,
Its error too checking over my pc.
Sometimes its woking well but sometimes i got that error code again, what happened damn..... its annoyed.
Too many trouble lately on blockchain.info

Nope! same here

Edit: all good and back up now

Am i the only that got this error code during today
"Maximum concurrent requests for this endpoint reached. Please try again shortly"
Its always said like that everytime i try to check any transaction.

Am i the only that got this error code during today
"Maximum concurrent requests for this endpoint reached. Please try again shortly"
Its always said like that everytime i try to check any transaction.

This required an UNBELIEVABLE level of ignorance or wilful stupidity to achieve. 

I mean, hell, the minute I hear "Random numbers over http" the deal is already broken.  HTTP is not private and has no message integrity.  Middleware intercepts and rewrites HTTP all the damn time.  Your message could be tampered anywhere along the way!

The http service shut down in January.  Blockchain noticed in June.  Wouldn't you think that if your security depends on a web service staying up, you'd at least write a script that would tell you within, say, 24 hours, if it went away?

What does it take to not notice the difference between '200 OK' and '301 Service Permanently Removed' responses?  Seriously!  How could you possibly write an app that wouldn't notice that!!

"PRNG initialized from only two sources" -- another deal-breaker.

And then, when it tries to read one of those sources and fails, it fails SILENTLY?  What the HELL?

I'm just ...  I can't.... wow.  I didn't think that level of ... whatever it is .... was even possible.

Apparently only a minority of users were affected, so it's likely that you would have been safe.

In a way, I suppose it's a good thing that this problem even happened. 34 BTC isn't a lot of money for a company like Blockchain.info and it certainly exposed quite a few serious technical issues with their programming practices which we didn't know about before.

EDIT: I'm taking programming courses at college right now, and I can totally see how I might accidentally mess up inheritance of methods for classes and subclasses in the same way Blockchain.info did especially when I'm not completely focused so I do have a bit of sympathy for them too.

Yah, they overrode SecureRandom with their own service.  But on platforms without enough memory their own service didn't get registered, and instead of detecting the error they wound up calling the parent class's method.

And this is important because their service, LinuxSecureRandom, initially uses state from /dev/urandom - same as the parent class but had a 'setSeed' method that mixed its input with the RNG state. 

The parent class, SecureRandom, is automatically initialized with bits from the native RNG if you DON'T initialize it - but if you call 'SetSeed' it uses your seed instead. 

So, yah, while not noticing the difference between '200 OK' and '301 service permanently moved' is awe-inspiring, so is failing to notice when their service overriding the native service failed to load. 

But geez, to list all the things that scream WAT here?  We'd have to add several more lines, including getting "random" numbers over HTTP in the first place, doing the initialization in an order that put the greatest reliance (ie, last update via 'setSeed' call) on the least secure source (ie, numbers retrieved over HTTP), and then .... Good grief.  It's a long list.

am happy that the blockchain mobile app (latest ver) i installed last week didn't synced with my web wallet.
There was so much to loose

An interesting point here is that the mistake which led to the most recent problem may have been (in fact probably was) an attempt to work around the previous problem. 

IE, they probably overrode SecureRandom and were getting numbers from random.org to mix with the output of the parent class, specifically BECAUSE of the earlier issue with SecureRandom. 

From what I've seen of this, the most crucial problem was not checking for success (ie status 200) on the HTTP response.  While in my opinion, it seems a little pointless to use an http connection to an external service to get entropy on a device that has a gyroscope/radio and several other natural noise sources (in addition to SecurRandom), it seems that if the had simply validated the response from random.org properly they would have caught this before it caused real problems.

I never said that it was the best method for working around the problem, nor did I say that it was implemented competently.

What I think it was, was a "quick fix" that they could get out the door in 24 hours when the problem with the Android RNG was discovered, which they probably planned to get back to and fix "for real" with error checking and probably an onboard source of bits and so on.... 

But such plans are hardly ever fulfilled.  Some security-ignorant beancounter goes, "We have a workaround?  Cool, now we need to work on this other thing instead."  And they never get back to it.

Additionally, in certain cases, the pseudorandom number generator in Blockchain for Android failed to access random data that was supposed to be mixed into the random bits downloaded from random.org. Instead of returning an error, the app simply used the 256-bit number provided by random.org as the sole input for generating private keys. That meant the random.org website was the sole supplier of entropy used in the generation process.

An interesting point here is that the mistake which led to the most recent problem may have been (in fact probably was) an attempt to work around the previous problem.  

IE, they probably overrode SecureRandom and were getting numbers from random.org to mix with the output of the parent class, specifically BECAUSE of the earlier issue with SecureRandom.  

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.

Last week Google announced a weakness in the Android platform that left users of certain BitCoin wallet applications at risk and potentially allowing the theft of funds.

Upon further examination, it emerged that the Android implementation of Java SecureRandom class contains a vulnerability that prevents the generation of secure random numbers to protect the wallet applications.

As a result, some signatures have been observed to possess colliding values that allow the private key (designed to protect the money in Bitcoin) to be revealed and money to be stolen.

The security issue is specific to the Android operating system and affects all Android applications that generate private keys on the user’s mobile device.

The random numbers generated turned out to be less random than expected and may be repeated and therefore are predictable.

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

Updated
May 28, 2015

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

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.

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

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

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.

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]

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.

 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. "

 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. "

True. They could just do like Bither do.


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?

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

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.

I have always used a blockchain.info wallet and was quite satisfied with it. Their sloppy coding is not giving me confidence to use them anymore. It's money at stake here and some users, quite unwisely, have their life savings in bitcoin stored on their wallets.

I have been postponing my purchase of a hardware wallet long enough. It is time to give it more thought.

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

I have always used a blockchain.info wallet and was quite satisfied with it. Their sloppy coding is not giving me confidence to use them anymore. It's money at stake here and some users, quite unwisely, have their life savings in bitcoin stored on their wallets.

I have been postponing my purchase of a hardware wallet long enough. It is time to give it more thought.

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.

=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=

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.

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.

To get increased randomness.

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

Does not an android phone provide enough entropy ?

Most users' doesn't allow GPS connection to apps like these and also some users' doesn't want to expose their phone number because of privacy concerns. They may give access to these if everything is stored/done locally but Blockchain.info is a web-wallet.


I think they only call random.org in Android for increased randomness.

Obviously reputable is a matter of interepretation.  But for me, the fact that they're probably the longest running web-wallet service not to be completely hacked and lose everything says something.  Also (and again, this may be just due to their longevity), I think they're the go-to block explorer for most people.  Kinda like google, they may not be the "best" search engine, that's a matter of debate, but many people equate search with google.  I believe that many people equate looking something up on the blockchain with looking it up on blockchain.info.

So, I guess I don't know a lot about their fuckups, and I don't use a web-wallet anyway (for security purposes), but yah, I had thought they were reputable.  Presumably, I don't know the whole story.

Reputable? In terms of their track record of fucking up?

Not just could, it does explain those threads.  @Cryddit, you're right, it's quite mind-boggling that a site as reputable as blockchain.info screwed this up so completely.

This would explain all of those threads about the 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F address which people were claiming that their bitcoins were stolen.

@OP: Could you please add '.info' after 'Blockchain' in the title?

I was in the middle of writing a breakdown of what went wrong, but you've beat me to it.

Basically, they have a LinuxSecureRandom class that's supposed to override the standard SecureRandom. This class reads from /dev/urandom and should provide cryptographically secure random values.

They also seed the generator using SecureRandom#setSeed with data pulled from random.org. With their custom SecureRandom, this is safe because it mixes the entropy using XOR, so even if the random.org data is dodgy it won't reduce security. It's just an added bonus.

BUT! On some devices under some circumstances, the LinuxSecureRandom class doesn't get registered. This is likely because /dev/urandom doesn't exist or can't be accessed for some reason. Instead of screaming bloody murder like any sensible implementation would, they just ignore that and fall back to using the standard SecureRandom.

If the above happens, there's a problem because the default implementation of SecureRandom#setSeed doesn't mix. If you set the seed, it replaces the entropy entirely. So now the entropy is coming solely from random.org.
And the final mistake: They were using HTTP instead of HTTPS 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 - see https://www.random.org/news/. So since that date, the entropy has actually been the error message (turned into bytes) instead of the expected 256-bit number. Using that seed, SecureRandom will generate the private key for address 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F 100% of the time. Ouch. This is around the time that address first appears, so the timeline matches.

I haven't had a thorough look at what they've replaced it with in the latest version, but initial impressions are that it's not ideal. Not disastrous, but not good.

This required an UNBELIEVABLE level of ignorance or wilful stupidity to achieve. 
...
I'm just ...  I can't.... wow.  I didn't think that level of ... whatever it is .... was even possible.