Doesn't work with disk encryption enabled or with a firmware password enabled.
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.
It isn't even a vulnerability. It's just the state of the world.
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.
Agreed in general — but note that what you described is slightly different. It isn't just "unrestricted physical access", but:
* 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.
> 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).
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.
If you need space you can remove half of the memory
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.
Restricting the set of attacks you're interested in preventing to the one somebody posted an article about is not a good security posture.
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.
This was mentioned in the article. Although I recommend having both a firmware password and encryption enabled. It's not as easy to break the firmware password these days, and it will help prevent further unauthorized access/changes. (Of course I'm paranoid.) http://reviews.cnet.com/8301-13727_7-57542601-263/efi-firmwa...
It seems to me that whenever something security related is published, there is an expectation that it has to be something completely new. Something that was previously thought impossible. It's almost as if software has no value if it doesn't exploit some new bug.
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.
> 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.
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.
I was hoping to learn about a Mac vulnerability, not a feature documented by Apple.
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.
For your entire disk though. If you only turn it on for your Personal folder, it does nothing to prevent this, and will in fact only give you a false sense of security.
This isn't really a new attack, but it is pretty cool way of automating it. Other comments mention this being mitigated with full disk encryption and a firmware password.
As mentioned in the OpenBSD FAQ[1] an attacker with physical access wins.
On the other hand, I find it reassuring that you can easily become root if you have physical access, since it means being able to easily recover from screwups with your regular account.
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.
My boss recently had a problem where they couldn't log into their Mac even though their password hadn't changed. With two minutes of googling I found it was very simple to enter single user mode and recover their account. Pretty neat, but a little disconcerting how easy it is to access your files if your laptop gets stolen.
Helps to hammer home the idea that encrypting your drive is really important.
How does encrypted SSD perform, compared to unencrypted? My SSD does reads/writes in the 500MB/s range. Does encryption significantly slow down performance?
It's noticeable for sure. My Samsung 830 SSD took a pretty serious hit in transfer rates. New full flash based Mac's like my late '13 retina i7 seems to handle it pretty well, though, there's still a noticeable difference. Worth it? Absolutely. If you do end up doing it - when prompted, I would recommend against saving your encryption key to iCloud.
Just turned it on on my 15" 2012 rMBP and it finished encrypting the drive. Before I was getting around 520-540MB/s read/write. Now it's 440-460MB/s. It's not a large hit, slightly noticeable, but worth the security. I am not sure about battery life, but I could not see any one else online complaining.
While physical access on almost any hardware (without whole-disk encryption) will always allow full access, it's good that this is sometimes raised as many people either don't know or don't internalize this.
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?
Does it work too if the account opened on the Mac is a non-admin 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?
There's one point I do not understand. After running this, you always need the ip of the victim to remote login, correct? or there's something I missed?
I see, but Isn't that a risk for the attacker? I taught the idea was to run a server on the victim and connect to it...
In my mind the script was supposed to post the victim ip on pastebin. There's something wrong with my approach? any good resource to understand the logic?
since you are statically sharing the server details... Isn't this as leaving your id card on the crime scene?
anyway, for who might be interested, the technical term is "reverse shell" (the one in the article) or "bind shell" (the one I wanted).
If you have physical access to a machine, you can reboot into single user mode and have root terminal access anyway. I don't see how this is any different?
you know googling how to hack a mac reveals several results which although don't use the same method use similarly easy hacks... there is a file you can remove or add which 'resets' the machine to how it came out of the factory (but does not delete any files, including the user folder)
This (including the original article) is all hogwash. All that Mac users have to do is to go into Security preferences and click "Turn On FileVault".
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.
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.