| Comments: |
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.
The investigation process is a simple 4-step procedure:
MacLockPick inserted into a suspect's Macintosh computer.
* Insert the MacLockPick flash drive into your suspect's computer * Double Click on the MacLockPick Application * Eject the MacLockPick flash drive from your suspect's computer * Return to the lab and investigate the data acquired and stored on the MacLockPick flash drive using the included program "KeyLog Reader". KeyLog Reader is shipped for Mac OS X, Microsoft Windows, and Linux. (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.
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 3-May-2007 8:47 PM (UTC)
| (Link)
|
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.
![[User Picture]](http://l-userpic.livejournal.com/73180911/236883) | From: netik Thu, 3-May-2007 8:01 PM (UTC)
| (Link)
|
ooof, thanks.
I just reconfigured my laptop's screensaver to require a password when I'm away. *paranoia*
![[User Picture]](http://l-userpic.livejournal.com/70952415/4224) | From: sol3 Thu, 3-May-2007 8:41 PM (UTC)
| (Link)
|
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.
![[User Picture]](http://l-userpic.livejournal.com/83884494/932864) | From: erg Wed, 4-Jun-2008 3:50 PM (UTC)
| (Link)
|
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."
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 3-May-2007 8:45 PM (UTC)
| (Link)
|
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.
![[User Picture]](http://l-userpic.livejournal.com/41092695/1371749) | From: mkj Wed, 9-May-2007 11:56 AM (UTC)
| (Link)
|
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.
![[User Picture]](http://l-userpic.livejournal.com/35025624/8296261) | From: mtbg Fri, 4-May-2007 7:28 PM (UTC)
| (Link)
|
...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/*.
From: ilgazc Fri, 4-May-2007 9:50 AM (UTC)
Quote from a server developer | (Link)
|
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. :)
| |