Funds of Every Wallet Created With The Trust Wallet Browser Extension Could Have Been Stolen Without Any User Interaction | Ledger (2024)

On November 14th 2022, Trust Wallet, a widely used software wallet, announced the release of its browser extension. It allows access to digital assets on several blockchains directly from the browser, and is a long-awaited addition to the existing iOS and Android apps.

The Ledger Donjon has recently discovered a critical vulnerability in this browser extension, allowing an attacker to steal all the assets of any wallet created with this extension, without any user interaction. By knowing the address of an account, it is possible to immediately compute its private key, then access all its funds. Below are details of the vulnerability, how the Ledger Donjon discovered it, its impact over time, an estimation of the vulnerable assets, and how Trust Wallet responded to fix it. But let’s start with recalling the basics.

How wallets are created

Entropy generation is tricky. As scientists, we like reproducibility and being able to explain phenomena with cause-and-effect principles. So, generally speaking it’s hard to generate randomness. Moreover, it’s tough to demonstrate that random numbers are correct, and a bad but not terminally flawed random number generator can easily fool the observer. For good randomness, we need uniform distribution of bits and bytes (and even all chunks size), and unpredictability. For an observer of a sequence, it must be impossible to have any information on the next part of the sequence to be generated.

As these properties are incredibly difficult to achieve, the cryptocurrency space tries to avoid relying on randomness as much as possible – but we still need it at one stage: when we create a new wallet.

You’re probably already familiar with your mnemonic, the 12 to 24 english words that allow you to backup your wallet (if not, you can checkLedger Academyarticle on this very topic).

This mnemonic encodes 16 to 32 bytes of entropy, according to theBIP 39 standard– the quality of this entropy is critical, since it’ll be the seed of all keys used by your wallet on all chains, following a deterministic derivation process defined by theBIP 32andBIP 44standards.

This Hierarchical Deterministic scheme is pretty much ubiquitous today, considering how easy it makes it for users to create a backup of an infinity of keys and its portability (despite BIP 39 being “unanimously discouraged for implementation”). Signer roaming is a powerful feature – when your favorite wallet fails or disappoints, you can just take your mnemonic with you (or even better, your Ledger device), switch to another one, keep your financial freedom and limit any impact of its downtime.

But again, it requires a flawless entropy source.

Overview of the Vulnerability

