Hacker News new | comments | show | ask | jobs | submit login
Root a Mac in 10 seconds or less (patrickmosca.com)
105 points by lelf 1259 days ago | hide | past | web | 61 comments | favorite



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.

Unrestricted physical access = root, the end.


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.


You don't necessarily need physical access the second time. You can just wait for an internet connection.


Of course. However, FDE will thwart this particular local attack.


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.


>Unrestricted physical access = root, the end.

please explain how to do that for an ATM. kthx :P


Please explain how to get unrestricted access to an ATM.


http://www.bbc.co.uk/news/uk-england-norfolk-18093981

gives a new meaning to 'hole in the wall' (the British term for an ATM)


And trademarked by Barclays Bank in the UK.



You drill a hole over the (covered) USB access port. There's a famous "Jackpotting ATMs" video from DefCon 2010 of how this would work.


It was a joke. Lighten up.


Here, read this BBC article from 2 weeks ago where people did exactly that....

http://www.bbc.co.uk/news/technology-25550512


Thanks for the link. Looks quite interesting. I wonder if the USB chargers in airplanes can be hacked to rickroll the entire plane :D


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

Also be careful what you plug in to Thunderbolt/Firewire. https://www.google.com/search?q=thunderbolt+firewire+dma


Anyone gets physical access to your stuff you can be owned. No story here.


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.



Wrong communication direction. I want the phone to send key presses to the computer.

And of course it has been done, although it required a custom kernel: http://cs.gmu.edu/~astavrou/research/acsac10.pdf


Is this new information? Essentially anything with single-user mode is pwnable when you have physical access.


It is new to me, although a blank page with the words "hold down command-S while booting" would have been a better article in my opinion.


Except if it is encrypted. Which it should be — any security-conscious Mac user should click this "Turn On FileVault" button and be done with it.


FileVault will defeat this method. Turn it on.


Yep, and check out Cauliflower Vest to do key escrow for FileVault if you're managing a bunch of Macs.

https://code.google.com/p/cauliflowervest/


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.


There's no home folder only filevault anymore with newer OS X versions.


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.

[1]http://www.openbsd.org/faq/faq8.html#LostPW


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.


Seems to me this does not work with encrypted drive(s).

(writing this from a MacBook with an encrypted SSD)


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.


I don't feel/see any performance loss at all. (I'm developing audio processing software).

I guess there is some performance degradation but unless you constantly max out your SSD you probably won't notice anything.



OS X and iOS heavily leverage the AES-NI instruction set (and whatever the equivalent is on ARM), so performance degradation is minimal.


It's up to the CPU actually and most CPU's have the AES instructionset by default.

In this case, the performance hit is minuscule.


It does slow things down technically, but not by much. You won't notice it.


Do you mean that rubberduck doesn't work or that protecting with encryption doesn't work?


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?


You have to reboot the computer, so no account is logged in when the attack is done.


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?


The script connects to your server. You open a listening socket on your server, then when the client connects it presents a shell.


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?


How is it a risk to the attacker? The attacker isn't presenting a shell on his server, the client is the one presenting the shell.

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


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?


There's also the sudo fail (fixed in 10.8.5)

http://cvedetails.com/cve/2013-1775


I thought you need to have access to an account that has sudo privileges and has logged in as root before (but don't know their password).


Indeed. So if people always lock their screens when walking away, they should be safe. In practice, they often don't.


They need to have successfully run the sudo command at least once. In practice, most people have never done that.


Not really a vulnerability, so much as a fact of life: If you don't lock your house (ie, turn on disk encryption), the door is, well, unlocked.


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)

example: http://www.hackmac.org/tutorials/how-to-create-a-new-adminis...

hacking with physical access is not usually difficult.


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.


right, but in reality i used that google search result to root a mac in our office.

i'm sure filevault works, but bad defaults are security bugs as well...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: