{"id":48155,"date":"2023-05-10T09:49:09","date_gmt":"2023-05-10T13:49:09","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=48155"},"modified":"2023-06-02T05:42:47","modified_gmt":"2023-06-02T09:42:47","slug":"fake-trezor-hardware-crypto-wallet","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/fake-trezor-hardware-crypto-wallet\/48155\/","title":{"rendered":"Case study: fake hardware cryptowallet"},"content":{"rendered":"

Easy to steal and cash out, \u0441ryptocurrency is one of the most attractive digital assets for attackers<\/a>. Accordingly, serious investors often use hardware cryptowallets to protect their crypto-investments. Such a wallet stores private keys away from vulnerable computers and smartphones and makes it much safer to sign transactions. But unfortunately, owning a hardware wallet doesn\u2019t guarantee the safety of your funds<\/a>, as one of our clients has learned the hard way.<\/p>\n

Hack symptoms<\/h2>\n

Attackers worked stealthily: on a fateful day in the transaction\u00a0history of a cryptowallet there appeared an operation in which a large sum of money was transferred to someone else.\u00a0However, no transactions were performed on that day by the victim at all. Moreover, the cryptowallet wasn\u2019t even plugged into a computer!<\/p>\n

\"Aaand\u2026<\/a>

Aaand\u2026 It\u2019s gone!<\/p><\/div>\n

Dissecting the wallet<\/h2>\n

The victim had purchased the rather popular hardware wallet Trezor Model T<\/strong>. It uses fully open-source code \u2014 both software and hardware-wise \u2014 and is based on the popular STM32F427 microcontroller.<\/p>\n

The Trezor Model T vendor has undertaken a wide range security measures that, in theory, should reliably protect the device from attackers. Both the box and the unit housing are sealed with holographic stickers, the microcontroller is in flash memory read-out protection mode (RDP 2). The bootloader checks the digital signature of the firmware and, if an anomaly is detected, displays an unoriginal firmware message and deletes all the data in the wallet. Accessing the device and confirming transactions require a PIN code that\u00a0\u2014 even though it doesn\u2019t protect the master access key (a base for generating the mnemonic seed phrase)\u00a0\u2014 is used to encrypt the storage where it\u2019s kept. Optionally, in addition to the PIN, you can protect your master access key with a password as per the BIP-39 standard.<\/p>\n

\"Do<\/a>

Do not use me, I am unsafe! (Source<\/a>)<\/p><\/div>\n

At first cursory glance, the wallet we examined appeared to be exactly the same as a genuine one, and showed no signs of tampering. The unit was bought through a popular classifieds website, and the holographic stickers on the box and the wallet itself were all present and undamaged. When started-up in update mode, the wallet displayed firmware version 2.4.3 and bootloader version 2.0.4.<\/p>\n

\"Fake<\/a>

Fake wallet update mode screen<\/p><\/div>\n

When handling the wallet, nothing felt suspicious either: all the functions worked as they should, and the user interface was no different from the original one. However, mindful of the theft that had occurred via it, we delved deeper. And that\u2019s where our interesting discoveries began.<\/p>\n

Right off the bat, we found that the vendor had never released bootloader version 2.0.4. The project change history at GitHub concisely states that this version was \u201cskipped due to fake devices\u201d. After such an intriguing statement, we just had to reach for the scalpel and begin our dissection, of course\u2026<\/p>\n

\"What<\/a>

What on earth is version 2.0.4?<\/p><\/div>\n

The housing was difficult to open: its two halves were held together with liberal quantities of glue and double-sided adhesive tape instead of the ultrasonic bonding used on factory-made Trezors. Even more curiously, inside there was an entirely different microcontroller showing traces of soldering! Instead of the original STM32F427, the unit had an STM32F429 with fully deactivated microcontroller flash-memory read-out protection mechanisms (RDP 0 instead of RDP 2 in genuine Trezors).<\/p>\n

\"It<\/a>

It looked perfectly genuine from the outside; however\u2026 (left \u2014 original, right \u2014 fake)<\/p><\/div>\n

Thus, the fake cryptowallet theory was proved true: it was a classic supply-chain attack in which an unsuspecting victim buys an already-hacked device. But the actual cryptocurrency stealing mechanism was still unclear\u2026<\/p>\n\n

Trojan firmware<\/h2>\n

We won\u2019t repeat the commonplace truths about cryptowallets that we covered earlier<\/a>, but we\u2019ve just one little reminder for you: a cryptowallet contains your private key, and whoever knows that key can sign any transaction and spend your money. The fact that the attackers were able to conduct a transaction while the offline wallet was stashed in its owner\u2019s strongbox means that they either copied the private key after it was generated, or\u2026 they knew it all along!<\/p>\n

Thanks to the deactivated flash-memory read-out protection, which our attackers decided not to turn on after the new microcontroller was soldered in, we easily extracted the wallet firmware and, by reconstructing its code, discovered that the attackers indeed knew the private key in advance. But how?<\/p>\n

The original bootloader and wallet firmware received only three modifications:<\/p>\n

First<\/em>, the bootloader-checks for protection mechanisms and digital signatures were removed, thus getting rid of the \u201cred screen\u201d problem during the firmware originality check at startup.<\/p>\n

Second<\/em>, at the initialization stage or when resetting the wallet, the randomly generated seed phrase was replaced with one of 20 pre-generated seed phrases saved in the hacked firmware. The owner would begin using it instead of a new and unique one.<\/p>\n

Third<\/em>, if the user chose to set an additional master-seed protection password, only its first symbol (a\u2026z<\/em>, A\u2026Z<\/em>, 0\u20269<\/em> or !<\/em> for any special character) was used, which, together with the no-password option, gave just 64 possible combinations. Thus, to crack a given fake wallet, only 64*20=1280 variants were to be considered.<\/p>\n

The fake cryptowallet would operate as normal, but the attackers had full control over it from the very beginning. According to the transaction history, they were in no hurry, waiting a whole month after the wallet was credited for the first time before they grabbed the money. The owner had no protection whatsoever: the game was lost from the very moment the money first arrived in the Trojan wallet.<\/p>\n

Response from the manufacturer<\/h2>\n

After our investigation was published, we received feedback from Trezor \u2013 the manufacturer of the hardware cryptowallet mentioned in the post. Confirming the third-party intruder\u2019s modification of the device described in the post, Trezor officials noted the following:<\/p>\n