Lately, there have been a lot of concerns about Direct Memory Access (DMA) attacks given light to software tools such as Inception making this attack more practical than ever.

In this blog post, I would like to help clarify what this attack is and how we can best mitigate this risk in conjunction with full disk-encryption (FDE).

When a device has got to the point that the operating system is active, then without appropriate hardening of the operating environment (BIOS/UEFI, Operating System, hardware, firmware, etc), there can be some measure of risk of attacks that can access system memory.  Attacks of this type are collectively referred to as Direct Memory Attacks.

Some specific examples of where this type of attack can be carried out are through connections such as FireWire, Thunderbolt, ExpressCard, PC Card or any other PCI/PCIe Hardware interfaces.  Inception is one example of an application that can utilize any of the mentioned interfaces to perpetrate such an attack.

To prevent DMA attacks, system administrators can do the following:

1. Ensure devices are always secured with the use of some form of power up authentication either thru a BIOS power on password or Pre-Boot Authentication (PBA) from a full disk encryption (FDE) product.
2. If devices are deemed to operating in an unsecure environment, be sure to require the use of hibernation mode and power off when not in use to prevent DMA attacks.
3. Ensure unnecessary ports that allow attackers to perform a DMA attack (such as FireWire, Thunderbolt, ExpressCard, PC Card or any other PCI/PCIe Hardware interfaces) are disabled in the Operating Environment, and that normal users are prevented from altering such settings.

Let’s discuss using FDE as a mitigation as the implementation can be tricky.

With most encryption products that provide Data-At-Rest (DAR) security, once a legitimate user has successfully authenticated at Pre-Boot, the drive is thereafter “unlocked” and its contents are readable by the operating system and/or any other processes.  If the threat of DMA attacks is considered a major risk, then the primary protection against this is to use interactive Pre-Boot Authentication.

Some FDE solutions allow for unattended Pre-Boot Authentication (for example BitLocker with TPM protection).  Thus even if the device is powered off when stolen, the attacker can power on the device and it will boot to the OS; similar issues apply to power modes such as Sleep.  Thus, the use of unattended PBA is not recommended to ensure an attacker is prevented from launching such an attack.  (Note: There are circumstances, depending on the risk profile, where unattended PBA via pre-boot networking with a management server acting as the external authenticator mitigates the risk.  Another possible mitigation is to utilize Intel Enterprise Digital Fence.

1. A DMA-based attack on software encryption is to gain access to the software Encryption Key as well as all sensitive data that is currently in memory.  The primary mitigation against such an attack is to use Pre-Boot Authentication with single or multi-factor strong credentials.
2. A DMA-based attack on a hardware-encrypted drive (SED) such as an Opal drive is an attempt to gain access to the PIN in memory (if it’s stored) that unlocks the SED returning from Sleep mode.  The primary mitigation against this attack is also the use of Pre-Boot Authentication coupled with disabling support of Sleep for the system.  The use of Sleep mode for Self-Encrypting Drives should be strongly cautioned.

To further guard against such attacks, it is important to block all ports which allow attackers to perform a DMA attack.

Below are some operating system changes one can do to as prevention:

1. For Apple OS X versions 10.7.2 and newer / Windows versions 8.1 and newer
   Disable FireWire DMA when the user has locked the OS, thus preventing Inception from working over Firewire. The tool will still work while a user is logged on.  However, this is a less probable attack scenario.
2. For OS X Mavericks 10.8.2 on Ivy Bridge release in 2012 and newer Mac machines
   These machines have enabled VT-D, effectively blocking DMA requests and thwarting all inception modules even when the user is logged in.  Look for vtd[0] fault entries in your log/console on such Mac devices if searching for proof of such attack attempts.

With proper controls and mitigations in place, we can greatly reduce the risk of a DMA attack in your environment.