4 ms·

FileVault 2 Easily Decrypted

nodata 15y ago
tl;dr: direct memory access via firewire can recover the key within an hour. Anyone know if firewire be disabled at the hardware level on macs?
- huwr2 15y ago
  I was going to suggest filling the socket with dried play-doh, but thus guy reckons removing the kernel extensions could help: https://discussions.apple.com/message/9200953#9200953 https://discussions.apple.com/message/9200953#9200953 Though that's a bit crude... I'd be interested too.
- droithomme 15y ago
  It's not really scanning memory, that's just their marketers trying to spin some razzlemadazzle for the plebes. It's using Firewire Target Disk mode to get raw access to the disk. Apple stores its admin passwords using the highly obsolete MD5 algorithm, which is easily cracked in most cases using rainbow tables generated using the seed that is stored in plain text. It's pretty simply and I have personally broke into my own File Vault partitions after forgetting the password. You don't even need to spent $995, it's trivial to do with almost no skills. Anyone can do it themselves, which should convince them that File Vault is useless and its CPU load a pointless price to pay for zero security gain. This has all been dead obvious from day one too, the cited article is not even news, it's an advertisement for a company selling junk to clueless law enforcement incapable of doing basic research. edit: OK, I'm wrong on some technical details: 1. Apple uses SHA-1 hashing not MD5. 2. I either need admin access in any account to access the /private/var/db/dslocal/nodes/Default/users/ folder and pull the plist with the hash from the account I am interested in, or I need to boot in Firewire mode which allows raw disk access to the unencrypted partition with that folder. (I haven't paid $995 for the referenced program but that would seem possible that's what it is really doing, not reading memory through FireWire looking for the plaintext password stored in the open in memory, which is also possible: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f... - this also helpfully notes that "sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext" deletes the relevant kernel extension to kill FW - I happen to already have this removed for other reasons.) Still just as vulnerable to rainbow tables, but shoot maybe it does scan memory.
  - kalleboo 15y ago
    Wouldn't Firewire Target Disk mode just give them the encrypted data, i.e. useless? The admin passwords are stored on the encrypted partition. edit: I guess your edits deprecate my reply
    - droithomme 15y ago
      Yes, the admin password hashes have to be stored unencrypted otherwise you can't log in at all.
  - Canada 15y ago
    So, you kinda made the part up about personally breaking then?
    - droithomme 15y ago
      No I didn't make it up, I have recovered passwords on encrypted volumes just as I said, and just as you can. It's been a few months since I last had to do this. After posting I realized I was unsure if the hashing algorithm was really MD5, went and looked at the actual hash after posting to make sure that I had it right, saw that it's SHA-1 not MD5, and appended the post with a prominently noted edit so it would be clear I wasn't trying to hide anything retroactively through edits. edit: It's foolish downvoting these two posts. The information is factual. I corrected my error about the hash. Both MD5 and SHA-1 are vulnerable to rainbow tables folks. To fix the rainbow attack Apple should be using Two Fish instead of SHA-1 which is highly susceptible to this attack, which is why I was able to recover my password. If you can recover your password, you don't have security. Attempting to do so is a good exercise in finding out if you have security, at least it was for me and I now use much better admin passwords, though the better solution would be for Apple to upgrade to a much more resilient hash for passwords.
      - caller9 15y ago
        Or they could salt the password hash with the username. Rainbow tables would need to be based on the salt and therefore unlikely to exist.
hukl 15y ago
Actually this applies to "all" other similar encryption technologies and is not limited to mac or firewire. You can also use Thunderbolt, PCMCIA, ExpressCard and even esata ports to have direct access to a computers RAM in which you passphrase is being held. Basically all ports which use DMA are possible if I remember correctly. Further reading: http://en.wikipedia.org/wiki/DMA_attack http://en.wikipedia.org/wiki/DMA_attack
- hukl 15y ago
  Basically the only "defense" is to shut your computer down when you're leaving it alone / unattended for some time.
  - willvarfar 15y ago
    Turning off the machine can be easily socially engineered around by a determined targeted attacker; all from fire alarms to a visit from IT staff to giving you a free memory stick at a trade show and so on. If you were to be gifted a new USB keyboard tomorrow from some random company, you'd likely accept it unquestioningly. Also, given that you leave your computer unattended, even whilst turned off, gives the attacker opportunity to insert a small device out of sight, rather as cleaners really have done with keyloggers on computers at banks. Isn't when you are present the time when its hardest for them to attack because of the physical contact required? Of course, in films the robber-dressed-as-janitor always manages to walk into the server-room with a tool box.. There are three types of attacker, right? 1) your password/data is valuable, its a targeted attack, the attacker will take the risk of direct access to the machine; they can do this by socially engineering you to insert the trojan hardware, or they can add some small hardware dongle when you don't see or understand 2) law enforcement, they will grab the machine, you'll know they have done so; DMA attack is just a lot more straightforward than freezing it and probing type attacks. 3) those prepared to use a $5 wrench http://xkcd.com/538/ http://xkcd.com/538/
  - nodata 15y ago
    Why won't disabling features which give easy access to ram work?
