Hacker News new | ask | show | jobs
by cxr 921 days ago
> 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

1 comments

If this is an AI response, it's one I approve. Wordy, yet entertaining. Opinionated, but sharing my opinions.
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?

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.
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.
The whole point of a hardware wallet is that the security of your computer shouldn't matter.
Exclusively focusing on the security failures arising from end-user UI/social engineering and ignoring the failures arising from poor engineering billed as modern software development best practices is another type of failure.