Technical write-up

This is the story of a wallet theft enabled by bad cryptography. It covers our research on problems with Libbitcoin Explorer 3.x (CVE-2023-39910), outlines how it is related to the Trust Wallet vulnerability (CVE-2023-31290), and shows some of the real-world impact that we were able to confirm. Additionally, it has some early research on problems with bx 2.x that we became aware of late in the disclosure process. If you’re looking for a less-technical summary, head over to the summary page and the FAQs.
这是由不良密码学实现的钱包盗窃的故事。它涵盖了我们对 (CVE-2023-39910) 问题 Libbitcoin Explorer 3.x 的研究,概述了它与 Trust Wallet 漏洞 (CVE-2023-31290) 的关系,并显示了我们能够确认的一些实际影响。此外,它还对我们在披露过程后期意识到的问题 bx 2.x 进行了一些早期研究。 如果您正在寻找技术性较低的摘要,请转到摘要页面和常见问题解答。

Table of Contents 目录

Part I - Tracing the Issue to the Source
第一部分 - 将问题追溯到源头

Please note that throughout this article, minor details relating to the victims have been omitted or changed.

Dude, Where’s my Cryptocurrency?

Our story starts on Friday, 21 July 2023. Upon attempting to use a well-protected cryptocurrency wallet, the wallet owner realizes that all of their funds stored in their wallet are gone. This was no accident – they were the victim of a sophisticated theft. The funds were sent to the attacker’s addresses on July 12th, at a time when the hardware wallet wasn’t in use for several days. (Details below)
我们的故事从 2023 年 7 月 21 日星期五开始。在尝试使用受保护良好的加密货币钱包时,钱包所有者意识到他们存储在钱包中的所有资金都消失了。 这绝非偶然——他们是一场复杂盗窃的受害者。这些资金于7月12日发送到攻击者的地址,当时硬件钱包已经好几天没有使用了。(详情如下)

The generation and use of the affected wallet was unusually strict:

  • Generated on an air-gapped Linux laptop with self-compiled software
    在带有自编译软件的气隙 Linux 笔记本电脑上生成
  • Use of BIP39 24 mnemonic word phrase
    BIP39 24助记词短语的使用
  • Mnemonic securely entered into Ledger & Trezor hardware wallets
    助记符安全地输入 Ledger & Trezor 硬件钱包
  • Good PIN and physical security on the hardware wallets
  • Mnemonic seed phrase never touched a non-air-gapped computer
  • Mnemonic seed backup well-protected

Dude, Where’s my Friend’s Cryptocurrency?

The victim reached out to their network of friends with similar key generation and management protocols, and a second victim was identified! The second victim also had the contents of their cryptocurrency wallet stolen during the same period of time – both victims Bitcoin (BTC) was stolen in the same minute on-chain. The victims realized this was no accident. They had fallen victim to a some type of hack.

The victims discovered their Bitcoin (BTC) holdings were not the only things stolen. The attackers had also taken Ethereum and other distinct cryptocurrency types from the same wallets. The victims realized this could only happen with an underlying leak of their main wallet private keys. Tricking their hardware wallets into authorizing incorrect transfers or breaking individual private keys of sub-accounts would manifest with a more limited impact.

A theft like this affecting two people at once despite their thorough precautions should be very unlikely. Even worse, the two victims weren’t the only ones affected by this. The publicly visible Bitcoin transactions of the theft pull in funds from what looks like many different wallets, possibly by up to a thousand different wallet owners on Bitcoin alone.

So, what in the world is going on!? Had someone found a remotely exploitable hardware wallet vulnerability, used it on a wide scale, and waited for months before executing the on-chain sweeping transactions collectively? Even worse, could one of the underlying cryptographic primitives be broken? Could Quantum Computer magic be involved? 😱

Tensions were running high - thus began the search for the source of compromise.

Our Cryptocurrency is Gone, But How!?!?

After coordination and communication, the two victims realized that their affected wallets were generated on a similar airgap laptop setup – although the individual victims’ wallets were generated several years apart. At that point, the issue seemed hard to pin down and could have originated from many sources. Our victims decided to start at the beginning – their wallet generation steps, from the first commands used and working their way up from there.

An essential tool that was involved in the wallet creation in both cases was the Libbitcoin Explorer in a 3.x version, via its bx binary. The Libbitcoin project has been around for a very long time (2011 !), is Open Source, and bx brings everything needed for an offline wallet generation in one self-contained binary.
在这两种情况下,参与钱包创建的一个重要工具是3.x版本的Libbitcoin Explorer,通过其 bx 二进制文件。Libbitcoin项目已经存在了很长时间(2011年!),是开源的,并将 bx 离线钱包生成所需的一切带到一个独立的二进制文件中。

Despite being a specialized tool that most wallet users won’t have heard of, bx has some popularity and is dedicated an appendix section in the “Mastering Bitcoin” book. In other words, it appeared to be a reasonable tool to use.
尽管它是大多数钱包用户不会听说过的专用工具,但它具有一定的知名度, bx 并且在“掌握比特币”一书中专门用于附录部分。换句话说,它似乎是一个合理的使用工具。

Brief example of the wallet generation workflow used in a Linux shell:
Linux shell中使用的钱包生成工作流程的简要示例:

# generate 256 bits of entropy, turn it into BIP39 mnemonics
bx seed -b 256 | bx mnemonic-new
<output of secret BIP39 mnemonic words>

The above command produces a 24 word BIP39 mnemonic phrase comparable to those of the victims’ wallet. This private key is the foundation of all wallet related security.
上面的命令生成一个 24 个单词的 BIP39 助记词,与受害者钱包的助记词相当。此私钥是所有钱包相关安全性的基础。

Could the bx binary command the victims used have something to do with the problem? The victims ensured that their /dev/random Random Number Generator (RNG) subsystem of the Linux laptops had sufficient entropy, but perhaps that wasn’t sufficient after all ..? Was there a major system configuration issue or virus?
受害者使用的 bx 二进制命令是否与问题有关?受害者确保他们的 /dev/random Linux 笔记本电脑的随机数生成器 (RNG) 子系统有足够的熵,但也许这还不够..?是否存在重大系统配置问题或病毒?

At this point in time, a handful of friends with Information Security backgrounds were called in to help review the situation and the relevant wallet generation code paths 🕵️‍♂️.
在这个时间点,一些具有信息安全背景的朋友被召集来帮助审查情况和相关钱包生成代码路径🕵️ ♂️。

As more eyes settle on the situation, the first signs of a major problem emerge.

Given Enough Eyes, All Bugs are Shallow?

The team decided that source code review of bx of the bx seed command is the logical place to start looking.
团队决定, bx seed 命令的 bx 源代码审查是开始查找的逻辑位置。

Running bx seed calls the new_seed(size_t bit_length) function in libbitcoin-explorer src/utility.cpp, which calls a pseudo_random_fill(data_chunk& out) function in the libbitcoin-system library:
运行 bx seed 调用libbitcoin-explorer src/utility.cpp中的函数,该 new_seed(size_t bit_length) 函数调用libbitcoin系统库中的 pseudo_random_fill(data_chunk& out) 函数:

