LEIPZIG, GERMANY – Hardware based cryptocurrency wallets may not be as secure as promised. That’s the judgement of Dmitry Nedospasov, Thomas Roth and Josh Datko who together presented their research at a session here at the 35c3 conference called “wallet.fail.”
In the talk the researchers demonstrate firmware, side-channel, microcontroller and supply-chain attacks that impact a range of wallets including Trezor One, Ledger Nano S, and Ledger Blue. Naturally, the manufacturers responded, claiming the research had holes and attacks were impractical and their hardware was safe to use.
“The sad reality is there is just not a lot of security in cryptocurrency [development]. And that is painful to hear,” said Nedospasov, a hardware design and security engineer, during his talk.
A cryptocurrency wallet is designed to store the public and private keys used to receive or spend a specific cryptocurrency. Wallets can be stored on a computer, but many use a dedicated cryptocurrency hardware-based wallets, considered a safer alternative.
The vendor critiques are below, but first the research.
Supply Chain Attack
The supply chain attack carried out by researchers was simple. The goal was to simulate how someone could manipulate the device before it gets in the hands of the customer. To do this researchers were able to tamper with the packaging of a hardware-based cryptocurrency wallet. Using a hair drier they peeled back a holographic seal (or sticker) that indicated the wallet wasn’t counterfeit or hadn’t been tampered with.
“Stickers don’t work,” said Datko, an embedded systems engineer. “But once the sticker is off you faced with opening the enclosure.” That, he said, was also simple for the Trezor One, Ledger Nano S, and Ledger Blue wallets.
“From there the attack is, taking the microcontroller and reworking it,” he said. That entails replacing it with your own microcontroller that has its own bootloader. An open case also allows you to install your own hardware implant. In Datko scenario, he implanted an RF transmitter that allowed him to remotely (within close proximity) trigger a transaction.
Researchers said they found a vulnerability in the Ledger Nano S tied to the device’s use of the STM32 microcontroller. The bug allowed an attacker to flash the chips with a custom firmware. To prove the point researchers flashed the chip with a version of the game Snake (see below).
The vulnerability is tied to a developer flaw which left an open programming port open and enabled on the Ledger Nano S circuit board. Using this to their advantage, researchers detailed a way to manipulate the microcontroller and compromise cryptocurrency transactions.
The wallet did have built-in mitigations to prevent this type of attack, such as blacklisting an entire memory region so it would be impossible to flash over the firmware’s bootloader. Researchers found a bypass to the mitigations and were able to flash the microchip’s firmware with their own, giving them control over the wallet. The malicious firmware loads, compromising the device the moment it’s turned on.
For the side-channel proof-of-concept attack, researcher Roth demonstrated an attack against the Ledger Blue hardware that entailed using an antenna to sniff out PIN numbers of the user.
He discovered that the signal was amplified when it was plugged in with a USB cable. Next, using software defined radio equipment he was able to capture the radio waves. Using artificial intelligence Roth then isolated the radio patterns of each number pressed to determine what PIN number was pressed. The technique was able to accurately determine the PIN password 90 percent of the time.
The adversary, in his proof-of-concept attack, would have to be in close proximity to the device and use an antenna to pick up key pad signals as they traveled across the Ledger Blue’s conductor wire.
In 2017, the Trezor One was found vulnerable to a fault injection via a microcontroller used in the wallet. Trezor quickly patched the bug. But, researchers here say that using a different technique and focusing on a different microcontroller (STM32F2) a motivated attacker could steal the wallet’s private key and PIN from the device’s Random Access Memory (RAM).
“Compromising the STM32 microcontroller means you can compromise the entire device,” Nedospasov said.
Researchers observed the Trezor One backs private key data temporarily to the device’s RAM and then dumps it when it “glitches.” To access the private key data researchers initiated a firmware upgrade procedure when a glitch occurred. To help the team grab the RAM data dump, they devised a way to delay the RAM from being cleared long enough to access the private key and PIN number.
“When you review the relevant code you see [during the firmware upgrade process] that there is a call to backup metadata.. We observed the backup was from the memcopy we were interested in.. So our basic procedure was go into bootloader, start a firmware upgrade and stop it before the RAM gets cleared,” Roth said.
Next, they used a simple string program to extract the private key and user PIN from the RAM dump.
Trezor and Ledger Respond
Both Trezor and Ledger responded to the research presented at 35C3. Ledger called the proof-of-concept attacks unrealistic and impractical. In a blog, Ledger responded:
“They presented 3 attack paths which could give the impression that critical vulnerabilities were uncovered on Ledger devices. This is not the case. In particular they did not succeed to extract any seed nor PIN on a stolen device. Every sensitive assets stored on the Secure Element remain secure.”
Regarding the proof-of-concept attack against the Ledger Nano S, Ledger called the research impractical.
“They demonstrated that physically modifying the Ledger Nano S and installing a malware on the victim’s PC could allow a nearby attacker to sign a transaction after the PIN is entered and the Bitcoin app is launched. It would prove quite unpractical, and a motivated hacker would definitely use more efficient tricks (such as installing a camera to spy on the PIN entry),” the company wrote.
Regarding the presentation at #35c3, we were not informed ahead of time about the details of the disclosure. We are working with the info as it arrives.
We will address the vulnerability in due time—as soon as possible.
Details in thread:
— Trezor (@Trezor) December 28, 2018
Trezor replied via a tweet stating: “Regarding the presentation at #35c3, we were not informed ahead of time about the details of the disclosure. We are working with the info as it arrives. We will address the vulnerability in due time—as soon as possible.”
“Please keep in mind that this is a physical vuln. An attacker would need physical access to your device, specifically to the board—breaking the case. If you have physical control over your Trezor, you can keep on using it, and this vulnerability is not a threat to you.”
Please keep in mind that this is a physical vuln. An attacker would need physical access to your device, specifically to the board—breaking the case.
If you have physical control over your Trezor, you can keep on using it, and this vulnerability is not a threat to you.
— Trezor (@Trezor) December 28, 2018
The entire wallet.fail session can be viewed here.