aristidb 15y ago
Infinite redirect chain on my mobile phone.
fdb 15y ago
Since the MacBook Air doesn't have a FireWire port, can I assume this technique doesn't apply? Or would it still be possible using one of the other ports?
- gtufano 15y ago
  The thunderbolt port have DMA access also, so I suppose the technique applies as well.
jvdh 15y ago
Additional info is here: http://news.cnet.com/8301-1009_3-57370628-83/security-concerns-on-apples-filevault-decryption-via-firewire/ http://news.cnet.com/8301-1009_3-57370628-83/security-concer...
jmah 15y ago
On PPC Macs with Open Firmware (pre-EFI), FireWire DMA would be disabled if a boot password was set. I haven't come across any details on recent models...
- pudquick 15y ago
  Works for Intel / EFI as well. Setting a boot password will lock out boot media / FireWire DMA. You can set it from your install media's Utilities menu (or while booted into Lion Recovery Partition). Fun fact: All of the Open Firmware / PPC Macs and most of the Intel Macs (with the exception of most every 2010+ model) could reset or blank the password by changing the RAM configuration. The newest Intel Macs, however, won't do this. You have to take the Mac to a service center where they generate a special binary (using an internal tool) that's specific to the machine(s) they need to unlock and place it on USB media, during boot, to trigger an unlock override. In short: Got a new new Mac? Don't set a password and forget it, write it down!
cyann 15y ago
This is what I set on my MBP (equipped with SSD): sudo pmset -a hibernatemode 25 destroyfvkeyonstandby 1 sms 0
- droithomme 15y ago
  Thanks, that is very useful, I was wondering why it didn't scrub it from memory when it sleeps. Article discussing this setting and providing links to a free and open forensic library so people can actually test the FW memory search method themselves, yanking passwords straight off of their friends laptops as a fun party trick or what not: http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevault-2-encryption/ http://www.frameloss.org/2011/09/18/firewire-attacks-against...
  - ryannielsen 15y ago
    It's not scrubbed from memory on short term sleep so the OS can provide a more user friendly experience – rather than dropping you at the EFI login window when you wake from sleep, you'll be presented with the more capable and better looking OS sleep unlock window. If the machine is asleep for "a while" then it will write out a sleep image file and power off RAM (and other hardware) to go into a deep sleep. Since the sleep image file is written to the FDE volume, you must first unlock the volume at EFI's login window to gain access to the sleep image and resume from sleep. That process takes far longer than waking from a warm OS, so it's not done by default. You can change sleep settings using pmset on the command line and force it to always destroy the FV keys on sleep, if security is more important that a quick wake from sleep.
    - droithomme 15y ago
      Yes, I switched the pmset settings after reading the article I linked to that discussed his settings and making the comment. Benchmarking it shows that with all programs quit and hibernatemode at 25, it takes around 2 seconds to enter RAM-off-sleep and 8 seconds to awaken from it, rather than both happening instantly with RAM-on-sleep. It's not really all that slow, I wouldn't say it's all that noticeably longer. It's kind of an impressively fast memory dump and restore.
JoshTriplett 15y ago
Current Linux disables the device-initiated DMA mechanism for firewire and other "untrusted" busses, though it should probably consider more types of busses "untrusted" than it does. This requires the host driver to initiate DMA, which it'll only do for devices it knows how to talk to safely. Turning this protection off (and thus making the system insecure) requires both compiling a kernel with the debugging-only option CONFIG_FIREWIRE_OHCI_REMOTE_DMA turned on and passing a kernel parameter at boot time, so you can't do it accidentally. I thought more recent versions of OS X fixed this problem as well, but perhaps not.
- ryannielsen 15y ago
  FireWire and Thunderbolt DMA is disabled if you set an firmware password. On systems which support Intel's VT-d technology, the OS will actually allow restricted DMA even with the firmware password set so you get almost all the benefits of DMA without the security compromise of having all memory exposed to the foreign device.
- mike-cardwell 15y ago
  This is a great article about this subject: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f... It contains mitigation information for OSX, Linux, Windows and various flavours of Unix.

