[woah]

How did the exploit work? Obviously it looks really bad for Ledger to keep having these web security failures, but the entire point of a hardware wallet is to make it so that you don't have to rely on the security of the code on your computer.

If the hardware wasn't compromised (sounds like this was just JS), then there was no way for the exploit to take anyone's private key. It sounds to me like the exploit would work by getting you to sign a transaction that would transfer out the funds, without the attacker ever getting your key.

The only way this is possible is if users are signing transactions on their Ledger without looking at them.

And this is place where the Ethereum community needs to look in the mirror. Blind signing is the default for using Ethereum with a Ledger. I'm not sure the technical reasons behind this, but I do happen to know that much of the information that gets signed is in very convoluted formats (meta transactions etc). This is not the case everywhere. Other ecosystems, like Cosmos, present the information to be signed in a plain text format that you can scroll through on the Ledger's screen before you sign it.

Ethereum needs to put some serious effort into making sure that anything that gets signed can be viewed in a human-readable format before signing. Until then, hardware wallets are security theater.

[chrisco255]

> The only way this is possible is if users are signing transactions on their Ledger without looking at them.

This is correct. Estimates are that the attackers successfully phished about $600K.

[wyck]

You can see a technical analysis here https://twitter.com/Neodyme/status/1735337711555285261 , this is a JS repo for app integrations for Ledger and really has nothing specifically to do with Ethereum itself or any hardware. There are several wallets solutions that make transactions easier and more secure for people using Eth, but Eth is a protocol running a network and doesn't concern itself with the app layer, and rightly so.

[woah]

Yea my point is that Ethereum has created a complex system without paying enough attention to generating human-readable signing blobs. This is not something that a wallet can help with. The information displayed on the Ledger's screen needs to be human readable so that people know what they are signing. This is something that needs to be solved by the community creating transaction format specifications and the people writing the Ledger Ethereum app.

Ledger deserves a lot of criticism for insecure JS, but the whole point of a hardware wallet is not to have to worry about the JS you are running.

[cxr]

> How did the exploit work?

Web browsers support programs written in a language called JavaScript (JS). When you're on a website that provides interactivity beyond the basics of e.g. clicking links that go to other pages or buttons to submit forms, that's generally because there's one or more JS programs (scripts) on the page making it happen. (Actually, most websites have JS programs nowadays, even if they don't even "do" anything and only exist to let you click links and submit forms.) JavaScript doesn't need to be compiled; your browser can just run it. Most websites up until about 15 years or so were just published in the clear. You could just read the code to see what they did. Gradually, with the introduction of heavyweight "libraries" and "frameworks" like jQuery, React, etc., web developers started adopting really complicated toolchains that, for one reason or another (and not all of them very good), would mangle their programs: the programmer would write scripts, run it through what amounted to a second-rate compiler, and then put the mangled code online instead of the code they actually wrote. Thus, the normalization of deviance began to set in—lots of programmers started doing this.*

Ledger has a browser extension. It lets websites integrate with Ledger Connect. Browsers require browser extensions to be written in JS, too. For one reason or another, none of them very good, programmers started using the same complex toolchains for browser extension development.

Around the same time, people stopped auditing the libraries they depended on. Pretty much the same principles behind the bystander effect and the free-rider problem, they just sort of assume that someone else is doing their job (even though the programmer making the app knows that they themselves aren't, and that no one else they know is, either, it's still assumed that someone out there is).

With the delegation of responsibility and the normalization of deviance around mangled JS, this provided fertile ground for people to start exploiting the software "supply chain" for websites and browser extensions. (I.e. the unreviewed code that programmers copy from other programmers. Because most people who call themselves software engineers are usually joking when they say it but never explain to anyone that it's all just one big joke, lots of companies end up hiring them and putting them in charge of writing programs for the company, and the programmers just copy what everyone else does since they don't know what they're doing.) Someone gained access to the account for a developer's "NPM" package. (NPM is a website where a lot of programmers like to put their hobby projects, and it gives them stats to make them feel good, like how many other programmers downloaded it so they could use it to make their boss's boss more money.) One of these packages was called "connect-kit". Someone put a bad version of "connect-kit" online, the Ledger browser extension used it instead of the copy that the programmers should have reviewed and checked into version control in the latest release of the browser extension, and the mangled package contained hard-to-find code that would steal Ledger users' cryptocurrency. Since everyone programming is just joking around and most of the JS now in existence on production websites is mangled, it didn't raise any red flags that something fishy was going on, because bad code looks about the same as normal code nowadays.

* usually when asked the programmers will argue that it was to make websites faster because the compiled programs would be smaller and consume less power, but empirically the adoption of these toolchains have actually resulted in larger programs that assume the same sort of hardware that the programmers themselves own in order to feel performant—and even then they're usually off

[jay_kyburz]

If this is an AI response, it's one I approve. Wordy, yet entertaining. Opinionated, but sharing my opinions.

[JeremyNT]

Yet it doesn't seem to really answer the question.

I get that what we're looking at a browser extension that relies on a bunch of webshit, some of which was malware.

As somebody not versed in "web3" specific webshits, I thought the point of a hardware token is that there was some kind of verification on the device itself. So this doesn't seem sufficient to "drain" a wallet - right?

My assumption would be that the computer running the malware never gets the key material directly, rather it submits some request to the hardware token, which prompts the user with the details on some external physical display. The user reviews the details, then does something in meatspace that causes the hardware token to sign the something in question and pass it back to the software on the PC.

So isn't it the case that the user would have to approve the malware drain transaction themselves? And if not... what's the point of these devices, anyway?

[woah]

Not sure if anyone actually read my original post. The problem is that Ethereum transactions are not especially human readable so they are commonly signed blind. As you point out, this is a problem.

[cxr]

So it wasn't the case that dynamically loading and executing a blob of unreviewed third-party code containing the offending section is what was responsible for those transactions being initiated. Oh wait, it was.

[woah]

The whole point of a hardware wallet is that the security of your computer shouldn't matter.