MacOS FileVault2 Password Retrieval

[dashesyan]

I've had this in my .profile for years:

  alias sleepsafe='sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25'
  alias sleepfast='sudo pmset -a hibernatemode 0'
  alias sleepdefault='sudo pmset -a hibernatemode 3'

Whenever I travel or need to leave my laptop, I always run `sleepsafe`, which will delete the key from memory and hibernate the computer when I close the lid. It has the added benefit of saving battery life.

Day-to-day, I use `sleepfast`, which is faster than the default hybrid sleep, because it doesn't spend time copying the contents of memory to disk.

I very rarely switch to `sleepdefault` which is the insecure and slower hybrid sleep.

This has been a known issue for years http://osxdaily.com/2013/07/06/maximize-filevault-security-d... https://nakedsecurity.sophos.com/2012/02/02/filevault-encryp...

[dootdootskeltal]

It doesn't work for me on Sierra, I disabled powernap and it keeps asking for my account password. Also I set standbydelay and standby to 0.

Edit: After some time and some tries, idk why but it started working.

Commands that I used:

$ sudo pmset -a darkwakes 0

$ sudo pmset -a standby 0

$ sudo pmset -a standbydelay 0

Also check that powernap is disabled.

[bburky]

I prefer YoNTMA: https://github.com/iSECPartners/yontma-mac

If the laptop is disconnected from AC, it hibernates. It will switch to hibernate if power is removed while already sleeping. If I want to force a hibernate manually, I just pull the power before closing the lid.

[j_s]

Thanks for sharing these awesome shortcuts!

Are there any caveats that I should be aware of before just stealing this to use for myself?

[tptacek]

Things like this are a reason I unhesitatingly recommend that people stick with their OS's built in FDE:

1. FDE is extremely limited. This particular attack is a clever abuse of sleep/reboot cycles, but of course people intimately familiar with FDE know that if a laptop is sleeping but not shut down it's already perilously close to the boundary at which FDE breaks down. And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off.

2. When flaws like this are found, the OS vendors have much more recourse than third parties do, which is why this post concludes by saying that Macs are now the most secure laptop platform with respect to DMA attacks against FDE.

Use FDE! Enable it on all your machines! But try not to rely on it, and don't waste too much time optimizing it.

[mtgx]

I don't know about Apple but Microsoft has a pretty nasty way of handling user's Bitlocker keys.

If you use a Microsoft account, your key is automatically backed-up in Microsoft's cloud. Red flag #1.

Also, as the recent Bitlocker bypass "bug" showed us, Microsoft has some way of bypassing Bitlocker encryption when it performs updates on the system. I don't know if they have some kind of key escrow or what, but either way - red flag #2.

Of course, I'd say the bigger problem is that Microsoft doesn't even give the majority of Windows users the option to encrypt their computers, by restricting Bitlocker to expensive computers and Windows licenses, while every other operating system does. So the advice to "just use the built-in FDE" doesn't work for the majority of Windows users.

[nicolas_t]

> And, of course, once it's woken up and unlocked --- which every attacker who actually challenges FDE can arrange for, all bets are off.

I'm not sure what you mean by that? Do you mean that the attacker can force you to wake up and unlock the computer? In that case FDE is not moot anyway, no?

For me, the reason I use FDE is in the case I lose or forget my computer somewhere, I do not want the legal liabilities with a thief accessing my customer's source code.

[emptybits]

Good on Apple for "completely" fixing this, according to the authors. But am I wrong to wish for more plain-English acknowledgement of the problem and reassurance in Apple's 10.12.2 release notes?

i.e. https://support.apple.com/en-ca/HT207423

Anyways, at this point in time it's nice to read (from the authors of the exploit): "The mac is now one of the most secure platforms with regards to this specific attack vector."

[jakobegger]

I read through the release notes, and I didn't see any mention of this issue at all. The fix must have been a EFI firmware update (my Mac did restart multiple times during the update, so this sounds plausible), but nothing is mentioned about this anywhere.

[KirinDave]

Good hack, good on Apple for getting fixes out.

But what worries me somewhat is that the tools for mitigation for these families of attacks include a lot of technologies that are traditionally opposed by the community here on the grounds that it "takes away control from the user.

I'm not sure how we balance out those tensions, but attacks like this sure as heck concern me about my homebuilt machine. I do my best not to keep any important keys there.

[artursapek]

You have a homebuilt mac? Like a hackintosh? If so, I'm pretty sure Apple doesn't owe you any kind of security assurances.

[kennell]

