29/01/2015
Blog technique
A tale of 31C3 – Part 1
Dimitri Kirchner, Frédéric Guihéry, Georges Bossert, Kelly Resche, Marion Vogt
The Chaos Communication Congress (CCC) is an enormous conference taking place each year from December 27th to 30th in Hambourg. This year was the 31st congress, named A new dawn in reference to the reaction towards Snowden’s revelations, and it has received more than 12 000 attendees for more than 100 talks at the Hambourg Congress Center. Each year, the CCC is known for changing the rules of the hacker world in a security perspective. This year was no exception. In order for you to understand what the CCC looks like, we have written here after a summary of each great talk we attended. This is the first part of a serie of two articles, which summers up talks about firmware analysis, SMU or UEFI bypass, Thunderstrike vulnerabilities and crypto.
Firmware analysis
AMD x86 SMU firmware analysis
Rudolf Marek presented his work regarding the analysis of the System Management Unit (SMU) firmware on AMD architecture. SMU is quite equivalent to the Intel ME technology but has been given less attention until now. As Intel ME, it is implemented in a dedicated micro-controller on the motherboard and ensures system and power management. This micro-controller is a LatticeMico32 with a 32-bit architecture.
Read access to the SMU runtime firmware is partially protected. Only the firmware header and part of the data area is accessible by the CPU. However, Rudolf noted that a variable, present in the readable data area, appears to be used as a function pointer by the SMU firmware. Using this, Rudolf implemented an attack that consists in modifying the pointer’s target: a specially-crafted SMU request triggers the pointer dereference and let him run specific malicious code.
Through this attack, Rudolf was then able to dump the whole content of the firmware, and run it with Qemu to better understand its behavior and protections. Rudolf found that the integrity of the SMU firmware is protected by a HMAC-SHA1, for which the secret key has been more or less revealed during the conference…
AMD patched these vulnerabilities: the runtime firmware is now entirely protected from read accesses by the CPU. And bounds checking is now applied during SMU request operations, so that untrusted code can no longer be executed.
Attacks on UEFI security, inspired by Darth Venamis's misery and Speed Racer
Rafal Wojtczuk and Corey Kallenberg showed in their talk different software attack vectors to bypass the measures that prevent the UEFI firmware from being modified. Their goal is also to provide exploitation methods that are easy to reproduce and that have few dependencies with the version of the system attacked. The protections to bypass are threefold: the chipset BIOS_CNTL register, the SMM (System Management Mode) and the Protected Range Mask (another chipset protection).
Write access to the Flash memory is only permitted if the BIOS Write Enable (BIOSWE) flag, in the BIOS_CNTL register, is set. When the platform boots, this flag gets unset. If a driver tries to set this flag, this triggers an SMI, whose associated SMM routine decides if the BIOSWE modification was legitimate or not. As it is not in the previous example, the SMM routine then unset the BIOSWE flag. However, there is a time-gap introduced by the SMM routine check which leads to a race condition. The speakers showed that an attacker can win the race to bypass the BIOSWE SMM control, by simply brute-forcing the Flash memory with a write operation as a second thread sets the Write Enable flag.
However this vulnerability is not effective on chipsets that have the SMM_BWP flag available, which says that the BIOS Region is not writable unless all processors are in SMM. To bypass this protection, the speakers showed an attack against the SMM (which is triggered when setting the BIOSWE fag). Rafal and Corey noted that during an ACPI S3 sleep, some chipset flags, such as the BIOSWE bit, are unset, and the platform configuration is saved in memory in a dedicated boot script. When waking up from S3 sleep, the boot script gets executed. This boot script is located in an ACPI table, which is not protected by any means. In particular, the boot script contains a pointer (EFI_BOOT_SCRIPT_DISPATCH_CODE) that can point to some arbitrary code that gets executed in the context of an ACPI S3 resume. Such context implies that the BIOSWE and BLE (BIOS Lock Enable) flags are unset, which means that Flash memory write does not trigger any SMI, thus Flash rewriting is fully permitted from a driver. The attack consists here to simply make the pointer to reference malicious code. And this malicious code can fully modify the UEFI firmware in Flash memory.
Besides, Rafal and Corey wanted to go further and break into SMM. They demonstrated an attack that permits to access the SMM code (in SMRam) with DMA accesses triggered by an hard drive driver. Those SMM code accesses should normally be blocked by the TSEG (Top of Memory Segment) register. However, by controlling the boot script used in S3 resume, the attacker also control the TSEG value that is restored. Thus, by controlling this value, an attacker can disable it and allows DMA accesses from a controlled device to the SMM code.
The last barrier to bypass is the chipset Protected Range Mask (PR Mask), that blocks any write access to specific areas of the memory (even from SMM), and especially the UEFI firmware code. The speakers found a vulnerability in the UEFI reference implementation that allows to bypass PR Mask protection. Besides, they noted that a specific UEFI variable, which is not protected by the PR Mask, and thus accessible from SMM, is used to specify the firmware path during a firmware update process. Thus, the attack consists in triggering an UEFI firmware update from a malicious SMM code. Rafal and Corey further noticed that PR Mask protection is even not really deployed in current platforms.
Finally, the impact of these results permits an attacker to maliciously modify the UEFI firmware and also to bypass any UEFI Secure Boot or TCG Trusted Boot. To protect against the last vulnerability, Intel is going to deploy a new dedicated protection (Platform firmware armoring technology) to prevent triggering firmware update from SMM. Regarding the two first vulnerabilities, manufacturers have to leverage the SMM_BWP flag and protect the integrity of the ACPI S3 resume boot script.
Thunderstrike: EFI bootkits for Apple MacBooks
Trammell Hudson presented a vulnerability on Mac platforms that allows an attacker to modify the content of the Apple EFI firmware.
He first showed that by using « in system programming », through a Dangerous Prototypes bus-pirate device and the flashrom tool, he was able to read and write the SPI Flash memory. But since this approach doesn’t provide efficient read/write performances, Trammell developed his own SPI reader/writer tool, called spiflash, which relies on a Teensy device.
After dumping the EFI firmware, he was able to do some reverse engineering on it. The firmware integrity appears to be only controlled by a CRC32, done by software. The absence of cryptographic verification is probably intended to speed the platform startup.
Trammell used Binwalk to make an entropy analysis of the firmware image. This tool permits to identify potential areas in the firmware that contain encrypted/compressed data or even ASCII strings. Further analysis showed that part of the firmware (the EFI Volumes) are compressed with the LZMA algorithm.
However, even with the understanding of the firmware structure, rewriting the EFI firmware through software means appears to be blocked. Indeed, the SPI Flash memory is locked by the chipset early during the boot sequence.
Trammell then focused his analysis on the firmware update process, that allows Apple to update the EFI firmware. This process is done with specific SCAP files. Those SCAP files are RSA-signed by Apple, and their signatures are checked before flashing the SPI Flash memory area. Still, this signature is only checked through software means.
In order to find a way to modify the firmware content, Trammell relied on a attack presented by Snare at Black Hat USA 2012. Snare used a Thunderbolt device with a modified firmware that exposes a malicious Option ROM to create a rootkit. As a remainder, Option ROMs are executed by the EFI firmware during platform startup. Trammell extended Snare’s attack by taking advantage of the fact that those Option ROMs get also executed during a firmware update process, and that SPI Flash memory is not entirely locked at this time. Thus, an execution of a malicious Thunderbolt Option ROM permits to update the EFI firmware with arbitrary code and, with some API hooking, to bypass the signature verification.
Trammell was then able to install his own RSA public keys so that only code that pertains to the attacker can be written to the SPI Flash memory, thus creating a robust bootkit that cannot be erased or modified through further legitimate firmware update process. Besides, such an attack could spread through Thunderbolt firmware rewriting, thus permitting to bypass air-gap « protections ».
As protection against this attack, Trammell mentioned that Apple should fix this vulnerability in new firmwares/platforms by preventing Option ROMs from being executed during the firmware update process. Besides, one can rely on the Trusted Boot (by leveraging the TPM functionalities), in order to measure and verify the integrity of all code that is executed at platform startup (and this includes Option ROMs).
Crypto
Revisiting SSL/TLS Implementations - New Bleichenbacher Side Channels and Attacks
Sebastian Schinzel presented his latest results on TLS attacks. This is a joint work with Juraj Somorovsky, Eugen Weiss, Jörg Schwenk and Erik Tews. The talk presented the 23rd USENIX Security Symposium in August 2014 paper and extended the topics presented at 28c3 and 29c3. All the described attacks affect flawed implementations of RSA-based TLS cipher-suites, on the other hand attacks do not impact neither ECC nor Diffie-Hellman suites security.
In the Bleichenbacker’s attack, published in 1998, against the RSA Encryption Standard PKCS#1 v1.5, author exploits some padding properties associated with RSA vulnerabilities resulting in a chosen-ciphertext attack to decrypt the »PreMasterSecret » (PMS) involved in TLS exchange. The adversary sends (chosen) encrypted messages to an oracle to distinguish whether, once deciphered, the message is valid (i.e. consistent with the PKCS#1 standard) or not.
A first countermeasure consists in unifying all error conditions and prevent an adversary to use them as an oracle. But this is not always applied by the protocol implementation. As an example, the Java Secure Socket Extension (JSSE) uses distinguishable error messages. This problem was communicated to the Oracle Security Response Team and the bug was assigned CVE-2012-5081. The flaw is fixed by the Oracle Java SE Critical Patch October 2012 – Java SE Development Kit 6, Update 37 (JDK 6u37).
Bleichenbacher’s original attack exploited explicit TLS error handling but he showed that timing channels attacks are also possible: an adversary can determine PKCS#1 compliance through response time. In 2012, authors found a timing-based Bleichenbacher attack against XML Encryption. So, a second needed countermeasure consists in processing valid and invalid records in constant time.
The TLS 1.2 RFC specifies to generate a random 48-bytes value and use it as PMS in case of incorrectly formatted RSA blocks. Consequently, the client and the server have different symmetric keys and the protocol will fail later. Notice that the random value is always generated even if messages are PKCS#1 v1.5 compliant. On the other hand, the TLS 1.0 and TLS 1.1 specifications mandate something different: the random value is generated »’only »’ if the message is not correctly formatted, leading to a timing channel.
Author showed that OpenSSL 1.0.1i uses the old method of preventing the Bleichenbacher attack; in that case the attack is not practical (timing differences are too small, implying a very weak oracle due to strict PKCS#1 checks). Then, he explained that two successful attacks against the JSSE and Cavium NITROX SSL accelerator chip implementation were found: JSSE handles exceptions causing different processing time, Cavium hardware TLS accelerator did not check the first byte‘s value, only the second byte (0x02) of the decrypted encoded message. Attacks were successful, performing in 19.5 hours and 41 hours respectively.
The bug against JSSE implementation was assigned CVE-2014-411 and it was fixed in the Oracle Java SE Critical Patch January 2014 – Java SE 7, Update 45 (and with the previous versions Java SE 5u55 and 6u65). Regarding the Cavium vulnerability, authors communicated their findings to vendors in November 2013. IBM gives their customers information about current state in the Security Bulletin: SSL/TLS side channel attack on WebSphere DataPower (CVE-2014-0852).
In their research, Schinzel and al. used a new TLS testing framework called T.I.M.E. (TLS Inspection Made Easy) to conduct attacks and analysis. You can check details here. Timing measurements were done with a patched version of the TLS implementation of MatrixSSL (client).
ECCHacks - A gentle introduction to elliptic-curve cryptography
Daniel J. Bernstein (DJB) and Tanja Lange presented a talk about elliptic-curve cryptography. In their talk, authors first introduced why we use ECC. The reason is that most efficient methods to break discrete logarithm and factorization don’t apply for elliptic curve cryptography. Then, authors explained arithmetic operations such addition or scalar multiplication and the Diffie-Hellman exchange taking in example « The Clock curve » (careful, it’s not an elliptic curve). Then, authors transposed the example to actual elliptic curve cryptography and more specifically on Edwards, Twisted Edwards, Weierstrass or Montgomery curves.
In the second part of the talk, speakers gave some advices on choosing safe elliptic curves. You can this way use curves recommended by standards such as the ANSI X9.62, NIST FIPS 186-2, NSA Suite B or ANSSI FRP256V1. Moreover, three recommendations were made by authors:
- never send uncompressed (x,y);
- always multiply DH scalar by cofactor;
- always choose twist-secure curves.
Finally, authors presented details on the next generation of curves such as the Curve25519 designed by DJB or Curve41417. Presentation is reachable at http://ecchacks.cr.yp.to/.
Finding the Weak Crypto Needle in a Byte Haystack - Automatic detection of key-reuse vulnerabilities
Ben Herzog described an algorithm which can detect keystream-reuse vulnerabilities. In order to illustrate its algorithm, he first introduced stream ciphers and why they are vulnerable to attacks if the same key is used twice or more.
A stream cipher works by xoring a plaintext with a keystream to get a ciphertext. But if we encrypt to different messages with the same key, it’s then quite easy to compute $c_1 oplus c_2$ with the commutativity of XOR to reveal result portions of the plaintext:
$c_1 = p_1 oplus k$
$c_2 = p_2 oplus k$
$c_1 oplus c_2 = (p_1 oplus k) oplus (p_2 oplus k) = (p_1 oplus p_2) oplus (k oplus k) = p_1 oplus p_2$
After that, Ben Herzog explained the inner working of the algorithm and showed a proof-of-concept attack on several examples of vulnerable data, including files encrypted by the DirCrypt malware and encrypted traffic generated by another malware such as Ramnit.
More precisely, the DirCrypt malware infects a computer and starts encrypting its file system. It uses RC4 as streamcipher and every file is encrypted with the same key as demonstrate by the Check Point’s Malware Research Team in their article « How (and why) we defeated DirCrypt » Check Point whitepaper. The second example with the Ramnit malware uses it’s own proprietary protocol to communicate over the port 443. In this one, some blocks are encrypted with the same key.
Another example of key-reuse vulnerability is the Microsoft Office encryption flaw [3]. Hongjun Wu of the Institute of Infocomm Research in Singapore discovered the flaw and described it in a new paper, The Misuse of RC4 in Microsoft Word and Excel.
Based on these example, Ben Herzog explained how its algorithm work. In few words, 4 steps are needed: * construct the XORspace of input data (containing for example two ciphertexts that we want to know if they are encrypted with the same key) by xoring the input with itself; * scan the XORspace along the diagonals; * look for « streaks » of positive evidence; * if positive evidence is « enough » – raise alarm.
It then constructs the evidence « Heat Map » (bytes with less evidence are in blue, bytes with more evidence are in red). We can see « streaks » of evidence along the diagonals at each side of the main diagonal and detect key-reuse.
CAESAR and NORX - Developing the Future of Authenticated Encryption
Philipp Jovanovic and Jean-Philippe Aumasson presented their new cipher NORX (also designed by Samuel Neves not present at the conference). NORX is one of the 57 ciphers submitted to CAESAR competition which started officially on March 15, 2014.
CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) is a competition initiated by Daniel J. Bernstein, with a committee of 22 cryptographers and sponsored by the NIST. CAESAR aims to identify a portfolio of Authenticated Encryption (AE) schemes with support for Associated Data (AD) that offer advantages over AES-GCM.
During their talk, the authors introduced some known issues regarding block cipher modes such as ECB, CBC with constant IV and CTR with reused nonce. Then, they talked about principles of AE: it takes in input a key, a nonce and a plaintext; and returns a ciphertext with an authentication tag (for integrity purpose). This way, there are several ways to provide AE:
- you can combine a symmetric cipher and a MAC:
- Encrypt-and-MAC as used in SSH
- MAC-then-encrypt as used in SSL/TLS
- Encrypt-then-MAC as used in IPsec (generally better, to be preferred)
- or you can use dedicated methods such as:
- authenticated block cipher modes (GCM, CCM)
- dedicated authenticated ciphers
- sponge functions
NORX is a family of ciphers which has a unique parallel architecture derived from the »sponge » construction « Monkey duplex ». It takes few parameters: word size, number of rounds, parallelism degree and tag size, and works with an original domain separation scheme to process header, payload and trailer data in one pass. NORX was designed for efficiency with both software and hardware in mind, which make it one of the fastest CAESAR candidates. Moreover, the goal of NORX is to provide a higher security, and a better robustness against side-channel leaks (especially with timings side-channels). Authors gave example of reuse of encryption key (for encryption and authentication) and padding oracle attacks, and showed how NORX was designed with such concern in mind.
For more information see: Caesar and Norx Website
If you want to read about bugs’ mining, code pointer integrity, ICS pwning, or Perl/SS7/XRayScanner vulnerabilities, you can continue on the second part of this article. If you have any question, please send your feedback by contacting us on Twitter @Amossys or by sending us an email at [email protected].
