In Depth Security Vol. III: Proceedings of the DeepSec Conferences

Dedication

This book is dedicated to the IT security community.

Without the contributions of that community’s members,

there would be nothing about which to write.

Table of Contents

Editors Preface

Stefan Schumacher and René Pfeiffer

BitCracker – BitLocker meets GPUs

Elena Agostini and Massimo Bernaschi

Building Your Own Web Application Firewall as a Service – And Forgetting about False Positives

Juan Berner

Web Application Firewall Bypassing – An Approach for Penetration Testers

Khalil Bijjou

Efail and other Failures with Encryption and E-Mail – Outdated Crypto Standards and HTMLMails as a Security Risk

Hanno Böck

Drones, the New Threat from the Sky

Dominique C. Brack

XFLTReaT – Unified Tunneling

Balazs Bucsay

Malware Analysis – Machine Learning Approaches

Chiheb Chebbi

I Wrote my Own Ransomware; did not make 1 iota of a Bitcoin

Thomas Fischer

New Attack Vectors for Mobile Core Networks

Silke Holtmanns

Without a Trace: Cybercrime, who are the Defendants?

Edith Huber and Bettina Pospisil and Walter Seböck

Defense Informs Offense Improves Defense – How to Compromise an Industrial Control Systems Network – and How to Defend it

Joseph Slowik

Editors Preface: In-Depth Security

Stefan Schumacher and René Pfeiffer

Information security has turned into a mainstream activity. It is next to impossible to count the many events and conferences filled with presentations about bugs in code, vulnerabilities, successful attacks, stolen data, ways to improve, protocol flaws, missing updates, and yet another devices connected to the global networks. Software developers are expected to create secure code automatically. They can select one of the many new frameworks and programming languages promising to do everything right and not to allow any mistakes, logical or otherwise. Modern operating systems have adopted technologies to defend against malicious applications. Given this description of paradise, all information security researchers around the world should be without work, and the DeepSec Chronicles Volume 3 should not exist. Where’s the catch?

First of all, there is the issue of complexity. New software, new hardware, new interactions, and new ways of using technology are created every day. But even if it is only a combination of already existing concepts, it is still something new. Then there is the number of connected devices and people around the world. While specific services might lose users, the overall number of entities using computers and networks rises steadily. The sheer number of combinations paired with ever shortening development cycles provides the perfect breeding ground for weaknesses in or even the absence of security. Finally the processes change slower than the implementation. We still use version number or count releases, but software development has shifted to continuous integration. Speeding up the integration of features and fixes in code means that the final version will change quickly. Trying to keep up in terms of manual reviews and security testing gets harder and harder.

This brings us back to the original motivation of creating the DeepSec Chronicles. Some ideas deserve a second look, longer consideration, and are meant to accelerate the creative process of repeatedly asking questions. Improvement requires in-depth knowledge combined with the right mix of proven technology and new concepts. By turning presentations held at the DeepSec In-Depth Security Conference into articles with additional background and implementation details we hope to give you all some new insights and a different perspective to look at the information technology infrastructure you are trying to improve or defend. In addition, we like to welcome anyone to contribute. Ask questions, test hypotheses, improve, and create! The world of information security will be thankful for your effort.

The editors wish to thank Susanne Firzinger and our graphic designer Florian Stocker for their help with creating this volume. Furthermore we like to thank all supporters who made the DeepSec conferences possible, and we thank our families for their continued support of absent-minded, highly concentrated family members writing code, hacking hardware, and brooding over tons of publications.

Stefan Schumacher

Stefan Schumacher is the president of the Magdeburg Institute for Security Research and editor of the Magdeburg Journal for Security Research in Magdeburg/Germany. He started his hacking career before the fall of the Berlin Wall on an East German small computer KC85/3 with 1.75 MHz and a Datasette drive.

Ever since he liked to explore technical and social systems with a focus on security and how to exploit them. He was a NetBSD developer for some years and involved in several other Open Source projects and events. He studied Educational Science and Psychology and does a lot of unique research about the Psychology of Security with a focus on Social Engineering, User Training and Didactics of Security/Cryptography.

He is currently leading the research project Psychology of Security, where fundamental qualitative and quantitative research about the perception and construction of security is done. He presents the research results regularly at international conferences like AusCert Australia, Chaos Communication Congress, Chaos Communciation Camp, DeepSec Vienna, DeepIntel Salzburg, Positive Hack Days Moscow or LinuxDays Luxembourg and in security related journals and books.

René Pfeiffer René Pfeiffer is one of the organisers of the annual DeepSec In-Depth Security Conference. He works self-employed in information technology, lectures at the Technikum Wien, and is involved with cryptography and information security for over 20 years.

Magdeburg and Vienna, October 2019

BitCracker

The Bitlocker Password Cracker

Elena Agostini and Massimo Bernaschi

