Forensics vendor warns Mac OS X FileVault vulnerable to decryption - Page 2

The passwords aren't in plaintext, the keys are in binary, but that's what you need, the binary key. And given physical access to the raw memory while the computer is on and logged in, there are ways to identify the binary key.

The passwords are plaintext. Both for user password and below, testing of an *unmounted* 256 DMG.

sudo ./MacMemoryReader ~/Desktop/ram_dump.mach-o

grep -abo canthackthis ~/Desktop/ram_dump.mach-o

585965363:canthackthis
1207265562:canthackthis
2025878541:canthackthis
^C

***UPDATE: WARNING: 256-bit AES ENCRYPTED DMG PASSWORDS ARE STORED IN PLAINTEXT IN MEMORY EVEN AFTER UNMOUNTING

The Cnet article is incorrect. See my test in the post above.

***Update: Warning: FILEVAULT2 external drive encrypted passwords are stored in plaintext in memory even after unmounting

***Update: Warning: 1Password master password for that app is stored in plaintext in memory

If they have physical access to a machine, it would appear the first thing an attacker would do is dump all the memory into a USB drive. Then go off and have fun reading all the passwords and stuff. So not just existing data on the computer is accessible but other data (web passwords perhaps?) can be read.

I'm wondering as well with RAM cached to disk. Upon restarting the machine, does some of that cached RAM stored on the hard drive get "put back" into active RAM? Hence re-loading exposed data into RAM even after restart/ shut down/ etc.

Interesting.

Indeed very informative article! Ty for posting.

I for one never had fast user switching enabled, and had screen lock after 5 min of innactivity. That should do it. Also have FV2 and Firmware password installed. I never use sleep, and i always shut down the computer at the end of the day or when i finish work

You can do this when going to sleep. You can't do it on logout, because system tasks continue to run in the background even when logged off. They will still need file system access.

I doubt this is deliberate. Disk images are (IIRC) mounted by Disk Utility, which the Finder launches in the background when you double-click on a DMG file. If, when you unmount, DU doesn't quit (perhaps because there are other mounted volumes, or maybe in order to speed up subsequent re-mounts) then it is possible for the keys to remain in memory. If the code simply frees the allocated memory, the data may remain until some other activity causes the RAM to be overwritten. DU should overwrite the memory with zeros before freeing it.

I don't think there's a need to keep the key encrypted in RAM while the image is mounted, since anyone trying to access the data could just access the mounted volume.

Personally, I don't care. I don't keep anything sensitive on my laptop.

Thanks. So I got the process name wrong, but it appears that my analysis is still correct. This specific problem (involving disk images, not File Vault 2) should be easily fixable.

Well, someone looking at the size of the encrypted home directory will know how much stuff you have stored. He won't know how much of it is critical data. I may have one critical document and 50GB of my iTunes music collection in there.

It depends on how it's done. You can pass the hash through as many times as you like so if someone tries to brute force the hash they see in RAM, they won't get your password because a hash result was used to generate it. If they figured out the process Apple used to create the hash, they could brute force it and without a salt, generate a lookup table but Apple just has to use random salts and make the hash process slow. Apple only does it once, brute force requires someone to do it many billions of times over.


They should be able to do it as soon as you have mounted the volume.


VM caches are flushed on reboot but of course the old VM caches aren't overwritten so plain text passwords that went into RAM and were paged to the drive will exist in your deleted files until overwritten. You could for example sell on an old computer that has a trace of your plain text passwords for your encrypted drives - hence why you should always zero the drive.


It depends on the attack that's being used. Say you were a rival company to Apple (e.g Samsung) and wanted to steal all the upcoming designs. You wouldn't try to copy GBs over the network while the drive was mounted, you'd send a trojan that installs as root and scan the RAM for plain text keys.

Then you'd either do a physical theft of the drives and be able to unlock them easily or unlock them at your leisure via a remote command, most likely when the systems were not in use.


It should be but I think they should encrypt volumes using hashed keys, which would require the encryption to be re-applied.

Cheers... Well, sounds like you have it covered!

Ah, interesting. Well, that's a point in favour of whole-disk encryption. FileVault2 would ensure someone that pulled the drive would not be able to read old VM caches even if the drive had not been zero'd.

I don't think I'd ever work with unencrypted drives ever again, given what I know now. I did have some fairly old hard disks and I just opened it up and smashed the platters. I guess 7-pass erase or whatever would've been less "physical" LOL. I think I didn't have the patience. Plus it's interesting seeing the innards of a modern hard drive. And to think it's old hat now. Spinning physical media... So '00s

I use an encrypted disk image to protect my sensitive files (tax returns, bank account details etc). Never saw any need to encrypt my whole HD.

Am quite disappointed with Apple if they don't remove the password from memory upon eject. They need a special version of free() which zeroes out, and a way to flag certain NSObjects as needing this, and have ARC honor it.

Hey guys, this may interest you: I've developed an open source tool that are able to facilitate the same functionality as the Passware tool. It is called Inception, and you can check it out here.

/shameless plug

Also, it turns out that both the Passware tool and Inception works over Thunderbolt daisy chaining as well. This opens up the possibility of being hacked when connecting to a Thunderbolt device, such as a hard drive or a Thunderbolt display. Since the FileVault2 DMA protection only is in effect when the OS is locked, the DMA attacks will essentially work if performed covert while the machine is unlocked.

The same restrictions as mentioned in the frameloss.org article and the posts above apply.

Thunderbolt is effectively a PCI Express slot. It has all the same vulnerabilities that could be exploited against a card installed in a Mac Pro's PCIe slot. If you attach an untrusted device, then it can access absolutely everything in the computer.

IT security departments should make a point of letting users know about this, if they think it is a serious concern.

That is is terrific.

That page also provides the crucial information that DMA can be turned off by setting a Firmware password for your Mac.  (I've been using Filevault2 in lieu of a firmware password, but now I know to use both.  What I don't know is that the performance hit will be by disabling DMA.

 

Cheers,

 

-j