Tuesday, December 6, 2016

Every Windows 10 in-place Upgrade (even with SCCM) is a SEVERE Security risk PART II


So, 127000 blog reads and a week later I believe it's a good time to publish the episode II of this story. Please read these few points and then see how to apply this on SCCM managed machines as well.


First a few things:

  1. My bad, I used the wrong term that was used in previous Windows versions. The BitLocker is SUSPENDED not DISABLED like I said. The end result is of course the same but I do want to use the correct terms.
  2. Most comments say this is an old thing that was in Windows decades ago. Yes, the Shift+F10 feature has been there for ages and I've used it for troubleshooting for ages. That is why I knew to look for it. I found it first in the beta-version of Windows 10. After finding it I knew the first time it really was an issue was the time when people upgraded from Windows 8 to 8.1 as that was the first time the in-place upgrade was recommended and we had BitLocker. So in XP you could press Shift+F10 but so what, we didn't use it to bypass BitLocker (I actually played Solitaire with it just for fun) - so I don't think this is the same thing at all…
  3. What makes this a "bug" (again you have to give me some slack, I'm Finnish and English is not my first language. I speak a language where we log on to Windows using the local Administrator account name of JÄRJESTELMÄNVALVOJA). So let me rephrase, this is a "mistake" that Microsoft forgot this in the upgrade sequence as they know how to block it and have a feature for that.
  4. I categorize myself as a conceptual hacker. This means that I find and use holes that are not Zeroday attacks or 3rd party application issues but holes based on principles that I know to look for because I've studied the OS for over 20 years. I teach Windows Internals and always tell my students that the base knowledge on the OS is a requirement for both creative troubleshooting and taking care of security. How would you know what's bad if you don't know what's normal.
    1. You can find my training on http://PluralSight.com/ and http://win-fu.com/ Let me teach you to find this stuff as well :)
  5. LTSB. You don't have to agree with me on this. This was just my personal opinion. I did offer other choices as well like the not leaving computers unattended when they are upgrading. I currently plan on staying on LTSB until 2018 and the do an easy upgrade to CBB - If things are worked out to the level I want by then.
  6. Will there be a time when this all will be put to a test? Yes, Microsoft just declared 1607 as Current Branch for Business. This means that 1507 release will be out of support in a few months and we will get to test this in action ;) You can read more about this here: https://blogs.technet.microsoft.com/windowsitpro/2016/11/29/windows-10-1607-is-now-a-current-branch-for-business-cbb-release/
  7. I know the Immutable laws of security and I know the computer is not your computer anymore if someone has physical access to it. If it wasn't a case like this trust me I would have gotten a bounty on this from Microsoft ages ago. I still believe that this is an issue as if I don't do inplace upgrades I don't have this issue… Some people got upset that I called it "SEVERE"… Well if you ask me when a computers integrity protection and data protection fail by pressing two keys… Sorry, I just believe it's SEVERE - I will agree to disagree with you on this if you don't.
  8. I also saw some recommendations on using Linux to hack the box - Although Linux is Finnish and I like to promote it, you don't need Linux to hack Windows - It does so itself just fine as I show in the next video.



Now let's talk about the next "issue" here. My good friend Johan Arwidmark made an amazing job in building a bandage for the Shift+F10 to be blocked. It could be used by SCCM/MDT or any manual upgrade. Here is the link: http://deploymentresearch.com/Research/Post/567/Using-ConfigMgr-to-fix-the-Shift-F10-security-issue-for-Windows-10-inplace-upgrades This is what Microsoft will probably use to fix the hole in the first place as well.

Although this is great I guess some people didn't see the real problem in this whole issue. If the Shift+F10 is a "bug" or a "mistake" it can be easily fixed as we see. The real security issue is the suspending of BitLocker. The next video shows you how to use this against any system including SCCM/WSUS controlled machines. Again it uses the knowledge gained on Windows Internals classes. I also do Security Audits (hire me ;) ) and you can bet I will take this into my toolbox for myself when I have the next bank to break into ;) And yes it does require physical access still and yes I boot the machine from a bootable media so you can just glue the USB ports. I will then take the disk at correct point and move it to another machine or start playing with Linux. Anyway at the end of the day you are fighting against windmills.




And BTW I have a big issue to disclose that's totally unrelated to this and needs Microsoft's actions before I can talk about it so do enroll to my newsletter - like thousands of you already have: http://eepurl.com/F-GOj

And be sure to follow me on Twitter @samilaiho

Thanks for all the great feedback,

Sami

