MacOS FileVault2 Password Retrieval | Hacker News Reader

MacOS FileVault2 Password Retrieval

blog.frizk.net

274 pointsmkesper83 comments

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...

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.

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.

Thanks for sharing these awesome shortcuts!

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

You could read through http://training.apple.com/pdf/WP_FileVault2.pdf for some of the details, or `man pmset`. Use `pmset -g` at any time to see your current settings.

Just make sure you eject any removable disks before hibernating. And, sleepfast may drain your battery faster than the default hybrid sleep

OP said sleepfast increases his battery life. It sounds like you lose whatever is in memory though

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.

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.

It is possible to suspend Bitlocker. This works by writing the key somewhere on the disk. Then when you reenable it the key is removed again. This is necessary if you normally store the key in the TPM chip and you're going to do something that will break its trust, like updating the BIOS.

The recent update would suspend Bitlocker during the installation which is not a nice thing to do automatically.

It doesn't mean Microsoft has the keys though.

You can optionally store your FDE key on Apple's iCloud, but Apple makes it extremely clear what it is doing and offers to let you do so or not do so.

Right-o about using the built in FDE. It's kind of funny to think about how many lay users walk around thinking their laptop is safely protected by a password.

My girlfriend was shocked at how easily I was able to "hack" her laptop and reset the forgotten password by changing whatever accessibility.exe to cmd.exe.

A PC + "expensive Windows professional license" is still cheaper than a Mac.

This is not really relevant to the discussion, or even fully accurate. Most people who buy windows licenses (including me) buy one of the base licenses because we generally don't need the other "professional" features on our home computers.

> 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.

Assume that there are generally two kinds of physical attackers:

* Casual, opportunistic attackers who will steal any available laptop.

* Targeted attackers who want your laptop in particular.

Against a casual attacker, even if your laptop is stolen unlocked, it's not going to be carefully kept unlocked. Doing so requires sophistication, care, and extra risk. Instead, the laptop is just going to get wiped.

