{"id":49943,"date":"2023-11-29T05:00:18","date_gmt":"2023-11-29T10:00:18","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=49943"},"modified":"2023-11-29T05:00:18","modified_gmt":"2023-11-29T10:00:18","slug":"vulnerability-in-hot-cryptowallets-from-2011-2015","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/vulnerability-in-hot-cryptowallets-from-2011-2015\/49943\/","title":{"rendered":"Randstorm: vulnerable crypto wallets from the 2010s"},"content":{"rendered":"

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.<\/p>\n

Randstorm vulnerabilities and consequences<\/h2>\n

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

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 \u2014 in the sense that it\u2019s far easier to find their private keys than the underlying Bitcoin cryptography assumes.<\/p>\n

The researchers estimate that several million wallets, totaling around 1.4 million BTC, are potentially at risk due to Randstorm. Among the potentially vulnerable<\/em> wallets, according to the researchers, 3\u20135% of them are actually vulnerable<\/em> 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.<\/p>\n

The researchers claim that the Randstorm vulnerabilities can indeed be used for real-world attacks on crypto wallets. What\u2019s 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\u2019t 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.<\/p>\n

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.<\/p>\n

The nature of Randstorm vulnerabilities<\/h2>\n

Let\u2019s 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.<\/p>\n

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.<\/p>\n

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

Now back to the BitcoinJS library. To obtain \u201chigh-quality\u201d pseudo-random numbers, this library uses another JavaScript library called JSBN (JavaScript Big Number), specifically its SecureRandom<\/em> 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<\/em> relies on the browser function window.crypto.random<\/em>.<\/p>\n

Therein lies the problem: although the window.crypto.random<\/em> 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 \u2014 Internet Explorer, Google Chrome, Mozilla Firefox, and Apple Safari \u2014 the window.crypto.random <\/em>function was simply not implemented.<\/p>\n

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<\/em> 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<\/em>.<\/p>\n

This is bad in and of itself because Math.random<\/em> is not cut out<\/a> for cryptographic purposes. But the situation is made even worse by the fact that the Math.random<\/em> implementation in the popular browsers of 2011\u20132015 \u2014 \u00a0in particular Google Chrome<\/a> \u2014 contained bugs that resulted in even less random numbers than should have been the case.<\/p>\n

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\u2019re much easier to brute-force \u2014 allowing vulnerable crypto wallets to be hijacked.<\/p>\n

As mentioned above, this isn\u2019t a theoretical danger, but rather a practical one \u2014 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.<\/p>\n

Randstorm: who\u2019s at risk?<\/h2>\n

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 <\/em>in popular browsers, by 2016 they\u2019d been fixed by changing the algorithms for generating pseudo-random numbers. Together, this gives an approximate time frame of 2011\u20132015 for when the potentially vulnerable crypto wallets were created.<\/p>\n

The researchers emphasize that BitcoinJS was very popular back in the early 2010s, so it\u2019s 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:<\/p>\n