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

[Cryddit]

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

[1715228655]

1715228655

[1715228655]

1715228655

[jbrnt]

If these stories were true, Blockchain.info has really messed up this time. I have the wallet on android (not 4.1). This could easily happen to me. Lucky I have never created new addresses on android, only send and receive on mobile from addresses created on web.

[achow101]

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

[Cryddit]

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.

[achow101]

This is really stupid of them. This is also why I don't trust third parties, they usually screw something up. I personally use Bitcoin Wallet for Android by schildbach and I rarely keep any coins there.

Also, has Blockchain.info fixed the problem with their app yet? If they haven't then a malicious user could try to generate that address and steal Bitcoins.

[Melbustus]

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.

Yeah. That was my reaction too. I code more defensively than that for free consumer web-apps that have nothing to do with money or sensitive data.

It's sad to see Blockchain blowing it like this. They raised $30M and have a team of 23. WTF have they been doing?!? Not only are they apparently 1) Not hiring the right people, 2) Not implementing any sort of code review over critical systems, 3) Not implementing any sort of reasonable testing procedures for a financial product...., but their overall product suite is essentially the same as it was >2 years ago when the entire company was basically just Ben.

I've been hugely disappointed in Blockchain over the past 1-2years.

[Muhammed Zakir]

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.

Unfortunately, people still use this wallet after many careless mistakes from Blockchain.info.


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

[Cryddit]

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

Done.  I'm still boggling over this.

[tspacepilot]

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

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.

[jl2012]

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

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.

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

[tspacepilot]

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

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.

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

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.

[achow101]

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.

I would not use their web wallet ever. They have had some fuck ups in the past. One I remember is an issue where they were using the same R or S (I don't remember which) values in the signatures of all transactions sent by them. This led to some user's Bitcoin's being stolen.

[RocketSingh]

Damn. This is ridiculous. Why did they need to call random.org ? Does not an android phone provide enough entropy ? I think, if phone location (lat, long) is used along with phone number, then better entropy can be created.

Does anyone know how blockchain.info generates the random number for an address while we create it through browser ? Do they call random.org there as well ?

[Muhammed Zakir]

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

To get increased randomness.

Does not an android phone provide enough entropy ?

-snip-

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.

 -snip-

I think, if phone location (lat, long) is used along with phone number, then better entropy can be created.

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.

Does anyone know how blockchain.info generates the random number for an address while we create it through browser ? Do they call random.org there as well ?

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

[tspacepilot]

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

[Muhammed Zakir]

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?

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

[jbrnt]

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.

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.

[tspacepilot]

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

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.

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're just trying to set away some coins for a future date, just generate a secure keypair and print it out.  You don't need computer hardware in order to keep a number safe (just my opinion).

[jl2012]

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.

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.

HW wallets are not mature and may not be as secure as you think: https://bitcointalk.org/index.php?topic=1022815.0;topicseen

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

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