And before anyone comments without reading the article: No, this is not unique to macs. This particular article is about how to do it to a mac without any security features enabled. Pretty much any machine on default settings is vulnerable to this kind of attack.
And disk encryption doesn't actually save you from it, it just makes the attacker have to do more work. Namely plugging a device with a bit of flash on it between the hard drive and the SATA controller and then booting a stub OS from the flash which runs the OS on the original hard drive in a hypervisor with a key logger in the keyboard driver and waits for the user to type the encryption password.
Unrestricted physical access = root, the end.
* unrestricted physical access,
* machine returned to the original user, enough time must pass for the user to enter the password,
* unrestricted physical access again.
Also, I'm not sure if you've seen a Mac inside lately — most recent ones do not have a SATA flash drive. And even in those that do, finding enough space to place your device would be at least very challenging (if not outright impossible).
And if we're speaking about a Mac, it's actually quite impressive how much you can improve your security just by enabling FileVault.
This is just details. An attacker isn't limited to not modifying the device. If you need space you can remove half of the memory (or all of it and replace it with fewer higher density sticks), or remove the cooling fan, or install a slightly smaller battery. Do your key logging directly on the physical input device instead of using virtualization if that's easier, or go the other way and do it entirely in software by altering the necessarily unencrypted code on the device that bootstraps to a password prompt.
In the worst case the attacker can just take the entire device and replace it with one that appears identical up to the point where the user types the FileVault password, then transmits the password to the attacker over cellular.
I would notice if I didn't have 16GB.
or remove the cooling fan
Any tech person is going to notice the difference in about 40 minutes. I know this because I once didn't seat the plug for the fan correctly on my girlfriend's Macbook.
or install a slightly smaller battery
This isn't going to be so simple. There's electronics in the battery that talks to other hardware in your Macbook. That said, it's one of the most accessible and fastest to replace components in a Macbook.
A spy-agency could manufacture a battery with he addition of a little microcontroller with its own cellular broadband. It's probably within the technical capabilities of such an organization to be able to use accelerometers and microphones to determine keystrokes enough to greatly narrow down the search space for passwords. The device should be able to sense when the machine comes back from sleep mode very easily, and a cluster of characters typed shortly after that is likely to be the password.
FDE is useful in case e.g. your laptop is stolen. And it's better than nothing against a local attacker who is trying to install a rootkit like this, but if that's the attack you're worried about then it's just rearranging the deck chairs on the Titanic. Worry more about preventing physical access by the attacker than what you can do after you've already lost.
please explain how to do that for an ATM. kthx :P
gives a new meaning to 'hole in the wall' (the British term for an ATM)
Also be careful what you plug in to Thunderbolt/Firewire. https://www.google.com/search?q=thunderbolt+firewire+dma
For example, everybody knows that root is allowed to do basically anything on a system. If you write a blog post about a technique that requires root access, the typical reaction is "boring, of course root can do that". Everybody knows it's possible, and therefore it's considered uninteresting.
Why doesn't that same attitude apply to other software development? If I write a new chat app or a new operating system, nobody replies with "boring, of course a computer can do that". Even though everybody already knows it's possible to write an operating system.
It sometimes baffles me why the practical side of software development is often considered trivial just because it begins with a root shell, or in this case, physical access.
It's considered uninteresting because typically, the difficult part should be becoming root. The root account is a single point of failure in any security architecture which includes it, so the expectation is that access to it is guarded in such a well-thought fashion that executing code with root privileges is a great feat.
Not that the code you run as root shouldn't be good all by itself -- hiding traces, being difficult to wipe out and so on -- none of which actually applies to the one presented in this article.
But in any case, the fact that, in ten seconds, one is able to do nasty things on a machine which readily exposes unlimited access in about 8 seconds is, at best, an impressive feat of automation.
> Why doesn't that same attitude apply to other software development? If I write a new chat app or a new operating system, nobody replies with "boring, of course a computer can do that".
If you write a new chat app, I'd probably reply with "boring", but a new operating system? No, that's a reasonable feat of technical prowess, even if all it does is boot, expose a minimal shell and multitask a couple of processes with minimal I/O. It's not necessarily impressive, but it does nonetheless allow for an interesting glance in the thought process of another programmer. It also requires a little work -- unlike, say, rooting a machine that basically gives you root prompt on boot.
The Rubber Ducky is interesting though. I wonder if Android apps have the right APIs available such that an app could do the same thing. As long as your battery isn't already full, there's nothing suspicious about plugging your phone into a computer.
And of course it has been done, although it required a custom kernel: http://cs.gmu.edu/~astavrou/research/acsac10.pdf
As mentioned in the OpenBSD FAQ an attacker with physical access wins.
I've noticed that secure systems have the property that the more secure they are against attackers, the easier it is to be locked out of what you own.
Helps to hammer home the idea that encrypting your drive is really important.
(writing this from a MacBook with an encrypted SSD)
I guess there is some performance degradation but unless you constantly max out your SSD you probably won't notice anything.
In this case, the performance hit is minuscule.
A more interesting question is whether this should be the case. As has been noted, this is by design and made far more sense when computing devices weren't quite so mobile. Perhaps it should take more effort to boot into single-user mode? Perhaps FileVault should be on by default with a cloud-stored key tied to your Apple account?
I'm a Linux person but my gf has a Mac. It became so slow an unusable after the years that I re-installed everything and created her a non-admin account to surf the Web and, months later, things seems pretty ok for her. I'm wondering if such a quick attack by plugging an USB device works too on an unprivileged account?
You could just as well post the IP address somewhere and connect later, but then you have to worry about escaping NAT.
I don't really know what resources would help, possibly the netcat man page? http://linux.die.net/man/1/nc
hacking with physical access is not usually difficult.
No solution provides absolute security. But FileVault really goes a long way. Read the original article to the end: it says that this "attack" doesn't work on machines encrypted with FileVault. Neither does the ages-old single-user-boot technique from the article you linked to.
i'm sure filevault works, but bad defaults are security bugs as well...