Trust Wallet relies onTrust Wallet Core, a cross-platform library that implements low-level cryptographic wallet functionality for many blockchains. It was mobile-focused, but it also targets Wasm since April 2022 (see#2132).

While most of the Trust Wallet Core is portable, a few modules and functions are very specific to a target. This is notably the case for the secure random generation part, used to create cryptographic material such as private keys, and mnemonic for HD wallets. Each implementation leverages the pseudorandom number generator (PRNG) offered by the operating system:

• For iOS,SecRandomCopyBytesis used.
• For Android, the entropy is provided by an instance ofjava.security.SecureRandom.

This is usually a good practice, as such primitives are supposed to be safe.

Wasm backend

There is a difference with the Wasm target. This module can run on several environments, like any browser supporting Wasm, or Node.js. These platforms do not provide a common strong PRNG, and one cannot get access to the “classic” system interfaces from these environments. For example, a Wasm module running in Chrome for Linux could not directly read/dev/urandom.

To tackle this, a dedicated so-called “secure random generator” has been implemented in#2240. It is based on a PR made in emscripten (see PR#12240in emscripten) written precisely to avoid reading/dev/urandom.

According to the author:

What we do here is simple, we wrapstd::random_devicewithstd::mt19937and return a random uint32 value, inspired byemscripten-core/emscripten#12240.

There is an important problem here, which leads to a critical vulnerability for wallet-core for Wasm and for any product relying on it: the PRNG used is a Mersenne Twister, and it should not be used for cryptographic purposes. Moreover, the specialized version mt19937 takes a single 32-bit value as input seed.

What are the consequences here? The custom Random module for Wasm implements two functions:random32which outputs a 32-bit random value, andrandom_bufferwhich fills a buffer of arbitrary size with random data. In the Wallet Core project, these functions are exclusively used by trezor-crypto, the cryptographic library developed by Trezor to ensure secure cryptography on their hardware wallets.

Now, let’s see how are generated HD wallets:

• Entrypoint is HDWallet. It takes a strength, and a passphrase to protect it later:

HDWallet::HDWallet(int strength, const std::string& passphrase) : passphrase(passphrase) { char buf[MnemonicBufLength]; const char* mnemonic_chars = mnemonic_generate(strength, buf, MnemonicBufLength); if (mnemonic_chars == nullptr) { throw std::invalid_argument("Invalid strength"); } mnemonic = mnemonic_chars; TW::memzero(buf, MnemonicBufLength); updateSeedAndEntropy();}

https://github.com/trustwallet/wallet-core/blob/3.1.0/src/HDWallet.cpp#L45

This functions then callsmnemonic_generateto create a BIP-39 mnemonic:

const char *mnemonic_generate(int strength, char *buf, int buflen) { if (strength % 32 || strength < 128 || strength > 256) { return 0; } uint8_t data[32] = {0}; random_buffer(data, 32); const char *r = mnemonic_from_data(data, strength / 8, buf, buflen); memzero(data, sizeof(data)); return r;}

https://github.com/trustwallet/wallet-core/blob/3.1.0/trezor-crypto/crypto/bip39.c#L55

mnemonic_generatecallsrandom_buffer, which outputs a random buffer filled using a Mersenne twister PRNG, whose instance has just been seeded:

void random_buffer(uint8_t* buf, size_t len) { std::mt19937 rng(std::random_device{}()); std::generate_n(buf, len, [&rng]() -> uint8_t { return rng() & 0x000000ff; }); return;}

https://github.com/trustwallet/wallet-core/blob/3.1.0/wasm/src/Random.cpp#L19

As the seed is just 32 bits, the Wasm version of wallet-core allows to create only 2^32 (~4 billion) possible mnemonics. All these mnemonics can be generated in a couple of hours in a single computer.

From there, an attacker is able to:

• Compute all the seeds, private keys, then addresses of every cryptocurrency handled by Trust Wallet.
• Scan the related blockchains to extract all the used addresses.
• Compute the intersection to get all the addresses of wallets created by Trust Wallet for Wasm, and steal their funds.

Running such attack takes much more than a couple of hours, but is doable with a few GPUs in less than a day (seemedium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoinfor a cost estimation. Attack is 256 times easier here).

Application to Trust Wallet browser extension

TheTrust Wallet browser extensionis an extension for Chromium-based browsers. It is clearly a MetaMask competitor, and is branded as a “secure multi-chain crypto wallet and gateway to thousands of Web3 decentralized applications (dApps).”

Extension is closed-source, but its code can be easily analyzed. It relies on the vulnerable Wasm implementation of Trust Wallet Core.

When a wallet is created, extension creates a 12-word mnemonic from a random 128-bit seed. Mnemonic is generated this way:

generateMnemonicWallet(e){return e||ct.error("Trying to generate wallet without password"),this.walletCore.HDWallet.create(Js.DEFAULT_STRENGTH,e)}

HDWallet.createis the auto-generated Wasm wrapper for the HDWallet constructor described above. That means the vulnerablerandom_bufferfunction is used, so mnemonics can be retrieved from the user address with a brute force attack.

This extension handles the following assets: AVAX, BNB, ETH, MATIC, SOL and TWT.

• Addresses are identical for ETH, BNB, MATIC, AVAX and TWT. These are standard Ethereum addresses, sharing the same derivation path (m/44’/60’/0’/0/0).
• Solana uses a different derivation path: m/44’/501’/0’/0’.

To drain the funds of all the Trust Wallet extension users, attacker can:

• Compute and store every possible mnemonic, then Ethereum private key and Ethereum address, that can be generated by this extension.
• Gather all the used Ethereum addresses created since the first release of the Trust Wallet browser extension, and store them locally.
• Perform a lookup in the address database.
• Empty wallet with the private key, if the address has been used.

These steps can be reproduced for every chain. We detail now how the Ledger Donjon implemented this attack on Ethereum and Binance Smart Chain, without, of course, draining the wallets.

Attacking Trust Wallet

The vulnerability allows an attacker to compute mnemonic from any address of a wallet created by the browser extension. For that, one needs to compute a mapping between the possible mnemonics and the resulting address.

Generating all the addresses the Trust Wallet extension can create

Based on the vulnerability in the PRNG previously explained, it is possible to enumerate all the addresses (and the related private keys) the Trust Wallet extension can create. My idea was to store every possible address in a big table. Then, from a list of addresses extracted from the Ethereum blockchain, one can check if some addresses are present in this table. If so, its private key can be computed.

Derivation from entropy to mnemonic then to Ethereum address uses the standard derivation mechanismBIP-32,BIP-39, and theBIP-44account hierarchy.

First difficulty was to enumerate all these addresses. Transformation from PRNG seed to address requires the following steps:

• Entropy generation: initialize the Mersenne Twister with the seed, and call it 16 times to gather the initial entropy.
• Entropy to mnemonic: one SHA-256 to compute the final checksum embedded in the last word.
• Mnemonic to seed: mnemonic are converted into a 512-bit seed using PKBDF2-HMAC-SHA512 with 2048 iterations. There are 2 SHA-512 computations per iteration, so total cost is 4096 SHA-512 computations.
• Seed to BIP-32 master key: 1 HMAC SHA-512 costing 2 SHA-512 computations.
• Master key to Ethereum private key: master key is derived on m/44’/60’/0’/0/0. This requires 3 hardened child private key derivations and 2 normal child key derivations.
  • Each hardened child private key derivation requires one HMAC SHA-512 (2 SHA-512) calculation and one addition on secp256k1.
  • Each normal child private key derivation requires a child private key derivation, and a scalar multiplication on secp256k1 to convert the private key provided in input to a public key.
• Ethereum private key to address: this last step requires a private to public key conversion, so another scalar multiplication, and one Keccak-256 hash.

Total cost for all these steps is then:

• Initialization and 16 calls to Mersenne Twister
• 1 SHA-256
• 4108 SHA-512
• 5 point additions
• 2 scalar multiplications on secp256k1

The most expensive steps are the SHA-512 computations and the scalar multiplications. To make it short, the overall process to transform the PRNG seed to an Ethereum address is slow. Running such computation on a single CPU would take months, and probably several weeks on the CPUs that were available in the Donjon. So, we implemented it using OpenCL (based onBIP39 Solver GPU) and ran it on 2 NVIDIA GeForce GTX 1080 Ti GPUs.

The output of this tool is a big file containing all the Ethereum addresses that the extension can generate. As there are 2^32 possible seeds, and each address is 20-bytes long, this table takes 80 Gb.

From there, table lookups are slow: to match an address, it would require iterating through all this big table.

To speed up these lookups, we split the table into 256 smaller tables, according to the first byte of the Ethereum address. Each table contains pairs of PRNG seeds, and their resulting Ethereum address.

Finally, to be able to perform fast lookups in each table, we sorted them according to the Ethereum address. It is now possible to do binary searches on these tables: lookups on these sorted tables are very cheap.

To save some disk space, we stored PRNG seed and only the first 8 bytes of each Ethereum address. The last 12 bytes are not necessary, as collisions are negligible in my use-case. Each entry takes then 12 bytes. Whole tables then take 48 Gb.

Here are the timings for each step:

Using these tables, it is possible to immediately retrieve the mnemonics used to generate an address. To assess the impact of the vulnerability, Binance asked me the mnemonic of 3 test addresses they provided. Here is the result:

$ time ./crack_address.py --table-dir /mnt/traces/tw/ 0xdf6D9547e163D5E7eafBe2FeB24Bfa12A4C913C0 0xE1E0580cb5eA0c0FD034FF2cdfc872ce4493676C 0x02b2Ae981b138F066344774A2AD75225A046c377Address: 0xdf6D9547e163D5E7eafBe2FeB24Bfa12A4C913C0RNG seed: 0xc92b023dMnemonic: stick bench smart report motor arrive enter river scale manage viable squeezePrivate key: 84117778e20a98f488234c89b6386b4175bb66ccf2fc77d14203f72a5a22686aAddress: 0xE1E0580cb5eA0c0FD034FF2cdfc872ce4493676CRNG seed: 0x1ae841e9Mnemonic: install issue guilt rescue slight barrel gasp vendor glimpse avocado cart frequentPrivate key: 3b0df65fe03a210661101172ca2a3e38fd75fdcc580248a2f28587c2ece0bba8Address: 0x02b2Ae981b138F066344774A2AD75225A046c377RNG seed: 0x2ed51a57Mnemonic: ginger pave slight million pencil flame monkey detect power protect soft derivePrivate key: 95a3be70efe04a7c06df98d68c4ccd7d453b0f39f6a097b24f2f2ac48d02494ereal 0m0,207suser 0m0,179ssys 0m0,028s

Retrieving the 3 mnemonics and private keys took a few hundred milliseconds. According to our tests,the process is actually fast enough to process in real time all the transactions on the Ethereum blockchain and to break all the vulnerable addresses as soon as they are used. By caching addresses already tested, the same applies for other blockchains such as BSC. In this attack scenario, one could monitor transactions when they reach the mempool, and compute sender or recipient private keys in real time.

Listing all the used Ethereum addresses

What we would like is to estimate the real number of vulnerable wallets, and their balance. This sounds easy, as all the transactions are public, hence all the addresses are available on the blockchain. However, there is no way to directly retrieve the list of the used addresses.

We implemented a method that iterates through every block of the Ethereum blockchain. We extracted the sender and recipient addresses of all the transactions, and the address parameters of every call to ERC-20 contracts.

Note that with this method, only used wallets can be detected: some vulnerable wallets that did not receive assets have never interacted with the blockchain.

We scanned the Ethereum blockchain between blocks 14820000 and 16096000. Block 14820000 was created on May 21 2022, hence just before the pull request that added the vulnerable code in Trust Wallet Core. 16096000 was the latest block when I wrote this post.

Public nodes seem to have a rate limit, so I queried several public nodes in parallel to gather a total of 147,910,120 addresses during several dozen hours. After duplicates are removed, we obtain a list of 32,613,317 unique addresses.

The same method has been used for Binance Smart Chain. Public BSC nodes have been scanned.

Estimating the number of vulnerable accounts

Finally, a tool to test if an address has been created by the Trust Wallet extension has been written. It makes a lookup in the generated tables, gets the PRNG seed, and from there compute the mnemonic, the Ethereum private key and the associated address.

Computation is very fast. Candidate addresses were sorted beforehand to minimize I/O and to perform a nested binary search. Lookups on the 32 million of addresses take a few minutes using a simple Python script.

Here is an example with an address taken from apublic tweetreplying to the announcement of the Trust Wallet extension. I took this one as an example as this address hasnever been used, so user funds are not at risk.

$ time python3 pwn_address.py 0xE17282BBbD0f32cA98683933382633ab6d9778B0RNG seed: 0x8ec170a8Mnemonic: sorry slush already pass garden decade grid drip machine cradle call putPrivate key: b9168c1fab55f840a5e04d96f7a38cb8803b67ec7c41f720fb6c487c08f3d536​real 0m0,194suser 0m0,170ssys 0m0,024s

Tool has been run on the dataset of 1,873,720 detailed above. Testing all the addresses and computing the private keys of vulnerable accounts took 4 min 22s, so it is very cheap.

With this list of vulnerable private keys, it’s possible to list all the corresponding addresses, their balances and obviously to drain them… During our investigations, around $30 millions were at risk at some point, but we didn’t monitor all chains and tokens overtime.

Remediation

2022, November the 17th

Vulnerability has been reported to Binance using theirbug bounty programon 2022, November the 17th.

To confirm the vulnerability, Binance sent us 3 addresses and asked them to provide mnemonics:

Can you please try to run your tool and provide mnemonics for these 3 addresses?
Wallet 1 – 0xdf6D9547e163D5E7eafBe2FeB24Bfa12A4C913C0
Wallet 2 – 0xE1E0580cb5eA0c0FD034FF2cdfc872ce4493676C
Wallet 3 – 0x02b2Ae981b138F066344774A2AD75225A046c377
Thanks!
Best regards.

Once all the possible addresses have been precomputed, retrieving the mnemonic from an address is as simple as a lookup in a 4-billion entries table. The three mnemonics have been retrieved in 0.2s:

$ time ./pwn_address.py 0xdf6D9547e163D5E7eafBe2FeB24Bfa12A4C913C0 0xE1E0580cb5eA0c0FD034FF2cdfc872ce4493676C 0x02b2Ae981b138F066344774A2AD75225A046c377Address: 0xdf6D9547e163D5E7eafBe2FeB24Bfa12A4C913C0RNG seed: 0xc92b023dMnemonic: stick bench smart report motor arrive enter river scale manage viable squeezePrivate key: 84117778e20a98f488234c89b6386b4175bb66ccf2fc77d14203f72a5a22686a​Address: 0xE1E0580cb5eA0c0FD034FF2cdfc872ce4493676CRNG seed: 0x1ae841e9Mnemonic: install issue guilt rescue slight barrel gasp vendor glimpse avocado cart frequentPrivate key: 3b0df65fe03a210661101172ca2a3e38fd75fdcc580248a2f28587c2ece0bba8​Address: 0x02b2Ae981b138F066344774A2AD75225A046c377RNG seed: 0x2ed51a57Mnemonic: ginger pave slight million pencil flame monkey detect power protect soft derivePrivate key: 95a3be70efe04a7c06df98d68c4ccd7d453b0f39f6a097b24f2f2ac48d02494e​real 0m0,229suser 0m0,194ssys 0m0,021s

2022, November the 21st

A few days after, on November the 21st, Trustwallet teampublicly committedon Github the fix avoiding the generation of new flawed seeds. We were quite worried someone would notice it and exploit the vulnerability.

2022, November

Trustwallet team updated the app to warn their users, prevent them from generating new flawed seeds and removed the receiving flows.

From there, we monitored the situation and the funds at risk. Only a few days after the release of this vulnerable wallets, around $30 millions were at risk.

2023, March

Trustwallet team granted us the highest bounty they offer : $100k

2023, April the 22nd

After months waiting for users to migrate their funds, Trustwallet team disclosed the vulnerability and wrote apostmortem. As of now, there are still wallets with remaining funds that can be stolen (~$100k). Trust Wallet promised the reimbursem*nt of stolen funds.

Conclusion

This vulnerability illustrates the worst case scenario of a crypto bug – compromised accounts forever.

Creating good randomness is a daunting task – Ledger devices rely on dedicated silicon logic in our certified smartcard chips that have been the gold standard of secure industries for the past 40 years to guarantee high quality randomness and tamper resistance.

Given the complexity of contacting the owners of those accounts and the possibility to use those compromised accounts on all kinds of different software and hardware wallets, TrustWallet did a pretty fine job reducing the risk for their users.

In the (very) (near) future it’s likely that bots will fight to be the first to steal funds deposited to those addresses, similar towhat happened with brain wallets in the past.

Special thanks to Jean-Baptiste Bédrune for saving the world. Only a few days after the release of the Trust Wallet extension, almost $30 millions were at risk. A nightmare scenario could have occurred if an attacker found the vulnerability after a couple of months.

During our investigations, we also noticed that a few addresses were vulnerable while they had been generated a long time before the Trust Wallet release. That probably means this vulnerability exists in some other wallet implementations which is concerning…