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 email@example.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:
- 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:
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/
Ok, so someone had to be first to ask so no throwing, but for a., how critical is the NoAdminRights part. If you do absolutely everything and the user still has admin rights, is it all for nothing?ReplyDelete
Well in Security I'd say it's never for nothing. It's always better to increase Security than not. But the #1 rule since 1993 has been that there can't be good Security in Windows unless you don't run admin rights.Delete
Are you able to clarify how the Windows Hardware Compatibility Requirement System.Fundamentals.Firmware.NoExternalDMAOnBoot protects(or not) systems? Just for completeness sake.
This one is something that Windows has always really adheared to as Windows hasn't been able to use DMA-enabled devices for booting anyway. Mac OSX has supproted booting from FireWire or ThunderBolt but not Windows. The real trouble really starts when the OS is alive but this requirement is important to have. We need to protect more against DMA when the Computer is a the logon state rather than physically off. There is more of this in the documentation of MSDN: https://msdn.microsoft.com/en-us/ie/dn932805(v=vs.94)#system_fundamentals_firmware_noexternaldmaonbootDelete
There is a lot more wrong with Bitlocker:ReplyDelete
2008: Vijay Bharadwaj and Neils Ferguson of Microsoft Corporation Comment on NIST standardization of XTS
> In our opinion, one serious shortcoming of the proposal is that it does not contain a clear statement of what application-level security goals XTS aims to achieve.
> The proposal appears to miss the effect of temporal effects on the security of XTS. It is possible for an attacker to observe a disk for a period of time and thereby gain a significant advantage in cryptanalysis.
> An attack on large data units [...] This shows that large data units significantly weaken the system.
> AES in XTS mode works with 16-byte blocks, and this allows for very fine-grained ciphertext manipulation attacks. We believe this is a significant problem in practice.
> In a code modification attack the attacker randomizes a block of code and tries to corrupt the code in such a way as to introduce a security hole in the system whilst keeping the system functional.
> The small block size of XTS-AES makes this attack rather easy. A larger block size makes it significantly harder.
> A modern operating system has thousands of settings that are important for the security of the system.
> Again, a larger block size significantly increases the security in two ways.
Complete comment here: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
2016: XTS is default for Bitlocker in Windows 10
> no argument given why it would be "more secure"
> it saves you two percent of time when converting 10 GB of data
Don't know who you are but I have two comments:Delete
1. I'll pay you 100€ to show me how you would hack BitLocker.
2. What's your replacement for BitLocker? What do you use?
Sorry, I had not set up my Blogger account yet, that's why my name was displayed as "Unknown".Delete
Second question first: The problem is not Bitlocker itself, but its default settings. I'm not using Windows, but if I did, I would switch it back to CBC mode and be aware that data is encrypted but not authenticated.
Attack would take a lot of preparation, but it could look something like this:
0. Perform some Windows installations in order to determine which disk blocks are probably used for interesting files (system executables, DLLs etc.).
1. When I have access to the victim's laptop, I copy the encrypted disk. At this point I cannot decrypt anything.
2. I wait for some time until some cricial security issues have been discovered and patched.
3. When I have access to the victim's laptop again, I surgically implant disk blocks from my image file in oder to reset particular binaries to the vulnerable versions. This is particularly easy with XTS because of the small size of unchained blocks.
4. When the victim is using his laptop again, I exploit the known vulnerability to take over.
PS: You don't have to pay me, because I am not willing to invest the time for a proof of concept.
1. Yes, agreed.Delete
2. Luckily you are like the others I've asked
It is not an easy attack. You have to prepare, you only have one try and have to be careful to not write rubbish to the disk.Delete
I totally agree that the DMA issue that you are highlighting is much more relevant for most users, because it can be done with a stolen laptop without too much preparations.
The original point was a different one: Microsoft experts were very critical of XTS cipher mode, yet they have chosen it as their default.
"Great blog created by you. I read your blog, its best and useful information. You have done a great work. Super blogging and keep it up.php jobs in hyderabad.ReplyDelete
You have shared the legal things about the windows 10 and its dma protection, It is good for our knowledge. If you are looking for home and office based MS Office Project 2016 Online, visit on softwareempire.ReplyDelete
Sami, this will be of interest: since Win10 v1703, there's the "Disable new DMA devices when this computer is locked"-GPO as you know. This GPO however produces weird results on win10 v1709 (RTM and 16299.19)! For me and several others that I read about, you need to disable the policy in order for other devices to work - for me it was the sound card, for other it included wifi ("code 10 - device cannot start")! This is reproducible and did not happen with v1703 on the same hardware. Please try it for yourself.ReplyDelete
->This needs be be reported to Microsoft - you have connections, will you tell the developers? If you need hardware to reproduce: for me it was an Asrock Motherboard H97 Pro4 with onboard soundcard by realtek.
Thanks for the notice. I've forwarded this to Microsoft.Delete
Microsoft asked for you to report this through the Feedback Hub as well, so please do so.Delete
Microsoft's official response to that:Delete
This is a big problem, as this setting is definitely an important one, but many companies will also need to upgrade to 1709, and don't want to wait on firmware updates that may never arrive.
Based on the wording of this response, is it safe to assume that while the GPo results in the devices breaking (machine bricking in my case), the registry key listed in this article does not?Delete
The GPO sets the same registry setting, and nothing else, so it should be the same result. Mine broke down when ever I set it via MDM, GPO or manually.Delete
Thanks, just did.ReplyDelete
I think MS messed up something in 1709 with this setting, please have a look at this Thread and my response..
Looks like in RS4 everything is fixed now. Another question I have is how to turn on "Kernel DMA Protection", when you open MSINFO32 on Windows 10, for us it is turned off, allthough Device Guard is ON.ReplyDelete