Hacker News Reader

Comment by nodata | Hacker News Reader

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?

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

Though that's a bit crude...

I'd be interested too.

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

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

Yes, the admin password hashes have to be stored unencrypted otherwise you can't log in at all.

So, you kinda made the part up about personally breaking then?

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.

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.

Reply on news.ycombinator.com