What encryption are you using? I was under the impression that FV2 (or any other full disk encryption solution) does not work on a Hackintosh

[ysleepy]

I'm interested in how this was fixed.

Is the update an EFI update which disables DMA or does it with IOMMU? Or is the memory just overwritten on boot?

I'm also quite surprised they leave the password in memory in multiple locations. - Assuming the password is only used to derive the KEK for the actual key.

[feld]

This exact command:

sudo firmwarepasswd -setpasswd -setmode command

enter in a password to lock down Option ROM, reboot. Now you're protected.

source, the hacker-now-Apple-developer: https://twitter.com/XenoKovah/status/809418554428657666

[dom0]

This interests me, too. I can only assume, since disabling DMA would imply a huge performance hit (and quite likely many broken devices?), that the update enables the IOMMU right from the system start, probably directly in the firmware, and has nothing/only a whitelist mapped, with further mappings only explicitly enabled by drivers?

[mkj]

Did a firmware password prevent it? The same problem with FireWire was prevented by that (a decade ago)

[partiallogic]

Would really want to know this as not everyone wants to upgrade their OSX

[nicolas_t]

Has Apple released patches for El Capitan?

I'm still using it instead of Sierra because of Karabiner but this could force me to upgrade.

That vulnerability seems to be a pretty obvious oversight. I remember hearing about DMA (in the context of Firewire) as an attack vector since people first started talking of Truecrypt and Filevault and scrubbing the memory seems obvious... It's worrying that this could have been overlooked by Apple's engineers.

[wlesieutre]

Is Karabiner Elements missing features you need? https://github.com/tekezo/Karabiner-Elements

I haven't tried it because I can't find the wireless mouse that I needed Karabiner for, but my impression was it has most of the functionality running, especially the key/button remapping which seems to be their biggest use case.

[nicholasserra]

Doesn't seem like the patch is for El Capitan, as all the kernel fixes only list Sierra.

[mweibel]

If that's the update: https://support.apple.com/en-us/HT207423 then yes.

[M4v3R]

To be fair, it seems that all OS vendors overlooked this:

https://www.youtube.com/watch?v=fXthwl6ShOg

[pier25]

Apparently this fix is only available for Sierra 10.12.2

A nice big finger from Apple to those of us that won't upgrade.

[miguelrochefort]

You better update quick! /s

Chances that someone use that device to hack your computer: 0

[hf]

FDE: Full Disk Encryption.

[eeeeeeeeeeeee]

Although this is an exploit and should be fixed, FDE rarely works if your computer is on / sleeping.

Same thing with the iPhone. Even though it has solid FDE, there have been exploits if the phone is on (even with a passcode, etc).

Turning off your device is the best protection, even if you have FDE.

[falcolas]

Well, I'd say "Turning off your device is the only protection when you have FDE", since shutting off your computer will do nothing to protect it if you don't have FDE enabled.

If it's not encrypted, connecting another computer to it with an appropriate cable will let you use it as a remote disk, leaving no real traces that it was touched.

[renaudg]

What do you mean ? This was a bug, but FV2 is clearly designed as FDE that works even if the computer is sleeping.

[kevinburke]

Is a 10.11 machine encrypted with FileVault vulnerable to this attack?

[appledude]

Yes, even if you install the December 2016 security update for 10.11.6; only 10.12.2 is protected against this Filevault vuln.

[kdeldycke]

I compiled all security enhancing configuration I found for macOS at: https://github.com/mathiasbynens/dotfiles/pull/686

Not sure these are mitigating the OP issue though. Still, can't be bad to harden macOS a little bit.

[kalleboo]

While I'm not excusing this bug (didn't they already go through this round of DMA bugs with FireWire?), this reinforces my belief that once you have physical access to a personal computer - all bets are off. If you lost your laptop, rotate all keys. Change all passwords. Assume everything is compromised.

[eeeeeeeeeeeee]

There is a huge difference between physical access and the computer being on. That is the first thing this exploit says -- it doesn't work if the computer was turned off previously.

This has always been the way to protect a computer that uses full disk encryption. Turn it off. Sleep mode will not protect you.

[therealmarv]

Is this the main reason why the Kernel Version number increased with macOS 10.12.2 ?

[appledude]

The kernel version was incremented due to kernel fixes (https://support.apple.com/en-us/HT207423). The Filevault vulnerability was fixed in 10.12.2 with a firmware update, part of the incremental update.

[djvdorp]

Dupe of https://news.ycombinator.com/item?id=13187655 ?