Randstorm: vulnerable crypto wallets from the 2010s

Researchers have discovered several vulnerabilities in the BitcoinJS library that could leave Bitcoin wallets created online a decade ago prone to hacking. The basic issue is that the private keys for these crypto wallets were generated with far greater predictability than the library developers expected.

Randstorm vulnerabilities and consequences

Let’s start at the beginning. Researchers at Unciphered, a company specializing in crypto wallet access recovery, discovered and described a number of vulnerabilities in the BitcoinJS JavaScript library used by many online cryptocurrency platforms. Among these services are some very popular ones — in particular, Blockchain.info, now known as Blockchain.com. The researchers dubbed this set of vulnerabilities Randstorm.

Although the vulnerabilities in the BitcoinJS library itself were fixed back in 2014, the problem extends to the results of using this library: crypto wallets created with BitcoinJS in the early 2010s may be insecure — in the sense that it’s far easier to find their private keys than the underlying Bitcoin cryptography assumes.

The researchers estimate that several million wallets, totaling around 1.4 million BTC, are potentially at risk due to Randstorm. Among the potentially vulnerable wallets, according to the researchers, 3–5% of them are actually vulnerable to real attacks. Based on the approximate Bitcoin exchange rate of around $36,500 at the time of posting, this implies total loot of $1.5-2.5 billion for attackers who can successfully exploit Randstorm.

The researchers claim that the Randstorm vulnerabilities can indeed be used for real-world attacks on crypto wallets. What’s more, they successfully exploited these vulnerabilities to restore access to several crypto wallets created on Blockchain.info before March 2012. For ethical reasons, they didn’t publish a proof-of-concept of the attack, as this would have directly exposed tens of thousands of crypto wallets to the risk of theft.

The researchers have already contacted the online cryptocurrency services known to have used vulnerable versions of the BitcoinJS library. In turn, these services notified customers who could potentially be affected by Randstorm.

The nature of Randstorm vulnerabilities

Let’s look in more detail at how these vulnerabilities actually work. At the heart of Bitcoin wallet security lies the private key. Like any modern cryptographic system, Bitcoin relies on this key being secret and uncrackable. Again, as in any modern cryptographic system, this involves the use of very long random numbers.

And for the security of any data protected by the private key, it must be as random as can possibly be. If the number used as a key is highly predictable, it makes it easier and quicker for an attacker armed with information about the key-generation procedure to brute-force it.

Bear in mind that generating a truly random number is no stroll in the park. And computers by their very nature are extremely unsuited to the task since they’re too predictable. Therefore, what we usually have are pseudo-random numbers, and to increase the entropy of the generation (cryptographer-speak for the measure of unpredictability) we rely on special functions.

Now back to the BitcoinJS library. To obtain “high-quality” pseudo-random numbers, this library uses another JavaScript library called JSBN (JavaScript Big Number), specifically its SecureRandom function. As its name suggests, this function was designed to generate pseudo-random numbers that qualify for use in cryptography. To increase their entropy, SecureRandom relies on the browser function window.crypto.random.

Therein lies the problem: although the window.crypto.random function existed in the Netscape Navigator 4.x browser family, these browsers were already obsolete by the time web services began actively using the BitcoinJS library. And in the popular browsers of those days — Internet Explorer, Google Chrome, Mozilla Firefox, and Apple Safari — the window.crypto.random function was simply not implemented.

Unfortunately, the developers of the JSBN library failed to make provision for any kind of check or corresponding error message. As a result, the SecureRandom function passed over the entropy increment step in silence, effectively handing the task of creating private keys to the standard pseudo-random number generator, Math.random.

This is bad in and of itself because Math.random is not cut out for cryptographic purposes. But the situation is made even worse by the fact that the Math.random implementation in the popular browsers of 2011–2015 —  in particular Google Chrome — contained bugs that resulted in even less random numbers than should have been the case.

In turn, the BitcoinJS library inherited all the above-mentioned issues from JSBN. As a result, platforms that used it to generate private keys for crypto wallets got much fewer random numbers from the SecureRandom function than the library developers expected. And since these keys are generated with great predictability, they’re much easier to brute-force — allowing vulnerable crypto wallets to be hijacked.