Against a targeted attacker, like the FBI when they took down Ross Ulbricht (who FDE'd his laptop), the attacker will simply wait until the laptop is unlocked.

I was curious about that, so I looked it up. Pretty interesting stuff.

[0] "On the afternoon of October 1, 2013, officers watched as Ulbricht entered the library and made his way up the stairs to work by the window at a desk in the science fiction section, Kiernan recalled. Meanwhile, sitting on a bench outside of the library, homeland security officer Jared Der-Yeghiayan — who had been working undercover as Silk Road employee "cirrus" — initiated a chat with Ulbricht, requesting that he log in to Silk Road's back end to fix a technical problem. As soon as Der-Yeghiayan could confirm that Ulbricht was logged into the site, FBI agents entered the library.

Two plainclothes FBI agents, one male and one female, walked up behind Ulbricht and began arguing loudly. This staged lovers' tiff caught Ulbricht's attention long enough to distract him from his laptop. As soon as Ulbricht looked up, the male agent reached down and slid the computer over to his female colleague, who quickly snatched it up and handed it over to Kiernan for further investigation."

[0] http://www.businessinsider.com/ross-ulbricht-will-be-sentenc...

If they made a movie about Snowden, they will surely made a movie about this.

Yup: http://www.theverge.com/2016/10/14/13290460/coen-brothers-si...

American Greed episode on Silk Road:

http://www.cnbc.com/live-tv/american-greed/full-episode/silk...

There was a similar, bar less dramatic, case in the UK recently - where police swiped the phone from the hands of a suspect as he took a call, and then kept interacting with the screen to keep it unlocked long enough to recover the evidence required.

In retrospect, it's a pretty obvious attack vector.

A dead man's switch with a very short time-out would make that kind of attack a lot harder.

For the extremely security-conscious, it could even be a kind of fail-deadly (https://en.wikipedia.org/wiki/Fail-deadly) feature that wipes the phone.

See, this is the problem with people's conception of FDE. This is actually a very silly solution to the problem.

The right approach is to recognize what FDE is good at (minimizing the risk that casual thieves will get data in addition to valuable parts, and protecting computers that can frequently be powered all the way off from even advanced attackers), and then use something better to protect sensitive data.

https://github.com/hephaest0s/usbkill Checks for changes with USB drives and shuts down the computer and optionally deletes files and wipes ram. USB stick on a wristband > unplugs when they take the computer > shuts down

>the attacker will simply wait until the laptop is unlocked.

A potential counter measure is for the machine to periodically encrypt itself again and prevent use until a password/key is supplied ("clamming up"). This would prevent an attacker who snatched a logged-into computer from having unbounded carte blanche access to the machine. I'm envisioning something that every 10 minutes locks itself.

Does anyone know of such a solution?

A screen saver (w/ require password & possible full hibernation with memory flush)?

That's defeated by a USB mouse jiggler [1], which is apparently commonly used by the type of people who seize computers in the wild.

[1] https://www.amazon.com/CRU-Inc-30200-0100-0011-WiebeTech-Jig...

Yes, my idea was a intension counter measure to 'mouse' jigglers.

I think they are talking about a system that unconditionally asks for the password every 10 minutes even while the computer is in active use.

Even though the computer may be “locked”, if the OS is running and accessing the disk, it means that the key is present somewhere in memory. There are various methods of accessing this key, the fallback brute-force method being the (https://en.wikipedia.org/wiki/Cold_boot_attack). The method from the article only removes the need to physically remove and cool the memory chips.

There are no memory chips to remove on recent Macs, making this attack much harder if not impossible to perform.

Macs still have memory chips, even if they are not removable. This can be attacked by using specialized hardware which you press onto the RAM chips’ connectors. The inability to remove RAM is not meant as a security feature, and therefore gives no significant protection against a motivated attacker with specialized hardware.

Ok, I thought that Apple would scrub all keys from memory when the computer goes to sleep so that a computer that's asleep would not be vulnerable to the Cold Boot Attack. Seems strange they don't do that? Or would it make waking up too slow?

My understanding is that it is configurable on macOS by enabling destroyfvkeyonstandby.

https://derflounder.wordpress.com/2014/02/12/power-nap-power...

Apple wants the computer to be able to wake up on its own in order to fetch new emails and such. Just a few minutes ago, I used Screen Sharing to connect to my sleeping MacBook from another room to check for updates based on this article's recommendation. Quite convenient, but it does imply that the OS keeps the keys around.

I'd bet that if you turn all that stuff off, they keys are scrubbed. That could be a good compromise instead of turning the computer completely off all the time.

Sleep does not shuts down ram.

> 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?

The Windows lockscreen has had a law enforcement backdoor since at least Windows XP. This effectively makes FDE worthless on Windows if you only put your computer to sleep instead of a full shutdown.

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."

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.

I saw the firmware-update progress bar (one of several similar progress bars that macOS/OS X can show during startup) during a 10.12.2 update. So that's a bit more confirmation...

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.

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

DMA attacks are potentially possible on more than just macs

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

Why would FV2 protect me from DMA attacks on machines that are essentially self built off the shelf parts?

Hint: it probably won't.

It unfortunately doesn't work on the boot volume of a Hackintosh, but pretty sure it does on other volumes.

Actually, there have been recent development on this.[1] I'm not brave enough to try it though.

[1] http://www.insanelymac.com/forum/topic/317290-filevault-2/

Sweet, thanks for the link, will give it a try after i got everything backed up :)

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.

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

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?

I wonder if the chipset can't do a sort of DMA emulation, or DMA with conditions versus the sort of free-for-all stuff you'd see with things like FireWire.

That's what an IOMMU does.

Without an IOMMU devices on extension buses directly address physical memory.

With an MMU the host CPU creates a virtual address space for devices and can thus limit access to the main memory (conveniently also allows passing devices to VM guests), much like virtual memory for processes/VMs.

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

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

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

Anyone who wants to stay secure should want to upgrade their system...

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.

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.

I haven't found a way to configure Karabiner Elements to replace Caps lock with Escape when I only press that key (for vim) and with Ctrl when I press it in combination with other keys (for the terminal).

I also have both Shift keys bound to () when pressed alone and Shift when pressed in combination with other keys.

Discussion of the caps lock solo/chorded feature here: https://github.com/tekezo/Karabiner-Elements/pull/170#issuec...

Looks like it's not in master, but somebody has builds that do it.

Thanks wlesieutre! I had looked in the issues but somehow missed that pull request. Now I can use Sierra :)

Happy to help!

Thanks for the use-case, i am really fascinated to use this from now on. Working with vim would be awesome.

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

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

That changelog includes a bunch of fixes that are Sierra only, so the answer may be "no" contrary to your comment.

This is the closest I can find on there to this issue and the fix is Sierra only:

IOFireWireFamily Available for: macOS Sierra 10.12.1 Impact: A local attacker may be able to read kernel memory Description: A memory corruption issue was addressed through improved memory handling. CVE-2016-7608: Brandon Azad

Attribution on that doesn;t look right; TFA was by "Ulf Frisk" who was nowhere on that page.

Why would someone be using El Capitan still, some may ask. Well there is software not updated for Sierra yet. For example, GPG for Mac is not yet ported over.

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

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

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.

You better update quick! /s

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

FDE: Full Disk Encryption.

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.

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.

Uhh, I think that was pretty clear from my comment. FDE only gives you "complete" security in transit if you shut it off. Leaving a FDE computer in sleep mode will not protect you.

But even in sleep mode, a FDE computer is still better than no encryption at all.

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

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

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

Are you planning to backport the fix? It would be very disappointing if a serious security problem like this would be left unaddressed. Not all of us can or want to switch to the latest major within months after its release.

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.

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.

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.

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

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.

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

Reply on news.ycombinator.com