Blog posts

  • Fuzzing Multiple C Parsers

    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.

  • Skycoin Hardware Wallet Firmware Vulnerabilities

    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.

  • Yubico libykpiv vulnerabilities

    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.

  • BC Vault One button side channel

    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.

  • KeepKey key erasure vulnerability (VULN-1971)

    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.

  • KeepKey receive buffer vulnerability (VULN-1969)

    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.

  • Base64 parser issues in multiple projects

    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.

  • KeepKey receive buffer vulnerability (VULN-1814)

    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.

  • Trezor One receive buffer vulnerability - part one

    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.

  • Trezor One dry-run recovery vulnerability

    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.

  • Yubico libu2f-host vulnerability - part two

    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.

  • Yubico libu2f-host vulnerability - part one

    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_decode vulnerability

    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.

  • U2F init packet information leak

    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.

  • OLED side channel - summary October 2019

    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.

Subscribe