Researcher Discloses Methods For Bypassing All OS X Security Protections

Trailrunner7 writes: For years, Apple has enjoyed a pretty good reputation among users for the security of its products. That halo has been enhanced by the addition of new security features such as Gatekeeper and XProtect to OS X recently, but one researcher said that all of those protections are simple to bypass and gaining persistence on a Mac as an attacker isn't much of a challenge at all. Gatekeeper is one of the key technologies that Apple uses to prevent malware from running on OS X machines. It gives users the ability to restrict which applications can run on their machines by choosing to only allow apps from the Mac App Store. With that setting in play, only signed, legitimate apps should be able to run on the machine. But Patrick Wardle, director of research at Synack, said that getting around that restriction is trivial. "Gatekeeper doesn't verify an extra content in the apps. So if I can find an Apple-approved app and get it to load external content, when the user runs it, it will bypass Gatekeeper," Wardle said in a talk at the RSA Conference here Thursday. "It only verifies the app bundle. If Macs were totally secure, I wouldn't be here talking," Wardle said. "It's trivial for any attacker to bypass the security tools on Macs."

Comments

root = same process

[jbolden]

And using the same logic I can get root on any Unix box.
1) Find an application that has root
2) Get it to load external content
3) The new content bypasses all the protections on the box.

Gatekeeper prevents downloaded applications that are untrusted from accidentally being run. It doesn't prevent trusted applications from doing anything.

Re:root = same process

[dottrap]

Gatekeeper prevents downloaded applications that are untrusted from accidentally being run. It doesn't prevent trusted applications from doing anything.

Exactly. Mod parent up.

And this is a *good* thing.

Apple has a separate sandboxing and entitlements system for more security. Apple makes apps distributed on the Mac App Store enable sandboxing. But for those apps (usually tools) that can't work within the limitations of the sandbox, developers can still ship outside the Mac App Store and do whatever they want. Code signing for GateKeeper is merely a trust checkbox that it is unlikely the vendor is doing anything really malicious or Apple would revoke their certificate and possibly pursue legal/criminal action for really nefarious activities since Apple gets a paper trail to hunt you down with as part of the process of getting a key to sign with.

If everything was locked down in the name of security, we would be denied all sorts of useful things.

Re:root = same process

[tlambert]

Gatekeeper also isn't "all MacOS X security". There's separate malware detection, and in order to do much of anything the user has to enter their computer account password.

It's a minor part of OS X security, mostly designed to keep casual users from installing stuff outside the apple store.

Yes.

There's also Mandatory Access Controls (MAC Framework) in the kernel itself, and there's BSM secure auditing in the kernel itself, and there's discretionary access controls, such as standard UNIX permissions, and there's POSIX.1e draft (it was never ratified as a standard) ACLs, and then there's whatever malware detection or antivirus protection you've jammed into the kernel as a MAC module via a KEXT, and in the absence of any access controls whatsoever, it's default deny, and then there's code signing, and encrypted pages within executables.

They didn't bypass any of that, and they wouldn't really be able to, even if they were root, because you can't get the Mac port for the kernel virtual address space without jumping through a massive number of hoops (which is why jailbreaking phones is non-trivial, and everyone uses script kiddy tools to do it, instead of jailbreaking from scratch).

And yeah, it's pretty stupid that Gatekeeper or anything else would be running as root and thus be exploitable with the escalated privilege available at install time, since it'd be pretty easy to just have it run as a role-based account, and have the kernel's cooperation, after cryptographic verification of the developer keys at the kernel level. But that doesn't let you bypass "All OS X Security": getting root doesn't really get you nearly 1/10th of the security bypassed (less, if you've installed third party anti-malware KEXTs that refuse to be unloaded except in single user mode during boot as part of an uninstall script, and are therefore always active).

They clearly do not understand the concept of "security in depth".

Re:Seems to not understand how it works

[Em Adespoton]

The clueless meter went off the charts for me at "by the addition of new security features such as Gatekeeper and XProtect to OS X recently" -- XProtect has been around since mid-10.6, and Gatekeeper is just a wrapper around XProtect.

The actual Synack presentation is better (I saw the precursor at CSW): "Gatekeeper doesn't verify an extra content in the apps. So if I can find an Apple-approved app and get it to load external content, when the user runs it, it will bypass Gatekeeper," is the real security flaw here. CSW had a good presentation on how to do this leveraging dylibs. With a simple exploit dropping a crafted dylib, you can run any code you can force the user to download via drive-by as root. And it's persistent, without adding a bunch of extra junk to the target system.

That said, this method still relies on working exploits (or more often, patched torrents of popular software). The skill level to pull off the entire attack chain is fairly high too -- you're going to see governments and organized crime using these techniques, not your average bot herder.

Hi I'm Patrick

[Anonymous Coward]

Aloha - hopefully this provides some more context and technical insight into my 'claims.' I'm honestly not trying to overhype everything and feel I have a decent understanding how computers/malware/exploits work -thanks to my time at the NSA ;). My goal is simply to show that Apple's built-in security mechanisms are trivial to bypass by malware/local attackers.