console_result seed::invoke(std::ostream& output, std::ostream& error)
    const auto bit_length = get_bit_length_option();

    // These are soft requirements for security and rationality.
    // We use bit vs. byte length input as the more familiar convention.
    if (bit_length < minimum_seed_size * byte_bits ||
        bit_length % byte_bits != 0)
        error << BX_SEED_BIT_LENGTH_UNSUPPORTED << std::endl;
        return console_result::failure;

    const auto seed = new_seed(bit_length);
data_chunk new_seed(size_t bit_length)
    size_t fill_seed_size = bit_length / byte_bits;
    data_chunk seed(fill_seed_size);
    return seed;

Only pseudo-random? Alright, a pseudo-random number generator (PRNG) doesn’t have to be bad if it’s a Cryptographically Secure Pseudo Random Number Generator (CSPRNG). Perhaps everything is fine, but let’s take a closer look.
只有伪随机?好的,伪随机数生成器 (PRNG) 如果它是一个加密安全的伪随机数生成器 (CSPRNG),它不一定是坏的。也许一切都很好,但让我们仔细看看。

We follow the call path: pseudo_random::fill(data_chunk& out) -> pseudo_random::next() -> pseudo_random::next(uint8_t begin, uint8_t end) -> std::mt19937& pseudo_random::get_twister()
我们遵循调用路径: pseudo_random::fill(data_chunk& out) -> pseudo_random::next() -> pseudo_random::next(uint8_t begin, uint8_t end) -> std::mt19937& pseudo_random::get_twister()

Wait a moment. mt19937, twister - this uses the Mersenne Twister PRNG? 🤔 At this point, the first alarm bells are going off. Mersenne Twister is not a CSPRNG, so it shouldn’t be in any code path that generates secrets. One alarming property of the Mersenne Twister is that its internal state can be reversed by an attacker who knows a few hundred outputs, endangering the secrecy of the other outputs of the same stream that the attacker doesn’t know (in simplified terms).
等一下。 mt19937twister - 这使用梅森费尔托斯特 PRNG?🤔 在这一点上,第一个警钟正在响起。 Mersenne Twister不是CSPRNG,因此它不应该位于任何生成机密的代码路径中。Mersenne Twister的一个令人担忧的特性是,其内部状态可以被知道几百个输出的攻击者逆转,从而危及攻击者不知道的同一流的其他输出的保密性(简化)。

However, if the PRNG is re-seeded before every wallet generation, only one output is fetched, and the single result is kept secret, would the weak construction of MT19937 be fatal enough for a remote theft if everything else is done well?
但是,如果在每次钱包生成之前重新播种 PRNG,只获取一个输出,并且单个结果保密,那么如果其他一切都做得很好,MT19937 的弱结构是否足以致命到远程盗窃?

The search within this the pseudo_random.cpp code file continues, and we don’t have to go much further into the pseudo_random::get_twister() details to learn the actual problem.
在此 pseudo_random.cpp 代码文件中的搜索仍在继续,我们不必进一步了解 pseudo_random::get_twister() 细节来了解实际问题。

// Use the clock for seeding.
const auto get_clock_seed = []() NOEXCEPT
    const auto now = high_resolution_clock::now();
    return static_cast<uint32_t>(now.time_since_epoch().count());

// This is thread safe because the instance is thread static.
if (twister.get() == nullptr)
    // Seed with high resolution clock.
    twister.reset(new std::mt19937(get_clock_seed()));

What the hell !? A bad PRNG algorithm, seeded with only 32 bit of system time, used to generate long-lived wallet private keys that store cryptocurrency? 😧

The group of investigators had to perform a ‘double-take’ here – surely bx couldn’t use this to generate private keys.
调查小组不得不在这里执行“双重拍摄”——当然 bx 不能用它来生成私钥。

The team investigating the compromise could not believe this to be the case, and setup a simple experiment to validate the hypothesis. Like all good experiments, environmental variables were under the control of the experimenters, in this case – it was the variable time itself that was most relevant in studying the issue at hand. Using the official bx version 3.2.0 release binary in combination with the libfaketime library to test our theory, and run separate executions under exactly identical clock conditions:
调查妥协的团队不相信这是事实,并设置了一个简单的实验来验证假设。 像所有好的实验一样,环境变量在实验者的控制之下,在这种情况下 - 变量 time 本身与研究手头的问题最相关。 使用正式 bx 版本的 3.2.0 发布二进制文件与 libfaketime 库相结合来测试我们的理论,并在完全相同的时钟条件下运行单独的执行:

$ wget -O ~/.local/bin/bx
$ chmod +x ~/.local/bin/bx
$ sudo apt install libfaketime
$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/ FAKETIME_FMT=%s FAKETIME=0

$ bx seed -b 256 | bx mnemonic-new
milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

$ bx seed -b 256 | bx mnemonic-new
milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

💥 Same time - same “random” wallet! Unbelievable.
💥 同一时间 - 相同的“随机”钱包!难以置信。

A secure and reliable utility would not derive the same mnemonic seed phrase under these circumstances. This was the first hard evidence that the bx seed secret generation code in an official release uses the broken time-based pseudorandom function for wallet entropy.
在这种情况下,安全可靠的实用程序不会派生相同的助记词种子短语。这是官方版本中的 bx seed 秘密生成代码使用破碎的基于时间的伪随机函数进行钱包熵的第一个确凿证据。

Digging deeper, the team confirmed that the code uses the standard MT19937 Mersenne Twister PRNG variant which only operates on 32 bits of initial seeding input by design, and not the MT19937-64 extended variant with 64 bits of seeding. So the PRNG can at most have 2^32 starting positions as an upper bound, regardless if it’s seeded by /dev/random or time.
深入挖掘,该团队确认该代码使用标准的MT19937 Mersenne Twister PRNG变体,该变体仅在设计上对32位初始种子输入进行操作,而不是具有64位种子输入的MT19937-64扩展变体。因此,PRNG 最多可以有 2^32 个起始位置作为上限,无论它是按还是时间播 /dev/random 种。

To put this in different words: when running bx seed -b 256 to request 256 bits of non-guessable entropy, the result is 32 bits of high-precision clock time that was put through a blender (or rather: twister 🌪️) and expanded to 256 bit without adding new information. The number of possible key variations would grow exponentially with the size if this were real entropy data, so the difference from the safe expected result (256 bits) and the actual result (32 bits) is of astronomical proportions.
换句话说:当运行 bx seed -b 256 请求 256 位不可猜测的熵时,结果是 32 位高精度时钟时间通过搅拌机(或者更确切地说:扭曲器🌪️)并扩展到 256 位而不添加新信息。如果这是真实的熵数据,可能的关键变化的数量将随着大小呈指数增长,因此与安全预期结果(256 位)和实际结果(32 位)的差异是天文数字比例。

