Slashdot Mirror
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."
But can we have a demo since it is so trivial?
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.
The summary made it sound like "wow, if a program runs arbitrary code, then arbitrary code might run" which is kind of...tautological. But the article has other goodies, like "the security check to keep dangerous code out of the kernel...runs with user permissions", and "code signing only rejects an app if it has an untrusted signature, but lets it through if it has no signature".
I thought that was a national security order or warrant from the secret courts.
"If Macs were totally secure, I would just be here talking - instead, I'm demoing!" Wait. That's not what he said.
This guy seems to think the fact that his computer is usable is an exploit. He doesn't mention anything that isn't just documented and known as the 'way it works'.
Pretty much everything he talks about makes it clear he doesn't actually understand the features and how they actually work. Every comment he makes ... makes almost no practical sense. Its not technically incorrect, its just pointless and doesn't actually mean anything from a security perspective. Its like saying These makes are insecure; the sky is blue; and magically the second is supposed to backup the first.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
It'as if millions of hipsters suddenly cried out in terror and were suddenly silenced.
https://www.rsaconference.com/writable/presentations/file_upload/ht-r03-malware-persistence-on-os-x-yosemite_final.pdf
Oh no !
Web browsers allow for remote code execution through Javascript ! (and Flash and Java applets, if you feel adventurous)
We're all doomed !
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Yeah it really is stupid. Is he saying "If you let me run malicious code on your computer, then I can run malicious code on your computer"? That's what it sounds like to me.
As far as I've ever heard, it is theoretically impossible to stop that kind of attack. If a user runs your code, then yeah, duh, your code can do whatever. I don't think that counts as a security vulterability.
Not quite it is more if you have a good approved app and If that app has a security flaw, you can use that flaw to hijack the OS.
Still it seems stupid. It is like saying you have permission to run scripts you can run a malicious script.
i thought once I was found, but it was only a dream.
It does sound and awful lot like the notorious MS07-052: Code execution results in code execution
.
Here's another article about one of his claims posted here http://apple.slashdot.org/stor...
If they run an app, they can... run an app? The only way to stop something like this would be to prevent any programs from running. Security would be limiting what that malicious code can do - to prevent it from running at all, you'd also have to prevent the machine from running ANY code, at all. And wouldn't that code execute inside OS X's sandbox? I'm not to update on Apple security, so I apologize, but doesn't it sandbox applications?
Personally, I'm wondering something. I know that files are locked off through permissions by default, but is the actual hard drive space itself (the physical blocks) as well? If not, couldn't you physically overwrite parts of it, and so add on your own code to be executed at boot time? If that's not possible, I apologize for the stupid suggestion. Just wondering...
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
These sorts of vulnerabilities exist in any OS with externalized code unless that is signed and verified before execution as well.
do not install Flash.
I think it's more saying "we have a security gizmo so that if you manage to run code here, it can't get out", and using a flaw to get out.
Seems like placing an application in the app store that has this "Extra Content" might be a bit problematic.
Perhaps not, but has there been any apps from the Mac App store with extra code to side load a program onto a Mac?
If I read this right, wouldn't "sudo find / -type f | sudo xargs chmod 440" at a command line render the system completely immune to any further tampering?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I mean, of course, 660. Getting over a bout of food poisoning that seems to be affecting my focus more than I thought it was.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
One of these days....
OSX is insecure, Apple is either incompetent and/or complicit with the FBI/NSA.
"If any question why we died, Tell them because our fathers lied."
Gatekeeper is supposed to prevent unsigned/non-Mac App Store code from running... so either if a download has been MitM'd or if the user was coerced into downloading something shady (e.g. trojan). The bypass I described bypasses this requirement - allowing unsigned code to be injected into existing downloads or hackers to now re-distribute unsigned/malicious trojans. So yah, it's about allowing unsigned code to execute - when Gatekeeper should block that.
Allowing unsigned code into the app bundle changes the app bundle and makes the signature invalid. That's how signatures work. The idea here is that a legitimately signed and installed app can then execute code outside the app bundle which will run without additional controls in place.
For example, if there's a text field in the app where you can enter a command and hit "run", then you can run whatever the hell you want.
That's not exactly a flaw in the Gatekeeper model, but one could argue that Gatekept(?) apps might want to refuse to execute certain dangerous system calls (e.g. exec, system, etc.).
Allowing unsigned code into the app bundle changes the app bundle and makes the signature invalid. That's how signatures work. The idea here is that a legitimately signed and installed app can then execute code outside the app bundle which will run without additional controls in place.
It depends. If you can add metadata to the bundle without it being detected (a problem that has cropped up with Linux repositories several times) then this is a genuine vuln. If OTOH it's something like "If you install a Python interpreter then you can use that to run arbitrary code that isn't validated by Gatekeeper" then it's a "Code execution results in code execution" issue. In the great tradition of journalists everywhere, the ThreatPost article never provided any links to any original material, so all we have is the writer's interpretation of what's actually going on,
Assuming the previous reply was by the guy who gave the talk, is it online anywhere?
The bypass allows at network-level remote attacker to inject executable code (a dylib) into a legitimate download (.dmg/.zip) without it being detected. When the user goes to run their download - the injected unsigned code is then also executed. IMHO Gatekeeper should block that -so yah its a Gatekeeper bypass not a remote code execution vulnerability. The RSA slides are somewhat short on details ([PDF] https://s3.amazonaws.com/s3.sy...) - for full technical details see: [PDF] https://www.virusbtn.com/pdf/m... (page 15+ describes the Gatekeeper bypass).
Hmm, theoretically impossible? I guess, *in principle*, any user could always just reformat and install Windows XP, but granting that at least *some* system components can be trusted, there is the notion of http://en.wikipedia.org/wiki/Proof-carrying_code/ which, although not commonly implemented due to the technology not being there yet for widespread adoption, could conceivably be implemented as a system wide policy.
The idea is that each piece of code contains within it a proof of its compliance with some formally specified security policy defined by the system, which the system verifies before the code is allowed to execute. The result is, as long as you can trust the security policy and things like the program loader, you can trust everything that executes, regardless of origin.
While writing this, it occurs to me that maybe the issue with even this system is no security policy could simultaneously allow all nonmalicious software features while excluding all malicious features, even in principle. A proof of this isnt so obvious to me though
A security vulture-ability?
One of the main problems here is that Apple themselves do not adhere to their own sandboxing.
So you can get something distributable from the App Store that actually isn't sandboxed.
That's Apple's own apps, and ONLY APPLES OWN APPS.
If Apple actually had to sandbox their own applications, they would implement reasonable security ways for their apps to do what they want.
Instead, they give their own apps carte-blanche and other developers have to deal with the sandboxing. This is why Coda from Panic left the App Store, for example.
Sandboxing is a freaking mess for applications that actually want to *do something*.
-- Frustrated, Anonymous Developer...
(FAD, not FAN).
No. Coming up on ten years ago, dude. Time to move on.
As far as I've ever heard, it is theoretically impossible to stop that kind of attack. If a user runs your code, then yeah, duh, your code can do whatever. I don't think that counts as a security vulterability.
No, definitely not a security issue when you have a piece of software that is only supposed to let the app store signed code run and then as long as there's a signature somewhere near it will run whatever the fuck you've put in this app that macuser101 has no suspicion of because 'macs are virus proof'. It will be a funny day when the first big mac virus sweeps through now that macs are numerous enough to present a valid target and casually brushes aside any token security measures.
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Linux, BSD and Windows just suuuuuuck so much compared to OS X that even if it were the least secure OS, most security researchers would still run it exclusively. Source: I am a security researcher.
Yeah, it is only a little better then 'if I have physical access I can change things, so the machine is insecure!'
Every once in a while some security tries restricting more system calls, but the functionality it strips breaks so many applications and annoys so many developers (and thus users who are no longer able to run things that used to work) that the attempt is backed off from.
My browser tells me that the SSL certificate for the site hosting TFA is owned by Kaspersky Labs. Now, whilst that doesn't necessarily mean that what the author says is wrong, I do get suspicious when anti-virus software vendors publish articles about new ways in which my computer is not secure.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
That is the job of the browser/downloader to detect, not Gatekeeper. Gatekeeper validates the App, not various data files it comes with.
It will be a funny day when the first big mac virus sweeps through now
I'm really anti-Apple, but people have been saying this for a long time, and it's still not true.
this guy's theoretical hack is still not practical, probable, or verified in meatspace. It's vaporware.
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
If I understand the exploit, what you do is take an app from the app store, modify it, and for some reason, the signature is still valid! The user gets a prompt if they want to install this app from a trusted source with a valid signature. And they say yes. Now you've gotten your payload onto the machine.
Sorry to reply to myself but I realized I missed an important part. There is still social engineering to get the user to run your app since you have to get it to them some other way.
Plus if you have your machine set to only install from the app store, doesn't it have some sort of handshake problem? I don't know how it all works, but I know when I install a new version of the OS on a Mac it only lets installs through the app store work by default. You have to disable that feature to install "Trusted" apps from outside of the App Store environment. You can also choose to wing it and allow all apps you find to install if you click the right check box.
In security it says:
Allow Apps downloaded from:
(3 check boxes)
1. Mac App Store
2. Mac App Store and identified developers
3. Anywhere
Seems like if you only had the Mac App Store checked then there would be no threat.
Even if option 2 was selected, it seems like it might be fairly safe if the developer's are not trying to infest a computer.
Obviously, option 3 would allow for all kinds of mayhem.
OSX, like all software, has bugs, some of those bugs are security flaws, and some of those flaws are serious. Third party software run on OSX has bugs, some of those bugs are security flaws, and some of those flaws are serious. Malware protection is imperfect.
Is anyone actually surprised by this? The real measures of security are:
- did you make a real effort to get it right the first time?
- how professionally do you respond to security flaws, and how well do you enable customers to be protected from those flaws?
- how well do you prevent those flaws from reappearing in the future?
Simply having flaws isn't much of a measurement, as this article tries to imply. Having flaws just means that you are developing real software, not vaporware . It's what you do about them that matters.
Gatekeeper is supposed to prevent unsigned/non-Mac App Store code from running... so either if a download has been MitM'd or if the user was coerced into downloading something shady (e.g. trojan). The bypass I described bypasses this requirement - allowing unsigned code to be injected into existing downloads or hackers to now re-distribute unsigned/malicious trojans. So yah, it's about allowing unsigned code to execute - when Gatekeeper should block that.
Wrong.
Gatekeeper's default setting allows only signed apps; but the user can opt for lesser security. But that's on the user, not Apple.
That sounds like Gatekeeper is more about protecting the Apple Store revenue stream than about the user's security.
It's really easy to disable GK. People on all other platforms have been ignoring prompts for years or blindly following instructions and ignoring the "OMG YOUR SECURITIES!!!1111"
Step 1: Make a fake 2 hour long video (padded with blank or corrupted video) with the first 5 minutes explaining how to turn off GK.
Step 2: Tell the user to properly play the video, you need to install this app or codec on this website somewhere.
Step 3: Rename the video file to some upcoming hot blockbuster movie, say "Avengers Ultron.mp4"
Step 4: Release on torrent / streaming / etc. sites
You know, what people have been doing for years everywhere else.
It's also pretty simple with i devices too. Just replace Step 2 with "In a roundabout way, tell them how to root their phone and install this app.
People who don't read prompts or have a hard-on for free stuff will always be stupid.
GPP here. If the app bundle is modified in transit - such as adding metadata, doesn't that change its signature and therefore Gatekeeper barfs? Or is the vulerability really that Gatekeeper sucks at checking sigs?
My understanding is that the app bundle is what you download. You don't download the app bundle plus some other junk that can be totally fishy, and Gatekeeper only checks the non-fishy part.
I don't have a huge amount of experience installing tons of Mac software, but generally speaking I've seen two kinds: .dmg files that contain a .app bundle you drop in /Applications to install and .dmg files (or .zip I suppose) that just have raw binaries in there (e.g. Eclipse). The former are signed and checked by Gatekeeper. The latter are neither signed nor checked by Gatekeeper.
Now back to the App Store. The App Store will never allow you to install the latter type of application. 100% of the stuff Apple slings through the App Store is signed app bundles. None of those things have dark corners that can be subverted by MitM attacks, do they? (I don't know, I've never downloaded a single thing through the App Store due to my knowingly-ironic preference for OSS stuff and dislike for the Apple walled garden).
This really sounds to me like "code execution leads to code execution" "vulnerability". But there has to be something here... I just don't understand it yet. Nobody would embarrass themselves at RSA with a big pile of nothin'.
Thanks for the link, the VB one contained the info I was after. Looks like a nice piece of work, and definitely a Gatekeeper bypass, just like the Linux repository signing bypasses where they didn't verify metadata.