Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Apple

Researcher Discloses Methods For Bypassing All OS X Security Protections 130

Posted by samzenpus from the protect-ya-neck dept.
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."
This discussion has been archived. No new comments can be posted.

Researcher Discloses Methods For Bypassing All OS X Security Protections More

Researcher Discloses Methods For Bypassing All OS X Security Protections

Comments Filter:

  • Good enough to criticize the mechanisms (Score:5, Insightful)

    by Anonymous Coward on Thursday April 23, 2015 @06:34PM (#49541251)

    But can we have a demo since it is so trivial?

    • Re: (Score:3, Interesting)

      by MachineShedFred ( 621896 )

      Yeah, my thoughts exactly. And, by the way, how is it a problem with the OS if a signed app has a vulnerability you are exploiting? That sounds like a problem with the app to me.

      "Oh, I can own OS X - I just need to convince Microsoft Outlook to run arbitrary code with privilege elevation!"

      *Yawn*

      • Its a problem because the OS isn't checking the entirety of the app for correct signatures, just part of it. Which kinda removes the point of checking at all.

        • Its a problem because the OS isn't checking the entirety of the app for correct signatures, just part of it. Which kinda removes the point of checking at all.

          Apple updating Gatekeeper in 3... 2... 1...

          There! Problem all gone!

      • Re: (Score:3)

        by AmiMoJo ( 196126 )

        The OS is supposed to sandbox apps so that if they do get 0wned the damage is limited and the rest of the OS and apps are not compromised. Apple has attempted to do that on OS X, but clearly it hasn't worked as well as they were hoping. Even if an app get compromised that isn't supposed to let the code take full control of the OS.

        • Re: (Score:3)

          by jythie ( 914043 )
          sandboxing always involves a trade off. Apps do not have full root capabilities, but a compromised app can still do damage within its range, which unfortunately is the range of what people want apps to be doing.

          • Re: (Score:2)

            by AmiMoJo ( 196126 )

            Sure, but the problem here is that the exploit executes in the sandbox process which has root. A normal, non-sandboxed app would run at normal user level and, as you say, be limited in the damage it can do. The sandboxing was supposed to add an extra layer of security, but backfired and actually helped the app to trivially get root access.

            • Re: (Score:2)

              by jythie ( 914043 )
              Well, it only executes in a root context if the application is given root access. There is not much you can do when you click the little 'yes I want to run this as root' confirmation. The OS can not really prevent exploits from being exploited in root level applications.

        • In no way does what the guy is describing magically allow code to take control of the full OS. If an application is executing, and then executes a maliciously crafted dylib, that dylib is still running as the user who executed the parent application - a.k.a. not root unless you've bent over backwards to re-enable the root user and log in as root because you completely hate security and best practices. If it wants to do something outside the permissions envelope of that user, it will still have to ask perm

          • In no way does what the guy is describing magically allow code to take control of the full OS. If an application is executing, and then executes a maliciously crafted dylib, that dylib is still running as the user who executed the parent application - a.k.a. not root unless you've bent over backwards to re-enable the root user and log in as root because you completely hate security and best practices.

            so, IOW, about 100 Mac Users worldwide.

      • Re: (Score:1)

        by Anonymous Coward

        if apple sells an app from the apple store then its freakin responsible for the app....you know why its difficult for apple?because they just pay for the brains of these app developers and then they resell it....so they are busy minting money instead of being responsible for the app store?

        • Following your "logic", Best Buy is responsible for the millions of computers that get infected with shit from running copies of Windows that were purchased at Best Buy and not patched / maintained? Because Best Buy just "pays for the brains of these app developers and then they resell it" ?

          Brilliant.

    • Re: (Score:3)

      by jythie ( 914043 )
      In this case not really. All he is describing is the first in a chain of requirements, the next one being finding a signed application that can be exploited. Probably doable, but a different (and somewhat duller) problem.

      • Agreed... I stopped bothering at "So if I can find an Apple-approved app and get it to load external content..."

        It's a possible corner-case privilege escalation at most, and nothing near the breathless 'OMGWTFBBQwe'reallgonnaDIE!' summary and headline. Oh, and it still requires the user to do something stupid.

        Wake me when someone finds a way to take remote control of an OSX box without first requiring a complicit keyboard actuator to help him do it.

        • Re: (Score:2)

          by jythie ( 914043 )
          Not only does it require the user to be complicit, it requires the download channel to be vulnerable to man in the middle attacks so that the content can be changed mid stream. This is of course possible, but modern browsers make it non trivial to accomplish on all but the most focused cases.

  • root = same process (Score:5, Informative)

    by jbolden ( 176878 ) on Thursday April 23, 2015 @06:46PM (#49541313) Homepage

    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 (Score:5, Insightful)

      by SuperBanana ( 662181 ) on Thursday April 23, 2015 @06:56PM (#49541393)

      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.

      • Re:root = same process (Score:5, Informative)

        by tlambert ( 566799 ) on Thursday April 23, 2015 @09:43PM (#49542363)

        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: (Score:2)

        by tlhIngan ( 30335 )

        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.

        Actually, it keeps people from running stuff downloaded from untrusted sources.

        Basically, anything downloaded from the Internet is considered "bad" unless they paid Apple to either host it in the Mac App Store, or they pa

      • Re: (Score:2)

        by jythie ( 914043 )
        *nod* expecting a system to do more than it is intended to do might represent a problem with user expectations, but that is a whole other domain.

    • Re: (Score:2)

      by bondsbw ( 888959 )

      I suppose the upshot is that the OS X app store doesn't behave like some of the other app stores.

      The iOS and Windows app stores do not allow you to publish an application that can execute external code. The APIs are restricted and their use may be discovered during the approval process.

      OS X app store submission process doesn't appear to have the same restrictions.

      • Re: (Score:2)

        by jbolden ( 176878 )

        Well it requires special permission to get an app that can run execute internal code on the iOS store. They do exist. For example gambit scheme, and I have a calculator with a javascript interpreter... They just want reasonable protections.

        OSX app store though is mostly wide open. There are some restrictions, for example sandboxing and use of external services, but mostly the idea is that the App Store for OSX should have 95+% the diversity of OSX applications.

    • Re:root = same process (Score:5, Informative)

      by dottrap ( 1897528 ) on Thursday April 23, 2015 @07:07PM (#49541511)

      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.

    • Yeah, that's how to build a botnet. The problem is just finding out how to do step 1 and step 2.

  • Worse than the summary (Score:5, Insightful)

    by Sowelu ( 713889 ) on Thursday April 23, 2015 @06:49PM (#49541345)

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

  • 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

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

  • Oh no !
    Web browsers allow for remote code execution through Javascript ! (and Flash and Java applets, if you feel adventurous)
    We're all doomed !

  • Here's another article about one of his claims posted here http://apple.slashdot.org/stor... [slashdot.org]

  • 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 of

    • In order to have raw access to the disk, you need to elevate permissions to root. If you can do that, there's no reason to go after the block storage - you already own the whole thing.

  • Therefore... (Score:1)

    by Anonymous Coward

    do not install Flash.

  • Is it trivial to have an app with extra baggage? (Score:3)

    by Wild_dog! ( 98536 ) on Thursday April 23, 2015 @09:25PM (#49542255)

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

  • 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?

    • Bah (Score:2)

      by Greyfox ( 87712 )
      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.

  • Hi I'm Patrick (Score:5, Informative)

    by Anonymous Coward on Thursday April 23, 2015 @10:10PM (#49542533)

    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.

    • 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

      Wrong. Anyone can inject code into any data stream trivially. It's getting it to run that's the tricky part. How exactly are you going to do that? If the code that's performing the download is in on the plot, then fine, but a) you would have to get that code past the App Store review, and b) you would have to expect Apple

      • Re:Hi I'm Patrick (Score:4, Informative)

        by Anonymous Coward on Thursday April 23, 2015 @11:30PM (#49542923)
        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).

    • I still don't see how this is any different from just exploiting an app vulnerability, regardless of the presence of GateKeeper. What you describe is no different than the hundreds of arbitrary code execution vulnerabilities found in Flash, Java, etc. since the dawn of these frameworks.

      GateKeeper was never meant to keep all malicious code from executing, ever. It was meant to give you an "are you really sure you want to run this thing that appeared in your downloads folder" chance to not screw yourself ov

      • Re: (Score:1)

        by Anonymous Coward
        Fair point - I don't disagree. But Apple touts Gatekeeper a cornerstone component of their security posture - and we can bypass it. Gatekeeper has one job - but fails at that. IMHO this is a problem (if a user says 'only allow code from the Mac App Store', Gatekeeper should enforce that). Also, Gatekeeper did a decent job protecting 'dumb' OS X users from downloading unsigned/malicious trojans (which yes, allowed attackers to build various OS X botnets in the past). Now hackers can return to their old metho

    • 1) Are you saying that the signature does not cover the entire download, and that an attacker could supplement or exchange content of the download without invalidating the signature, and have the injected code execute when the user starts the app?

      2) Sounds bad.

      3) Sounds bad

      4) That a signature-based AV engine is only effective when attacks have been reported, analysed and a has been signature developed is bloody obvious. All an AV engines is good for is herd immunity. Which is sorta ok, except that they are

      • Re:Hi I'm Patrick (Score:5, Informative)

        by Anonymous Coward on Friday April 24, 2015 @02:03AM (#49543417)
        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 :/

  • One of these days....

    OSX is insecure, Apple is either incompetent and/or complicit with the FBI/NSA.

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

  • this guy's theoretical hack is still not practical, probable, or verified in meatspace. It's vaporware.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close