It all actually started when I was delivering a session on Windows 8.1 in TechEd. I believed what the documentation says and told people that in Windows 8.1 never before seen DMA-enabled devices would not be usable on the logon screen. So if your computer had no one logged on or the computer was locked we would not need to worry about DMA-attacks anymore. As I soon learned this did not actually work in Windows 8.1 and Microsoft told me that it had "skipped" from the RTM build without them (that I was interacting with) knowing about it. I felt horrible as I had given misinformation but more that I had "skipped" the vital "Always test - Don't just trust" policy of mine.
Now the story continued when things like this showed up:
Quote from: https://technet.microsoft.com/en-us/itpro/windows/whats-new/whats-new-windows-10-version-1507-and-1511
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.
So the problem with Windows 10 was that Microsoft gave misinformation to my customers and on their websites that Windows 10 would now protect them from the DMA-attacks as wasn't the case by default. Now the bigger problem with this is that MS only supports settings this ON via MDM. Now honestly how many of my customers have MDM? Almost none :( There is no support to set it via SCCM (as it doesn't support custom URIs), Provisioning package or most of all Group Policy...
I got a friend of mine (thanks to Petri Paavola @petripaavola) to help me and build me a PowerShell script so I could experiment without InTune.
I set the setting but DMA still worked. I thought maybe I really need InTune so I installed InTune and set the setting from there... Still nothing... Now I got really worried. Was the setting done wrong or was this yet again a "skipped" feature. Now I needed to get secure@microsoft.com and the product Group on board with this as this seemed.. well.. fishy...
I would like to thank Microsoft for working with me on this. It took a long time but now finally we have some results. First of all the DMA-protection is not FULL. Quote from MS:
”This mitigation only protects PCI-based buses, for example, ExpressCard, Thunderbolt, & some docking stations (PCIe based). Older, non-PCI busses such as 1394 and CardBus are still vulnerable.”
That is why I got it working all the time as I was using FireWire to steal the memory.
So the story continues By Microsoft providing me instructions to deal with this:
- Set the DMA protection on https://msdn.microsoft.com/en-us/library/dn904962(v=vs.85).aspx#DataProtection_AllowDirectMemoryAccess
- Use Group Policy to block Firewire like we have done for years: Blocking the SBP-2 driver …
So I started to experiment again. Sadly this information is not complete either and I know most of my customers have them deployed incomplete as well and have had for many years :( When I used the instructions as such the TB3-devices didn't work (as I expected). When I used the recommended GP-settings to block just FireWire my TB3-devices and Dock now worked but so did PassWare Memory Imager... This is in turn because the instructions don't include all 1394 devices that you can find from here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx
I have reported this to Microsoft as well and I hope the instructions are fixed soon.
Now to give you what you are probably here for :) First how to set the DMA-protection on without InTune:
- In a few days/weeks you will get an Insider Build that has a Group Policy settings to set this! Thanks to a lot of feedback from MVPs and customers.
- Until then the registry key you can set with any method you want is this:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\Pci
- DisableExternalDMAUnderLock (DWORD) = 1
Second, here is recommendation from now on to my customers to block DMA but allow the use of ThunderBolt 3 devices:
- Have UEFI+SecureBoot+TPM+NoAdminRights
- Block DMA for ThunderBolt by using the registry key until we get the GPO
i.
Or MDM of course if you have one…
- Use Group Policy to disable FireWire
i.
See the old article: https://support.microsoft.com/en-us/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-dma-and-thunderbolt-dma-threats-to-bitlocker
ii.
But
block these ClassIDs:
- {7ebefbc0-3200-11d2-b4c2-00a0C9697d07}
- {c06ff265-ae09-48f0-812c-16753d7cba83}
- {d48179be-ec20-11d1-b6b8-00c04fa372a7}
- {6bdd1fc1-810f-11d0-bec7-08002be2092f}
For some cases if the customer really requires it: add a PIN
code protector and disable standby.
Hope this clears things out and sorry it took a while but there is coordinated disclosure procedure I want to respect. If you found this helpful please enrol to my newsletter at: http://eepurl.com/F-GOj
And remember my training videos on PluralSight and my Dojo at https://win-fu.com/dojo/
Sami
