7 ms·
Root a Mac in 10 seconds or less
- zwily 13y agoFileVault will defeat this method. Turn it on.
- jvdh 13y agoFor 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.
- kybernetyk 13y agoThere's no home folder only filevault anymore with newer OS X versions.
- packetslave 13y agoYep, 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/ https://code.google.com/p/cauliflowervest/
- wyager 13y agoDoesn'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.
- lstamour 13y agoThis 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-firmware-protection-locks-down-newer-macs/ 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 https://www.google.com/search?q=thunderbolt+firewire+dma
- AnthonyMouse 13y agoIt 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.
- wyager 13y agoOf course. However, FDE will thwart this particular local attack.
- AnthonyMouse 13y agoRestricting 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.
- ksk 13y ago>Unrestricted physical access = root, the end. please explain how to do that for an ATM. kthx :P
- kybernetyk 13y agoPlease explain how to get unrestricted access to an ATM.
- petemc_ 13y agohttp://www.srmti.com/news/cash-machines-raided-with-infected-usb-sticks-11109/ http://www.srmti.com/news/cash-machines-raided-with-infected...
- baldfat 13y agoAnyone gets physical access to your stuff you can be owned. No story here.
- Uchikoma 13y agoSeems to me this does not work with encrypted drive(s). (writing this from a MacBook with an encrypted SSD)
- x0054 13y agoHow does encrypted SSD perform, compared to unencrypted? My SSD does reads/writes in the 500MB/s range. Does encryption significantly slow down performance?
- tmikaeld 13y agoIt's up to the CPU actually and most CPU's have the AES instructionset by default. In this case, the performance hit is minuscule.
- pulmo 13y agohttp://osxdaily.com/2011/08/10/filevault-2-benchmarks-disk-encryption-faster-mac-os-x-lion/ http://osxdaily.com/2011/08/10/filevault-2-benchmarks-disk-e...
- Groxx 13y agoIt does slow things down technically, but not by much. You won't notice it.
- wyager 13y agoOS X and iOS heavily leverage the AES-NI instruction set (and whatever the equivalent is on ARM), so performance degradation is minimal.
- aaronpeck 13y agoIt'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.
- kybernetyk 13y ago
- KyeRussell 13y agoIs this new information? Essentially anything with single-user mode is pwnable when you have physical access.
- jwr 13y agoExcept 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.
- pikachu_is_cool 13y agoIt 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.
- e28eta 13y agoI 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.
- scotth 13y agoI believe that you can. Take a look: http://www.guidingtech.com/15008/adb-control-keypress-broken-android-keys/ http://www.guidingtech.com/15008/adb-control-keypress-broken...
- e28eta 13y agoWrong 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 http://cs.gmu.edu/~astavrou/research/acsac10.pdf
- aparadja 13y agoIt 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.
- weland 13y ago> 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.
- yourad_io 13y agoThere's also the sudo fail (fixed in 10.8.5) http://cvedetails.com/cve/2013-1775 http://cvedetails.com/cve/2013-1775
- pikachu_is_cool 13y agoI 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).
- yourad_io 13y agoIndeed. So if people always lock their screens when walking away, they should be safe. In practice, they often don't.
- pikachu_is_cool 13y agoThey need to have successfully run the sudo command at least once. In practice, most people have never done that.
- adventureloop 13y agoThis 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 http://www.openbsd.org/faq/faq8.html#LostPW
- jheriko 13y agoyou 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-administrator-account/ http://www.hackmac.org/tutorials/how-to-create-a-new-adminis... hacking with physical access is not usually difficult.
- jwr 13y agoThis (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.
- jheriko 13y agoright, 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...
- casca 13y agoWhile 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?
- userbinator 13y agoOn 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.
- randlet 13y agoMy 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.
- TacticalCoder 13y agoDoes 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?
- herge 13y agoYou have to reboot the computer, so no account is logged in when the attack is done.
- bigd 13y agoThere'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?
- jstanley 13y agoThe script connects to your server. You open a listening socket on your server, then when the client connects it presents a shell.
- bigd 13y agoI 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?
- jstanley 13y agoHow 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 http://linux.die.net/man/1/nc
- bigd 13y agosince 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).
- VeryVito 13y agoNot 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.
- seanhandley 13y agoIf 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?