Anyone can re-compute and find a victim’s originally used entropy after a maximum of about 4.29 billion attempts if they have specific characteristics to look for to see if they successfully found a cryptocurrency wallet. In this case, by checking derived wallet addresses that were seen receiving funds on a public blockchain in the past. To put this number into perspective: brute-forcing this key space takes a few days of computation on the average gaming PC, at most. And unfortunately, anyone with sufficient programming skills could do it.
任何人都可以在最多大约 42.9 亿次尝试后重新计算并找到受害者最初使用的熵,如果他们有特定的特征要寻找,看看他们是否成功找到了加密货币钱包。在这种情况下,通过检查过去在公共区块链上接收资金的派生钱包地址。为了正确看待这个数字:在普通游戏 PC 上,暴力破解这个密钥空间最多需要几天的计算时间。不幸的是,任何具有足够编程技能的人都可以做到。

In terms of cryptocurrency wallet security, this is a pretty catastrophic situation.

Friday 21 July ends with a handful people who know that everything just got very complicated. Not only did some friends irrevocably lose complete control over their wallet private keys and funds - the ad-hoc group also has a serious disclosure problem on their hands.

Given that the theft was first identified in the US, early team members wanted to avoid failing to report a crime and get appropriate tax loss reporting for victims, and so an early disclosure of our findings to the FBI was made. We also saw this could be helpful in quickly limiting the fund movements of attackers on major exchanges, if that became necessary.

Part II - Context and Impact
第二部分 背景和影响

For this section, we’ll switch to a non-chronological presentation for readability.

Codename “Milk Sad” 代号“牛奶悲伤”

Faced with the unexpected task of handling an urgent disclosure, we were in need of a project name that was relevant yet told outsiders nothing about the technical issue. The suggestion was made to use the first two words of first BIP39 mnemonic secret generated by bx on time zero - milk sad wage cup reward [...] -> Milk Sad. We found our project name.
面对处理紧急披露的意外任务,我们需要一个相关的项目名称,但对技术问题一无所知。建议使用由时间零生成的第一个 BIP39 助记符秘密 bx 的前两个词 - milk sad wage cup reward [...] > 牛奶悲伤。我们找到了我们的项目名称。
Technical write-up

Not the First Hack: Weak entropy in Cake Wallet

Very early in our evaluation of the possible flaws that could lead to an issue like this, one of our team members recalled a weak entropy situation in Cake Wallet.

While no CVE was filed for Cake Wallet as far as we can tell, in May 2021 the Cake wallet team announced a weak entropy vulnerability in their wallets requiring all users to rotate their mnemonic phrases.
虽然据我们所知,Cake 钱包没有提交 CVE,但在 2021 年 5 月,Cake 钱包团队宣布其钱包中存在弱熵漏洞,要求所有用户轮换他们的助记词。

Some further investigation into this situation by Reddit user Pure-Cricket7485 revealed the glaring flaws in Cake Wallet’s entropy sourcing strategy.
Reddit用户Pure-Cricket7485对这种情况进行了进一步调查,揭示了Cake Wallet熵采购策略的明显缺陷。

Notably: Cake Wallet Used Dart’s non-secure Random() to generate wallet seeds:
值得注意的是:Cake Wallet使用Dart的非安全Random()来生成钱包种子:

Uint8List randomBytes(int length, {bool secure = false}) {
  assert(length > 0);
  final random = secure ? : Random();
  final ret = Uint8List(length);
  for (var i = 0; i < length; i++) {
    ret[i] = random.nextInt(256);
  return ret;

This can be a real problem considering Dart’s Random() can fall back to 0 or system time
考虑到 Dart 的 Random() 可以回退到 0 或系统时间,这可能是一个真正的问题

Random::Random() {
  uint64_t seed = FLAG_random_seed;
  if (seed == 0) {
    Dart_EntropySource callback = Dart::entropy_source_callback();
    if (callback != nullptr) {
      if (!callback(reinterpret_cast<uint8_t*>(&seed), sizeof(seed))) {
        // Callback failed. Reset the seed to 0.
        seed = 0;
  if (seed == 0) {
    // We did not get a seed so far. As a fallback we do use the current time.
    seed = OS::GetCurrentTimeMicros();

One Reddit user compared this approach to Mersenne Twister, which got us considering if bx had a similar flaw.
一位Reddit用户将这种方法与Mersenne Twister进行了比较,这让我们考虑了bx是否有类似的缺陷。

Not even the second Hack: Mersenne Twister use in Trust Wallet
甚至没有第二个黑客:Mersenne Twister在Trust Wallet中的使用

A few days into our disclosure process, we learned of the Trust Wallet vulnerability that Trust Wallet published in late April 2023. After reading Ledger Donjon’s excellent write-up on the discovery and research of CVE-2023-31290, we’re somewhat shocked: this is so close to the vulnerability in bx. And the Trust Wallet publication confirms that attacks on their user’s wallets go back as far as December 2022. Why did it take until mid-2023 for money to disappear from bx-generated wallets?
在我们的披露过程几天后,我们了解到 Trust 钱包于 2023 年 4 月下旬发布的 Trust 钱包漏洞。在阅读了 Ledger Donjon 关于 CVE-2023-31290 发现和研究的精彩文章后,我们有些震惊:这与 中的 bx 漏洞如此接近。Trust 钱包出版物证实,对其用户钱包的攻击可以追溯到 2022 年 12 月。为什么直到 2023 年年中,钱才从生成的钱包中 bx 消失?

There’s a lot to unpack here, so let’s start with the vulnerability details.

The vulnerable Trust Wallet version and bx share the same basic, fatal flaw of generating wallet entropy from the unsuited MT19937 Mersenne Twister algorithm. bx additionally uses some clock information to seed MT19937, but this doesn’t make a big difference to practical offline brute-force attacks by remote attackers. It’s still the same limited 32 bits of key space that attackers can comb through completely.
易受攻击的信任钱包版本,并具有相同的基本致命缺陷, bx 即从不适合的 MT19937 Mersenne Twister 算法生成钱包熵。 bx 此外,还使用一些时钟信息来播种 MT19937,但这对远程攻击者的实际脱机暴力攻击没有太大影响。它仍然是攻击者可以完全梳理的有限的 32 位密钥空间。

From what we know, Trust Wallet only creates 12 word BIP39 mnemonic based wallets, which fixes the entropy requirements (and therefore PRNG usage) to 128 bit. bx more is flexible and generates 128 bit, 192 bit, 256 bit outputs (and others). More variations means more search space, but do the wallets generated with bx seed -b 128 overlap with the ones created by Trust wallet?
据我们所知,Trust 钱包只创建 12 字 BIP39 助记符钱包,它将熵要求(因此 PRNG 用法)固定为 128 位。 bx MORE 非常灵活,可生成 128 位、192 位、256 位输出(以及其他输出)。更多的变体意味着更多的搜索空间,但是生成的 bx seed -b 128 钱包是否与Trust钱包创建的钱包重叠?

As it turns out, they do not - due to a nuance in the PRNG usage. The MT19937 Mersenne Twister algorithm used by Trust Wallet and bx is the same, but the output is consumed slightly differently.
事实证明,由于 PRNG 使用的细微差别,他们没有。Trust Wallet 使用的 MT19937 Mersenne Twister 算法 bx 相同,但消耗的输出略有不同。

When filling the entropy array with PRNG data, Trust Wallet consumes one MT19937 output of 32 bits, takes the least significant 8 bits of this output to fill the array, and throws away the other 24 bits via the & 0x000000ff bitwise-and in wasm/src/Random.cpp:
当用 PRNG 数据填充熵数组时,Trust 钱包会消耗一个 32 位的 MT19937 输出,取此输出中最低的 8 位来填充数组,并通过 wasm/src/Random.cpp & 0x000000ff 中的按位丢弃其他 24 位:

// Copyright © 2017-2022 Trust Wallet.


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; });

Due to the C++ mechanisms used in libbitcoin-system for pseudo_random::fill(), its code performs the same 32 bits -> 8 bits truncation, but exactly the other way around - taking the 8 most-significant bits from the PRNG instead.
由于 中使用的 libbitcoin-system pseudo_random::fill() C++机制,其代码执行相同的 32 位 - > 8 位截断,但恰恰相反 - 而是从 PRNG 中获取 8 个最重要的位。

As a result, all generated bx seed outputs are - to our knowledge - in a completely different key space than what the Trust Wallet code would generate, which means the BIP39 mnemonics are also different.
因此,据我们所知,所有生成的 bx seed 输出都与Trust Wallet代码生成的密钥空间完全不同,这意味着BIP39助记符也不同。

To confirm this, here’s a quick experiment. The Ledger Donjon write-up contains a specific example wallet that they describe as follows:
为了证实这一点,这里有一个快速实验。Ledger Donjon 的文章包含一个特定的示例钱包,他们描述如下:

RNG seed: 0x8ec170a8
sorry slush already pass garden decade grid drip machine cradle call put

If we re-compute RNG seed 0x8ec170a8 with the bx code for a 12 word BIP39 mnemonic, it comes out as the following instead:
如果我们使用 12 个单词 BIP39 助记符的代码重新 bx 计算 RNG 种子 0x8ec170a8 ,它会出现如下结果:

local chef load churn future essence type leave program weird ancient owner

This confirms that the the wallet generation process is indeed different.

In Ledger Donjon’s write-up, they close with the following line, which reads a lot like foreshadowing to us:
在Ledger Donjon的文章中,他们以以下行结束,这句话读起来很像给我们铺垫:

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…

However, we suspect the other wallets seen by Ledger Donjon weren’t wallets generated by bx 3.x versions, unless Ledger Donjon experimented a lot with the PRNG outputs and hit this other usage pattern. The presence of more affected wallets in the 12-word Trust Wallet range suggests there are yet other affected wallet generation tools out there which use MT19937, though. Due to time constraints, we did not investigate this further for the time being.
但是,我们怀疑 Ledger Donjon 看到的其他钱包不是由 bx 3.x 版本生成的钱包,除非 Ledger Donjon 对 PRNG 输出进行了大量实验并达到了其他使用模式。不过,在 12 字信任钱包范围内存在更多受影响的钱包表明还有其他受影响的钱包生成工具使用 MT19937。由于时间限制,我们暂时没有进一步调查。

When comparing our disclosure task on bx with that of Ledger on Trust Wallet, it’s notable that their disclosure was to a single, commercial, evidently well-funded wallet vendor. Based on their publications, Trust Wallet had direct communication paths to individual users that they could leverage to selectively inform them of vulnerabilities related to their wallet. Additionally, their wallet was only vulnerable for a limited amount of time, and the issue was discovered relatively quickly, with many users still regularly using the app.
当将我们的披露任务 bx 与 Trust Wallet 上的 Ledger 披露任务进行比较时,值得注意的是,他们的披露是针对一个单一的、商业的、显然资金充足的钱包供应商。根据他们的出版物,Trust Wallet与个人用户有直接的通信路径,他们可以利用这些路径有选择地通知他们与其钱包相关的漏洞。此外,他们的钱包仅在有限的时间内容易受到攻击,并且该问题被发现相对较快,许多用户仍然经常使用该应用程序。

In their post-mortem, the Trust Wallet team lists the total lost funds as $170,000 USD:
在事后分析中,Trust 钱包团队将损失的资金总额列为 170,000 美元:

Despite our best efforts, two exploits occurred, resulting in a total loss of approximately $170,000 USD at the time of the attack.
尽管我们尽了最大努力,但仍发生了两次漏洞利用,导致攻击发生时总共损失约 170,000 美元。

As we understand, Trust Wallet decided to financially incentivize users to move their funds to safety, as well as reimbursing lost funds for users affected by the theft. Additionally, they paid a significant $100,000 USD bug bounty to Ledger Donjon for the coordinated disclosure.
据我们了解,Trust Wallet决定在经济上激励用户将资金转移到安全地带,并为受盗窃影响的用户补偿损失的资金。此外,他们还向 Ledger Donjon 支付了 100,000 美元的巨额漏洞赏金,用于协调披露。

In our case, unfortunately, most of these factors did not apply. Given the Libbitcoin project’s noncommercial nature, lack of direct communication channels to end users, multiple years of affected wallets and likely widely imported/exported keys and BIP39 mnemonics, the situation was much more difficult on the security researcher side.

With the Trust Wallet & Ledger Donjon write-ups out there, all bx seed private keys compromised, and active on-chain exploitation for bx wallets ongoing, it was clear to us that a long coordinated disclosure was not beneficial. If we wanted to give affected bx wallet owners the chance to recover their funds, we would have to aim for a publication in days, not months. In this situation, time is on the side of the attackers rather than the victims.
随着Trust Wallet和Ledger Donjon的报道,所有 bx seed 私钥都被泄露,钱包的链上积极利用正在进行中,我们很清楚,长期协调的披露是没有好处的 bx 。如果我们想让受影响的 bx 钱包所有者有机会收回他们的资金,我们必须在几天而不是几个月内发布。在这种情况下,时间站在攻击者一边,而不是受害者一边。

Well-established security programs like Google Project Zero have a similar policy for actively exploited vulnerabilities:
像Google Project Zero这样的成熟安全程序对主动利用的漏洞也有类似的策略:

[…] if Project Zero finds evidence that a vulnerability is being actively exploited against real users “in the wild”, a 7-day disclosure policy replaces the 90-day policy. […]
[...]如果Project Zero发现有证据表明漏洞正在“野外”针对真实用户积极利用,则7天披露策略将取代90天策略。[...]

Ongoing On-Chain Thefts - Some Facts
持续的链上盗窃 - 一些事实

We decided to focus on Bitcoin as the main coin network for a limited analysis considering our time constraints. Due to the flexibility of bx seed output, funds on every BIP39 mnemonic (or even just BIP32 seed) compatible coin under the sun could be affected. With regular day jobs to take care of and limited time & compute resources, doing various steps 100x times wasn’t an option. This overview is therefore narrowly focused on Bitcoin, and only presents a partial view of the overall theft actions. Consider the presented figures a lower bound for the overall affected monetary value.
考虑到我们的时间限制,我们决定将比特币作为主要的硬币网络进行有限的分析。由于输出的 bx seed 灵活性,阳光下每个BIP39助记符(甚至只是BIP32种子)兼容硬币的资金可能会受到影响。由于需要处理常规的日常工作以及有限的时间和计算资源,因此无法执行 100 倍的各种步骤。因此,本概述狭隘地集中在比特币上,仅提供了整体盗窃行为的部分视图。 将所提供的数字视为整体受影响货币价值的下限。

For Bitcoin, there are two main clusters of transactions that we think were malicious:

1.) The big 2023-07-12 theft:
1.) 2023-07-12 大盗窃案:

date 日期 transaction 交易 destination address 目标地址 moved value 移动值 note 注意
2023-07-12 10:41 593e11588a2529ed.. 3GMQRwh8Yz1WVftL.. ~5.0538 14 inputs 14 路输入
2023-07-12 10:41 81cfe97cc16a4939.. 3LwDzjA1xH8amCHu.. ~9.744 BTC ~9.744 比特币 > 300 inputs
2023-07-12 10:41 a22b33a9a4ca0de2.. 3D2mKf28exn26v7B.. ~14.847 BTC ~14.847 比特币 > 1200 inputs

We attribute these to one well-prepared actor, who stole around ~29.65 BTC worth upwards of $850,000 USD in Bitcoin alone (8/2023 exchange rate). We think it’s likely this actor also carried out theft of other coins in the same day. At the time of writing, these funds have not moved away from their new location.
我们将这些归因于一位准备充分的演员,他偷走了大约 ~29.65 BTC,仅比特币价值超过 850,000 美元(8/2023 汇率)。我们认为该演员很可能在同一天还盗窃了其他硬币。在编写本报告时,这些资金尚未迁离新地点。

2.) There is a second, earlier pattern of fund movements that we suspect are also thefts:

This behavior started May 3rd 2023 and consisted of multiple smaller wallet sweeps which continued until July 15th. In total, we think this sweeping sums up to about 0.33 BTC. The funds have been moved again to further addresses, which differentiates this actor pattern from the first we outlined.
这种行为始于 2023 年 5 月 3 日,包括多次较小的钱包扫描,一直持续到 7 月 15 日。总的来说,我们认为这个横扫的总和约为0.33 BTC。资金已再次转移到进一步的地址,这使这种参与者模式与我们概述的第一个模式区分开来。

We have not seen any reports of stolen funds for these addresses. Theoretically, this special actor may be legitimately moving his funds from many distinct wallets (see further analysis) or he is a malicious actor. The addresses reported below are linked by being spent in the same transaction, which indicates that this a single actor or group.
我们没有看到任何关于这些地址资金被盗的报告。 从理论上讲,这个特殊行为者可能合法地从许多不同的钱包中转移资金(见进一步分析),或者他是一个恶意行为者。 下面报告的地址通过在同一笔交易中花费来链接,这表明这是一个单一的参与者或团体。

Suspected Attacker Addresses:

Here’s a list with some known coins with confirmed thefts (before the publication of this disclosure):

  • Bitcoin (BTC) 比特币 (比特币)
  • Ethereum (ETH) 以太坊 (ETH)
  • Ripple (XRP)
  • Dogecoin (DOGE) 狗狗币(狗狗币)
  • Solana (SOL) 索拉纳(溶胶)
  • Litecoin (LTC) 莱特币 (莱特币)
  • Bitcoin Cash (BCH) 比特币现金(BCH)
  • Zcash (ZEC) Zcash(ZEC)

There are likely many more coin types involved, as the additional cost to execute this attack on other coins for the affected wallets is limited to the R&D time required for identification and funds withdrawal. We hope that attackers have some increased risk of getting caught via coin-specific tracing of their identities and methods, but do not have anything to report there.

Overall, our estimation is that over $900,000 USD worth of cryptocurrency assets were moved as part of the overall theft actions (@exchange rate 8/2023), although some of the drained wallets may have been taken over via other vulnerabilities.
总体而言,我们的估计是,作为整体盗窃行动的一部分(@exchange率 8/2023),价值超过 900,000 美元的加密货币资产被转移,尽管一些耗尽的钱包可能已被其他漏洞接管。

Searching for Wallets - Motivation and Limits
搜索钱包 - 动机和限制

The primary reason for rapidly searching for affected Bitcoin wallets was to assess the overall damage in terms of magnitude of stolen & remaining funds, as well as to provide technical confirmation that the vulnerability was real and the sole explanation for the initially analyzed theft. We had some hope that if we came across any substantial remaining funds, there would be a small but non-zero chance to somehow inform the rightful owner so that they could save their funds. In the planning phase, we were considering options to relay a warning message to the wallet owner via a centralized cryptocurrency exchange used for direct deposits, finding wallet owners with publicly listed addresses, or discovering some other back channels. At the very least, we could extend the disclosure time scheduled in that case while searching for options.

Ultimately we did not identify any substantial remaining funds above a threshold of $5000 on the Bitcoin network in the analyzed ranges related to wallets generated with bx 3.x versions, as of the disclosure publication date. It’s plausible that larger sums of funds remain on similarly affected wallets of one sort of another, with slightly different derivation paths, but we did not find them with our analysis steps so far. It is also possible that some wallet owners use additional BIP39 passphrases, which provide moderate to strong protections depending on passphrase strength and other factors and make discovery much harder.
最终,截至披露发布日期,在与版本生成的 bx 3.x 钱包相关的分析范围内,我们没有发现比特币网络上任何超过5000美元阈值的大量剩余资金。更大的资金仍然停留在一种类似受影响的钱包中,这是合理的,其衍生路径略有不同,但到目前为止,我们的分析步骤还没有找到它们。一些钱包所有者也可能使用额外的BIP39密码短语,这些密码短语根据密码短语强度和其他因素提供中等到强大的保护,并使发现变得更加困难。

We want to be very clear on the scope of our research-related actions:

  1. The two originally described victims managed to recover a small portion of their own wallet contents that had not yet been stolen, using their regular wallet setup they had before the theft.
  2. We did not move any funds on any of the unknown victim wallets, on any coin.
  3. We do not know or are in any way associated with the attacker(s) that stole the funds.

In summary, none of the group members moved any funds that they were not the legal owner of, or knows the identities of the thiefs.

As far as we’re aware, even under ideal hypothetical circumstances, moving other people’s funds to avoid theft by bad actors can become a legal nightmare. Even in the most ideal scenario – where there is a single victim, clear ownership proofs, well-established identities on both sides, single jurisdiction and reliable private communication options - this carries a lot of risk.

In our situation, the circumstances were substantially worse than the ideal case in most ways we could think of. Therefore, we saw any scenario that involved us moving anything of any value, which we didn’t own before the disclosure, as opening the floodgates of legal problems. (Remember that we’re not lawyers, and this is not legal advice; We’re also not finance folks, so this is also NOT financial advice)

For the adventurous reader, who would consider going ahead anyway as a “white knight” in this case, please consider the following dilemma: any attacker can recompute the owner’s private keys, which nullifies the value of any cryptographic signatures with those keys. In any scenario that involves moving a wallet owners’s funds away to a wallet you control, how do you know the person showing up in your inbox (or on your doorstep) asking to get back “their” funds is the legal owner? Particularly if there is no centralized entity, such as a big cryptocurrency exchange, that backs the claim and can provide circumstantial evidence?

That’s a tough situation! And this dilemma doesn’t even touch other problems such as complying with anti-money-laundering (AML) laws, tax declarations, and a host of other aspects.

In case you are one of the affected victims of the theft: no, we definitely do not have your funds or know of a way to get them back. We’re sorry.

If it’s any consolation, we’ve worked hard to give our affected friends and all other victims at least some explanation and closure on why any funds could be stolen in the first place, and help them to avoid getting burned again by the same vulnerability.

You may use the lookup service to check if your wallet was impacted.

Searching for Wallets - Implementation
搜索钱包 - 实施

Please note that we’re intentionally vague on some non-trivial technical details, since we need to make an ethical trade-off between sharing the technical details that are needed to shine a light on this problem, and giving bad actors an unnecessary technical advantage on day 1. Additionally, while we are big fans of Open Source, we will not release custom code we wrote for parts of the on-chain analysis at this time for similar reasons.
请注意,我们故意在一些不平凡的技术细节上含糊不清,因为我们需要在分享揭示这个问题所需的技术细节和在第 1 天为不良行为者提供不必要的技术优势之间做出道德权衡。此外,虽然我们是开源的忠实粉丝,但出于类似的原因,我们目前不会发布我们为部分链上分析编写的自定义代码。

For our exploratory research, we focused on the BIP44, BIP49 and BIP84 standard address formats and derivation paths. Our primary focus was on finding both formerly used as well as currently used Bitcoin wallets generated by bx seed | bx mnemonic-new on bx 3.x versions with common BIP39 mnemonic word phrase lengths and settings.
对于我们的探索性研究,我们专注于BIP44,BIP49和BIP84标准地址格式和派生路径。我们的主要重点是查找以前使用和当前使用的比特币钱包,这些钱包由具有常见 BIP39 助记词短语长度和设置的版本 bx seed | bx mnemonic-new 生成 bx 3.x

Specifically, this covers:

  • 128 bits = 12 words, bx seed -b 128
    128 位 = 12 字, bx seed -b 128
  • 192 bits = 18 words, bx seed -b 192 (default)
    192 位 = 18 字, bx seed -b 192 (默认)
  • 256 bits = 24 words, bx seed -b 256
    256 位 = 24 字, bx seed -b 256

We used a publicly available list of all Bitcoin addresses historically seen by the Bitcoin network and constructed a bloom filter with a very low false positive rate on the data set. Using this filter, we were able to do quick address lookups to query and discard many unused wallet candidates, for which the relevant derived accounts were never seen by the network, without doing costly lookups to a Bitcoin full node.

We only consider wallets where the first address was used. The standard mandates to scan the first 20 addresses, but computing addresses is a bottle-neck in our search. We also only consider wallets using the standard derivation paths specified by BIP44, BIP49, and BIP84. In total, we discovered over 2600 distinct and actively used Bitcoin cryptocurrency wallets that are based on the bad bx seed entropy.
我们只考虑使用第一个地址的钱包。 标准要求扫描前 20 个地址,但计算地址是我们搜索中的一个瓶颈。 我们也只考虑使用 BIP44、BIP49 和 BIP84 指定的标准派生路径的钱包。 总的来说,我们发现了超过2600个基于坏 bx seed 熵的不同且积极使用的比特币加密货币钱包。

The majority of these wallets, a group of over 2550, has an oddly similar usage pattern with small deposits around the same dates in 2018. We think this is the result of some automatic tool use of bx, and that these wallets may actually share the same owner. We’re not sure what this experiment was about, but they’re all in the 256 bit seed output range and have a BIP49 address type (‘3’ prefix), which helps distinguishing them a bit from other addresses.
这些钱包中的大多数,超过2550个,具有奇怪的相似使用模式,2018年同一日期的小额存款。我们认为这是一些自动工具使用 bx 的结果,并且这些钱包实际上可能共享同一个所有者。我们不确定这个实验是关于什么的,但它们都在 256 位种子输出范围内,并且具有 BIP49 地址类型(“3”前缀),这有助于将它们与其他地址区分开来。

Excluding this large number of special wallets, we’ve identified less than 50 wallets with more individual usage patterns that we associate with likely use by human wallet owners. Those are distributed across the mentioned ranges and address types. We know this survey to be incomplete, as we have not discovered all wallets involved in the sweeps we observed on the blockchain.

Within this set of wallets, we were able to find and identify both of the initial victim’s wallets. This gives us confidence that our research into the the explanation for the theft is correct.

A decent portion of the discovered individually used wallets did not have any BTC funds on them since before 2023, so no money could be moved away from them by the attackers. However, we still consider them fully affected for two reasons:
自 2023 年之前以来,发现的个人使用的钱包中有相当一部分没有任何 BTC 资金,因此攻击者无法从他们身上转移任何资金。但是,我们仍然认为它们完全受到影响,原因有两个:

  1. Any new deposits to them are at risk of immediate, automated theft (as outlined in the Ledger Donjon article).
    向他们存入的任何新存款都有立即自动被盗的风险(如 Ledger Donjon 文章中所述)。
  2. Access to the underlying wallet private keys allows reconstructing all derived addresses on all coins, linking the wallet owner’s previous actions on all of them, a significant privacy impact.

Other Confirmed Victims of this Theft

Within a few days after the large theft of July 12th 2023, a victim of the theft came forward on Reddit:
在 2023 年 7 月 12 日发生大宗盗窃案后的几天内,一名盗窃受害者在 Reddit 上挺身而出:


The Reddit user u/0n0t0le provides an interesting data point, since he lost ~0.25BTC but was able to move away and recover over 1.05 BTC that the attackers didn’t find or take at that point.
Reddit用户u/0n0t0le提供了一个有趣的数据点,因为他损失了~0.25BTC,但能够离开并恢复超过1.05 BTC,攻击者当时没有找到或拿走。

We were able to confirm for case 1) that the user had their funds in a vulnerable wallet in the bx seed ranges.
我们能够确认案例 1) 用户的资金在范围内的 bx seed 易受攻击的钱包中。

