Milk Sad at 38C3


Talk Recording

We presented a talk at the 38th Chaos Communication Congress (38C3) which took place in Hamburg on 27–30 Dec 2024.

Click below to watch the talk:

Language: English, optional German translation available via gear icon in lower right corner. See the privacy page for the video CDN hosting details.

Direct links: High-definition recording on media.ccc.de, fallback variant on Youtube.

Context

See the talk schedule entry for the conference.

After the official short Q&A on-stage, we had an extended Q&A workshop room session without recording right after the talk.

Our previous announcement:

In case you’re reading this before the talk takes place, feel free to ask for us at the Church of Cryptography assembly, where our team member and talk speaker John Naulty (aka sather) will host a number of cryptography related sessions on topics adjacent to Milk Sad. We’re interested in your questions and comments on our work!

Talk Notes

Intro

If you’re here, you probably saw our presentation (or a copy of the slides) and followed the QR code link here. Welcome!

We designed our presentation to be more approachable to viewers who do not interact with cryptography, cryptocurrencies, or security research on a daily basis. However, some of you do, or simply want to know more! Here are the more technical notes and references with links to support the presentation and show you some paths deeper down the rabbit hole.

The Team

Our research has been the work of many people throughout different stages. The credits section is the public list of people involved in CVE-2023-39910 and the initial intensive weeks of research and disclosure. To summarize, many friends and colleagues with a background in development and infosec got together to work out the initial mystery and its implications.

From there, a smaller subgroup continued the research into wallet details, real world usage and related vulnerabilities.

The July 2023 Theft

The best place to start on this topic is our initial disclosure writeup, which tells the initial story and context of wallet security, how we got involved, and how the first events unfolded from our perspective. If you want to jump ahead to the code snippets that explain how bx seed was vulnerable, go here. If you would like to see the security research and disclosure from Ledger Donjon that preceded ours in early 2023 on a very similar vulnerability in Trust Wallet, go here.

The disclosure timeline and our notes on the libbitcoin team’s response give some context on why the disclosure was extra difficult for us, in addition to the inherent complexities of quickly disclosing a serious vulnerability that is exploited in the wild.

Instead of trying to update the first writeup article with all the new information, we switched to a different and more incremental format. On the research updates page, you find a list of separate articles on our progress and different topics.

For example, update #1 from November 2023 shows details on the key sizes, address formats and path usage of the discovered wallets in the weak range associated with libbitcoin-explorer. There, we also describe weak wallets in that range which don’t use the BIP39 standard, and outline how much Ethereum we think was stolen in the July 2023 attack. In update #5, we described some additional data on how many Bitcoins were stolen in July 2023, and where they came from.

Technical Background

Cryptography and Cryptocurrencies are really complex subjects. In the presentation, we had to cut this down to the essentials.

Specifications:

Random number generators are also a big topic, so we’ll just link to some of the bad ones that were involved in the flaws:

The Milk Sad Project Name

Running bx seed with a system timestamp of 0 (PRNG seed 0x0) to generate a 24-word always gives the following BIP39 mnemonic secret:

milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

Brute Force Attack

In the absence of other shortcuts, trying all possible combinations is one of the most basic attacks and basically applies to all security systems out there which use secrets.

Modern symmetric key cryptography uses key sizes of over 112 bit, and the NIST recommendation for usage beyond 2030 is 128 bit. Through the exponentially increasing number space of longer binary values, naive brute-force attacks also get exponentially more complex. Note that the “bit” sizes of keys are different and not directly comparable for some asymmetric key algorithms, so it’s easier to think about symmetric encryption standards like AES than about asymmetric standards like RSA here. Correctly generated keys of sizes equivalent with the NIST recommendations are thoroughly infeasible to brute-force (in the absence of other severe flaws), even with extreme amounts of computation power or special hardware and decades of patience.

By weakening cryptocurrency wallets from their supposed key strength of between 128 bit to 256 bit (depending on the chosen BIP39 variant) down to 32 bit, they turn from “unbreakable” to “everyone knows they’re trivial to break”, cryptographically speaking.

When researching weak wallets, the main challenge and computational effort is not in generating the weak initial PRNG data, but in the BIP39 key derivation (SHA512 hashing) and in the BIP32 key derivations with multiple child keys, which vary based on the evaluated derivation path. Additionally, finding wallets with actual usage on the blockchain requires pre-computing, storing and quickly checking information on wallet addresses - per blockchain (coin type)! Compared to this, the last step of generating relevant addresses from public keys is usually fairly cheap.

Some context on the practical aspects are in the initial writeup. Our update #3 goes into some depth on our data sources and the bloom filter we used for fast space-efficient lookups of addresses in memory. In update #8, we further described the necessary work and how we were able to speed up the BIP32 computations by 6x on our machine via changes to some core libraries via unorthodox changes (our code forks for this are public).

Trust Wallet Flaws

The Trust Wallet software has the unfortunate distinction of having two separate, serious PRNG flaws over the lifetime of the software.

The “first” flaw, and the one we were aware of during our initial disclosure, is CVE-2023-31290. Here, a Trust Wallet variant also used the Mersenne Twister PRNG, and generated very similar (but different!) weak wallet ranges to libbitcoin. We covered this in the initial writeup and update #2.

In early 2024, the nice folks from SECBIT Labs disclosed CVE-2024-23660 on an older vulnerability, which we investigated in update #5. In this “second” flaw, incorrect usage of the trezor-crypto library led to the use of the MINSTD_RAND0 algorithm with LCG16807 and time-based seeding when used under iOS. This is even easier to break then the other wallet ranges, since the key complexity is effectively less than 31 bit in this case. In the same article, we also showed when relevant wallets were generated and how they were used.

Wallets with Extreme History

That’s a wild one, we know. See update #7 for details.

Cake Wallet

The Cake Wallet vulnerability has been public for years, and so we mentioned it in the initial writeup. However, after some persistent digging and some luck, we were able to go further in the analysis and wallet recovery efforts than other people before us, leading to new results and a lengthy road to publication due to concerns about some remaining funds.

See update #6, update #9, update #10.

Ethical Challenges

See the talk recording.

Statistics

Details on the wallet numbers and usage statistics:

Defense

For wallet users, one particular mechanism we can recommend is to use a BIP39 passphrase. This is a separate secret from the BIP39 mnemonic phrase, and can be seen as an additional encryption layer. An attacker has to know both to derive the correct wallet keys and steal funds. In the context of wallets generated from weak PRNGs, the use of a sufficiently complex BIP39 passphrase basically hides these keys from the attacker, giving the victim a lot more time and opportunities to learn about the wallet problem and move their funds to a more secure wallet. Weak passphrases can still be broken, but since the attacker has to try this for every potentially interesting wallet, any reasonably strong passphrases add a significant additional amount of work for attackers.

Research Outlook

New exploratory wallet-related research is currently on hold. We still have some interesting things to share, but may take a while until we get around to writing them up.

Data, Code

See update #11.

If you want to get hands-on and investigate some of the discovered weak wallets on your own, the easiest place to start are our published lists of weak Bitcoin and Ethereum addresses.

Contact

See contact.