Tag: DMA
Windows: new feature using IOMMU to block DMA access for Thunderbolt devices when machine is locked
The latest version of Windows apparently has new protections against PCILeech and related attacks:
Sysdream article on using PCILeech to attack Windows
Nice article by Sysdream on using PCIleech to attack Windows DMA.
Intel patch for UEFI pre-memory DMA protection in PEI
Intel has submitted a V3 patch to the tianocore EDK2 project, with additional DMA protection for UEFI on Intel systems.
[PATCH V3 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI
V3:
1) update the function comments of InitDmar()
2) update the function comments of SiliconInitializedPpiNotifyCallback()
3) remove duplicated BAR debug message.
4) fix the size field in the mPlatformVTdNoIgdSample structure.
V2:
Minor enhancement: Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(), for better code management.
V1:
This series patch adds Pre-Memory DMA protection in PEI. The purpose is to make sure when the system memory is initialized, the DMA protection takes effect immediately. The IntelVTdPmrPei driver is updated to remove the global variable and add VTD_INFO_PPI notification. The VTdInfoSample driver is updated to install the initial VTD_INFO_PPI before memory init, and add more content after memory init by reinstalling VTD_INFO_PPI. This patch is validated on one Intel Client kabylake platform.
For more info, see full patch:
https://lists.01.org/mailman/listinfo/edk2-devel
Intel Whitepaper updated: Using IOMMU for DMA Protection in UEFI Firmware
We recommend firmware developers review this docment to understand threats from unauthorized internal DMA, as well as DMA from non-PCI devices that platform firmware may configure. Using an IOMMU such as Intel VT-d allows fine-grain control of memory protection without broadly disabling bus-mastering capabilities in the pre-boot space.
Note: this whitepaper was originally published under the title “A Tour beyond BIOS Using Intel® VT-d for DMA Protection in UEFI BIOS” in January 2015.
https://firmware.intel.com/blog/updated-whitepaper-using-iommu-dma-protection-uefi-firmware
Click to access Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf
PCI Express DIY hacking toolkit
This repository contains a set of tools and proof of concepts related to PCI-E bus and DMA attacks. It includes HDL design which implements software controllable PCI-E gen 1.1 endpoint device for Xilinx SP605 Evaluation Kit with Spartan-6 FPGA. In comparison with popular USB3380EVB this design allows to operate with raw Transaction Level Packets (TLP) of PCI-E bus and perform full 64-bit memory read/write operations. It’s early version of my first much or less complicated FPGA project, so the speed is quite slow (around 1-2 Mb/s), but in upcoming releases it will be significantly increased by connecting PCI-E endpoint to MicroBlaze soft processor with AXI DMA engine. However, even such low speed is more than enough for reliable implementation of various practical attacks over PCI-E bus: to demonstrate applied use cases of the design, there’s a tool for pre-boot DMA attacks on UEFI based machines which allow executing arbitrary UEFI DXE drivers during platform init. Another example shows how to use pre-boot DMA attacks to inject Hyper-V VM exit handler backdoor into the virtualization-based security enabled Windows 10 Enterprise running on UEFI Secure Boot enabled platform. Provided Hyper-V backdoor PoC might be useful for reverse engineering and exploit development purposes, it provides an interface for inspecting of hypervisor state (VMCS, physical/virtual memory, registers, etc.) from guest partition and perform the guest to host VM escape attacks.
https://github.com/Cr4sh/s6_pcie_microblaze
Ulf: Attacking UEFI over DMA
Attacking UEFI:
Unlike macs many PCs are likely to be vulnerable to pre-boot Direct Memory Access (DMA) attacks against UEFI. If an attack is successful on a system configured with secure boot – then the chain of trust is broken and secure boot becomes insecure boot. If code execution is gained before the operating system is started further compromise of the not yet loaded operating system may be possible. As an example it may be possible to compromise a Windows 10 system running Virtualization Based Security (VBS) with Device Guard. This have already been researched by Dmytro Oleksiuk. This post will focus on attacking UEFI over DMA and not potential further compromises of the system.[…]
https://github.com/ufrisk/pcileech
http://blog.frizk.net/2017/08/attacking-uefi.html
Microsoft Windows DMA Guard
[…] New Bitlocker features in Windows 10, version 1507:
* DMA port protection. You can use the DataProtection/AllowDirectMemoryAccess MDM policy to block DMA ports when the device is starting up. Also, when a device is locked, all unused DMA ports are turned off, but any devices that are already plugged into a DMA port will continue to work. When the device is unlocked, all DMA ports are turned back on.
[…]
This policy setting allows you to block direct memory access (DMA) for all hot pluggable PCI downstream ports until a user logs into Windows. Once a user logs in, Windows will enumerate the PCI devices connected to the host plug PCI ports. Every time the user locks the machine, DMA will be blocked on hot plug PCI ports with no children devices until the user logs in again. Devices which were already enumerated when the machine was unlocked will continue to function until unplugged. This policy setting is only enforced when BitLocker or device encryption is enabled.
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-deviceguard
https://docs.microsoft.com/en-us/windows/device-security/device-guard/deploy-device-guard-enable-virtualization-based-security
https://docs.microsoft.com/en-us/windows/device-security/device-guard/device-guard-deployment-guide
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-manage
https://docs.microsoft.com/en-us/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies
Inception: hacking tool exploiting PCI-based DMA
Inception has been around since at least 2014, but I just noticed it. 😦
Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. Inception aims to provide a relatively quick, stable and easy way of performing intrusive and non-intrusive memory hacks against live computers using DMA. Inception’s modules work as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over a IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating system’s code. Once found, the tool manipulates this code. For instance, in the unlock module, the tool short circuits the operating system’s password authentication module that is triggered if an incorrect password is entered. […] However, vendors generally dismiss DMA attacks as a non-issue, which I hope that the awareness that this tool generates will change. Users deserve secure devices, even when attackers gain physical access.[…]
https://github.com/carmaa/inception
http://www.breaknenter.org/projects/inception/
http://www.breaknenter.org/2014/09/inception-metasploit-integration/
Windows 10 new preboot security features
There’s a few new preboot-related features in recent builds of Microsoft Windows, excerpt of some of them below.
New features in Windows 10, version 1511:
* Credential Guard: Enable Credential Guard without UEFI lock. You can enable Credential Guard by using the registry. This allows you to disable Credential Guard remotely. However, we recommend that Credential Guard is enabled with UEFI lock. You can configure this by using Group Policy.
* Bitlocker: DMA port protection. You can use the DataProtection/AllowDirectMemoryAccess MDM policy to block DMA ports when the device is starting up. Also, when a device is locked, all unused DMA ports are turned off, but any devices that are already plugged into a DMA port will continue to work. When the device is unlocked, all DMA ports are turned back on.
* Bitlocker: New Group Policy for configuring pre-boot recovery. You can now configure the pre-boot recovery message and recover URL that is shown on the pre-boot recovery screen. For more info, see the Configure pre-boot recovery message and URL section in “BitLocker Group Policy settings.”
* New BCD events: Event ID 4826 has been added to track the following changes to the Boot Configuration Database (BCD): DEP/NEX settings, Test signing, PCAT SB simulation, Debug, Boot debug, Integrity Services, Disable Winload debugging menu
* New PNP events: Event ID 6416 has been added to track when an external device is detected through Plug and Play. One important scenario is if an external device that contains malware is inserted into a high-value machine that doesn’t expect this type of action, such as a domain controller.
* TPM: Key Storage Providers (KSPs) and srvcrypt support elliptical curve cryptography (ECC).
* TPM: The following sections describe the new and changed functionality in the TPM for Windows 10: Device health attestation, Microsoft Passport support, Device Guard support, Credential Guard support […]
https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-1507-and-1511
https://technet.microsoft.com/en-us/windows/release-info
Attacking UEFI Runtime Services
Ulf has an informative new article (and video) about attacking UEFI Runtime Services on Linux-based systems using PCILeech:
Attackers with physical access are able to attack the firmware on many fully patched computers with DMA – Direct Memory Access. Once code execution is gained in UEFI/EFI Runtime Services it is possible to use this foothold to take control of a running Linux system. The Linux 4.8 kernel fully randomizes the physical memory location of the kernel. There is a high likelyhood that the kernel will be randomized above 4GB on computers with sufficient memory. This means that DMA attack hardware only capable of 32-bit addressing (4GB), such as PCILeech, cannot reach the Linux kernel directly. Since the EFI Runtime Services are usually located below 4GB they offer a way into Linux on high memory EFI booting systems. Please see the video below for an example of how an attack may look like. […]
Full post:
http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html
Firmware Security 