Live data from Hacker News

Ledger's NPM account has been hacked

github.com

101–110 of 130 posts

Re: Ledger's NPM account has been hacked

#101
post #88

We've been building Socket [1] to detect and block this exact type of supply chain attack. Our Socket AI scanner [2] successfully detected this attack. It uses dozens of static signals combined with an LLM to detect novel attacks that evade traditional scanning tools. This is what Socket AI produces when given @ledgerhq/connect-kit 1.1.7 to analyze: > The obfuscated code block is highly suspicious and likely contains…

Is it possible to consume the malware list as JSON/SSE?

Yes, please get in touch with me at (my_username)@socket.dev.

Re: Ledger's NPM account has been hacked

#102
post #89

I only have a Ledger because my required me in order to implement a crypto wallet on the website. I have 2 seed phrases written on the back of a book since 2017 and it has kept me well, no hacks so far.

Have you turned it on recently? Mine bricked itself with no warning.

Re: Ledger's NPM account has been hacked

#103
post #96

And once again calls to allow optional signing support natively to NPM will be rejected citing that it might intimidate drive-by devs who do not want to learn to setup a yubikey or nitrokey for artifact signing. I have talked to the NPM team about this multiple times over the last several years and they literally believe no signing at all is better than some devs feeling pressured to sign. You need no stronger eviden…

This isn't quite accurate. In fact, npm did ship a form of code signing called 'npm provenance' in April 2023. We wrote a semi-official deep dive on the feature in cooperation with the npm team that explains how to sign your npm packages [1].

You can see npm provenance in action on this npm package page [2] if you scroll to the very bottom and look under the "Provenance" heading.

[1]: https://socket.dev/blog/npm-provenance

[2]: https://www.npmjs.com/package/@socketsecurity/cli

Re: Ledger's NPM account has been hacked

#104
post #88

We've been building Socket [1] to detect and block this exact type of supply chain attack. Our Socket AI scanner [2] successfully detected this attack. It uses dozens of static signals combined with an LLM to detect novel attacks that evade traditional scanning tools. This is what Socket AI produces when given @ledgerhq/connect-kit 1.1.7 to analyze: > The obfuscated code block is highly suspicious and likely contains…

Do you discuss anywhere what you use for static analysis? I skimmed through your blog but didn't see any details. Also -- did you detect and publish this BEFORE it became public knowledge? It's unclear.

Re: Ledger's NPM account has been hacked

#105
post #42

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 wo…

> 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

Re: Ledger's NPM account has been hacked

#106
post #88

We've been building Socket [1] to detect and block this exact type of supply chain attack. Our Socket AI scanner [2] successfully detected this attack. It uses dozens of static signals combined with an LLM to detect novel attacks that evade traditional scanning tools. This is what Socket AI produces when given @ledgerhq/connect-kit 1.1.7 to analyze: > The obfuscated code block is highly suspicious and likely contains…

Do you discuss anywhere what you use for static analysis? I skimmed through your blog but didn't see any details. Also -- did you detect and publish this BEFORE it became public knowledge? It's unclear.

We've built our own minimalist static analysis engine that only supports scanning for the specific supply chain threats we care about. For that reason, it's a lot simpler and faster than a generic engine.

I'll see if we can write up a bit about how it works in a future blog post.

Re: Ledger's NPM account has been hacked

#107
post #88

We've been building Socket [1] to detect and block this exact type of supply chain attack. Our Socket AI scanner [2] successfully detected this attack. It uses dozens of static signals combined with an LLM to detect novel attacks that evade traditional scanning tools. This is what Socket AI produces when given @ledgerhq/connect-kit 1.1.7 to analyze: > The obfuscated code block is highly suspicious and likely contains…

Love Socket! A lot of folks (think most) were loading the compromised package through another package, @ledgerhq/connect-kit-loader [1], via a CDN call [2]. Would be great if Socket could pick up on this because Socket's @ledgerhq/connect-kit-loader page [3] doesn't include any warning.

[1]: https://socket.dev/npm/package/@ledgerhq/connect-kit-loader

[2]: https://github.com/LedgerHQ/connect-kit/blob/main/packages/c...

[3]: https://socket.dev/npm/package/@ledgerhq/connect-kit-loader/...

Re: Ledger's NPM account has been hacked

#108
Co-founder @ Phylum here (https://phylum.io). We've been actively scanning dependencies across most open source package registries (e.g., npm, PyPI, Crates.io, etc.) for a few years now. Quite successfully, I might add, with recent findings targeting financial institutions [1], North Korean state actors [2], and some of the first malware staging to be seen on Crates.io [3].

The fact that an attacker was able to pull this off against a _secure_ hardware device is shocking but not surprising. The mechanism by which they did it is interesting and fairly insidious. Unlike a lot of other attacks that will publish the malware to the registry, this one pulls the payload from a CDN. So, static analysis of the loader (i.e., the intermediary package on npm) is unlikely to yield sufficiently interesting results. Solely focusing on the obfuscation angle is also not of particular use since quite a bit of packages are obfuscated on npm (like, a surprising amount of it. In Q3 2023 we saw over 5,000 _new_ packages shipped with some form of obfuscation).

Nonetheless, our automated platform pinged us this morning about some changes to this package and our research team has been digging into it to determine the impacts.

With that said, we've produced (and open sourced!) several tools that aim to help with software supply chain style attacks:

1. Birdcage is a cross-platform embeddable sandbox [4]

2. Our CLI is extensible and integrates Birdcage so you can do things like `phylum npm install...` or `phylum pip install...` and have the package installations be sandboxed [5]

We've also got a variety of integrations [6] along with a threat feed of software supply chain attacks (of which the Ledger package and other APT attacks have appeared).

Happy to answer any questions! A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!

1. https://blog.phylum.io/encrypted-npm-packages-found-targetin...

2. https://blog.phylum.io/junes-sophisticated-npm-attack-attrib...

3. https://blog.phylum.io/rust-malware-staged-on-crates-io/

4. https://github.com/phylum-dev/birdcage

5. https://github.com/phylum-dev/cli

6. https://docs.phylum.io/docs/integrations_overview

Re: Ledger's NPM account has been hacked

#110
post #96

And once again calls to allow optional signing support natively to NPM will be rejected citing that it might intimidate drive-by devs who do not want to learn to setup a yubikey or nitrokey for artifact signing. I have talked to the NPM team about this multiple times over the last several years and they literally believe no signing at all is better than some devs feeling pressured to sign. You need no stronger eviden…

This is the same NPM that made a change causing the `integrity` field to go silently missing from `package-lock.json` [0][1] when installing packages, and then also not complaining at any other time in the future.

[0] https://github.com/npm/cli/issues/4460

[1] https://github.com/npm/cli/issues/4263

Post reply on HN