Thursday, September 01, 2016

BENIGNCERTAIN — Remote Extraction of RSA Private Keys

TL;DR: The so-called BENIGNCERTAIN exploit dropped by the Shadow Brokers extracts RSA private keys from a captured memory dump using a technique similar to the one I described in a paper in 2006.

BENIGNCERTAIN is a "[..] remote exploit for Cisco PIX devices that sends an Internet Key Exchange (IKE) packet to the victim machine, causing it to dump some of its memory. The memory dump can then be parsed to extract an RSA private key and other sensitive configuration information" (from Mustafa Al-Bassam's writeup).

To extract RSA private keys from a captured memory dump, the exploit uses a technique similar to the one I described in a paper entitled "All Your Private Keys are Belong to Us — Extracting RSA Private Keys and Certificates from Process Memory" (2006).

A brief summary of the technique: The standard storage formats for RSA private keys and SSL certificates, as described in PKCS #8 and x509 respectively, are used to create a signature for locating them in memory. Using this signature, a simple pattern match could be done to extract the candidate asymmetric keys in their plaintext form, which could then be verified using an external tool such as OpenSSL.

The following tweet contains different screenshots of the disassembly of the BENIGNCERTAIN exploit, showing the relevant code snippets:
For a more detailed description of the BENIGNCERTAIN exploit refer to:
Key takeaways:
  • The Shadow Brokers leak illustrates that the proposed technique to extract RSA private keys from memory dumps is easy to use, very effective in the wild and extensively field-tested by the Equation Group (widely believed to be operated by the NSA).
  • Specialized hardware, like a hardware security module (HSM) or a smartcard, can safeguard your cryptographic keys from such an attack.

Tuesday, November 08, 2011

A Bug Hunter's Diary

I'm happy to announce that my new book »A Bug Hunter's Diary - A Guided Tour Through the Wilds of Software Security« is now available in paperback and ebook editions.

► View the detailed Table of Contents here (PDF).

► Chapter 2 is available for download here (PDF).

► Visit the book's companion website for further information, news, and resources.

    I hope you enjoy the book as much as I enjoyed writing it!

    Monday, May 16, 2011

    How to get gdb working on Apple iOS 4.3.x

    ► Step 1: Download and install gdb

    1) Download gdb at
    2) Transfer the file to the iDevice (e.g. via SSH)
    3) Install the package with the following command
      iPhone:~ root# dpkg -i gdb_1518-11_iphoneos-arm.deb

      This version of gdb will work on iOS 4.3.x with ASLR but it has a problem displaying the register values. To solve this issue I wrote a little gdb script.

      ► Step 2: Download and use my gdb script

      1) Download the gdb script at
      2) Transfer the file to the iDevice (e.g. via SSH)
      3) Start gdb and load the script with the following command:
        (gdb) source registers.gdb

        The script implements a new gdb command called 'ir' ([i]nfo[r]egisters) that lists the registers and their contents. Example output:
          (gdb) ir
          r0      0x10004005      268451845
          r1      0x07000006      117440518
          r2      0x00000000      0
          r3      0x00000c00      3072
          r4      0x00001a03      6659
          r5      0xffffffff      -1
          r6      0x00000000      0
          r7      0x2feb5dbc      803954108
          r8      0x00000000      0
          r9      0x3f45afb4      1061531572
          r10     0x00000000      0
          r11     0xffffffff      -1
          sp      0x2feb5d84      803954052
          lr      0x35cd575f      902649695
          pc      0x35cd5c00      902650880

          Alternatively, rename the file to '.gdbinit' and put it in the home directory of the user that will run gdb.

          Friday, January 14, 2011

 now with FORTIFY_SOURCE support

          New release.

          What's new with version 1.4:

            * Support for FORTIFY_SOURCE (--fortify-file, --fortify-proc)
            * Lots of other bugfixes and improvements
              - Check if the readelf command is available
              - readelf support for 64-bit ELF files
              - Check if the requested files and directories do exist
              - '--dir' is now case-sensitive and correctly deals with trailing slashes
              - Check user permissions
              - Etc.

          ► Example of the new '--fortify-file' option

          The following testcase is vulnerable to a classical stack buffer overflow (see line 10):
          tk@ubuntu$ cat testcase.c
          01 #include <string.h>
          02 #include <stdio.h>
          04 int
          05 main (int argc, char* argv[])
          06 {
          07        int     a = 1;
          08        char    buf[12];
          10        strcpy (buf, argv[1]);
          11        printf ("%08x\n", a);
          13        return 0;
          14 }
          Compile the testcase without stack canary support (-fno-stack-protector) and without FORTIFY_SOURCE:
          tk@ubuntu$ cat /etc/lsb-release
          DISTRIB_DESCRIPTION="Ubuntu 10.10"
          tk@ubuntu$ gcc -fno-stack-protector -o testcase testcase.c
          Check the executable file with

          The output shows, that FORTIFY_SOURCE is indeed not supported by the executable file. Now we try to overflow the stack buffer:
          tk@ubuntu$ ./testcase AAAA
          tk@ubuntu$ ./testcase AAAABBBBCCCCDDDD
          As can be seen from the output, the stack variable 'a' was successfully overwritten with our overly long command line argument ('a' was overwritten by the supplied D's or 0x44 in hexadecimal). Now we compile the testcase with FORTIFY_SOURCE support but without stack canaries and check the executable file with again:
          Under Ubuntu FORTIFY_SOURCE is activated when compiled with -O2 or higher. On other Linux distributions (e.g. Fedora or openSUSE) you need to add the compiler flag '-D_FORTIFY_SOURCE=2'.

          The output of shows, that the executable file was successfully compiled with FORTIFY_SOURCE. Now we try to overflow the buffer again:
          tk@ubuntu$ ./testcase AAAABBBBCCCCDDDD
          *** buffer overflow detected ***: ./testcase terminated
          ======= Backtrace: =========
          ======= Memory map: ========
          007d4000-007f0000 r-xp 00000000 08:01 135323     /lib/
          007f0000-007f1000 r--p 0001b000 08:01 135323     /lib/
          007f1000-007f2000 rw-p 0001c000 08:01 135323     /lib/
          0080f000-00829000 r-xp 00000000 08:01 131159     /lib/
          00829000-0082a000 r--p 00019000 08:01 131159     /lib/
          0082a000-0082b000 rw-p 0001a000 08:01 131159     /lib/
          00851000-009a8000 r-xp 00000000 08:01 138119     /lib/
          009a8000-009aa000 r--p 00157000 08:01 138119     /lib/
          009aa000-009ab000 rw-p 00159000 08:01 138119     /lib/
          009ab000-009ae000 rw-p 00000000 00:00 0
          00ff9000-00ffa000 r-xp 00000000 00:00 0          [vdso]
          08048000-08049000 r-xp 00000000 08:01 658356     /home/tk/testcase
          08049000-0804a000 r--p 00000000 08:01 658356     /home/tk/testcase
          0804a000-0804b000 rw-p 00001000 08:01 658356     /home/tk/testcase
          09e50000-09e71000 rw-p 00000000 00:00 0          [heap]
          b779f000-b77a0000 rw-p 00000000 00:00 0
          b77ae000-b77b0000 rw-p 00000000 00:00 0
          bfb00000-bfb21000 rw-p 00000000 00:00 0          [stack]

          This time the attempt to trigger the buffer overflow was successfully mitigated by FORTIFY_SOURCE.

          ► Example of the new '--fortify-proc' option

          With the new option '--fortify-proc' it is also possible to check running processes for FORTIFY_SOURCE support:

          You can download the new version 1.4 of here.

          Thursday, July 15, 2010

          Zone Crasher

          I released a new security advisory for Oracle Solaris and OpenSolaris. See TKADV2010-005 for a detailed description of the vulnerability and the OpenSolaris source browser for the source code fixes.

          Tuesday, May 04, 2010

 now with kernel support

          New release.

          What's new with version 1.3:

          * Additional checks for a number of kernel hardening features.
            Thanks to Jon Oberheide (
          Example of the new "--kernel" option:

          You can download the new version 1.3 of here.

          Sunday, April 18, 2010

          Split-process model FTW

          As I already mentioned in my last posting Google Chrome supports a split-process model that allows each browser tab to exist in its own process. The benefits to such a configuration include security and stability, as a bug in the renderer will only cause problems with a single tab that can be closed while others remain active.

          ► Want an example?

          If you open this testcase in Apple's Safari the browser will crash. If you open the testcase in Google Chrome only the current tab will be affected. It's a simple stack overflow (stack exhaustion) bug. This is a stability issue that by itself cannot lead to remote code execution. See this blog entry for more information about stack overflows.

          If you want some more information about the particular bug see the Chromium bugtracker or Webkit's Bugzilla.

          Apple also finally recognized the benefits of such a split-process model: see WebKit2.

          Friday, April 02, 2010

          "Kernel Bug" in Google Chrome

          I have to admit that I'm deeply impressed by the security architecture of Chromium, the open-source browser upon which Google Chrome is built. Google provides a lot of interesting background information on the security architecture of Chromium here and here. The most important security feature of Chromium is that the browser has two modules in separate protection domains: a »browser kernel«, which interacts with the operating system, and a »rendering engine«, which runs with restricted privileges in a sandbox.

          If there's a bug in the rendering engine (JavaScript V8, Webkit, FFmpeg etc.) it will only affect a sandboxed renderer process. As long as you can't escape the sandbox you're quite limited in what you can do. But if you find a bug in the browser kernel the game changes.

          Lately (see TKADV2010-004) I found an out-of-bounds array indexing bug in the FTP handling code of Google Chrome. As all the networking code, including the handling of FTP, is implemented in the browser kernel, the bug not only affects a sandboxed browser tab but the whole browser.

          If you want to crash your Google Chrome browser (Windows version <= see my advisory for a proof of concept.