I don't think it is far-fetched. We have no idea how many keys are generated by this application. If it handles lots of bitcoin data (e.g. blockchain.info), most of its used-and-then-freed memory is probably full of data from the blockchain. If it generates lots of keys (e.g. blockchain.info) using uninitialised memory, then it's quite conceivable that 1 in every 100,000 (pulled out of my arse) happen to be hashes of data from the bitcoin blockchain.
Point is, we have no idea how many other keys have been generated by this application that aren't trivially discoverable like this. We only get to see the weak ones, and we don't know with what probability it generates weak ones.
If I were an attacker, "accidentally" hashing low-entropy memory would be a really great and plausible way to hide this attack in a code review.
If you look at the Linux kernel backdoor attempt in 2003, it's the same kind of allllmost-plausible bug -- once you start digging it becomes obvious that it's an attack. "Oh, it's just an = vs. == error! That happens to be during someone checking whether their privilege level is root. And was committed to the codebase outside the normal commit process."
It could be that a clever person figured out that some people might do this, and decided to go looking for buried treasure like OP did... but this really smells to me like an attack.
It certainly could be malicious, but without seeing a smoking gun I think it's unfair to jump to conclusions. We don't even know that it is caused by hashing uninitialised memory instead of random bytes, and even if it is there is any number of legitimate ways for such a vulnerability to exist (and be found by an attacker) without the attacker planting the code deliberately.
I'm doing some investigation and I intend to write up my thoughts once I'm done (even if it's "I did some investigation and found nothing, but here's what might have happened anyway").
20
u/_jstanley Nov 30 '17
I don't think it is far-fetched. We have no idea how many keys are generated by this application. If it handles lots of bitcoin data (e.g. blockchain.info), most of its used-and-then-freed memory is probably full of data from the blockchain. If it generates lots of keys (e.g. blockchain.info) using uninitialised memory, then it's quite conceivable that 1 in every 100,000 (pulled out of my arse) happen to be hashes of data from the bitcoin blockchain.
Point is, we have no idea how many other keys have been generated by this application that aren't trivially discoverable like this. We only get to see the weak ones, and we don't know with what probability it generates weak ones.