Please note that BIP39 mnemonic secrets as well as other wallet private keys typically do not contain any clear indication on the software used to generate them. As a format designed to be exportable and importable between different wallet software, it is therefore possible that users do not clearly or correctly recall where a given wallet was created. This can lead to a lot of confusing information on potentially affected other wallet software, and makes fact-finding harder.

In the interest of correctness, we’re currently not listing other open leads that we’re following up on, but may update this section at a later point in time.

Basic Timeline of Thefts and Our Disclosure

Date 日期 Event 事件
2022-11-17 Ledger Donjon discloses Trust Wallet vulnerability to Binance
Ledger Donjon向币安披露了Trust Wallet漏洞
2022-11-21 Trust Wallet code patch on GitHub publicly removes Mersenne Twister usage
GitHub 上的 Trust 钱包代码补丁公开删除了 Mersenne Twister 的使用
2022-11-21+ 2022-11-21+ Trust Wallet selectively notifies affected users of the vulnerability
Trust 钱包有选择地通知受影响的用户该漏洞
2022-12-? 2022-12-? Vulnerable Trust Wallet wallets exploited on-chain (according to vendor)
2023-03-? 2023-03-? Vulnerable Trust Wallet wallets exploited on-chain again (according to vendor)
2023-04-22 Trust Wallet publicly discloses Trust Wallet vulnerability
2023-04-25 Ledger Donjon publishes their Trust Wallet vulnerability write-up
Ledger Donjon 发布他们的 Trust Wallet 漏洞文章
2023-05-03 First potential exploitation of bx 3.x wallets
钱包的 bx 3.x 第一次潜在利用
2023-07-12 Main exploitation of bx wallets
钱包的主要 bx 利用
2023-07-21 We discover the bx vulnerability during incident response analysis
我们在事件响应分析期间发现 bx 漏洞
2023-07-22 We send initial email to establish communications with the Libbitcoin team
我们发送初始电子邮件以与 Libbitcoin 团队建立沟通
2023-07-25 First Libbitcoin team response, indicating team is too busy for contact
第一个 Libbitcoin 团队回应,表明团队太忙而无法联系
2023-07-25 We send context information without vulnerability details to the Libbitcoin team, asking for followup
我们将没有漏洞细节的上下文信息发送给 Libbitcoin 团队,要求跟进
2023-08-03 We send technical vulnerability details and detailed disclosure context to the Libbitcoin team
我们向 Libbitcoin 团队发送技术漏洞详细信息和详细的披露背景
2023-08-03 Libbitcoin team response, indicating they do not feel this is a bug
2023-08-04 We request a CVE for the bx seed vulnerability in versions 3.x from MITRE
我们请求 MITRE 3.x 版本中漏洞的 bx seed CVE
2023-08-05 Libbitcoin team response, further detailing they do not feel this is a bug
2023-08-07 MITRE assigns CVE for the bx 3.x issue
MITRE 为 3.x 该问题分配 CVE bx
2023-08-08 Publication of this article

