Easy to steal and cash out, сryptocurrency is one of the most attractive digital assets for attackers. 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’t guarantee the safety of your funds, as one of our clients has learned the hard way.
Attackers worked stealthily: on a fateful day in the transaction history of a cryptowallet there appeared an operation in which a large sum of money was transferred to someone else. However, no transactions were performed on that day by the victim at all. Moreover, the cryptowallet wasn’t even plugged into a computer!
Dissecting the wallet
The victim had purchased the rather popular hardware wallet Trezor Model T. It uses fully open-source code — both software and hardware-wise — and is based on the popular STM32F427 microcontroller.
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 — even though it doesn’t protect the master access key (a base for generating the mnemonic seed phrase) — is used to encrypt the storage where it’s kept. Optionally, in addition to the PIN, you can protect your master access key with a password as per the BIP-39 standard.
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.
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’s where our interesting discoveries began.
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 “skipped due to fake devices”. After such an intriguing statement, we just had to reach for the scalpel and begin our dissection, of course…
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).
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…
We won’t repeat the commonplace truths about cryptowallets that we covered earlier, but we’ve 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’s strongbox means that they either copied the private key after it was generated, or… they knew it all along!
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?
The original bootloader and wallet firmware received only three modifications:
First, the bootloader-checks for protection mechanisms and digital signatures were removed, thus getting rid of the “red screen” problem during the firmware originality check at startup.
Second, 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.
Third, if the user chose to set an additional master-seed protection password, only its first symbol (a…z, A…Z, 0…9 or ! 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.
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.
Response from the manufacturer
After our investigation was published, we received feedback from Trezor – the manufacturer of the hardware cryptowallet mentioned in the post. Confirming the third-party intruder’s modification of the device described in the post, Trezor officials noted the following:
- This attack on the supply chain happened over a year ago, and since then there’ve been no similar cases. After investigating the attack, Trezor published a blogpost with recommendations on how to avoid such problems.
- If you run the bootloader of the non-existent version 2.0.4 on an original device and try to install fake firmware, the user is notified that the wallet has unofficial firmware installed. If the user ignores this message and proceeds to update the new firmware, the warning appears again. Users should under no circumstances ignore these messages.
- In our post, it was stated that “the wallet was bought from a trusted seller through a popular classifieds website“. It was assumed that the seller was verified and assigned as “trusted” by the administration of the classifieds website, and not by Trezor. Trezor separately notes that only purchases of cryptowallets from official sellers are safe. To avoid ambiguity, we’ve edited this phrase, replacing it with “the wallet was bought through a popular classifieds website”.
In addition, Trezor strongly recommends that you adhere to the following guidelines when purchasing and using their hardware cryptowallets:
- Always buy hardware and software from an official vendor or seller.
- Never ignore warnings on your device or software.
- Keep your cryptowallet firmware always updated.
- Before using a new device, reset it to the factory settings.
How to prevent the fake device threat
It’s not easy to tell a fake cryptowallet from a real one without special knowledge and experience. The main safeguard is to buy your wallet directly from the official vendor and choose models with special versions of protected microcontrollers (even original Trezors aren’t ideal in this sense: there are other brands’ wallets with better protected chips and extra protection mechanisms).
It should be remembered that even an authentic and unmodified wallet can be vulnerable to a number of threats. The priority measures include the use of a password (if supported by your wallet), and, of course, protection for all computers and smartphones.