tl;dr: direct memory access via firewire can recover the key within an hour. Anyone know if firewire be disabled at the hardware level on macs?

huwr2 15y ago
I was going to suggest filling the socket with dried play-doh, but thus guy reckons removing the kernel extensions could help: https://discussions.apple.com/message/9200953#9200953 https://discussions.apple.com/message/9200953#9200953 Though that's a bit crude... I'd be interested too.
droithomme 15y ago
It's not really scanning memory, that's just their marketers trying to spin some razzlemadazzle for the plebes. It's using Firewire Target Disk mode to get raw access to the disk. Apple stores its admin passwords using the highly obsolete MD5 algorithm, which is easily cracked in most cases using rainbow tables generated using the seed that is stored in plain text. It's pretty simply and I have personally broke into my own File Vault partitions after forgetting the password. You don't even need to spent $995, it's trivial to do with almost no skills. Anyone can do it themselves, which should convince them that File Vault is useless and its CPU load a pointless price to pay for zero security gain. This has all been dead obvious from day one too, the cited article is not even news, it's an advertisement for a company selling junk to clueless law enforcement incapable of doing basic research. edit: OK, I'm wrong on some technical details: 1. Apple uses SHA-1 hashing not MD5. 2. I either need admin access in any account to access the /private/var/db/dslocal/nodes/Default/users/ folder and pull the plist with the hash from the account I am interested in, or I need to boot in Firewire mode which allows raw disk access to the unencrypted partition with that folder. (I haven't paid $995 for the referenced program but that would seem possible that's what it is really doing, not reading memory through FireWire looking for the plaintext password stored in the open in memory, which is also possible: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f... - this also helpfully notes that "sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext" deletes the relevant kernel extension to kill FW - I happen to already have this removed for other reasons.) Still just as vulnerable to rainbow tables, but shoot maybe it does scan memory.
- kalleboo 15y ago
  Wouldn't Firewire Target Disk mode just give them the encrypted data, i.e. useless? The admin passwords are stored on the encrypted partition. edit: I guess your edits deprecate my reply
  - droithomme 15y ago
    Yes, the admin password hashes have to be stored unencrypted otherwise you can't log in at all.
- Canada 15y ago
  So, you kinda made the part up about personally breaking then?
  - droithomme 15y ago
    No I didn't make it up, I have recovered passwords on encrypted volumes just as I said, and just as you can. It's been a few months since I last had to do this. After posting I realized I was unsure if the hashing algorithm was really MD5, went and looked at the actual hash after posting to make sure that I had it right, saw that it's SHA-1 not MD5, and appended the post with a prominently noted edit so it would be clear I wasn't trying to hide anything retroactively through edits. edit: It's foolish downvoting these two posts. The information is factual. I corrected my error about the hash. Both MD5 and SHA-1 are vulnerable to rainbow tables folks. To fix the rainbow attack Apple should be using Two Fish instead of SHA-1 which is highly susceptible to this attack, which is why I was able to recover my password. If you can recover your password, you don't have security. Attempting to do so is a good exercise in finding out if you have security, at least it was for me and I now use much better admin passwords, though the better solution would be for Apple to upgrade to a much more resilient hash for passwords.
    - caller9 15y ago
      Or they could salt the password hash with the username. Rainbow tables would need to be based on the salt and therefore unlikely to exist.

hukl 15y ago

Actually this applies to "all" other similar encryption technologies and is not limited to mac or firewire. You can also use Thunderbolt, PCMCIA, ExpressCard and even esata ports to have direct access to a computers RAM in which you passphrase is being held. Basically all ports which use DMA are possible if I remember correctly. Further reading: http://en.wikipedia.org/wiki/DMA_attack http://en.wikipedia.org/wiki/DMA_attack

hukl 15y ago
Basically the only "defense" is to shut your computer down when you're leaving it alone / unattended for some time.
- willvarfar 15y ago
  Turning off the machine can be easily socially engineered around by a determined targeted attacker; all from fire alarms to a visit from IT staff to giving you a free memory stick at a trade show and so on. If you were to be gifted a new USB keyboard tomorrow from some random company, you'd likely accept it unquestioningly. Also, given that you leave your computer unattended, even whilst turned off, gives the attacker opportunity to insert a small device out of sight, rather as cleaners really have done with keyloggers on computers at banks. Isn't when you are present the time when its hardest for them to attack because of the physical contact required? Of course, in films the robber-dressed-as-janitor always manages to walk into the server-room with a tool box.. There are three types of attacker, right? 1) your password/data is valuable, its a targeted attack, the attacker will take the risk of direct access to the machine; they can do this by socially engineering you to insert the trojan hardware, or they can add some small hardware dongle when you don't see or understand 2) law enforcement, they will grab the machine, you'll know they have done so; DMA attack is just a lot more straightforward than freezing it and probing type attacks. 3) those prepared to use a $5 wrench http://xkcd.com/538/ http://xkcd.com/538/