Please note that this timeline focuses on the main events and is not exhaustive.

Libbitcoin Team Response and Context

During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation.
在我们加速向 Libbitcoin 团队协调披露期间,Libbitcoin 团队很快对我们调查结果和 CVE 分配的相关性提出了异议。根据我们的理解,他们认为 bx seed 任何 bx 用户都不应该有效地使用命令,因为它被充分记录为不适合安全生成钱包。

We do not agree with this assessment.

Please consider the following timeline and linked resources:

Date 日期 Information 信息
2013-07-21 Libbitcoin Explorer predecessor tool adds a newseed command for entropy generation
Libbitcoin Explorer的前身工具增加了一个 newseed 用于熵生成的命令
2014-10-16 First Libbitcoin Explorer wiki documentation page for bx seed
第一个 Libbitcoin Explorer wiki 文档页面 bx seed
2014-12-14 First Libbitcoin Explorer (bx) release starting with version 2.0.0
第一个 Libbitcoin Explorer (bx) 版本从版本 2.0.0 开始
2015-12-21 Libbitcoin Explorer (bx) release 2.2.0
Libbitcoin Explorer (bx) 发布 2.2.0
2017-02-10 Libbitcoin Explorer (bx) release 2.3.0
Libbitcoin Explorer (bx) 发布 2.3.0
2015-01-19 A Libbitcoin team member adds and updates bx seed usage suggestions to “Mastering Bitcoin” (described below)
一位 Libbitcoin 团队成员添加和更新 bx seed 了“掌握比特币”的使用建议(如下所述)
2016-10-21 The Libbitcoin team changes the seed generation to Mersenne Twister via PR#559commit
Libbitcoin团队通过PR#559将种子生成更改为Mersenne Twister,提交
2017-03-08 Libbitcoin Explorer (bx) 3.0.0, includes PR#559
Libbitcoin Explorer (bx) 3.0.0,包括 PR#559
2019-08-29 Libbitcoin Explorer (bx) 3.6.0, currently latest official release
Libbitcoin Explorer (bx) 3.6.0,目前最新的官方版本
2021-05-02 bx seed command gets renamed to bx entropy on GitHub branch, still based on Mersenne Twister, PR#62812
bx seed 命令在 GitHub 分支上重命名, bx entropy 仍然基于 Mersenne Twister,PR#628,1,2

