[Warning!]Numerous BitcoinJS -based wallets are still under the threat.

[satscraper]

Unciphered, a cybersecurity group, has issued a warning regarding the vulnerability of wallets built on BitcoinJS and generated between 2011 and 2015. According to their estimates,  up to $2.1B is still under the threat . The optimal course of action for users with wallets from that period is to transfer their stashes to wallets from the latest generations

[1714283157]

1714283157

[1714283157]

1714283157

[1714283157]

1714283157

[Yamane_Keto]

So the weak point is a JavaScript class called SecureRandom(), which generates an entropy of less than 48 bits of entropy, and the list could be longer if we included closed source wallets that rarely update the code, especially since some closed source wallets are still not supported bc1 addresses.

[gmaxwell]

https://youtu.be/Gs9lJTRZCDc?t=3072

[satscraper]

So the weak point is a JavaScript class called SecureRandom(), which generates an entropy of less than 48 bits of entropy, and the list could be longer if we included closed source wallets that rarely update the code, especially since some closed source wallets are still not supported bc1 addresses.

SecureRandom() is solely a tip of the iceberg. The core of their narrative is that most of the early wallets lack the code integrity and,  thus, rely on 3rd parties libraries with bunch of vulnerabilities. They even invented the term for this phenomenon - Randstorm.

[NotATether]

SecureRandom() is solely a tip of the iceberg. The core of their narrative is that most of the early wallets lack the code integrity and,  thus, rely on 3rd parties libraries with bunch of vulnerabilities. They even invented the term for this phenomenon - Randstorm.

This is the reason why I steer clear of all JavaScript-based wallets. It's not possible to verify everything that is going on, since most dependencies used inside the projects have too many dependencies of their own.

Of course, Python also has that kind of problem, but not nearly as bad. And if you use a good wallet such as Electrum, the amount of packages you're pulling in are extremely limited (1 QR code package and 1 cryptography package if you're not using hardware wallet support), so it's simple to verify each of them.

[satscraper]

. And if you use a good wallet such as Electrum, the amount of packages you're pulling in are extremely limited (1 QR code package and 1 cryptography package if you're not using hardware wallet support), so it's simple to verify each of them.

BTW, Elecrum's  QR code package also had (or probably still has in some of  multiple Electrum versions&forks)  flaws in code that potentially  open attack channels for malicious actors. This was demonstrated by Eric Michaud in his video presentation on SEC-T 2022. (watch from 18:00).

[NotATether]

BTW, Elecrum's  QR code package also had (or probably still has in some of  multiple Electrum versions&forks)  flaws in code that potentially  open attack channels for malicious actors. This was demonstrated by Eric Michaud in his video presentation on SEC-T 2022. (watch from 18:00).

Not very welcoming news to be honest   although I believe this issue was fixed for the Bitcoin edition in 4.53.4(?) or somewhere after that version.

The screencast shown in the presentation is too small to see even in 1080p resolution, do you know where I can find a copy of this slide? I am unable to see the attack clearly, in particular the payload.

[satscraper]

BTW, Elecrum's  QR code package also had (or probably still has in some of  multiple Electrum versions&forks)  flaws in code that potentially  open attack channels for malicious actors. This was demonstrated by Eric Michaud in his video presentation on SEC-T 2022. (watch from 18:00).

Not very welcoming news to be honest   although I believe this issue was fixed for the Bitcoin edition in 4.5.4(?) or somewhere after that version.

The screencast shown in the presentation is too small to see even in 1080p resolution, do you know where I can find a copy of this slide? I am unable to see the attack clearly, in particular the payload.

In his presentation he said they addressed this security issue to Electrum team and he believed they fixed this somewhere in June 2022. But i took the quick look on all releases and found that probably  the real fix has appeared in 4.3.4 ((January 26, 2023) which "replaced vendored qrcode lib".

Nevertheless. I'm sure that numerous users are  still  glued  to the earlier versions, even 3.8 is still used (I know this from the posts in Russian section). Besides, as I already said, there are  plenty of Electrum forks which may still be vulnerable.

[DaveF]

Could just be me, but I don't see this as as big a deal as they are making it out to be.

The vulnerability has been known for a long time as have others, there are dozens, perhaps 100s of state sponsored actors like North Korea, actively going people funds. If there was a real substantial risk the coins would have been moved long ago.

Having that handy graphic that is in the 1st post is also irrelevant. So the product still exists, does it still use the same code? Did they have other mitigations in place back in the early 2010s?

The fact that people are still generating wallets that hold real amounts of funds with just a PC / phone and not a hardware device or a 2nd airgapped machine is more of a risk.

-Dave

[o_e_l_e_o]

The vulnerability has been known for a long time as have others, there are dozens, perhaps 100s of state sponsored actors like North Korea, actively going people funds. If there was a real substantial risk the coins would have been moved long ago.

But a quick internet search shows that North Korea are continuing to steal coins through various "hacks". And then there are the cases like Atomic wallet, which has been around for years, suddenly losing millions of dollars worth of coins. Just because something hasn't been hacked yet doesn't mean it's secure indefinitely. If I generated a private key with 50 bits of entropy, then it might last long enough to fund and and then spend from within a day or two, but if you store coins on it long term then they will be stolen eventually.

The fact that people are still generating wallets that hold real amounts of funds with just a PC / phone and not a hardware device or a 2nd airgapped machine is more of a risk.

You will still see lots of people on this forum "recommend" that people download bitaddress or iancoleman and run it on an airgapped machine in order to generate a private key or seed phrase. While these tools should obviously be ran on an airgapped when using them to interact with pre-existing private keys or seed phrases, I've long argued against using any website, airgapped or not, to generate entropy from scratch.

[mv1986]

SecureRandom() is solely a tip of the iceberg. The core of their narrative is that most of the early wallets lack the code integrity and,  thus, rely on 3rd parties libraries with bunch of vulnerabilities. They even invented the term for this phenomenon - Randstorm.

This is the reason why I steer clear of all JavaScript-based wallets. It's not possible to verify everything that is going on, since most dependencies used inside the projects have too many dependencies of their own.

Of course, Python also has that kind of problem, but not nearly as bad. And if you use a good wallet such as Electrum, the amount of packages you're pulling in are extremely limited (1 QR code package and 1 cryptography package if you're not using hardware wallet support), so it's simple to verify each of them.

@NotATether I am using Electrum exclusively (besides hardware wallets) and I update it whenever there is an update from the original source from electrum.org. I just relied on its reputation and I wonder if there is anything else you pay attention to. Do you always update to the newest version or is there sometimes reason to stick with an older version?