23 comments:

  1. But with Biospassword(+TPM) and have done a proper disable config of other bootable devices like USB. Its seems not likly to be explited after hotfixing with Johans script for the wims.

    Unless you fake PXE deploy that is.. hm.. :D Maybe disable pxe aswell in end of TS and enable before reinstall/refresh... :)

    ReplyDelete
  2. This issue goes away if you require a password to unlock bitlocker but disable TPM, does it not? This forces the person with the unlock key to be physically present when the computer reboots, which is a step in the right direction, right?

    Unless the PE installer can suspend protection on any volume without needing a key, which would be a more serious (backdoor) problem...

    ReplyDelete
    Replies
    1. No, this does work on all scenarios of BitLocker so disabling the the TPM and requiring a password doesn't help.

      Delete
    2. How? Does Windows have an alternate key that the installer uses to unlock the volume?

      Obviously, if the owner unlocks the volume at startup, they are still physically in control of their machine during the upgrade process...

      Delete
  3. The computer needs to be on when you start the upgrade so your BitLocker volume is unlocked. The upgrade writes a temporary key on the disk that is used until the upgrade is done.

    ReplyDelete
  4. I'll have to pay closer attention next time I install a "feature update" or whatever they're calling it now. I could've sworn it prompts me to enter my non-TPS protected password each time I reboot.

    If Microsoft really is writing a temporary unlock key to the keychain on the volume during installs, then there's your point of exploit regardless. They shouldn't do that! :)

    (Though the Shift+F10 "feature" is one that's long been overdue for removal from the installer. Or at the very least, it should be protected with a login session ala Linux or FreeBSD's "insecure" console feature.)

    ReplyDelete
  5. Thanks for sharing this info. If we have a software firewall policy in place through a 3rd-party app that disables USB external media, are there any other ways to exploit BitLocker or would we be thoroughly protected?

    ReplyDelete
    Replies
    1. Depends if you can boot from other media like DVD-ROM or if you can remove the harddisk.

      Delete
    2. The policy disables mountable devices including DVD/CD-ROM and USB. None of our Windows 10 systems have internal optical drives. I'm not sure what could be done once the hard disk has been removed but I was under the impression that moving the hard drive to another computer would keep an encrypted system from decrypting unless you had the recovery key.

      Delete
    3. Sadly the hard disk encryption is suspended in this state so the recovery password is not required.

      Delete
  6. Sami, if you are connected to people working with Microsoft on a fix, please let them know that there are even more situations to be taken care of than the self-invoked shift-F10. I upgraded our company's machines inplace from 8.1 to 10240->1511->1607 and each time, file chooser dialogues appeared on the same machines, that could be used to elevate one's privileges. Reason was a certain MSI package that windows setup for whatever reason would need the source files for before setup would continue. The package is "open text exceed 14" as well as "open text exceed 14 3d", those are available as trials, so MS could reproduce this. We deployed it using GPO's native software deployment and the MSI was on a share.
    So the unauthenticated interaction with the file chooser (running as system account) is another security no-go.

    But I am afraid the BL suspension will be the first thing to address and I see no way to solve that apart from removing that feature completely, thus, making inplace upgrades no longer hands free (unless we use BL with TPM-only or netunlock).

    ReplyDelete
    Replies
    1. Luckily more than 90% of my users use TPM only :) And btw I believe you can build it secure with just that.

      Delete
  7. This comment has been removed by the author.

    ReplyDelete
  8. Sami, it seems you focused on the last 3 lines. Will you tell the team about the MSI installer issue, please?
    And about your "without PIN is secure enough" - I have an interesting question for you: https://social.technet.microsoft.com/Forums/en-US/b00fe0ce-7554-49bf-8a87-05b14632799b/gpo-20-where-to-set-these-win10-specific-things?forum=win10itprosetup - please tell me what you know about that, do I need MDM/Intune/SCCM, or is it possible without?

    ReplyDelete
    Replies
    1. I Will let them know about the MSI issue. The DMA-setting can currently be put in Place via InTune/MDM or PowerShell although I don't have the PowerShell script to give you. I have a friend who has done it so I know it can be done. But not with SCCM or GPO. There is an open investigation going related to this setting so I can't tell you all right now but I Will keep you posted.

      Delete
  9. Thanks for the post, but black background and white text really hurts my eyes...

    ReplyDelete
  10. Sami, any news? I have looked at the win10-exclusive powershell commands. There is no cmdlet that has a name pointing into that direction, I have my doubts.

    ReplyDelete
    Replies
    1. There is no PowerShell cmdlet. As I said my friend has created a script with PowerShell but it uses WMI to set it, not a dedicated cmdlet.

      Delete
  11. Any news on this? (will there be a change?)

    Sami, thanks for your other blog-post on DMA vs Bitlocker: http://blog.win-fu.com/2017/02/the-true-story-of-windows-10-and-dma.html

    ReplyDelete
  12. The creator's upgrade is out. It disallows Shift F10, but still suspends bitlocker.

    ReplyDelete
  13. I want to thank you for writing this article.This is great Article for me. It also more very informative & awesome.

    ReplyDelete