We’re aware of a single warning note in the bx seed documentation page in the wiki:
我们知道 wiki 的文档页面中 bx seed 有一个警告说明:

WARNING: Pseudorandom seeding can introduce cryptographic weakness into your keys. This command is provided as a convenience.

The wording “can introduce” is quite weak and a user may not be aware that this produces a seed that is completely insecure and should not be used to store anything of value.

When adding bx seed related workflows to the “Mastering Bitcoin” book appendix, Libbitcoin team members described it as follows:
在将相关工作流程添加到 bx seed “掌握比特币”一书附录时,Libbitcoin团队成员对此进行了如下描述:

Generate a random “seed” value using the seed command, which uses the operating system’s random number generator. Pass the seed to the ec-new command […] $ bx seed | bx ec-new > private_key [...]
使用 seed 命令生成随机“种子”值,该命令使用操作系统的随机数生成器。将种子传递给 ec-new 命令 [...] $ bx seed | bx ec-new > private_key [...]

Similarly, in “Mastering Bitcoin” Chapter 4:

You can also use the Bitcoin Explorer command-line tool (see [appdx_bx]) to generate and display private keys with the commands seed, ec-new, and ec-to-wif: $ bx seed | bx ec-new | bx ec-to-wif [...]
您还可以使用比特币浏览器命令行工具(参见[appdx_bx])生成和显示带有命令 seed ec-new 的私钥,和 ec-to-wif$ bx seed | bx ec-new | bx ec-to-wif [...]

Neither Chapter 4 nor the Appendix contain the warning that bx seed does not produce secure random numbers. The examples do not warn the user that wallets created like this are insecure.
第 4 章和附录均不包含不产生安全随机数的警告 bx seed 。 这些示例不会警告用户像这样创建的钱包是不安全的。

We informed the authors of “Mastering Bitcoin” and they will revise the text.

The following Libbitcoin documentation includes bx seed:
以下 Libbitcoin 文档包括 bx seed

Page  Command Excerpt 命令摘录 Last changed 上次更改时间
wiki landing page 维基登陆页面 bx seed | bx ec-new | bx ec-to-public | bx ec-to-address 7/2018
bx mnemonic-new documentation
BX 助记符-新文档
bx seed -b 128 | bx mnemonic-new 4/2017
bx hd-new documentation BX 高清 - 新文档 bx seed | bx hd-new 4/2022
Random Numbers 随机数 bx seed -b 256 7/2018

