7

Machines such as the MS Surface Pro 3 comes with bitlocker encryption and UEFI secure boot out of the box. However, the default boot order is network -> usb -> ssd.

If an attacker gets physical access to the machine (while it is locked or shut-off), is it possible for him to boot using usb (with some other OS) to compromise (including reading and writing over) the victim's files? I believe that data confidentiality is still protected by bitlocker, but I hope to get some confirmation on the possible attack vectors possible.

I am also aware that there is an option to set a password to prevent changes to the UEFI settings or to disable booting from usb, but I am interested in attack vectors in the default scenario where the password is not set and the boot order is network -> usb -> ssd.

Thank you.

  • By "writing over", do you mean modification, or does simple destruction count? – Mark Nov 21 '14 at 9:49
  • 2
    In case of full disk encryption (like bitlocker) it is important to have a pre-boot authentication. Without it the full disk encryption is practically useless. Do you use pre-boot authentication? – pabouk Nov 21 '14 at 11:57
  • Simple destruction counts too. Pre-boot authentication is not on by default. The main protection it offers is against cold boot as described in this article: technet.microsoft.com/en-us/security/jj884374.aspx In the scenario I mentioned, let's assume that cold boot attacks is not an option and the attacker is specifically trying to boot via usb to attempt to compromise the victim's data. – Kevin Lee Nov 21 '14 at 15:29
  • 2
    @kevinze , If physical access is possible I don't know of any protection scheme that protects against data destruction. – Brian Duke Nov 22 '14 at 14:35
  • Come to think of it, that is true. What about reading the victim's files? – Kevin Lee Nov 22 '14 at 17:58
8

After conducting extensive research on the Bitlocker platform, I believe I can answer my own question.

Key reference: Bitlocker Drive Encryption Technical Overview

In our default setup (at least on MS Surface Pro 3), Bitlocker, UEFI and Secure Boot are on. There is TPM 2.0 enabled. The UEFI is not password protected, and the boot order allows USB before SSD.

Attackers have the interest in booting into an alternative OS because popular password cracking tools like Ophcrack run from Linux (actually it wouldn’t work on the Surface Pro 3 because it is a class 3 UEFI device that does not support Legacy BIOS mode). In addition, if the hard disk is not encrypted, the alternate OS has the liberty to read the files from the hard disk, and even “reset” the Windows password by messing around with the Windows SAM and registry.

In our scenario, since Bitlocker encryption is on, the hard disk partition is encrypted so an alternate booted OS will not be able to see our files.Also, the TPM will conduct an integrity check on the pre-boot components and will realize we are booting into another system, and thus will not release the keys needed to decrypt the hard disk partition. Furthermore, one cannot simply boot a Live Linux USB, or install Linux on the hard disk, since Secure Boot would not allow that. Can we just turn off Secure Boot, since there is no password protection on the UEFI settings?

Yes, an attacker has the ability to turn off Secure Boot and boot into an alternate OS. However, that is not a concern because the default Bitlocker policy will use Secure Boot for integrity validation as well, and turning off Secure Boot will trigger the Bitlocker recovery key lockout. The attacker should not have the recovery key in his possession and brute forcing it is infeasible. Since the attacker cannot go past the recovery key screen, the hard disk will not be decrypted and the data remains protected. An intelligent user should also sense that something is up if he is prompted for the recovery key for no legitimate reason like a system update (in case we are afraid of Evil Maid attacks).

Local group policy editor

In the UEFI settings, the attacker could also turn off the TPM protection. This will definitely trigger the Bitlocker recovery key lockout because Bitlocker relies on TPM for its usual decryption keys. Therefore, it is pointless to do so.

Therefore, while it is possible to make the system “more secure” by password protecting the UEFI, it does not seem necessary to do so.

In addition, Surface Pro 3 is certified as a ‘Connected Standby’ device. In other words, we don’t have to go to the extremes of always shutting down the device or putting it to hibernate for added security in some configurations. We don’t really need to have pre-boot authentication also (i.e. just have TPM-only authentication). It does not have any DMA ports, so DMA attack is not possible. It is not susceptible to Cold Boot attacks, since system memory cannot be easily removed. See this reference article.

In his talk on ‘Building a Bulletproof Bitlocker’, Sami Laiho mentions that TPM-only authentication is good enough for 90% of people. If you’re interested, he talks about Bitlocker and added configurations that you could set up (for general devices, not just the Surface Pro).

