Blog posts
-
While auditing internal infrastructure for Radically Open Security, I discovered a weakness in the
devise-two-factorTime-based One-time Password (TOTP) library. With the help of Chris MacNaughton, we confirmed the vulnerability and informed the upstream vendor of the library.
This article has some details about the vulnerability and disclosure. -
In late July and August 2023, a team of fellow researchers and I rushed to understand, write up and publish a serious cryptocurrency wallet creation issue in the
Libbitcoin Explorerbxsoftware tool that left victims exposed to remote & automated wide-scale theft of funds.
The coordinated theft of assets that happened on 2023-07-12, during whichbxuser’s funds were targeted among with other weak wallet types, amounted to millions of dollars in damages across hundreds of victims and various blockchains and coin types. -
Heiko Schäfer discovered a new security issue in the Yubico
yubihsm_pkcs11.sodriver library, which we disclosed together to Yubico. The YubiHSM PKCS#11 client-side library is designed to interact with Yubico HSM2 hardware security modules. Due to flaws in the memory handling, the library code accidentally returns 8192 bytes of previously used process memory under some circumstances. This impacts the memory confidentiality of the calling program for some usages. -
The article describes a new vulnerability in the KeepKey hardware wallet. Vulnerable code in the Ethereum transaction handling can leak memory from attacker-controlled address locations onto the display when processing a crafted EthereumSignTx message. An attacker with physical access to an unlocked KeepKey device can extract the BIP39 seed or other confidential device secrets via this flaw without tampering with the device hardware or leaving permanent traces.
-
I have discovered two new security issues in the Yubico libykpiv client-side code which were introduced as a regression in the
2.3.0release. Flaws in the memory handling of the auth handshake procedure with a PIV smartcard could lead to memory corruption, denial of service or other unexpected behavior under some conditions. The practical security impact on tested production binaries appears to be limited. -
The article describes several vulnerabilities in the KeepKey hardware wallet. Flaws in the supervisor interface can be exploited to bypass important security restrictions on firmware operations. Using these flaws, malicious firmware code can elevate privileges, permanently make the device inoperable or overwrite the trusted bootloader code to compromise the hardware wallet across reboots or storage wipes.
-
The article describes a vulnerability in the KeepKey hardware wallet which allows triggering specific wallet functionality at times when it should not be available. Under certain limited conditions, this may be used to trick users into accepting unwanted actions on the device.
-
The ChipSHOUTER PicoEMP is an electromagnetic fault injection (EMFI) tool by NewAE that is available as a do-it-yourself project.
-
The journey of repairing a NewAE PhyWhisperer USB module with the help of a thermal camera and some hot air reworking.
-
This article gives a quick look inside a SafePal S1 cryptocurrency hardware wallet (likely hardware revision
V1.3). -
I have discovered a new security issue in the Yubico HSM client-side code. An attacker with control over the data input of the SSH Certificate Signing functionality can cause a stack buffer overflow with arbitrary data in the
yubihsm-shelltool. The overflow is mitigated into a denial of service through existing runtime hardening. -
I have recently discovered and demonstrated a new vulnerability in the KeepKey hardware wallet. Unlike some previously reported issues, this vulnerability is triggered by electrical fault injection and requires invasive physical access to the target device, but it has some interesting characteristics that makes it easier to achieve than other attacks of this nature.
-
I discovered during the analysis of the CVE-2021-31616 vulnerability that the stack canary logic in the KeepKey firmware was broken and could be bypassed to perform practical stack smashing attacks.
Further investigation revealed that the incorrect stack protection assembler code is produced through a bug in certain GCC 9 and GCC 10 compiler versions for ARM, where it has been present for about a year. This problem has the potential to affect a wide range of ARM based embedded systems. -
I have recently discovered the serious CVE-2021-31616 vulnerability in the KeepKey hardware wallet.
This is part I of a small article series that describes some of the technical journey of how I got code execution on the device. -
I have recently discovered a serious vulnerability in the KeepKey hardware wallet.
Through a stack buffer overflow, remote or local attackers can execute code on the device and perform actions such as stealing the wallet keys from within a malicious website. The vulnerability was introduced with firmware v7.0.3 and patched with v7.1.0 after my disclosure. -
I’ve continued my research on weaknesses in the Yubico HSM library and recently found additional vulnerabilities in it through fuzzing.
A malicious HSM device with authentication can trigger out of bounds read operations (CVE-2021-27217) on the host that may lead to segmentation faults and crash the program. -
In part II of this article series, I show some practical examples of opening tamper evident seals without detection.
-
This article series is about my personal experiences with some types of tamper evident seals. As physical security countermeasures, seals are designed to allow detection of unauthorized physical access to equipment and therefore deter attackers from tampering with it. Like many researchers, I’m intrigued by the security mechanisms that I come across and want to find out how well they hold up in practice.
-
Shortly after publishing my article on Skycoin hardware wallet issues, I discovered that the Skycoin developers had missed two important patches for old upstream firmware vulnerabilities in the Trezor that were still present in their code, so I reported that problem as well.
-
This article presents more details, measurements and observations for the OLED side channel issue that I reported back in 2019. It also shows some data on the main mitigation technique that I evaluated during the disclosure.
I recommend reading the original blog article and the SatoshiLabs article as an introduction to this topic. More vendor articles are linked in the original article. -
After my previous research had uncovered security issues in other Yubico smartcard libraries, I decided in July to take a closer look at the Yubico libyubihsm library. Libyubihsm is responsible for interacting with the YubiHSM2 Hardware Security Module that is used in enterprise systems with advanced cryptography requirements. After applying a few days of my private research time & fuzzing experience to it, I discovered multiple memory issues in the library code.
-
As part of my fuzzing research into C parsers, I took a look at the open source GoPro GPMF-parser project. The GPMF-parser software decodes custom telemetry metadata from GoPro camera video recordings. Multimedia file parsers are notoriously difficult to write safely in C, so I expected some memory security issues and saw this as a good exercise for fuzzing.
-
I’ve done a lot of dynamic program analysis on hardware wallet software in the last years. In June, I decided to spend some time on analyzing a few popular open source C parser projects to have a change of scenery and see if I could find interesting security issues there. One goal of this research was to get more experience with a variety of different codebases for fuzzing and develop a better understanding of related challenges.
-
In April, I took a closer look at another cryptocurrency hardware wallet that is based on a fork of the Trezor One code. During this analysis, I found a number of memory safety issues and other code problems, which are described in the following article.
-
In April, I analyzed two Yubico C smartcard libraries using libFuzzer.
During this process, I found two vulnerabilities in libykpiv plus a few minor other security problems and a number of generic bugs. Essentially, a malicious PIV (FIPS 201) smartcard can cause two sorts of issues during the host-initiated private RSA key generation, namely an out of bounds read on the host library stack (CVE-2020-13131) and a denial of service (CVE-2020-13132). Under some conditions, host process memory is copied into a corrupted RSA public key and returned by the library to the caller. The potential to obtain stack memory of the host via public keys is an unusual information leak. -
In May 2019, I discovered that the BC Vault One has different electrical noise emissions depending on the physical pressure on the device case. This can potentially be used by a local hardware implant in USB periphery to capture information during the secret PIN entry, as I will explain in this article.
-
The article describes a vulnerability in the KeepKey hardware wallet which allows an attacker to erase a cryptographic key and compromise the U2F 2nd factor protection of the KeepKey. I discovered this issue by fuzzing a custom KeepKey emulator setup with libFuzzer and AddressSanitizer. The vulnerability was fixed with firmware v6.2.2 in September 2019.
-
The article describes a buffer overflow vulnerability in the USB receive buffer of the KeepKey hardware wallet that was fixed with firmware v6.2.2 in September 2019. I discovered this issue by fuzzing a custom KeepKey emulator setup with libFuzzer and AddressSanitizer.
-
This article describes a number of memory safety issues in two base64 decoding and encoding libraries. I found these issues during fuzzing research of the Shift Cryptosecurity BitBox01 and during the resulting disclosure process.
-
The article describes the buffer overflow vulnerability in the USB receive buffer of the KeepKey hardware wallet that was fixed with bootloader v1.1.0 and firmware v5.5.0 in June 2018.
-
The article describes the buffer overflow vulnerability in the USB receive buffer of the Trezor One that was fixed with the 1.6.2 firmware in June 2018.
-
In the first half of 2018, I found a number of security issues in the Trezor One hardware wallet during my master thesis on fuzzing and verification. Most of the issues were discovered through the powerful combination of fuzzing with libFuzzer and error detection via sanitizers such as Address Sanitizer and Undefined Behavior Sanitizer.
-
As described in part one, I discovered in late 2018 through manual code analysis that the Yubico libu2f-host host-side C library contained an out of bounds write vulnerability.
-
As part of the background research on the U2F HID handshake information leak, I discovered through manual code analysis that the Yubico libu2f-host host-side C library contained an out of bounds write vulnerability which could be triggered by a malicious U2F client device.
-
Bech32 reference C code written by Bitcoin developer Pieter Wuille for the BIP 173 standard contained an unsigned integer overflow that leads to a buffer overflow for certain malformed Bech32 addresses. While this code is not used in the Bitcoin core implementation, it is included in over a dozen cryptocurrency projects, notably in multiple hardware wallets and a Lightning node implementation.
-
In November 2018, I noticed irregularities during packet analysis of U2F packets on the Trezor One hardware wallet. The data segment in the U2F init response packets was three bytes longer than it should be. According to the U2F specification, this packet consists of 24 (= 7 + 17) data bytes and the rest of the 64 byte USB packet must be set to
0x00. -
During security research in April 2019, I have discovered that the common OLED SSD1306-like displays used in many cryptocurrency hardware wallets and other embedded devices are leaking information about the display contents towards the USB interface from which the device is powered. This represents an interesting side channel that had so far not been discovered by other vendors and researchers.
.svg){kind=icon}
