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

[Lorenzo]

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.

You're probably thinking of an earlier issue with Android wallets that happened a couple of years ago. It turned out that Android's pseudorandom number generation was flawed, which impacted mobile wallets that used it as a source of randomness for generating private keys. I know Mycelium was one of the wallets which were affected.

EDIT: Found a page (link) with more info:

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.

Although both incidents involved users losing funds due to flawed random number generators, the most recent issues with Blockchain.info's mobile wallet were an altogether separate thing. The incident that you're thinking of was pretty much the fault of Google whereas this one was caused by very poor programming choices made by Blockchain.info.

[Cryddit]

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.  

[tspacepilot]

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.

[Cryddit]

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.

[Lorenzo]

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. 

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.

From reading another article, I got the impression that they did in fact try to get entropy from two sources (the phone itself and Random.org). It's only that in some cases, the app failed to use both sources and only used Random.org for whatever reason and that was the cause of the problem.

I'll see if I can dig up the article somewhere...

EDIT: Found 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.

Link: http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/

So not only did they fail to catch the fact that Random.org was returning an error message, but they also failed to catch the fact that they weren't using two sources of entropy. Had just one of those issues been fixed, it's likely this problem wouldn't have existed at all.

[Cryddit]

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.

[chronicsky]

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

[Lorenzo]

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.

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.

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

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

[tspacepilot]

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.

Sure, programming can be difficult and takes concentration, I don't disagree.  But if you want to use HTTP, you may as well learn the return code for "success" and check for it.  That's not too difficult to do and there's a big difference between writing one-off programs for a class when you're sleepy and deploying a commerical scale app that's meant to manage other people's money!

[ranochigo]

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

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

It affected everyone who ran android 4.1 and below. Based on the number of transactions, 227 as of now, it isn't that small. AFAIK, only if you generate an address on the wallet, you will be affected.

[favdesu]

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.

and this is the reason why I moved my pocket coins. (to ninki)

[scat]

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.

[chronicsky]

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.

Nope! same here

Edit: all good and back up now

[tspacepilot]

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.

I got that just a few minutes ago.  Just double-checked and I'm still getting it.  The home page is fine and looking up addys are fine but looking up a transaction and I'm getting this funny reply.  But, to be clear, I'm not using the android app, this is via a web-browser on my laptop.

[scat]

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.

Nope! same here

Edit: all good and back up now

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

[tspacepilot]

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.

Nope! same here

Edit: all good and back up now

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

I'm pretty sure that the issue with BCI at the moment is related to the stress test going on (and being discussed here: https://bitcointalk.org/index.php?topic=1094865.0).  I'm waiting on a transaction to confirm for like going on 3.5 hours now.  I wish I had known about the test.  Anyway, I'm not saying that BCI doesn't have it's issues, but I think they can't really be faulted for the current state of affairs.

[bitnanigans]

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

If you're looking for an alternative Android app, you can try the Bitdash Wallet for Android which we built last year.