- nodata 15y ago
  Why won't disabling features which give easy access to ram work?

aristidb 15y ago

Infinite redirect chain on my mobile phone.

fdb 15y ago

Since the MacBook Air doesn't have a FireWire port, can I assume this technique doesn't apply? Or would it still be possible using one of the other ports?

gtufano 15y ago
The thunderbolt port have DMA access also, so I suppose the technique applies as well.

jvdh 15y ago

Additional info is here: http://news.cnet.com/8301-1009_3-57370628-83/security-concerns-on-apples-filevault-decryption-via-firewire/ http://news.cnet.com/8301-1009_3-57370628-83/security-concer...

jmah 15y ago

On PPC Macs with Open Firmware (pre-EFI), FireWire DMA would be disabled if a boot password was set. I haven't come across any details on recent models...

pudquick 15y ago
Works for Intel / EFI as well. Setting a boot password will lock out boot media / FireWire DMA. You can set it from your install media's Utilities menu (or while booted into Lion Recovery Partition). Fun fact: All of the Open Firmware / PPC Macs and most of the Intel Macs (with the exception of most every 2010+ model) could reset or blank the password by changing the RAM configuration. The newest Intel Macs, however, won't do this. You have to take the Mac to a service center where they generate a special binary (using an internal tool) that's specific to the machine(s) they need to unlock and place it on USB media, during boot, to trigger an unlock override. In short: Got a new new Mac? Don't set a password and forget it, write it down!

cyann 15y ago

This is what I set on my MBP (equipped with SSD): sudo pmset -a hibernatemode 25 destroyfvkeyonstandby 1 sms 0

droithomme 15y ago
Thanks, that is very useful, I was wondering why it didn't scrub it from memory when it sleeps. Article discussing this setting and providing links to a free and open forensic library so people can actually test the FW memory search method themselves, yanking passwords straight off of their friends laptops as a fun party trick or what not: http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevault-2-encryption/ http://www.frameloss.org/2011/09/18/firewire-attacks-against...
- ryannielsen 15y ago
  It's not scrubbed from memory on short term sleep so the OS can provide a more user friendly experience – rather than dropping you at the EFI login window when you wake from sleep, you'll be presented with the more capable and better looking OS sleep unlock window. If the machine is asleep for "a while" then it will write out a sleep image file and power off RAM (and other hardware) to go into a deep sleep. Since the sleep image file is written to the FDE volume, you must first unlock the volume at EFI's login window to gain access to the sleep image and resume from sleep. That process takes far longer than waking from a warm OS, so it's not done by default. You can change sleep settings using pmset on the command line and force it to always destroy the FV keys on sleep, if security is more important that a quick wake from sleep.
  - droithomme 15y ago
    Yes, I switched the pmset settings after reading the article I linked to that discussed his settings and making the comment. Benchmarking it shows that with all programs quit and hibernatemode at 25, it takes around 2 seconds to enter RAM-off-sleep and 8 seconds to awaken from it, rather than both happening instantly with RAM-on-sleep. It's not really all that slow, I wouldn't say it's all that noticeably longer. It's kind of an impressively fast memory dump and restore.

JoshTriplett 15y ago

Current Linux disables the device-initiated DMA mechanism for firewire and other "untrusted" busses, though it should probably consider more types of busses "untrusted" than it does. This requires the host driver to initiate DMA, which it'll only do for devices it knows how to talk to safely. Turning this protection off (and thus making the system insecure) requires both compiling a kernel with the debugging-only option CONFIG_FIREWIRE_OHCI_REMOTE_DMA turned on and passing a kernel parameter at boot time, so you can't do it accidentally. I thought more recent versions of OS X fixed this problem as well, but perhaps not.

ryannielsen 15y ago
FireWire and Thunderbolt DMA is disabled if you set an firmware password. On systems which support Intel's VT-d technology, the OS will actually allow restricted DMA even with the firmware password set so you get almost all the benefits of DMA without the security compromise of having all memory exposed to the foreign device.
mike-cardwell 15y ago
This is a great article about this subject: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f... It contains mitigation information for OSX, Linux, Windows and various flavours of Unix.