Ledger Exploit — A Semi-Technical Perspective

Read to learn the following:

1. What happened? (Based on what we know)
2. Why wasn’t Ferrum Network impacted?
3. What did we learn?

What happened? (Based on what we know now)

Ledger was exploited earlier today. Ferrum Network announced this issue earlier.

Let’s dive into the findings from Ledger

Finding by Ledger

1. On Thursday morning, CET, a former Ledger Employee, fell victim to a phishing attack that gained access to their NPMJS account.

Problem

1. This shows that even the most versed web3 players are susceptible to phishing attacks. However, the larger problem here is #OpSec on the part of Ledger
2. Why did a former Ledger Employee still have access and permission to push updates to Ledger NPM? Employee access should be revoked as part of the employee exit process.

Finding by Ledger

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.

Problem

1. The attacker was able to push code to production by using the credentials of a former employee. Why are developers allowed to push updates that impact production codebases directly to NPM repos? There should be a process that requires approvals before code updates can be pushed to critical packages and repos.
2. What exactly does a rogue Wallet Connect project mean? Why is it so easy to swap official Wallet Connect production deployments with this supposed rogue project? Where are the layers of approval to make production updates that impact millions of users and billions of dollars?

Why wasn’t Ferrum Network impacted?

When Wallet Connect pushed its last major update, Ferrum disabled the Wallet Connect integration on our dApps. This prevented Ferrum Community members and dApp users from being exposed to this Ledger exploit. I want to emphasize this was a stroke of luck. We had other items on our roadmap and didn’t push out the latest Wallet Connect integration to prod for our dApps. If we had done so, our own users would be exposed to the exploit as well.

It doesn’t stop here, though. Other than the prioritization coincidence that saved Ferrum users, Ferrum Network deployment procedures lean towards mitigation efforts to avoid exploit vectors.

For example:

1. The development team is not able to push code to production
2. There is a dedicated set of production engineers, only 3 individuals in the organization are able to interact with production systems
3. This applies to our GitHub code bases as well.
4. No developer is able to submit code to Ferrum-maintained repos.
5. Each developer must fork the repo like an open-source contributor
6. Once they work on their code, they must submit a PR against ferrum/develop branch that has to be reviewed and approved by Ferrum Maintainers.
7. Even at this point, the code is only merged into ferrum/develop branches. Any direct code merge requests to ferrum/main production branches by developers and/or contributors are denied
8. Once the maintainers approve and merge the developer code into ferrum/develop, they must create a release. Only 3 individuals at the organization are capable of doing this
9. Once a release is created, it must be reviewed, and then it can be merged into ferrum/main
10. At this point, either our infrastructure deployment process takes over, or the production engineers with rights to production accounts can deploy the code
11. Access to production systems is restricted further by SSO and 2FA enforcement

As you can see, Ferrum Network takes security very seriously. We operate from a basis of paranoia when it comes to security and try to put in mitigation measures and procedures to limit exposure in the event of potential attacks.

What did we learn?

Even with all of the security procedures we have in place at Ferrum Network, if we had used the Wallet Connect integration in our dApps at the time of the exploit, our dApps would still be impacted.

How can this be possible when we have done everything possible to secure our systems, deployment procedures, and application code?

Well…. Welcome to #web3, while web3 is the new frontier in software development, it is also still the wild west of development practices. The standards and security principles developed and matured over decades in web2 haven’t fully been adopted by web3 teams just yet.

In this example, the oversight from Ledger team on the problems described above, coupled with an automatic update of dependancies by upstream providers could have led to this exploit. As a practice dependency versions should be explicitly defined and not set to auto-update to the latest version. For one, this can crash your #dApp if a breaking change is introduced by the dependency maintainers, but much worse is this situation where malicious code was injected into the dependency, and then updated and applied to your dApp.

Summary

Web3 Teams

1. Review and update or implement #OpSec processes that define how to handle employee exit, production deployment restrictions, and archived apps.
2. Enforce 2fa, SSO, and require multiple layers of approval for production deployments and code updates.

Web3 Users

1. Don’t blindly sign transactions. Review the call data and try to understand what the #dApp is requesting a signature for.
2. As a best practice, revoke approvals once you are done conducting a specific transaction.
3. Always use burner wallets when interacting with test and or beta applications.
4. Keep your treasury and funds in wallets that do not interact with smart contracts or dApps and only move to hot wallets or active wallets when there is a need to swap, stake, bridge, etc.
5. Only move the amount needed, conduct the swap, bridge, and stake transaction, and then revoke approvals.
6. By taking the above steps, you will reduce the chances of exposing your entire net worth to the possibility of an exploit resulting from some employee at some company succumbing to a phishing scam.

Some things you should know

1. The importance of hardware wallets:
   Although no system is completely foolproof, hardware wallets like Ledger offer an added layer of security compared to software wallets. It’s important to note that the exploit in question was a supply chain attack, which means it targeted the software used to interact with the hardware wallet. This doesn’t mean that hardware wallets are not secure, but rather that users should be cautious when using any software that interacts with their hardware wallet.
2. The role of open-source software:
   Open-source software can be a double-edged sword. On one hand, it allows for transparency and collaboration, which can lead to more secure and robust systems. On the other hand, it can also make it easier for malicious actors to find and exploit vulnerabilities. It’s crucial for developers to stay vigilant and actively monitor and update their dependencies, as well as to encourage responsible disclosure of vulnerabilities.
3. The need for better security education:
   As mentioned in the post, even the most experienced web3 players can fall victim to phishing attacks. This highlights the need for better security education and awareness for users at all levels. Users should be encouraged to learn more about common attack vectors, best practices for securing their accounts and assets, and how to identify and avoid potential scams.

Stay safe, stay vigilant.

About Ferrum Network

Ferrum is Pioneering Interoperability 2.0 — a new era of interconnected blockchains. Powered by a multichain messaging engine known as Quantum Portal, Ferrum Network’s mainnet will bring value, data, and functional interoperability to every chain in the industry.

Utilize Ferrum Network to build and deploy solutions on one network and instantly enable multichain functionality without the burden or technical debt that comes with managing a multichain infrastructure.

Ferrum Network Important Links

Website | Telegram | Twitter | YouTube | Discord