All these examples do not contain any warning that the created wallets are insecure.

Other notable characteristics:

  • The bx seed -b parameter cannot be configured to output less than 128 bits of binary output size. Related code comments on this limit include The minimum safe length of a seed in bits and These are soft requirements for security and rationality.. It seems strange that the design explicitly prevents the user from creating a seed that is too short, but does not prevent him from creating a seed that has not enough randomness.
    不能将该 bx seed -b 参数配置为输出小于 128 位的二进制输出大小。有关此限制的相关代码注释包括 The minimum safe length of a seed in bits 和 These are soft requirements for security and rationality. 。奇怪的是,该设计明确阻止用户创建太短的种子,但不阻止他创建具有足够随机性的种子。

General notes: 一般说明:

  • Dates regarding releases and commits are taken from Git/GitHub timestamp information. This may deviate from the actual dates in some cases.
    有关发布和提交的日期取自 Git/GitHub 时间戳信息。在某些情况下,这可能会偏离实际日期。

Suspected RNG Problems in Older bx Versions
旧 bx 版本中可疑的 RNG 问题

For the main part of our short and busy disclosure, we focused on the Mersenne Twister related issues in bx versions released after March 2017.
对于我们简短而繁忙的披露的主要部分,我们专注于 2017 年 3 月之后发布的版本中的 bx Mersenne Twister 相关问题。

However, we recently observed some behavior on older bx versions before 3.0.0 that indicate other weak random number generator behavior of bx seed, in part depending on the system environment bx is executed on. Specifically, the std::random_device entropy source in combination with std::default_random_engine may not behave securely enough if the random engine uses insufficient seeding and acts as a non-CSPRNG similar to Mersenne Twister.
但是,我们最近在旧 bx 版本上观察到了一些行为 3.0.0 ,这些行为表明其他 bx seed 弱随机数生成器的行为,部分取决于执行的系统环境 bx 。具体来说, std::random_device 如果随机引擎使用不足的种子并充当类似于Mersenne Twister的非CSPRNG,则熵源组合在一起 std::default_random_engine 的行为可能不够安全。

Tool 工具 Version 版本 Release 释放 Status 地位 Details 
sx 1.x ? 1.x ? 2014 🔍 likely affected (some systems)
🔍 可能受影响(某些系统)
std::random_device + std::default_random_engine
std::random_device + std::default_random_engine
bx 2.0.0 - 2.1.0 2014 - 2015 🔍 likely affected (some systems)
🔍 可能受影响(某些系统)
std::random_device + std::default_random_engine
std::random_device + std::default_random_engine
bx 2.2.0 - 2.3.0 2015 - 2017 ❔ unclear, improved behavior
❔ 不清楚,行为改善
std::random_device + std::uniform_int_distribution
std::random_device + std::uniform_int_distribution
bx 3.0.0 - 3.6.0 2017 - now 2017 - 至今 🔥 confirmed exploitable
🔥 确认可利用
get_clock_seed() + std::mt19937 Mersenne Twister
get_clock_seed() + std::mt19937 梅森龙卷风

Please regard this as preliminary indications of potential problems. It is possible that some of the public thefts exploit random number generator issues in versions before bx 3.0.0, but we have not confirmed this yet.
请将此视为潜在问题的初步迹象。一些公共盗窃可能利用了以前的 bx 3.0.0 版本中的随机数生成器问题,但我们尚未确认这一点。

We plan to follow up on this with additional research.

Part III - Summary and Outlook
第三部分 总结与展望

Basic Lessons Learned 吸取的基本教训

  • Use BIP39 passphrases for your wallets, ideally with a complex passphrase based on entropy from a separate source.
    为您的钱包使用 BIP39 密码短语,最好使用基于来自单独来源的熵的复杂密码短语。
  • Trust only heavily audited software to be in your wallet generation path.
  • Document every wallet generation setup for your future self, this may be very important.

Summary 总结

In this article, we presented technical information of a weak entropy generation function in Libbitcoin Explorer, confirmed the practical use of the weak function for over 2600 cryptocurrency wallets on the Bitcoin Mainnet, and connected it to a recent large theft of cryptocurrency funds on multiple popular blockchains that amounts to an estimated $900k of damages. Additionally, we described the close similarities with another actively exploited vulnerability in Trust Wallet, and provided some background on the Libbitcoin Explorer context and overall timeline.
在本文中,我们介绍了 Libbitcoin Explorer 中弱熵生成函数的技术信息,确认了弱函数在比特币主网上超过 2600 个加密货币钱包的实际使用,并将其与最近在多个流行区块链上发生的大量加密货币资金盗窃联系起来,估计造成 90 万美元的损失。此外,我们描述了与Trust Wallet中另一个被积极利用的漏洞的密切相似之处,并提供了有关Libbitcoin Explorer上下文和整体时间表的一些背景。

Future Work 未来工作

  • We plan further security research into bx 2.x RNG behavior.
    我们计划对 RNG 行为进行 bx 2.x 进一步的安全研究。
  • We may update this page in the next days as more information becomes available.

Additional References 其他参考资料

  • Security bug - Mersenne Twister MT19937 usage in Intel cryptography library
    安全漏洞 - 英特尔加密库中的梅森费尔托斯特 MT19937 用法

Commercial Work 商业工作

We have not received any reward for this research and are not accepting donations.

If you like our work, check out the following commercial services offered by different team members and organizations:

  • Distrust, LLC 不信任有限责任公司
    • Infosec firm focusing on high risk clients
    • Pentesting, threat modeling, hands-on security engineering
    • Full stack security evaluations and advisory retainer contracts
    • Covers: Shane Engelman, Anton Livaja, Ryan Heywood, and Lance Vick
  • Christian Reitter 克里斯蒂安·赖特
    • Freelance InfoSec Consultant
    • Pentesting, Code Audits, Security Research, Fuzzing
  • Heiko Schaefer 海科·舍费尔
    • Focus on OpenPGP: OpenPGP CA, Sequoia PGP, OpenPGP on HSM devices (OpenPGP card, PKCS #11, PIV)
      专注于OpenPGP:OpenPGP CA,Sequoia PGP,HSM设备上的OpenPGP(OpenPGP卡,PKCS #11,PIV)

Other Notes 其他注意事项

  • Included Libbitcoin code snippets are licensed under AGPLv3.
    包含的 Libbitcoin 代码片段在 AGPLv3 下获得许可。
  • For other code snippets, see the included copyright notice.

Credits 学分

  • Core Team  核心团队
  • Special Thanks  特别鸣谢
    • Jack Kearney - Turnkey 杰克·科尔尼 - 交钥匙
    • Several trusted advisors that wish to remain uncredited. You know who you are.

原文始发于milksad:Technical write-up

版权声明:admin 发表于 2023年8月17日 下午3:04。
转载请注明:Technical write-up | CTF导航