
The solution is based on a USB Flash drive that can be inserted into a suspect's Mac OS X computer that is running (or sleeping). Once the software is run it will extract data from the Apple Keychain and system settings in order to provide the examiner fast access to the suspect's critical information with as little interaction or trace as possible.
MacLockPick takes advantage of the fact that the default state of the Apple Keychain is open, even if the system has been put to sleep. It also makes use of the openly readable settings files used to keep track of your suspect's contacts, activities and history. Once awakened a Mac will return it's keychain access levels to the default state found when it was initially put to sleep. Suspects often (and usually) transport portable systems in this sleeping state.
MacLockPick is not for sale to the general public. Purchasers will be required to provide proof that they are a licensed law enforcement professional. Users are required to ensure that the use of this technology is legal on federal, state, and local level.
And can we expect that there will soon be an anti-lockpicking fix for the Macs?
It's a good thing I run Windows systems that aren't prone to this kind of invasive hacking.
(emphasis mine)
If you need to run their app by hand, that doesn't help you bypass a locked screensaver, so it's really just a data-gathering program (with some smarts to extract passwords from the keychain). Not much of a "MacLockPick" if it doesn't bypass a lock.
It's possible they're just leaving out the part about bypassing the lock, but in that case, why wouldn't the autorun bit launch the main app?
Yeah, I saw this too. I can't figure out why they make such a big deal of the fact that keychains are unsecured while the computer is sleeping if you have to wake it up to extract the data. Perhaps the USB drive is somehow able to intervene and keep the keychain data from being resecured while the computer wakes up? And does it also circumvent the option to require a password upon awakening? If not, it sounds like the device is a total scam...
I'm also suspicious of their claim that their software can grab the current user's login password. If I understand correctly, that password should never be stored *anywhere* in cleartext.
Yeah, that's weird. I didn't read it very carefully. It starts off sounding like, "plug this into a sleeping laptop and it sucks the passwords out". But if you actually have to run an app on the desktop of the logged-in user, that's a whole lot less impressive.
ooof, thanks.
I just reconfigured my laptop's screensaver to require a password when I'm away. *paranoia*
Even more than that, what you want to do is open up keychain access - go into the edit menu and select "Change settings for keychain foobar" and then turn on the "lock when sleeping" options. If you really want to be paranoid, you can also have the keychain lock itself after X minutes of inactivity.
After reading an article about this on gizmag, I googled "Mac OS X locking system settings from usb drive" just to find out how to lock down not just the keychain, but also the preferences and such. It says it only works if someone has left the defaults alone, so it should be easy to defeat, perhaps more completely, with your hackintosh.
MacLockPick takes advantage of the fact that the default state of the Apple Keychain is open, even if the system has been put to sleep.
I guess this is a way of positioning it to sound like an advantage, instead of saying, "If the system is actually shutdown, you're not going to be able to get into it."
Yeah, but I don't think any Mac users actually shut down their laptops; they sleep well. And when the battery dies, they auto-sleep.
this makes me happy that i have a PC for once...
You say that as if you believe similar toolkits don't exist for Windows.
You say this as if you believe *far more effective* toolkits don't exist for Windows.
Remember, kids, Firewire is basically a port hooked up toy your system's memory.
Unless you have an openfirmware password. (what's with the openid hate btw?)
I'm surprised they don't just use the firewire port to grab a copy of system RAM. That would make far more sense.
You know, while I've heard a number of claims that FireWire gives full memory access, I don't know as anyone's actually tested whether that works, or how well. The spec says it's supposed to work that way, but I don't know whether it's actually implemented like that in controllers or not.
The winning hack at the MacHax Best Hack Contest at MacHack 2002 demonstrated this.
"Without requiring any preinstalled software on the unsuspecting target machine, Quinn lit up the crowd by plugging in a FireWire cable and starting an animated fire on the screen."
Impressive - I hadn't heard about this. Now I'm curious whether anyone's adapted it for less frivolous uses. Or how much money could be made by developing a product that used this and marketing it to forensic investigators.
http://www.csoonline.com/read/050106/ipods_pf.html
http://www.codeangel.org/article/crack_a_mac_with_firewire
Both recent.
The nice folks at Matasano did a couple of pieces on this:
http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/
http://www.matasano.com/log/710/rutkowska-on-cheating-physical-memory-acquisition/
...quite apart from the fact that if you've got physical access to a machine, there's really nothing to stop you from doing pretty much whatever you want...
I'm not entirely sure that this will stack up to its claims. If you use Keychain.app to view passwords, unless you've selected 'always allow' previously, you have to type in your account password regardless of the lock status of the keychain (in fact if it's locked, you need to type your password twice). doing the same thing from the commandline with /usr/bin/security also pops up a dialog.
SSHKeychain, which is good in and of itself, is configured by default to lock the keychain when the screensaver kicks in. It seems to also do it on system sleep, although I can't find a preference that controls that.
Surely there are others?
Presumably you grab the encrypted values. That "Return to the lab and investigate the data acquired" step presumably involves a brute-force attack to crack the keychain password. (At least, I hope that Apple's smart enough to make the keychain rainbow-table-proof.)
If that's the case, then keychain status doesn't come into it; you just snarf ~/Library/Keychains/*.
I alerted some developer about a thing I saw on Internet claiming local hack of server. He said he will fix it just because he doesn't want his product to appear with security alerts when searched from google. The reason he didn't care too much? He said if there is a actual person sitting on your chair doing evil things, you have more serious problems rather than software security. :)