[HN Gopher] Ledger's NPM account has been hacked
___________________________________________________________________
Ledger's NPM account has been hacked
Author : meehow
Score : 219 points
Date : 2023-12-14 13:42 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ramijames wrote:
| Yikes.
| kossTKR wrote:
| Ledger has been hacked so many times now i've lost count.
|
| I remember buying one in 2019, and shortly thereafter all
| customer data was dumped on the internet endangering everyone who
| bought one.
|
| Then after deep diving the tech i threw it in the trash, it
| seemed like security theatre product.
|
| There's also been so many phishing attempts, fake ledgers sold,
| bricked ones losing funds, it's total shitshow that ecosystem if
| you check their subreddit going back in time.
|
| The more you rely on 3. parties, and the more obfuscated your
| setup is, the more unsafe your data is. I just use isolated cheap
| laptops and encrypted usb's now.
| lxgr wrote:
| Do you build and program these laptops and USB drives yourself?
| nullstyle wrote:
| "bricked ones losing funds"
|
| That's the user's fault. The product makes it very clear you
| need to create a recovery sheet and store it in a safe deposit
| box or other secure place. If you actively ignore the
| instructions you deserve it.
|
| Could you share some of your deep dive and tell us about what
| concerns you found? I use one of their wallets and I'd like to
| investigate more now as well.
| rekoil wrote:
| A few months ago they also pushed a new feature which, if
| enabled, literally exfiltrated your secret key to external
| parties, requiring only 2 to reassemble the full key...
|
| Avoid
|
| Avoid
|
| Avoid
| dboreham wrote:
| The only reason things like Ledger exist is because regular
| smart cards (e.g. Yubikey) don't yet support the signature
| schemes used on blockchains.
| meehow wrote:
| Regular smart cards also don't have screens, so it would mean
| totally blind signing. That's the problem which hardware
| wallets are solving, but sometimes the screen is just too
| small to show all the details of complex transactions.
| chrisco255 wrote:
| Yubikeys are fine for basic sign-in/sign-out functionality,
| but even on a basic web app, your auth tokens are something
| else independent of your Yubikey signature.
| meowface wrote:
| >I just use isolated cheap laptops and encrypted usb's now.
|
| I figure this isn't practical for most end users. Is there an
| alternative hardware wallet that you think is okay for most
| people? How do you feel about Trezor?
| anders16 wrote:
| Coldcard! https://coldcard.com/
| yownie wrote:
| I'm curious about coldcard as well, however what would you
| say are the benefits over a trezor / ledger device?
| Rastonbury wrote:
| I don't know which it more practical trusting an exchange,
| paying a hardware wallet or maybe encrypted file in s3
| bdd8f1df777b wrote:
| How? My set up is less secure, but more auditable than
| hardware wallets--a dedicated hard disk running a portable
| Linux doing nothing else than crypto. And only for sending
| out funds. For receiving funds I use my normal operating
| system with view-only keys.
| pants2 wrote:
| The modern solution is to use MPC wallets like ZenGo.
| ametrau wrote:
| I must be missing something. It couldn't be as dumb as
| using a photo of your face as the key.
| rahen wrote:
| For "most people", I wouldn't know, but for the typical HN
| reader, I would advise something open-source, verifiable,
| DIY, stateless and air-gapped, and that is the seedsigner:
|
| https://seedsigner.com
|
| To me, this is the perfect solution for a long term saving
| account, completed with a Lightning wallet for spending. The
| coldcard and Jade wallet are also great options.
| irusensei wrote:
| Same here. The most infuriating thing is how they downplayed
| the data breach, specially considering some of their customers
| live in dangerous countries.
|
| I've switched to a Coldcard. Everything from purchase to the
| device operation seems to be highly focused on security and
| protections against tampering. No client software... it's all
| sneakernet. Coinkite even deleted my customer data a few weeks
| after purchase without me having to request.
|
| I still have my ledger. I think it is a nice device but when I
| tried to repurpose it as an yubikey of sorts (it has fido and
| gpg micro apps) it didn't actually worked alright. I never
| trusted ledger live though.
| matheusmoreira wrote:
| I've found the most secure key management is to keep important
| keys offline and stored on paper and only load them into a live
| tails/whonix system for brief uses. I even contributed a binary
| decoding feature to zbar to let me store them on printed QR
| codes and easily input them back in.
|
| > bricked ones losing funds
|
| Well of course. It's just a computer and all computers fail.
| Cheap laptops can also fail and destroy your keys. USB flash
| storage failure is even more likely. This is the number one
| argument for storing keys on paper which is actually known to
| last centuries.
| binarymax wrote:
| NPM forces 2fa, so I'm curious what the scenario was here. Was a
| committers phone compromised?
| rdl wrote:
| Github action
| rdl wrote:
| Actually worse than that, former employee phished for
| credentials, per Ledger themselves. Underlying cause is utter
| incompetence by company, 4th strike.
| Daviey wrote:
| The Github action leaked the creds, seemingly via a log. Looks
| like that action has been in use for ~4 months.
| koolba wrote:
| Automated publishing without a human involved kind of kills
| the whole point of 2FA anyway.
|
| It is kind of funny that the crypto world of multi sigs
| relies on blind trust of unverified UI components.
| latchkey wrote:
| Technically, it is just the frontends. You can always
| interact with the contracts directly and that can't ever be
| shut down (if you know what you're doing). Can you do that
| with your bank?
|
| Let's also not forget that every other website on the
| planet that relies on npm also relies on the blind trust of
| unverified UI components. This isn't just silo'd to crypto.
| jeroenhd wrote:
| If properly configured and audited, this approach can be
| secure. Github is the only way configured to publish to
| NPM, and NPM pushes can only be initiated by signed commits
| from trusted accounts with MFA, the entire workflow is can
| be secure on its own.
|
| I don't really see the point for a project that doesn't
| seem to update their code all that often, though. The risk
| of misconfiguring something doesn't seem worth the effort
| saved by having someone with a 2FA key upload a tarball
| generated on their dev machine.
| hn_throwaway_99 wrote:
| This is exactly why GitHub support OpenID Connect,
| https://docs.github.com/en/actions/deployment/security-
| harde..., so that long-lived secrets don't need to be present
| as part of the build.
|
| I'm not sure if NPM supports OIDC, which would be ironic
| given that both GitHub and NPM are owned by Microsoft.
| fkyoureadthedoc wrote:
| Why would that be ironic?
| hn_throwaway_99 wrote:
| Sorry, my sentence was poorly written, I meant it would
| be ironic if NPM _didn 't_ support OIDC.
| KomoD wrote:
| Source?
|
| Their twitter says "This morning CET, a former Ledger
| Employee fell victim to a phishing attack that gained access
| to their NPMJS account."
|
| And Github Actions automatically redacts the secret in the
| log
| Daviey wrote:
| You are right, I should have waited for the postmortem.. it
| appeared the likely way because the secret was in the
| release pipeline env.
|
| However.. something doesn't add up. There is no chance that
| a malicious actor gained access and in a couple of hours
| put together this exploit. Or, I can't see someone putting
| together this exploit, THEN trying to spear-phish in hope
| of getting lucky and pressing the button.
| ezekg wrote:
| > I can't see someone putting together this exploit, THEN
| trying to spear-phish in hope of getting lucky and
| pressing the button.
|
| How can you not see someone doing that? The effort netted
| them $600k.
|
| Is this not how exploits work? Build the exploit and then
| try to use it by finding an "in." They don't find an "in"
| and then build the exploit.
| forward1 wrote:
| 2FA only protects login. Pretty much all account security from
| that point on is based on portable bearer tokens.
| binarymax wrote:
| Not sure what you mean. Every time I publish to NPM it
| prompts me for a one time code.
| mikeryan wrote:
| Sounds like they're publishing to npm with a GitHub action
| which can be done with an automation token which bypasses
| 2fa
| jiripospisil wrote:
| There is an option to always require 2fa when publishing a
| package.
|
| > To protect your packages, as a package publisher, you can
| require everyone who has write access to a package to have
| two-factor authentication (2FA) enabled. This will require
| that users provide 2FA credentials in addition to their login
| token when they publish the package.
|
| > Require two-factor authentication and disallow tokens: With
| this option, a maintainer must have two-factor authentication
| enabled for their account, and they must publish
| interactively. Maintainers will be required to enter 2FA
| credentials when they perform the publish. Automation tokens
| and granular access tokens cannot be used to publish
| packages.
|
| https://docs.npmjs.com/requiring-2fa-for-package-
| publishing-...
| mikeryan wrote:
| NPM _optionally_ enforces 2FA. You can create an automation
| token to bypass it. In that case depending on how branches are
| protected a push to the right branch can publish a new package.
|
| https://github.blog/changelog/2020-10-02-npm-automation-toke...
|
| Heck if they have an automated deployment and use devs personal
| GitHub handles all it would take is forgetting to remove an ex
| employee from the right github access group. Even if you took
| away all other access when they left.
| nathell wrote:
| Just yesterday I watched a talk [0] at WarsawJS about LavaMoat
| [1], a set of tools to protect against malicious behaviour from
| npm dependencies. Guess it's time to look into it deeper.
|
| [0]: https://naugtur.pl/pres3/lava/2023end.html
|
| [1]: https://github.com/LavaMoat/LavaMoat
| zaphod420 wrote:
| One of the comments on the github issue...
| https://github.com/LedgerHQ/connect-kit/issues/29
|
| "The @ledgerhq/connect-kit-loader allows dApps to load Connect
| Kit at runtime from a CDN so that we can improve the logic and UI
| without users having to wait for wallet libraries and dApps
| updating package versions and releasing new builds.
|
| This looks like an extremely dangerous approach now, if I
| understand it correctly, connect-kit-loader trusts whatever the
| CDN throws at your dApps. So when connect-kit is comprised, all
| downstream dApps are automatically exposed."
| lxgr wrote:
| Is there even an alternative? Once you can inject arbitrary
| code into a library that a web app loads and executes (except
| if it's in an iFrame), it's game over, no?
| chrisandchris wrote:
| Partially, one could use a Content-Security-Policy to lock
| things further down.
| meehow wrote:
| So it was intended to be used this way. Didn't work very well.
| Connect-kit-loader trusts whatever the CDN throws, CDN trusts
| whatever NPM throws and NPM trusts whatever GitHub throws.
| cantSpellSober wrote:
| > Yes, .5/.6/.7 versions are compromised
|
| So was there a threat to Ledger users? Elsewhere it's said:
|
| > production build failed
| ashishbijlani wrote:
| Plug: we've been building Packj [1] to detect malicious
| Python/NPM/Ruby/Rust/Java/PHP packages. It carries out
| static/dynamic/metadata analysis to look for "suspicious"
| attributes such as spawning of shell, invalid/expired email
| (i.e., no 2FA), use of files, network communication, use of
| decode+eval, mismatch of GitHub code vs packaged code, and
| several more.
|
| 1. https://github.com/ossillate-inc/packj
| aftbit wrote:
| Can you show the result of running a scan against this
| compromised repo? Would your tool have caught this crypto
| drainer live on revoke.cash?
| cmeacham98 wrote:
| Tried it myself and they don't appear to have implemented the
| part of the scan that would catch this, relevant snippet from
| the logs: [+] Analyzing repo-pkg src
| code match.... N/A [Coming soon!]
| capableweb wrote:
| And since you're bragging/plugging it here, I take it you
| tested it against this repository+version and it detected it?
| rdl wrote:
| LOL https://twitter.com/Ledger/status/1735326240658100414
|
| FINAL TIMELINE AND UPDATE TO CUSTOMERS:
|
| 4:49pm CET:
|
| Ledger Connect Kit genuine version 1.1.8 is being propagated now
| automatically. We recommend waiting 24 hours until using the
| Ledger Connect Kit again.
|
| The investigation continues, here is the timeline of what we know
| about the exploit at this moment:
|
| - This morning CET, a former Ledger Employee fell victim to a
| phishing attack that gained access to their NPMJS account. - The
| attacker published a malicious version of the Ledger Connect Kit
| (affecting versions 1.1.5, 1.1.6, and 1.1.7). The malicious code
| used a rogue WalletConnect project to reroute funds to a hacker
| wallet. - Ledger's technology and security teams were alerted and
| a fix was deployed within 40 minutes of Ledger becoming aware.
| The malicious file was live for around 5 hours, however we
| believe the window where funds were drained was limited to a
| period of less than two hours. - Ledger coordinated with
| @WalletConnect who quickly disabled the the rogue project. - The
| genuine and verified Ledger Connect Kit version 1.1.8 is now
| propagating and is safe to use. - For builders who are developing
| and interacting with the Ledger Connect Kit code: connect-kit
| development team on the NPM project are now read-only and can't
| directly push the NPM package for safety reasons. - We have
| internally rotated the secrets to publish on Ledger's GitHub. -
| Developers, please check again that you're using the latest
| version, 1.1.8. - Ledger, along with @Walletconnect and our
| partners, have reported the bad actor's wallet address. The
| address is now visible on @chainalysis . @Tether_to has frozen
| the bad actor's USDT. - We remind you to always Clear Sign with
| your Ledger. What you see on the Ledger screen is what you
| actually sign. If you still need to blind sign, use an additional
| Ledger mint wallet or parse your transaction manually. - We are
| actively talking with customers whose funds might have been
| affected, and working proactively to help those individuals at
| this time. - We are filing a complaint and working with law
| enforcement on the investigation to find the attacker. - We're
| studying the exploit in order to avoid further attacks. We
| believe the attacker's address where the funds were drained is
| here: 0x658729879fca881d9526480b82ae00efc54b5c2d
|
| Thank you to @WalletConnect , @Tether_io, @Chainalysis , @zachxbt
| , and the whole community that helped us and continue to help us
| identify and solve this attack.
|
| Security will always prevail with the help of the whole
| ecosystem.
| rdl wrote:
| 1) They are using some phishable auth (SMS? TOTP? password
| only?) to secure super high value repo? For fuck's sake,
| they're a HARDWARE KEY VENDOR which also supports U2F/FIDO2 as
| an app.
|
| 2) Former employee has signing/push auth on super high value
| repo?
|
| 3) Single person has signing/push auth on super high value
| repo?
|
| .com
| cobertos wrote:
| > "This morning CET, a former Ledger Employee fell victim to a
| phishing attack that gained access to their NPMJS account."
|
| Ouch. A _former_ employee had active credentials to phish for.
|
| > "@Tether_to has frozen the bad actor's USDT."
|
| Wasn't like, >30% of the point of crypto to not allow people to
| do this sort of high-level/centralized freezing?
| bastawhiz wrote:
| > Wasn't like, >30% of the point of crypto to not allow
| people to do this sort of high-level/centralized freezing?
|
| I mean, unlimited Tether can be created or destroyed at the
| whim of some guy with a big button somewhere. The promise of
| crypto being the embodiment of true distributed governance
| went out the window with USDT ages ago.
| tock wrote:
| Everyone using fiat backed centralised stablecoins these days
| like USDT and USDC. Not only do they have blacklists but they
| can also burn your balance + they are fully upgradeable aka
| they can add/remove any functionality they want any time :p
|
| The blacklists need to exist as per regulations though.
| rdl wrote:
| Tether/USDC and other centralized stablecoins are really
| "their own thing", not "crypto" in the cypherpunk sense.
| mattwilsonn888 wrote:
| You can have gradations of control. USDT and USDC are
| centrally managed.
|
| We used to have DAI, which was fully decentralized and over-
| collatoralized by Ethereum tokens (the native currency of the
| platform DAI is rooted on) - but the founder mysteriously
| died as the DAO was taken over and made to begin
| collateralizing DAI against USDC and USDT, ironically.
|
| It is a shame how far crypto has fallen culturally that this
| stablecoin business is some niche story. Most people are in
| it for the money, but many good people are not.
| earthboundkid wrote:
| There is no possible way that USDT is backed one-to-one. It
| just isn't. If it were, it would have a simple audit trail
| that they would publish. They don't because it isn't. It's
| a scam that will at some point unravel, and everyone will
| lose their shirts because of "many good people" lol.
| chrisco255 wrote:
| They do post audits on the regular:
| https://tether.to/en/transparency/#reports
| rewtraw wrote:
| It's possibly backed greater than 1:1. Tether likely
| cleaned up their operations over the past few years, but
| the "Tether Truthers" are still anxious about fraud. Even
| more transparency is welcome of course.
|
| > Cantor Fitzgerald CEO Howard Lutnick on CNBC:
|
| > "I'm a big fan of this stablecoin called Tether...I
| hold their treasuries. So I keep their treasuries, and
| they have a lot of treasuries. They're over $90 billion
| now, so I'm a big fan of Tether."
|
| https://twitter.com/leomschwartz/status/17346948000190632
| 07 https://tether.to/en/transparency/#usdt
|
| > Tether also reported all time high excess reserves of
| $2.44 billion.
|
| https://www.theblock.co/post/230241/tether-attestation-
| repor...
| chrisco255 wrote:
| I don't think MakerDAO ever integrated USDT as collateral,
| but they did integrate USDC. It's unfortunate DAI is not
| fully decentralized, but the best fully decentralized
| stable coin efforts (like RAI and LUSD) often suffer from a
| capital efficiency problem.
|
| I think it's fine to have a spectrum of centralized assets
| and decentralized assets represented as tokens. Blockchains
| are public, permissionless, ledgers.
| aftbit wrote:
| Hold on what? I missed all of this MakerDAO drama. The
| founder died and now assets are collatoralized by USDT
| instead of ETH? Looks like at least
|
| Some links I found for further reading:
|
| https://cointelegraph.com/news/makerdao-co-founder-
| nikolai-m...
|
| https://maker.defiexplore.com/stats
| hanniabu wrote:
| > but the founder mysteriously died
|
| Hello CIA
| chrisco255 wrote:
| Tokens are fully programmable, so you can encode whatever
| logic you want in them, including freezing if you want that
| functionality. This is mainly done in dollar-backed stable
| coins.
|
| The base level assets, like ETH and BTC, cannot be frozen
| like this, although centralized exchanges will often
| blacklist addresses (and the chain of custody) involved in
| major exploits.
| matheusmoreira wrote:
| That was the point, yes. The whole problem is people
| reinvented the entire centralized banking system _on top of_
| crypto. Stuff like USDT should not even _exist_ , people were
| supposed to adopt crypto wholesale and only convert to fiat
| currency to pay taxes until the government caved and allowed
| paying taxes in crypto.
| orf wrote:
| $610k drained:
| https://twitter.com/zachxbt/status/1735292040986886648
| wslh wrote:
| There are at least three type of vulnerabilities here:
|
| 1/ Handling the custody of secrets by the company. The
| attackers first attacked and accessed a former Ledger employee
| with official Ledger account secrets. This is where secrets
| were mismanaged since the actual company secrets should never
| be in the hands of former employees.
|
| 2/ The attack could occur on an actual employee so they should
| employ ways to be protected against this kind of attack.
|
| 3/ The use of CDNs should have security measures in place. This
| is one of the most common attacks nowadays.
| renonce wrote:
| So Ledger was able to coordinate with a number of entities to
| minimize the impact of the attack? Isn't that directly contrary
| to crypto's decentralized design?
|
| If one is to make crypto really decentralized, relying on a
| small number of authorities for security seems contrary and
| maybe poisonous to that goal.
| woah wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| coneonthefloor wrote:
| > Discover what security feels like
|
| Quote from their sales site.
| mecsred wrote:
| Feels pretty apt honestly. This is about how secure I feel
| using modern technology. The only thing that makes me ok using
| a bank is knowing I can go ask a human being to chase my money
| down when it vanishes suddenly. There's even a non-zero chance
| they get it back to me!
| matheusmoreira wrote:
| Security is not absolute. Even cryptographic hardware can be
| vulnerable.
|
| Yubico for example had to replace many of their YubiKeys after
| a vulnerability was detected in its secure element firmware
| which affected the strength of keys generated on the device.
| They sent me a replacement YubiKey after I contacted them.
|
| https://www.yubico.com/support/security-advisories/ysa-2017-...
| oefrha wrote:
| Pretty fascinating that the malicious code doesn't seem to be
| obfuscated one bit. Even contains the word "drain" in multiple
| places. At least use innocuous looking variable names ffs.
| asylteltine wrote:
| When will npm finally take security seriously? How many incidents
| do they need? Don't allow non hardware mfa and add verified
| namespaces already!
| lainga wrote:
| Never. It is this way for cosmogonical reasons; it fulfils a
| purpose. I see Isaac Schlueter as the modern Genghis: "If you
| had not committed great sins, God would not have sent a
| punishment like me upon you."
| mikeryan wrote:
| It's not NPMs job to secure _your_ repo. They provide the tools
| to protect it. It's your job as a maintainer to not shoot
| yourself in the foot.
| NoGravitas wrote:
| LOL, I initially thought this was Ledger, the command-line
| personal finance management software, and was worried that it was
| actually something important.
| NoGravitas wrote:
| Downvoters are wondering where their apes went.
| neom wrote:
| I thought the whole point of ledger was that it's a physical
| wallet that can't easily be compromised. Not your keys not your
| crypto and all that?
| chrisco255 wrote:
| This was a UI popup that got injected into the middleware
| provided by Ledger that is used to make it easy for apps to
| prompt Ledger users for a signature. The keys aren't
| compromised by this attack, this is more similar to a phishing
| attack, but via supply chain to increase fake legitimacy.
| feross wrote:
| 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 malicious behavior. The presence of obfuscation and the
| unclear purpose of the code raise significant red flags.
|
| Feeling very proud of our team right now as this validates that
| our static analysis + LLM approach works well on novel malicious
| dependencies. If you're interested, we maintain a listing of
| malicious packages detected by this system [3].
|
| Small plug: If you'd like real-time protection against attacks
| like this, you can install Socket for GitHub to automatically
| scan every PR in your repo. The free plan is incredibly generous.
| If you do decide to install it, it's important that you enable
| the 'AI Detected Security Risk' alert type in your Security
| Policy to activate this protection.
|
| [1]: https://socket.dev
|
| [2]: https://socket.dev/blog/introducing-socket-ai-chatgpt-
| powere...
|
| [3]: https://socket.dev/npm/issue/malware
| theteapot wrote:
| Apparently 1.1.5|6 we're also compromised?
| stevelacy wrote:
| Is it possible to consume the malware list as JSON/SSE?
| feross wrote:
| Yes, please get in touch with me at (my_username)@socket.dev.
| ryanjshaw wrote:
| 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.
| feross wrote:
| 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.
| meagher wrote:
| 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/...
| feross wrote:
| Thanks for reporting this. Fixed:
| https://socket.dev/npm/package/@ledgerhq/connect-kit-
| loader/...
|
| We don't currently detect 'implicit dependencies' loaded via
| CDN URLs, though we'll look into what it would take to
| support this.
| jbirer wrote:
| 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.
| resolutebat wrote:
| Have you turned it on recently? Mine bricked itself with no
| warning.
| lrvick wrote:
| 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 evidence of the NPM teams negligence than
| these two times they refused to even accept community contributed
| optional signing support saying they would come up with something
| better than PGP. Still waiting 10 years later.
|
| https://github.com/npm/npm/pull/4016
|
| https://github.com/node-forward/discussions/issues/29#issuec...
|
| Meanwhile PGP secures the supply chain of the Linux distros that
| power the whole internet, and Debian signs hundreds of npm
| packages used in their dependency graph, but it is still not good
| enough for NPM.
|
| You can use the well tested and rust-written Sequoia/sq now and
| never touch GnuPG. You can also self certify your keys with
| keyoxide. The past complaints are largely moot and still people
| stick to their guns on this.
|
| https://openpgp.dev/book/
| feross wrote:
| 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
| lrvick wrote:
| I am sure virtually everyone understands "code signing" to
| mean what it has meant historically. The author of code signs
| git commits, or a tarball, or signing a package as in the
| debian, arch, guix sense. All of which typically share
| cryptography standards like PGP rather than rolling their own
| solutions.
|
| Each maintainer has a signing key to identify themselves to
| the public without need for any central infra, and signs the
| packages they publish. Someone that accesses some centralized
| server or account will not be able to impersonate the key
| held by that developer or the signatures they issue.
|
| This new provenance system and the fulcio system which it is
| based on, is a centralized setup where you use traditional,
| usually phishable, authentication with a SaaS, and then the
| SaaS takes your submission and signs it for you with a
| centrally managed keychain. Having done security auditing for
| many fintech signing systems, I can tell you I have almost
| never once seen anyone get this right, particularly when
| there is no accountability.
|
| Is this done in a secure enclave with a public remote
| attestation of the software image running on it that I can
| locally compile and verify the matching hash of? Does that
| code enforce the participation of multiple distributed people
| to make updates, key exports, or key imports using shamirs
| secret sharing or similar?
|
| Or maybe it is just sitting on an amazon box somewhere a few
| people ssh to from their daily driver macbooks ?
|
| I don't -hate- centralized signing existing as an -option- if
| it is done very well and highly accountable (which fulcio is
| not, imo). That said, -mandating- centralized signing on
| behalf of developers as the only path is really insulting, as
| though people who write software can't type a couple commands
| to provision a PGP key on a smartcard and publish their key
| to keyoxide which is strictly better in every way from a
| threat modeling perspective.
|
| Speaking of Fuclio, this was meant to "invent" a solution for
| container signing, even though PGP multisig has existed from
| the start. No one used it because none of the major players
| in container software documented it other than the podman
| team.
|
| https://github.com/containers/image/blob/main/docs/container.
| .. https://docs.podman.io/en/latest/markdown/podman-image-
| trust...
|
| Back to NodeJS, Debian and Arch already sign npm packages
| with PGP keys. It works fine. We need to let people actually
| do that with NPM. Tell me how many supply chain attacks have
| happened in Debian or Arch recently compared to NPM?
|
| PGP may be a small barrier to entry, but it is a standard
| with solid smartcard support and works in practice. It should
| be the default recommendation to all developers, and end
| users should be able to set policies to only install packages
| signed by a trusted set of maintainer or reviewer keys.
| rkeene2 wrote:
| 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
| wslh wrote:
| I have round up more information on this issue and the context
| here [1].
|
| [1] https://news.ycombinator.com/item?id=38646314
| louislang wrote:
| 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
___________________________________________________________________
(page generated 2023-12-14 23:01 UTC)