As mentioned above, this isn’t a theoretical danger, but rather a practical one — the Unciphered team was able to exploit these vulnerabilities to restore access to (in other words, ethically hack) several old crypto wallets created on Blockchain.info.

Randstorm: who’s at risk?

BitcoinJS utilized the vulnerable JSBN library right from its introduction in 2011 through 2014. Note, however, that some cryptocurrency projects may have been using an older-than-latest version of the library for some time. As for the bugs afflicting Math.random in popular browsers, by 2016 they’d been fixed by changing the algorithms for generating pseudo-random numbers. Together, this gives an approximate time frame of 2011–2015 for when the potentially vulnerable crypto wallets were created.

The researchers emphasize that BitcoinJS was very popular back in the early 2010s, so it’s difficult to compile a full list of services that could have used a vulnerable version of it. Their report gives a list of platforms they were able to identify as at risk:

• BitAddress — still operational.
• BitCore (BitPay) — still operational.
• Bitgo — still operational.
• info — still operational as Blockchain.com.
• Blocktrail — redirects to https://btc.com or https://blockchair.com .
• BrainWallet — dead.
• CoinKite — now sells hardware wallets.
• CoinPunk — dead.
• Dark Wallet — redirects to https://crypto-engine.org .
• DecentralBank — dead.
• info (Block.io) — still operational.
• EI8HT — dead.
• GreenAddress — redirects to https://blockstream.com/green/ .
• QuickCon — dead.
• Robocoin — dead.
• Skyhook ATM — redirects to https://yuan-pay-group.net .

Besides Bitcoin wallets, Litecoin, Zcash, and Dogecoin wallets may also be at risk, since there are BitcoinJS-based libraries for these cryptocurrencies, too. It seems natural to assume that these libraries could be used to generate private keys for the respective crypto wallets.

The Unciphered report describes a host of other intricacies associated with Randstorm. But what it all basically boils down to is that wallets created between 2011 and 2015 using the vulnerable library may be vulnerable to varying degrees — depending on the particular circumstances.

How to protect against Randstorm

As the researchers themselves rightly state, this isn’t a case where fixing the vulnerability in the software would suffice: “patching” wallet owners’ private keys and replacing them with secure ones just isn’t doable. So, despite the fact that the bugs have long been fixed, they continue to affect the crypto wallets that were created when the above-discussed errors plagued the BitcoinJS library. This means that vulnerable wallet owners themselves need to take protective measures.

Because the task of drawing up a complete list of cryptocurrency platforms that used the vulnerable library is difficult, it’s better to play it safe and consider any crypto wallet created online between 2011 and 2015 to be potentially insecure (unless you know for sure that it’s not). And naturally, the fatter the wallet — the more tempting it is to criminals.

The obvious (and only) solution to the problem is to create new crypto wallets and move all funds from potentially vulnerable wallets to them.

And since you have to do this anyway, it makes sense to proceed with the utmost caution this time. Crypto protection is a multi-step process, for which reason we’ve put together a comprehensive checklist for you with loads of additional information accessible through links:

1. Explore the main crypto threats and protection methods in detail.
2. Understand the differences between hot and cold crypto wallets, and the most common ways they are attacked.
3. Use a hardware (cold) wallet for long-term storage of core crypto assets, and a hot wallet with minimal funds for day-to-day transactions.
4. Before transferring all funds from the old wallet to the new one, equip all your devices with reliable protection. It will guard your smartphone or computer against Trojans looking to steal passwords and private keys or clippers that substitute crypto wallet addresses in the clipboard, as well as protect your computer from malicious crypto miners and unauthorized remote access.
5. Never store a photo or screenshot of your seed phrase on your smartphone, never post your seed phrase in public clouds, never send it through messengers or email, and don’t enter it anywhere except when recovering a lost private key.
6. Securely store your private key and the seed phrase for its recovery. This can be done using the Identity Protection Wallet in Kaspersky Premium, which encrypts all stored data using AES-256. The password for it is stored nowhere except in your head (unless, of course, it’s on a sticky note attached to your monitor) and is unrecoverable — so the only one with access to your personal documents is you.
7. Another option is to use a cold crypto wallet that doesn’t require a seed phrase to back up the private key. This is how, for example, the Tangem hardware wallet works.