Randstorm Exploit: Bitcoin Wallets Created b/w 2011-2015 Vulnerable to Hacking

Bitcoin wallets created between 2011 and 2015 are susceptible to a new kind of exploit called Randstorm that makes it possible to recover passwords and gain unauthorized access to a multitude of wallets spanning several blockchain platforms.

“Randstorm() is a term we coined to describe a collection of bugs, design decisions, and API changes that, when brought in contact with each other, combine to dramatically reduce the quality of random numbers produced by web browsers of a certain era (2011-2015),” Unciphered disclosed in a report published last week.

It’s estimated that approximately 1.4 million bitcoins are parked in wallets that were generated with potentially weak cryptographic keys. Customers can check whether their wallets are vulnerable at www.keybleed[.]com.

The cryptocurrency recovery company said it re-discovered the problem in January 2022 while it was working for an unnamed customer who had been locked out of its Blockchain.com wallet. The issue was first highlighted way back in 2018 by a security researcher who goes by the alias “ketamine.”

The crux of the vulnerability stems from the use of BitcoinJS, an open-source JavaScript package used for developing browser-based cryptocurrency wallet applications.

Especially, Randstorm is rooted in the package’s reliance on the SecureRandom() function in the JSBN javascript library coupled with cryptographic weaknesses that existed at that time in the web browsers’ implementation of the Math.random() function, which allowed for weak pseudorandom number generation. BitcoinJS maintainers discontinued the use of JSBN in March 2014.

As a result, the lack of enough entropy could be exploited to stage brute-force attacks and recover the wallet private keys generated with the BitcoinJS library (or its dependent projects). The easiest wallets to crack open were those that had been generated before March 2012.

The findings once again cast fresh light on the open-source dependencies powering software infrastructure and how vulnerabilities in such foundational libraries can have cascading supply chain risks, as previously laid bare in the case of Apache Log4j in late 2021.

“The flaw was already built into wallets created with the software, and it would stay there forever unless the funds were moved to a new wallet created with new software,” Unciphered noted.

Original Source