Note that encryption does not prevent the attacker from writing over the hard disk with random bits.

Additional reading: Comments on Bitlocker

Note: there may be backdoors and implementation errors which are unknown. The answer here is based on available information from Microsoft and general knowledge about FDE systems. It also assumes that the TPM can be trusted and that brute forcing the encryption itself is "infeasible" without a very fast supercomputer (i.e. will take "too many" lifetimes to break at present time). That said, feel free to point out additional vulnerabilities so that we can be more aware of the potential threats and under which circumstances we should be concerned about them (i.e. assumptions about the attacker). I would just like to comment that a vulnerability in a part of the system does not immediately imply that an attacker can engineer a successful attack to extract information from it, although it indeed does increase the chance of success.

  • Cold boot attacks are possible as the device can be modified to make memory removal easier. One thing TPM can't do is to assert the physical state of the system, like whether someone soldered cables directly on the mainboard to dump the RAM that way without even doing a cold boot attack. – user42178 Mar 19 '15 at 14:06
  • I don't know if you're just suggesting a theoretical possibility or you have evidence that people have done this successfully when the ram is on-board and not removable. I have provided a reference article in my original answer also. – Kevin Lee Mar 22 '15 at 14:56
  • It's a theory I thought about but I don't see why it wouldn't be possible. The computer itself isn't designed to be tamper proof (like a smartcard is) and because the keys are in the TPM you can make it boot, so just sniff the communication between the CPU and RAM (or maybe just the TPM<->CPU communication, not sure if there's any encryption involved there) and you can get the keys. Not easy, but definitely possible for a government. – user42178 Mar 22 '15 at 15:27
  • I disagree, some computers are designed to be more tamper proof than others. Anyway, it's easy to say that any system can be compromised. However, we shouldn't stop there. For example, what is the attacker and defender model? What can they do? Do they have infinite time and resources? E.g. brute forcing AES 256 is possible if you have billions of years; but even governments don't live that long. You propose the idea that the TPM can be compromised. Maybe there is way, but is it feasible or not? Yes govts are powerful but please don't make them seem almighty... – Kevin Lee Mar 24 '15 at 9:17
  • We're not talking about bruteforcing AES. We're just talking about soldering some tiny wires in a lab. What can the defender do ? Avoid keeping the keys in the TPM so that in the event the machine is stolen by the attacker, the attack I'm describing won't work because the keys are nowhere near the machine. Or just prevent the machine from being stolen altogether, but that's risky. – user42178 Mar 24 '15 at 9:20
2

There is an entire literature in the Blackhat and Defcon communities showing how to exploit the software that manages TPMs, retrieve secret keys from the TPM by interposing on the communication between the TPM and the CPU, and other attacks. The answer above by Kevinze and his followup comments are simply not accurate (he/she argues that such exploits are only theoretical). Section 5 in this paper gives a brief summary of some known ways to exploit TPMs: https://www.blackhat.com/docs/us-14/materials/us-14-Weis-Protecting-Data-In-Use-From-Firmware-And-Physical-Attacks-WP.pdf

  • Whether something is 'secure' or not it depends on the attacker/defender model that is assumed. When I wrote my initial answer, I did assume the TPM to be something trusted (sorry for not stating). I then showed how the attacker couldn't simply alter some settings or try to boot into another OS without triggering a Bitlocker lockout. Yes, TPMs are not 100% fool-proof. That being said, with updated knowledge that we have, we should be clear of exactly how such attacks can be conducted and evaluate its requirements and practical risk, rather than simply concluding so. – Kevin Lee Aug 4 '15 at 16:23
  • For example, I did mention that cold boot attacks on a Surface Pro 3 isn't as feasible, because system memory is not easily removed from that particular device. Some attacks on TPM may involve very sophisticated hardware tampering as well. One could say that it is a feasible attack given sufficient time, skill and effort (and you can say the same for any system as well). But we should go beyond making such general claims. – Kevin Lee Aug 4 '15 at 16:29
1

Physical access is always a very risky thing. While I don't now of any security flaws right now that will give you immediate access there are a lot of other things that you can do, eg. using a USB keylogger to intercept the user's password when he uses the machine the next time. There have been attacks using PCI cards utilizing direct memory access (http://en.wikipedia.org/wiki/DMA_attack). The lists goes on.

  • UEFI secureboot also checks PCI OptionROMs :) – MemCtrl Dec 19 '14 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.