This post analyzes the attack on Ledger as an example of how a spear phising led to a software supply chain (SSC) attack on the software connect-kit tool that the company’s hardware wallets used, enabling the actor to drain monies worth $600,000 at least.
This attack came by the end of a year plagued with supply chain incidents. In this post we analyze the attack, its impact, how it was handled, and what lessons could be extracted.
Ledger and his hardware wallet users are obvious targets for cybecriminals. Wallet drainers were attacking Ledger users via phising attempts on the crypto apps front-ends, and the criminals need to know user coordinates to drive the phising campaigns. Ledger had a data breach by July 2023 as well as being part of the Sept 2020 data theft on their e-commerce Shopify, an incident with a large impact. The post “Update: Efforts to Protect Your Data and Prosecute the Spammers” shows how deep these breaches went.
Ledger needs to take security seriously (it is a key part of their business), with an internal research lab (donjon) handling device security certification, a bug bounty program, security bulletins, and threat modeling. So far so good …
How the attack was done
Ledger detected an exploit using Ledger’s DApp Connect Kit on Thursday the 14th of December 2023. This exploit injected malicious code inside Ethereum-based decentralized applications (DApps) that were using Ledger Connect Kit, tricking users into signing transactions that drain their wallets.
The exploit was quickly spotted and a resolution was implemented briefly after. In the meantime, a low volume of users fell into the attack and signed transactions draining their wallet.
The attack started when a former Ledger employee fell victim to a phishing attack that gained access to his/her NPM account via the session token. The attackers published malicious versions of the @ledgerhq/connect-kit (1.1.5, 1.1.6 and 1.1.7, now retired). The attackers could run arbitrary code with the same level of permissions as the wallet app: attackers can immediately drain users’ funds without interaction, distribute numerous phishing links to deceive users, or exploit users’ panic by convincing them to transfer assets to a new address, resulting in asset loss due to downloading a fake wallet.
Wallet front-ends (dApps) typically used the connect-kit-loader package from Ledger to load the Connect Kit at runtime from a JavaScript CDN (jsDelivr). Unfortunately, the URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 was not pinning the exact version (1.1.4 at the time), so when the malicious versions were uploaded, they got served (and cached) by the CDN. And no checksum was used to ensure that the downloaded resource from the CDN was actually the expected one (which should be used when distributing code from a CDN). This checksum-based scheme is named Subresource Integrity (SRI).
The injected code likely manipulated transaction data, fooling users into confirming manipulated payments. For example, a user approving a token payment to enable an app’s functionality may have instead seen an approval for a payment to the hacker’s address. No matter how secure the hardware wallet is, monies were drained.
Discovery and Investigation
Different users started to post messages in X (aka Twitter) that the Zapper front-end “was hijacked”. Credit goes to Mathew Lilley, the CTO of the cryptotrader Sushi, who first cautioned in a Twitter post that a “commonly used web3 connector” has been compromised. Later he pointed at LedgerHQ/connect-kit as the compromised library, and gave a first assessment, a bit bruntly:
What happened?
— I'm Software 🦇🔊 (@MatthewLilley) December 14, 2023
In short, @Ledger made a chain of terrible blunders.
1. They are loading JS from a CDN.
2. They are not version locking loaded JS.
3. They had their CDN compromised.
I would avoid using ANY dApps until their teams confirm that they have mitigated the attack. https://t.co/a3brXNQSx9
User 0xViva opened a ticket in the GitHub project repo: [URGENT] This repository utilizes a malicious version of npm package @ledgerhq/connect-kit, 1.1.7.
On Dec 15, 2023 the blockchain security form SlowMost published an analysis post giving full details of the malicious versions.
The Ledger hardware wallet was not compromised, only the Ledger Connect Kit. However, since many applications use that library, such as SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, etc., the scope of the impact was significant. According to bittrace.io, some victims, out of panic, tried to transfer assets to a new address, but downloaded a fake wallet app!
The very same day, Jameson Lopp accurately tweeted on the flaws that allowed the attack to succeed:
It sounds like today's security incident was the culmination of 3 separate failures at Ledger:
— Jameson Lopp (@lopp) December 14, 2023
1. Blindly loading code without pinning a specific version and checksum.
2. Not enforcing "2 man rules" around code review and deployment.
3. Not revoking former employee access.
How the incident was handled
The Ledger CEO, Pascal Gauthier, posted on the same day of the attack a disclosure letter giving further details on the incident, which is definitely good: Hiding the head in the sand like an ostrich is the worst way to handle any cybersecurity incident.
The structure of the letter is interesting: It promptly recognized the existence of malicious versions of the library draining monies, which is good (denying the reality is nonsense):
“Today we experienced an exploit on the Ledger Connect Kit, a Javascript library that implements a button allowing users to connect their Ledger device to third party DApps (wallet-connected Web sites).
This exploit was the result of a former employee falling victim to a phishing attack, which allowed a bad actor to upload a malicious file to Ledger’s NPMJS (a package manager for Javascript code shared between apps).
We worked swiftly, alongside our partner WalletConnect, to address the exploit, updating the NPMJS to remove and deactivate the malicious code within 40 minutes of discovery. This is a good example of the industry working swiftly together to address security challenges.”
What? A former employee with publishing rights had not its credentials on NPM revoked?
The CEO followed by enumerating the security controls in place but hinting that something was weak with the NPM access:
“Now, I’d like to address why this happened, how we will improve our security practices to mitigate this specific risk in the future, and share our recommendation to the industry, so we can be stronger together.
The standard practice at Ledger is that no single person can deploy code without review by multiple parties. We have strong access controls, internal reviews, and code multi-signatures when it comes to most parts of our development. This is the case in 99% of our internal systems. Any employee who leaves the company has their access revoked from every Ledger system.
This was an unfortunate isolated incident. It is a reminder that security is not static, and Ledger must continuously improve our security systems and processes. In this area, Ledger will implement stronger security controls, connecting our build pipeline that implements strict software supply chain security to the NPM distribution channel.”
Well, it seemed that the NPM account with permissions to publish new versions of the library had less stringent security controls than other parts of their software infrastructure. Isolated incident due to bad luck?
The ending of the letter is a more standard section of engagement with the authorities, “under control statement”, and apologies:
“Ledger has engaged with authorities and is doing all we can to help as this investigation unfolds. Ledger will support affected users in helping to find this bad actor, bring them to justice, track the funds, and work with law enforcement to help recover stolen assets from the hacker. We deeply regret the events that unfolded today for affected individuals.
The situation is now under control and the threat has passed. We understand the panic this caused for the community and broader ecosystem.”
The letter annexes a timeline, which is very good for users to understand how the incident was discovered, which specific containment and remediation actions were taken, and how the damage on affected users will be recovered / compensated. This is the most coin-specific part:
“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 has frozen the bad actor’s USDT.”
According to this, containment was swift as the rogue WalletConnect project for rerouting funds was disabled promptly. But even with this, some wallets were drained.
Aftermath: How The Industry Reacted
Some users expressed anger at Ledger for failing to prevent the compromise, while others cautioned against the dangers of relying on third-party libraries.
The cybersecurity industry has a niche in cybercoin. Wallet draining campaigns are well-known, which mainly use phishing sites to deceive end-users. The usual SaaS business (Scam-as-a-Service) has specialized actors for wallet draining, like the scam vendor Inferno Drainer which announced stop-of-operations in Nov 2023. This seems to be a false flag anyway, according to recent activity seen in Dune’s @scamsniffer. The scheme they follow was explained by this Group-IB post:
Some analysts gave hints on what failed to make the attack possible. This comment by user brianddk in the ticket on project’s repository gives us insights on the root cause:
A comment by another user, HenryQW, pointed at the second thing that made the malicious versions able to propagate via CDN:
It is too early to see long-term initiatives to make crypto wallet front-ends more robust against phishing attacks. Looks like requiring adherence to a standard similar to what the PA-DSS does for software vendors of payment applications could be welcomed in the crypto industry.
And Now, Lessons Learned!
It is amazing how a hardware wallet, the epitome of crypto security, was breached simply by graining access to NPM credentials of a Ledger “former employee” (probably username/password without 2FA protection, or an access token). This incident serves as a striking reminder that when you are under fire, your software infrastructure needs to be protected with the same care as your software or hardware products.
Most software supply chain attacks begin by compromising an internal account (often for a developer or devops engineer). The attackers then either move laterally to breach internal systems in the software infrastructure like the CI/CD system or the deployment tools, or manage to add malicious logic to source code repositories, which could be detected if proper handling of changes with branch protection and code reviews are in place. But attackers do not need to go so deep when the target is a popular library published in a public registry, especially if they can gain access to publish (write) credentials. And this is what happened in this attack.
2FA authentication, specifically using robust elements like security keys, limits the risk with interactive operations. For CI/CD pipelines, access tokens with limited access stored as a CI/CD secret is the usual way to go (and the access token should not be leaked). Unfortunately, it seems that the employee did not have a robust 2FA set. NPM allows organizations to enforce 2FA (but this is optional, not the default), which is probably what Ledger should have. And do not forget to add appropriate credentials revocation procedures for former employees, especially with access to resources as critical as the NPM scope owned by the organization.
Version pinning for dependencies with reviewed version bumps is a practice that mitigates the spread of malicious dependencies. In the context of the Ledger incident, the versions of the library that the connect-kit-loader took from CDN should have been pinned, and “do not trust whatever the CDN throws”. Having a checksum verification e.g. via SRI (or even a digital signature scheme also authenticating the source) should be used when pulling from a CDN for dynamic code loading.
The rest is a story.
For the more conventional phishing campaigns directed to wallet users, the question is: What makes users fall into traps set by criminals and to confirm transactions they never intended to perform? The phishing sites in this domain are well designed and convincing, imitating popular crypto brands; and they also offer free tokens, minting NFTs and other rewards. Avoiding users to fall into such traps is a problem looking for a solution.
And to not forget the related cryptohacking attacks, a more general threat, where the adversaries take over cloud infrastructures to run miners for cryptocurrency, often for privacy coins like Monero XMR and Zcash, with hidden transaction histories. Cryptojacking is relevant because it may affect ANY organization, and though the profit for the attacker could be low, the cost for the victim could be large (Sysdig mentioned in this report that it takes $53 in cost for the victim organization for every $1 mined for the attacker).
References
- Ticket “[URGENT] This repository utilizing a malicious version of npm package @ledgerhq/connect-kit, 1.1.7” in Github repository.
- Letter from the Ledger CEO on the incident, 14 Dec 2023.
- Security Incident Report, by Ledger, 20 Dec 2023.
- Ledger Exploit Endangers DeFi; Sushi Says ‘Do Not Interact With ANY dApps’, post in CoinDesk by Oliver Knight, 14 Dec 2023.
- Supply Chain Attack on Ledger Connect Kit: Analyzing the Impact and Preventive Measures. Post by SlowMist on the attack, Dec 2023.
- Web3 Security Concepts: Wallet Drainers, by Jammel Weaver, in Rektify AI, Jul 2023.
Watch our Video Demo