1) So yes, Gatekeeper is designed to only allow downloaded code to execute if its signed, or from the Mac App Store. This prevents a lot of attacks, such as user's infecting themselves with trojans, or downloads that have been modified in transit (e.g. by a remote attacker w/ some network level access). The technique I described (full technical details here: https://www.virusbtn.com/pdf/magazine/2015/vb201503-dylib-hijacking.pdf), allows anybody to inject unsigned code into internet downloads. Then, even if the user has set Gatekeeper to only allow code from the Mac App Store, the unsigned code is allowed to run. Since most (e.g. all OS X AV security products and about 2/3 of the apps in my dock) OS X software is distributed via HTTP and/or user's are dumb and download all sorts of shady code - IMHO, this bypass is a problem. Yes, I understand the user still has to run the code - my point is that we can completely bypass Gatekeeper.

2) In OS X, kernel extensions must be signed. The techniques I described are known (see: https://reverse.put.as/2013/11/23/breaking-os-x-signed-kernel-extensions-with-a-nop/), but allow any unsigned kernel extension to be loaded, even on Yosemite.

3) I also showed the Apple blotched the rootpipe patch, meaning any local user can priv-esc to get r00t, even on fully patched OS X 10.10.3 or 10.10.4 beta (video of poc: https://vimeo.com/125345793).

4) XProtect (Apple's built in AV product) is signature-based, thus can be trivial bypassed. Yes this is obvious.

Re:Hi I'm Patrick

[Anonymous Coward]

The injection attack scenario I envision is where an remote attacker (with network level presence) can inject code into user's legitimate downloads. Like when I go download Wireshark, MS Word, Adium, or most OS X security product (all over HTTP) - attacker MiTM's this. The key point here is that the user is going to run what they download (which is now infected). The main point is, Gatekeeper is designed to and should block such modifications/injections - that is to say (Gatekeeper) shouldn't allow infected downloads w/ unsigned code to run. That's all i'm claiming - Gatekeeper's checks can be bypassed. Also i specified 'internet downloads' since this doesn't impact content downloaded directly from the Mac App Store (this is separately verified).

Re:Hi I'm Patrick

[Anonymous Coward]

1) Yes - exactly :) The .dmg or .zip isn't wholly signed. When the user clicks the application, only it's signature is verified (so we can't modify it/it's bundle in anyway). However, if the application attempts to load external relative content, such as dylibs (outside it's bundle, but still on the .dmg), *that* content is not verified. So an attacker can inject a legit/vulnerable app + external .dylibs into any insecure (HTTP) internet download - or host such a malicious .dmg/.zip. Of course, we'll make the .dmg/.zip look totally legit, since we can hide files/folders, set a top-level alias/icon/background etc.

2) Agreed

3) Agreed

4) Agreed - I wrote a simple p.o.c. malware that generically bypassed all (popular) 3rd-party OS X security tools (AV, Firewall tools, etc) - even though it did common malware 'things' like persist, exfil data, download/execute commands. Your skepticism of their claims/effectiveness seem right on :/

Re:Good enough to criticize the mechanisms

[LordLimecat]

Its done every year at Pwn2Own.

Re:Good enough to criticize the mechanisms

[Anonymous Coward]

Not sure how to 'demo' this to you guys - but this is exactly how to do it:
1) Find a Apple-signed or Mac App store binary the contains an *external relative reference* to a dylib. Apple's Instruments.app works great
2) Create a .dmg or .zip file that contains Instruments.app as well as the external folders/frameworks with the dylibs that app tries to load - these can be unsigned/malicious
3) Hide the files/folders, and create a top-level icon/alias to Instruments.app. This icon can be anything (e.g. 'Flash Installer'). This makes the download look believable :)
4) Get users to download this ('free photoshop!' - see OSX/iWorm for an example of Mac user's being dumb) *or* inject this into internet downloads if you have network-level presence. Tons of OS X software is distributed over HTTP :/
5) Even if the user has Gatekeeper set to 'only allow code from the Mac App Store' when the user runs the download the unsigned dylibs will be loaded and execute. In other words, Gatekeeper fails to do what it was designed to do - prevent MiTM attacks/user's from running unsigned code.

more technical details here [PDF]: https://www.virusbtn.com/pdf/magazine/2015/vb201503-dylib-hijacking.pdf

Re:Good enough to criticize the mechanisms

[macs4all]

4) Get users to download this ('free photoshop!' - see OSX/iWorm for an example of Mac user's being dumb) *or* inject this into internet downloads if you have network-level presence. Tons of OS X software is distributed over HTTP :/

so, again, like every other OS X exploit, this depends solely on Social Networking to propagate.

So, IOW, after about 100 or so Macs worldwide get infected, whatever package was responsible for spreading malware via this method would be added to Apple's malware list, be pushed out automatically to all users of OS X, and, like those infrequent times before, that would be that...

Then, Apple simply adds checking of DyLibs and other add-ons to OS X, and closes this hokey forever. Problem solved!

So, thanks to the black hat who brought this exploit to Apple's attention; so that they can take care of it.