BitLocker is a full-disk encryption feature available in recent Windows versions. It is designed to protect data by providing encryption for entire volumes and it makes use of a number of different authentication methods. In this work we present a solution, named BitCracker, to attempt the decryption, by means of a dictionary attack, of memory units encrypted by BitLocker with a user supplied password. To that purpose, we resort to GPU (Graphics Processing Units) that are, by now, widely used as general-purpose coprocessors in high performance computing applications. BitLocker decryption process requires the execution of a very large number of SHA-256 hashes and also AES, so we propose a very fast solution, highly tuned for Nvidia GPU, for both of them. In addition we take the advantage of a weakness in the BitLocker decryption algorithm to speed up the execution of our attack. We benchmark our solution using the three most recent Nvidia GPU architectures (Kepler, Maxwell and Pascal), carrying out a comparison with the Hashcat password cracker. Finally, our OpenCL implementation of BitCracker has been recently released within John The Ripper, Bleeding-Jumbo version.

Keywords: BitLocker, Hash, SHA-256, AES, GPU, CUDA, Cryptographic Attack, Password Cracking

Citation: Agostini, E. & Bernaschi, M. (2019). BitCracker: BitLocker meets GPUs. In S. Schumacher & R. Pfeiffer (Editors), In Depth Security Vol. III: Proceedings of the DeepSec Conferences (Pages 1–16). Magdeburg: Magdeburger Institut für Sicherheitsforschung

1 Introduction

BitLocker is a data protection feature that integrates with the Windows operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers. It offers a number of different authentication methods, like Trusted Platform Module, Smart Key, Recovery Password, user supplied password. Bit-Locker features a pretty complex proprietary architecture but it also leverages some well-known algorithms, like SHA-256 and AES. It is possible, and relatively easy (to this purpose, commercial tools are available (Elcomsoft Forensic Disk Decryptor 2018)) to instantly decrypt disks and volumes protected with BitLocker by using the decryption key extracted from the main memory (RAM). In addition, it is also possible to decrypt for offline analysis or instantly mount BitLocker volumes by utilizing the escrow key (BitLocker Recovery Key) extracted from a user’s Microsoft Account or retrieved from Active Directory.

If the decryption key can not be retrieved, the only alternative remains to unlock password-protected disks by attacking the password. The same commercial tools above mentioned, offer this as an option but in a quite generic form (i.e.,) without taking into account the specific features of BitLocker. Moreover, according to some comments¹, they may be also not fully reliable. The goal of the present paper is to describe our approach to attack BitLocker password-protected storage units. We carefully studied available information about Bit-Locker architecture and directly inspected several types of units in order to find out how to minimize the amount of work required to check a candidate password. The platforms we use for the attack are based on Nvidia GPUs and we carefully optimized the most computing intensive parts of the procedure achieving a performance that is, at least, comparable with that provided by well-known password crackers like Hashcat (Hashcat 2018) for the evaluation of the SHA-256 digest function. However, the main goal of our work is not providing an alternative to Hashcat as a general framework for dictionary attacks but to offer the first open-source high performance tool to test the security of storage units protected by BitLocker using the user password and recovery password authentication methods.

2 BitLocker

BitLocker (formerly BitLocker Drive Encryption) is a full-disk encryption feature included in the Ultimate and Enterprise editions of Windows Vista and Windows 7, the Pro and Enterprise editions of Windows 8 and Windows 8.1, Windows Server 2008 and Windows 10. It is designed to protect data by providing encryption for entire volumes.

BitLocker can encrypt several types of memory units like internal hard disks or external memory devices ²(flash memories, external hard disks, etc..) offering a number of different authentication methods, like Trusted Platform Module, Smart Key, Recovery Key, password, etc.. In this paper we focus on two different authentication modes: the user password mode, in which the user, to encrypt or decrypt a memory device, must type a password (as represented in Figure 1) and the recovery password mode, that is a 48-digit key generated by BitLocker (regardless of the authentication method chosen by the user) when encrypting a memory device³. By means of the recovery password the user can access an encrypted device in the event that she/he can’t unlock the device normally.

Figure 1: BitLocker encryption of an USB pendrive using the password authentication method.

During the encryption procedure, each sector in the volume is encrypted individually, with a part of the encryption key being derived from the sector number itself. This means that two sectors containing identical unencrypted data will result in different encrypted bytes being written to the disk, making it much harder to attempt to discover keys by creating and encrypting known data. BitLocker uses a complex hierarchy of keys to encrypt devices. The sectors themselves are encrypted by using a key called the Full-Volume Encryption Key (FVEK). The FVEK is not used by or accessible to users and it is, in turn, encrypted with a key called the Volume Master Key (VMK). Finally, the VMK is also encrypted and stored in the volume; for instance, if the memory device has been encrypted with the user password method, in the volume metadata there are two encrypted VMKs: the VMK_U, that is the VMK encrypted with the user password, and the VMK_R, that is the VMK encrypted with the recovery password.

During the decryption procedure (Figure 2) BitLocker, depending on the authentication method in use, starts to decrypt the VMK. Then, if it obtains the right value for the VMK, it decrypts in turn the FVEK and then the entire memory device.

The attack described in the present paper aims at decrypting the correct VMK key which belongs to an encrypted memory unit through a dictionary attack to the user password or to the recovery password. That is, if an attacker is able to find the password to correctly decrypt the VMK key, she/he is able to decrypt the entire memory unit with that password.

Figure 2: BitLocker encryption/decryption scheme

2.1 User Password VMK Decryption Procedure

To gain an insight about the workings of our attack, more information are necessary about the VMK decryption procedure (Figure 3) when the authentication method is a user password (see also (N. Kumar and V. Kumar 2008) (Aorimn 2018) and (Metz 2018)):

1. the user provides the password;

2. SHA-256 is executed twice on it;

3. there is a loop of 0x100000 iterations, in which SHA-256 is applied to a structure like:

typedef struct {

unsigned char updateHash[32];

//last SHA-256 hash calculated

unsigned char passwordHash[32];

//hash from step 2

unsigned char salt[16];

uint64_t hash_count;

// iteration number

} bitlockerMessage;

4. this loop produces an intermediate key, used with AES to encrypt the Initialization Vector (IV) (derived from a nonce);

5. XOR between encrypted IV and encrypted Message Authentication Code (MAC) to obtain the decrypted MAC;

6. XOR between encrypted IV and encrypted VMK to obtain the decrypted VMK;

7. if the MAC, calculated on the decrypted VMK, is equal to the decrypted MAC, the input password and the decrypted VMK are correct;

Figure 3: VMK decryption procedure

All the elements required by the decryption procedure (like VMK, MAC, IV, etc..) can be found inside the encrypted volume. In fact, during the encryption, BitLocker stores not only encrypted data but also metadata that provide information about encryption type, keys position, OS version, file system version and so on. Thanks to (Metz 2018), (Aorimn 2018), (N. Kumar and V. Kumar 2008) and (Kornblum 2009) we understood how to get all of these informations reading the BitLocker Drive Encryption (BDE) encrypted format. After an initial header, every BDE volume contains 3 (for backup purposes) FVE (Full Volume Encryption) metadata blocks, each one composed by a block header, a metadata header and an array of metadata entries.

Figure 4: FVE metadata block, BitLocker Windows 8.1

In Figure 4 we report an example of FVE block belonging to a memory unit encrypted with Windows 8.1, enumerating the most interesting parts:

The -FVE-FS- signature, which marks the beginning of an FVE block

The Windows version number

The type and value of a VMK metadata entry

According to this value, the VMK has been encrypted using the user password authentication method

The salt of the VMK

According to this value, the type of VMK encryption is AES-CCM

Nonce

Message Authentication Code

Finally, the VMK

2.2 Recovery Password VMK Decryption Procedure

As above mentioned, the recovery password is a kind of passe-partout for all the authentication methods. According to (Kornblum 2009), the recovery password is a 48-digit number composed by eight groups of six digits; each group of six digits must be divisible by eleven and must be less than 720896. Finally, the sixth digit in each group is a checksum digit. For instance, a valid recovery password is: 236808-089419-192665-495704-618299-073414-538373-542366. The number of all possible recovery password candidates is huge, thus building the entire dictionary would require too much storage.

The algorithm used by BitLocker to encrypt a device using the recovery password is similar to the user password one (with a few differences during the initial SHA-256 application): use the input password to produce an intermediate key useful to encrypt the VMK.

When the user encrypts a new memory device, regardless of the authentication method chosen, BitLocker always generates a recovery password; for this reason, every BitLocker encrypted memory unit has at least an encrypted VMK. Finally, performance in case of a recovery password attack is similar to the performance in case of a user password attack; therefore, during the rest of this paper, we report only about the performance of user password attacks.

3 BitCracker

Our software, named BitCracker (BitCracker on GitHub 2018), aims at finding (starting from a dictionary) the key of a memory unit encrypted using the user password authentication or recovery password methods of BitLocker. It executes on GPUs (Graphics Processing Units ⁴) the BitLocker decryption procedure with several performance improvements as described in the following sections:

We introduced a preprocessing step before starting the main attack, to store in memory useful information for the SHA-256 based main loop (Section 3.1)

We found a way to remove the final MAC computation and comparison (Section 3.2).

Finally, our code has been widely optimized for NVIDA GPUs (CUDA-C) but we implemented also an OpenCL version for portability reasons.

3.1 First improvement: SHA-256 and W Words

The most time-consuming part of the decryption algorithm is the loop of 0x100000 (1.048.576) SHA-256 operations, since a single hash involves many arithmetic operations. Moreover, during each iteration, the SHA-256 algorithm is applied twice to the 128 byte structure bitlockerMessage (Section 2.1) which is composed by several fields as shown in Table 1.

According to the SHA-256 standard (for a