>>My name is Patrick Wardle, I’ve worked at a variety of acronymed places, currently the chief security researcher at Synack. So briefly, at Synack we do crowd source vulnerability discovery with vetted security researchers. So if you are interested in signing up with us to be a freelance researcher / hacker and get paid to find vulnerabilities in our customer web apps, mobile apps and IOT devices check out synack dot com.
Alright, today we’re going to be covering, ah, a lot of interesting stuff. We’re going to start by looking at what happens when an application, which is running at the privileged level of the user once to perform a more privileged action. We’ll then discuss some  core issues with how apps perform   temporary elevation of privileges and due to these core issues will then show a lot of bugs. We’ll talk about how to find these bugs. Discuss    actual vulnerabilities and then end with some exploits.


So our goal for today is to describe a reliable way to locally escalate privileges. Um, such privileges escalation is often an essential step that malware wants to accomplish. So again step one: malware kinda gets on your box. Normally then it’s going to be running in somewhat of a constrained environment or at least at the privileged level of normal user, not root. So then for step number two, the malware’s going to want to escalate its privileges generally to root.   Focusing on this second step, number two, and talk about how to escalate privileges specifically by exploiting bugs, vulnerabilities in installers and updates. So first let’s look at how an application can authenticate with the operating system, to be authorised to be temporarily perform high privileged actions. So,  if you’re a MAC user I’m sure you’re very familiar with these authentication dialogues, what Apple calls them,  so we’ll also refer to them as authentication or auth prompts. So, apps run at user privileges, but sometimes they need to perform higher privilege actions, most commonly, installers updaters, you know, are going to have to write files to the system directory, perhaps update a kernel extension. Obviously, this needs to be done at higher privileges. Other actions, for example, debugging another process     or even changing operating system settings, such as the time, will often require the user to reauthenticate in order for the application to perform that higher privilege action. So these are quite common, I get them about one a day on my box, and you know, and if not that, at least a few every week. So, first let’s look at a conceptual overview of kinda what happens behind the scenes, when an application, for example, an installer, wants to perform a privileged action. So first it’s going to invoke an authentication API, and we’ll talk about what these are on the next slide. This will generate an XPC message, which is sent to the authorization daemon. This daemon then consults the authorization database and it usually says, OK, I will allow you to perform this action, but first you have to reauthenticate. So, it does this by sending another XPC message to the security agent. This agent is then responsible for  showing the actual authentication prompt. And then once the user enters the correct credentials and they’re validated, the application that requested this higher privileged action, is then allowed to  perform it. So, let’s take a closer look at these steps.Can assume we have an application for example installer that wants to perform a higher privileged action. So it kicks this off by invoking something like authorization execute with privileges. And  this is a function we’ll talk about a lot. You can see on the slides, when you invoke this function, you basically just specify a path of what you want to be executing with these higher privileges. And once the user is authenticated, this will then be executed. So if you look at this function, it’s open source,  we can see it calls execv system binary named security underscore auth trampoline. This binary is what sends the XPC message to the authorization daemon auth D. We can verify this by using the lsmp utility, which is a utility that can show you sending and receiving of mock messages. Alright, so once the authentication daemon receives this XPC message, which is basically an authorization request, it will consult, as I mentioned, the authorization database. This is in slash var slash db auth dot db and the system auth trampoline requests the system dot privileges dot admin rights. So we can dump this authorization database and we can see that privilege exists and as the comments or the information in the database shows, this is often associated with the authorization execute with privilege function, which is what the application just invoked.
So again the authorization daemon is probably going to say sure, I’ll allow you, or I’ll grant you this privilege temporarily, but first the user is going to have to reauthenticate. So, in order to facilitate this, the daemon then sends an XPC message, as I mentioned, to the security agent. So, the security now has received the XPC message and it is what displays the authentication dialogue. Now, this is done by design, because Apple didn’t want the user to have to trust the application with their password. So since a trusted system utility is displaying this authentication prompt the application that’s requesting the higher privilege actually has no access to the user’s actual password. So we can use the LS app info utility and see, yes the security agent is actually the last process that was spawned. And again, this is because it was spawned on    when it gets these XPC requirements   from the authentication data. It again displays that prompt and handles the verification of user’s credentials. Once the user has verified him or herself, control flow returns back to the security underscore trampoline, ah, utility, which via at a call to execv executes the binary which the app location originally requested. And again, since this security underscore off trampoline utility is setUID and owned, and is owned by root, the binary or the script that the application requested to be executed will now be executed with root privileges. OK, so that was a behind the scenes look at what happens again when an application requests or needs to perform some action at a higher privilege level. Now let’s talk about how to abuse this process, starting with some core or funda- fundamental issues. So one of the main issues is these pop-ups cannot be easily verified. Anybody can spoof them, they’re just a window asking for credentials. So on the left we have a legit pop-up from the Slack application, and on the right - who knows? Is it spoofed? You now, is this some malware just asking for credentials? Or is it even a legi - legit authentication prompt that was spawned via the security agent, but is going to execute something malicious? And, what is Slack doing anyways, why does it need to perform a privileged action? So, we’ll look at some real life examples that abuse this. Um, again, playing off the fact that the user generally trusts these authentication prompts and they are not easily verified. Now, I do want to point out though that these are not, in my opinion, real vulnerabilities. I mean, they’re like somewhat UI issues, but you know when I mentioned to a few people that this is what my talk was gonna be about, a lot people immediately jumped on this. So again, as we’ll see we’ll actually talk about some more problematic vulnerabilities, but I wanted to mention this and, and cover this here.
Especially since, Mac, Mac malware often uses this, or abuses this in order to get root credentials. So the first example is a Mac malware called OSX Proton B. what happened was, the malware authors or hackers, infected the legitimate application website of an application named Transmission...sorry called Handbrake. Handbrake is an open source video transcoder, so again the hackers access that website, um, got access to the application, infected it with some malicious code, and then, anytime moving on in the future when the users would then download this application they themselves would then become infected. So, when the malware runs, the first thing it does is spawns one of these windows, but it doesn’t do it through the security agent, it creates its own NS window. So, it’s 100% fake. But it mimicks and looks exactly like a real authentication prompt. However, when the user enters their password, since it’s fake, the malware has access to the actual bytes or value of the user’s password. So we can see this in a debugger, attached to the malware when the user enters their password, we can see it’s present in the malware’s memory. And then the malware used this to execute something root.  Now also there’s also nothing stopping malicious code from creating a real authentication prompt and then get something to get executed as root once the user authenticates. And by real, I mean, via the system API which is: authorization execute with privileges. Again, it’s about three lines of code, so here’s an example of how trivial it is to create a legit authentication prompt that will then execute something malicious. If you want to make it malicious, um, but convincing, very easy to do, ah, here I just  grabbed the actual icons from the legitimate Slack application, copied them into my X code project. Ah, you then set the  ico - icon file key in the apps info dot P list file, which will then be displayed in this legitimate, albeit, malicious authentication dialogue.So, if we execute this, a pop-up will be displayed on screen and it’s legit again, in the sense that this is being displayed by the s-s-ssystem security agent. And since Slack, or at least on my box,  is popping up this authentication dialogue all the time, like you know, it’s very easy to trick users. And once they enter their credentials, whatever we asked to be executed as root, will be. So here’s an example of a piece of malware that actually does this. It’s iWorm. So iWorm was  distributed via cracked applications, on Pirate Bay. So users think they would be getting, for example of PhotoShop, and they would but it would also be packaged with iWorm. When the malware was executed it would invoke the authorization execute with privileges function, which would then display an authentication prompt. Now, users would likely enter their password, because again there’s no way to verify this, and also they’re installing software so they are used to seeing this, especially when they are performing  some installer. Now once the user enters their credentials the malware executes something named zero and this will be executed as root. If we look at what the zero binary does, it persists the malware as a launch daemon, which means the malware will now always be running as root persistently. Now again, malware spoofing or creating  these authentication prompts, pretty much comes down to social engineering. These are not bugs, these are not vulnerabilities, but they work so we can’t not get too much. So now I want to talk about some real issues. Some fundamental core vulnerabilities. So we’ve been talking about this authorization execute with privilege API function. The good thing about this API is that’s very easy to use, again you just specify whenever you want to be executed as root and then the system will take place of everything else, displaying the authentication prompt, and then when the user verifies and enters his or her credentials, whatever you ask to be executed by root will be by the system. So, that’s great. The problem is, it performs no verification of what it’s executing, it’s open to massive race condition. So, an example, a legitimate application, say an installer, needs to perform some privileged ac-action, needs to execute something as root. So what it’ll do is, it’ll invoke that authentication execute with privilege function and give it a path or something to execute, for example an installer script. In the meantime, while the user is entering their credentials, some local malicious code that doesn’t have these higher level privileges can actually modify that installation script. And then once the user finishes entering his or her credentials, the system will blindly execute what the app originally requested with no validation or verification that hasn’t been modified or infected in some manner. Another issue is legit applications, imagine they have authenticated securely and we’ll talk about how to do this in a minute, often then do authorized actions that are insecure. So for example they can persist non validated components, they can create insecure temporary files, they even load and execute other non validated components. So imagine for example, there’s an installer app that is now running as root authenticated, securely, correctly, but then it creates, in the temporary directory a property list of P listed file. A few second later it then moves that P list file out of temp into the system’s launch daemon directory, where the launch daemon will be executed as root. Obviously again, some local non privileged code can modify that property list while it’s in the temporary directory  and the when it’s moved into the launch daemon’s directory the   malicious code will have inherited root permissions. 


Alright, so now let’s talk about actually finding some these bugs. And since we will see this as such a systemic problem. We’re actually only  look at software I has installed on my box. So first let’s look at who calls this horribly insecure authorization execute with privilege function. So you can corrupt the file system looking for binaries which import this. Start maybe by looking at slash applications. It actually turns out that whenever this API is called apple will log this, specifically to the var slash log slash diagnostic messages logs. Now unfortunately these logs are only kept for a few days, but you can start by looking there to see, basically who has displayed one of these authentication prompts, because they invoke the authorization execute with privileges function. So if we grab or dump these we can see that pretty much everyone calls this function, ah, again on my box, slack, demo fusion, chrome,  snitch, free dome, sparkle, everybody. Now, just because someone calls this function, doesn’t mean it’s necessarily an exploitable bug. It’s kind similar to stir copy, right? We know like stir copy is a dangerous API, but if stir copy is used correctly, it doesn't necessarily mean there’s going to be a buffer overflow. An example of a safe use of this function is - imagine an installer wants to perform privileged system command. For example, it wants to execute reboot. Now obviously, local malicious code can’t modify this slash sbin reboot utility, right? It’s protected with system integrity protection and etcetera etcetera etcetera. So this, for example, is safe. So in order through for some thing to be exploitable - what authorization execute with privileges is about to execute? It has to be writeable, modifiable and infectable by the local non privileged code. Turns out though,  this is pretty much always the case. So the question is, how do we tell what is about to be executed as root, is, is verifiable, is accessible by this, er, local unprivileged code? So the question is is first - what is this going to execute, and then: is this writeable?


So, there’s two ways to tell, or figure out what this function is about to execute. The first is if you use a process monitor or utility. I wrote a free one, that’s open source and will be online after this talk. We can basically look at the arguments to the security underscore auth trampoline. Again, this is the set UID process that gets invoked when someone calls authorization execute with privileges. So here for example we can see it’s downloading, or rather going to execute an installer application that’s in slash downloads. Obviously, local non privileged code can modify that. Another example is you can basically just debug the process and set breakpoint on the  authorization execute with privilege function, and then look at the arguments, specifically the third argument RSI and look at what this is. Again, this will be the path of what is about to be executed as root. And once we know what is about to be executed, we can check the permissions of this file, usually a script or a binary, and if it’s owned by the user, which it normally is, this means code which is running as ruser user, user not root can modify this code. And again, once the user then authen - authenticates, we will have root. So later we’ll talk also about how apps should securely authorize or authenticate themselves, but as we mentioned, even if they do that securely, if then they execute other actions, which themselves are insecure, this still gives us, gives us an opportunity to elevate privileges to root. So, in order to find these bugs, pretty much, what I do at least, is monitor the file system, or watch what processes these higher elevated privilege application’s will then execute. So again,  the question is: can the unprivileged code modify these? Example, a property list installer application, it might have in it’s slash resource folder in the downloads directory, it might be  authenticated correctly and securely, but then goes to execute that, that secondary component itself has not been validated. So again, perhaps, local malicious code can modify that and get root via that means. Alright, enough with conceptual blabbering, ah it’s time to talk about some exploitable bugs. In this section we will talk about the bugs, and then in the next section how to generically exploit such vulnerabilities. And note, if I don’t mention a CVE associated with a vulnerability, it’s a 0day bug that a vendor has decided not to patch. So the first bug is on a popular IOT device, one that I use, dropcam, basically, when you buy a new dropcam and you go to configure it, the instructions say: plug it into the computer. This will mount something, ah, on a drive, double click that - which is the installer application, and then follow the authentication prompt and it will install and configure the dropcam for you. Basically setting up the wifi network etcetera for the IOT device. So, it turns out though, when it executes this application off this mounted share, what is does, it makes a copy of the installer application into the user’s temporary directory. It then executes this via the authorization execute with privilege function in order to execute that with root privileges. So what we can do do is, we can attach this process with a debugger, here we use LLDB. We set a breakpoint on the authorization execute with privilege function, and when we hit this breakpoint, we can dump the third argument, again, RSI, and this is the path of what is about to be executed with root privileges. And again we can see it’s the installer application has been copied into the user’s temporary directory. Now again, there’s a large window of time when the user is legitimately authenticating, where local malicious code could modify that installer application in the temporary directory. And again, since the authorization execute with privilege function does not validate what is about to be executed, as soon as the user completes the authentication, our malicious code will be executed now with root privileges. Next is Chrome. This is a rather popular browser that i use on my box. It also invokes the authorization execute with privilege function in a variety of instances. For example, if you’re installing it as a non admin user or if you’re setting things up like auto updates. So we can observe this by running our process monitor and again we see that security underscore off trampoline process. And if we look at what that is about to execute as root, we can see it’s a script named keystone underscore promote underscore preflight dot SH. the script, which again is run, is root, once the user authenticates is owned by a normal user, so that means that any point   local non root code your box could modify that and then when the user performs, for example, sets up an auto update, Chrome will blindly execute that as root. Next up is little snitch, this is everyone’s firewall on Mac OS, something I used to run, until I wrote my own, ah, unfortunately their installer had a local privilege escalation, and this is an example of something that authenticates correctly, but then performs malicious actions that then non local privilege code could leverage to elevate its privileges to root. So, the issue was the authorized installer, which again is running as root, wrote a property list to the temporary directory. It then moved that into the launched daemon’s directory, where it will be loaded and executed as root. So again, what local privilege code could do was modify that property list when it was in the    temporary directory and then once it was moved into the system launch daemon directory and executed, the malicious code would get root. So we take a closer look at this bug on the screen on the top right we can see the little snitch installer calls something write P list owner mode to file. And we can see this calls the NS temporary directory function to the get the user’s temporary directory and write out what will be the launch daemon’s property list. So what we can do is, we can attach a debugger to the installer, and then set a breakpoint on the method execute command as root. And what we can see, we can see what this command is then doing, is moving the P list from the temporary directory into the system launch daemon directory and then setting it to be owned as root . Obviously again, while this is in temp, a user who doesn’t have correct privileges or some malicious malware could modify that and then it could execute with higher privileges to root. Little snitch actually patched this pretty quickly, so kudos on their response, as CVE 2017 26 75. I also do a lot of malware analysis, though I use VM ware, so whenever you go install the mware, or when it tells you there’s an update, what it does is it saves various scripts into the user’s temporary directory, and then executes them as root via the authorization execute with privileges functions. So we can see this by debugging the VMware installer or updater - again you set a breakpoint on the authorization execute with privileges function, and then when the breakpont is hit, dump the third arg and you can see  what’s being executed - again it’s these scripts that are out of the overwritable temp directory. Again,nothing is verified so these will then be executed as root. Alright, more security software - yes. This is the VPN I run, that secures free dome, turns out that is vulnerable as well. So when you install this VPN, it tell you, hey, I’m about to show you a pop-up please enter your credentials. And then when this pop-up is displayed, it doesn’t actually say what free dome is doing, it says, something OSA script, which is Apple script. So I wonder what is Apple script executing? So, if you disassemble free dome, we have some disassembly on the sly, we can see it’s executing an Apple script to authenticate and then execute something as root via the do shell script  script as script with admin privs. This thing calls Apple script to display an authentication prompt and when the user enters their credentials, whatever was requested, is executed as root. So our process monitor shows that Apple script is executing a script in the application’s bundle, which is of course writeable or modifiable by local non privileged code. 
Next up is sofos, yes, due to you know work compliance I have to run anti-virus on my computer, my boss told me though, that if I found a vulnerability in it, I could uninstall it, and so this was kind of the motivation for that [laughs] gonna hold him to that!
So when you download sofos, ah it’s a zip file. When you unzip it, it executes an installer application, and you guessed this, then this in turn executes a secondary component via the authorization execute with privileges. And we can dump via the debugger what’s it about to execute - and it’s something called installation dot deployer. Again if there’s some malicious code on the box that has not root privileges, it can modify this component and then that will be executed as root. Alright, finally we’ve got sparkle. Now sparkle is an auto update library that’s used in a good number of apps. Now I do want to point out this is merely a list of apps from 2016 that used sparkle. I have not validated if these are all vulnerable but i just wanted a list. Let’s look at a example or a specific instance of an application that uses sparkle that is vulnerable. So I do a lot of reverse engineering, I use hopper dot app occasionally, it’s a nice app, anytime it has an update or a new version the sparkle library it’s compiled in displays this pop up telling me that there’s a new version. If we click on it, sparkle will download something called auto update dot app  into a non protected cache directory, it then executes this. Now depending on the user’s permissions, for example if they’re a standard user versus an admin user, this will display an authentication prompt. If we view this in a debugger, attaching to the auto update process, set a breakpoint on an authorization execute with privileges - we can see it’s trying to execute something named file op out of a user writeable cache directory. Again, if there’s any local non privileged code it can obviously modify anything in this cache directory and then that will be executed by root when sparkle completes the update process. Alright, enough knocking on third party apps, I think by this time we understand that the authorization execute with privileges function is, you know, sh*tty, don’t use it, um but everyone pretty much does. So I want to talk about some issues in Apple’s code now, they’re not safe from these issues either. So, the first thing is, I’m not really sure this is a bug, it’s more of a silly issue, but when a user drags something via finder into a higher privileged directory the finder dot app displays an authentication prompt. Basically saying, hey you need to provide correct creds in order  for me to com-complete this copy action. The problem is, it doesn’t validate that what the user originally meant to copy wasn’t modified during the time they were authenticating. So we can imagine a scenario where a user is trying to move an app into for example slash applications, they have to provide the credentials - again some local unprivileged code could perhaps modify what they’re moving into applications, and then the move would still succeed and now they just got some malicious code into a higher privilege directory - which might be executed by other users. Alright, something though that I think is a real issue. So Apple’s package installer is called installer dot app. Basically, when you double click on a PKG file, installer dot app will automatically executed to handle the installation update of this package. And why does this happen? Well, if we dump the info dot P list file of the installer dot app, we can see it advertizes as the default handler for packages. Note also, it’s a signed utility via Apple and also has some special privileges or entitlements. So here’s an example  when a user double clicks on a PKG file - installer dot app will be executed to handle that, it will display this nice installation prompt and then request user permissions. Again, this is all just standard stuff. I took a closer look at this process and realized this signed trusted and [inaudible 26:57]  application would load dynamic libraries from slash temp. I have no idea why. No we’ll talk shortly about weaponizing this, but let’s look at what is going on. So when the user double clicks on a PKG file that has a plugins directory, installer dot app would take those plugins, copy them into the user’s directory and then load them into its trusted process context. In a debugger we can set a breakpoint on DL open in the installer dot application and then we can dump what is about to be loaded and we can see yes, it’s about to actually load an unsigned dynamic library from the user’s temporary directory. You can also use an application like task explorer, which I wrote, we can filter on unsigned dynamic libraries and see, yup,  there’s an unsigned dynamic library loaded from the temporary directory. Alright, so that’s about a thousand ways to get root but what if you want more? And not because we’re greedy but on recent versions of Mac OS, you’re actually still somewhat limited when you have root permissions. You can’t bypass system integrity protection to modify operating system components. And you can, you can also not run unsigned code in the kernel. So the bugs I find, found that I’m going to talk about here  need root in order to trigger, but once you then exploit these vulnerabilities, you have these even higher privileges. So the first bug allows us to bypass system integrity protection and also survive a full OS upgrade. This is something malware would like to do. Alright, so it’s time to upgrade, what happens is the user will download the OS update from the app store. Long story short, an entitled binary named OSI helper D will tell the system to boot off an installer image. Install ESD dot DMG - this is what is downloaded from the app store - and then this is when the system reboots what it actually installs the new version of the operating system. So our goal is to get into this installer image  because once the system has booted off it we’re essentially booting or executing outside the context of the operating system, so operating system level protection - such as system integrity protection are no longer in play. So Apple generically realises an attack vector, or that is to say [inaudible 29:08] off an untrusted disk image so they block that ability unless you have the correct entitlements, which an Apple utility such as OS IS Helper D has. So step one is to get  into the OS installer application which is  downloaded from the app store when the user wants to perform an upgrade. And we can use a neat run time dylib injection technique I like to call dylib proxying. Basically what you do is  you  replace a dynamic library that the application is dependent on and then proxy request through the original one as not to break any system functionality. And then when that application is executed, the dynamic loader will naively and blindly load the the malicious dylib in place. Ah, this was a technique that was used in some Israeli malware on the Windows platform. I haven’t seen it used on the Mac operating system, I’m not sure why kind a neat technique. Alright, so now we have code executed in the trusted context of the operating system installer application. So what we can do now is mod-modify and infect the install DSD disk image and then the OS IS helper already blesses it. Oops, there’s no validation that what it’s about to bless has not been tampered with. So now the system reboots, we’re running in the process context outside the operating system and so we can obviously bypass system integrity protection and ensure also that our malware fully lives or survives through a full OS upgrade. So as a proof of concept I took i Worm, which is a well known piece of malware that we talked about earlier, and injected this into the installation image and then during this install process I copied it into a system integrity protection protected directory - which means that once the OS install upgrade completed, that malware was essentially undeletable. Apple fixed this as  CVE 2017 69 74. Alright, what about a pure kernel bug, again our goal is to get unsigned arbitrary code running in the context of the kernel. Again, root for this bug is a prerequisite, but showed a lot of ways to get root privileges, so that’s OK. So, I stumbled across this bug, ah, I was writing some code that uses the audit system and  I noticed there was an interesting B copy. So B copy is essentially a mem copy, copy something from source to destination, by some number of bytes, here we can see the B copy source is a sock added struck named SA, destination is sock adder underscore storage named ARG sock adder and it’s max size of the destination size of the buffer is 128. Now, interestingly, the number of bytes that are copied is the size of the sock adder source structure. So any time you see a B copy, using the number of bytes to copy based on the source, always take a closer look at that. So how, how do - we know the destination object is of max size 128, so the question then becomes can we make the source the subject a sock adder bigger than that? Turns out the answer is yes. You can create a unix socket that creates a path that allows us to create a socket structure that’s bigger than 128 bytes. So what we do is, we create that then we call bind which will trigger the vulnerable B copy, because it’s trying to audit that socket operation, and via the diagram we can see that since these sock adder structure is bigger than 128  this will a cause a heap overflow. For example, here we can see the 41 41 41 is now in a kernel pointer we can control. So exploiting this bug will give this arbitrary unsigned code execution in the context of the kernel. Alright so that was the deal with bugs, but what good are bugs if we can’t exploit them?
So let’s talk now about how to exploit such vulnerabilities. Alright, so again back to the user assisted elevation of privileges. Our goal is to get root when a vulnerable but legitimate application invokes or displays an authentication prompt. So as a limited process, or limited local code, to do the exploit we have to three things. We have to wait for a vulnerable application to start, VMWare, Sparkle, Little snitch, whatever - then we have to wait for it to perform a insecure authentication request, and then while the user’s entering their credentials, quickly infect the vulnerable file, and then as soon as the user completes the authentication we will have root. So step one, we need to monitor for the execution of these vulnerable application,   doubt this is really easy to do, or have have special privileges. You can use the NSworkspace notification center and register a notification for application launches and exits. So in our notification handler we bail an application if it’s not of interest, for example, calculator. But if it is, for example it’s SOFO VM Ware or one of the myriad of applications we talked about, we move on to step two - which is monitoring for the vulnerable file to be created. We also care about application exits, because we want to stop monitoring once the application exits. Ok. so as non privileged code, you can watch for specific files and directories using FS events. So here’s some code where we watched for a target file. Now, this will be application specific, for little snitch, for example, it’s the property list in the user’s temporary directory. For Free Dome it’s a script in their application bundle. For Sparkle, it’s the auto update dow- application that’s downloaded. Either way though, we can detect when these vulnerable files are created. And once we get a call back in our call back handler, we know it’s go time - let’s go infect. Alright, now we’ve seen the file has been created. Again, once the user authenticates, this will be executed  as root with no verification. So we mention again this file will be application specific so dictates the infection technique. So for example for a property list of P list file, we’re probably going to modify the program arguments array and point it to a malicious binary. For a script, you can just infect adding some  extra commands that you want to be executed as root. And if it’s going to execute as mock binaries as root, you can either infect that or actually just replace it with your own binary and again that will be executed as root. And a very valid question is: don’t we have to win a race - and the answer is: yes. So again, the application is usually going to drop whatever it wants to execute as root, then throw off the authentication prompt, and then while the user is authenticating we can jump in and infect that. So this user authentication usually takes at least one or two seconds, and that is like a massive window that we can always win. Now a prerequisite of this exploitation is that this non privileged local malicious code has to have the ability to write to the item that’s about to be executed, right? If it’s non writeable we can't modify or touch it. This is usually just an issue, not because we don't have the correct permissions, but because of what is about to be executed is on a read only share. So one example is do to gatekeeper. So I found a bunch of issues with gatekeeper, and the way Apple fixed them is to implement something called apps trans location. Basically now on modern versions Mac OSX, you download a zip file from the internet, when you go to double click and unzip and execute the app within it, it’s transparently copied to a  read only share, and executed from that share. And this is to deal with a bunch of gatekeeper issues. This read-only is bad for us because imagine that application is executing something in it’s application bundle as root.  Now it’s sitting on this read-only share, so we can’t modify that anymore. Well, it turns out this is pretty easy to bypass - again if your local  non privileged code - you can just remove the quarantine attribute from that downloaded zip file and then app trans location won’t happen. The application will remain in the downloads directory and you can modify it as much as you want. Recall also, Apple’s installation dot app - which is the default handler for PKGs, can be coerced into loading unsigned malicious dylibs. What if the package though doesn’t have plugins? Well, would be great if we could infect arbitrary PKG files. So normally PKG files are distributed on disk images, DMG’s, and when you double click a DMG, it’s mounted, but on a read-only share. So, again, this is problematic for us. What we can do though is as local non privileged code, we can register to be the default handler for DMG images. Then when the user double clicks on that, it’ll execute our code we can then force that DMG to be mounted with read-write privileges. We can then modify that package, inject a malicious plugin and then when the user double clicks on that, that malicious unsigned dynamic library will loaded into the trusted process context of Apple’s installation application. So that was generically how to exploit some vulnerabilities, and how to deal with read-only issues. Let’s now look at some actual exploits. So demo time, here we have VM Ware it’s telling us to do an update. And we’re good users so we know that when an application requests an update, we should listen, because it’s going to patch security fixes and give us all these great new features. So in the demo we’ll see the exploiter utility which running with normal low-level privileges, is going to detect that the mware   is running, it’s going to register a file watch for the scripts that the VM ware drops into the temporary directory, and then infects those scripts. And then when the updater completes, by asking the user to please provide their credentials - we will pop it out as root. So watch closely, we’re waiting for VMware, see if the VMware is running...we detected that the script is about to be present, in a second, infect that, VMware legitimately asks for creds... via the authentication execute with privilege function. As soon as that executes whatever the Mware asks to executed which are scripts out of the temp directory are now executed as root. And again there’s no verification on these so we  pop calc as root. Here’s an…[clapping] yes! [laughs] [applause]...I saw a funny tweet, it was like, clap at DefCon if you see calculator running….gotta use calc even on Mac. So here’s another demo on Chrome. This is pretty much the the simplest, stupidest exploit ever. Basically you have a Python script that’s running as non privileged user and it’s going to infect that script that Chrome runs, or requests to run with root privileges. Again Chromes asks the user to authenticate, and they do, will be able to pop  calc. Really the hardest thing here was basically to get calc to run as root. So we run our Python script, it infects that script, because we have the right privileges, Chrome asks the user to authenticate because they want to execute the script as root, again there’s no validation so,  then Chrome executes the script as root which we’ve infected to execute calc. Ah, again, Chrome said yeah we’re not going to fix this. 
Finally let’s talk about exploiting Apple’s installer. I think this is kinda my favourite. Why? It’s because people use installer dot app all the time. And what we can do is basically, inject malicious code, unsigned dynamic libraries into the package which is about to be installed, and then installer dot application will load them. So, in three steps, we basically expand the PKG, inject our malicious dylibs  into it, repackage it up, and then when the user double clicks to  execute this, installer dot app will load our malicious unsigned dylibs into its process context. So now we're running within installer dot app. So what could we do here? We can either display our own authentication prompt which everyone will trust, because it’s the installer application displaying an authentication prompt which is what is always does anyways. Or to be even more stealthy,  we can just wait until installer dot app requests the user to authenticate any way. And then piggyback off that. Reported this to  Apple via their bug reporting website. Got no response. Maybe they’re just sick of hearing from me. [laughs] Probably. [laughs]. They don’t really like me. Alright, so let’s start by wrapping...end by wrapping this all up. So, hopefully you have a healthy paranoia of these authentication prompts. I do. Why? First, they can be spoofed, like there’s no way really to easily validate that is not completely fake. And even if it is,  a legitimate pop-up that the security agent has displayed - like how do you know what it’s about to execute? And again, every freaking application invokes this insecure API, meaning local code that’s on your box, if it wants to elevate its privileges as root can very easily infect there. So, if you’re a malware author, stop spoofing these boxes, like it’s like really lame, do something a little cooler. Um, yeah know, I’m getting bored as a Mac analyst, malware analyst CND, Ahmet         knows what I’m talking about [laughs] [clapping] he complains to me all the time [laughs] so instead like be patient, wait till one these vulnerable applications which is  pretty much most applications needs to perform an upgrade or is installed - and again what you can then do is piggyback into that and then when the user authenticates, you will have root again, a lot more stealthy, a lot more elegant.
So what is the answer, well the answer is to use SM job bless,this is an API that recently introduced by Apple and it does allow you, or applications to do secure authentication, but it’s incredibly complicated. So what you have to do is put whatever you want to be executed as root, this is called the Helper tool, in the contents slash libraries slash launch services directory. Then in your application's info dot P list file, you have to identify the  signing information of the Helper tool. Then you invoke SM Job Bless, which will cause the service management daemon to copy your helper application into a secure location. Then in that secure location it is cryptographically verified that it hasn’t been tampered with. Only then, once that verification has been validated, it’s copied to the system launch daemon directory and executed as root via a launch daemon. So here’s code to do it, you can see it’s actually not too complex in code once you get everything set up and again, this will allow you to securely install and execute something with higher privileges that local malicious code cannot tamper with. So why aren’t people using it? Why is Chrome Mware, SoFO , little snitch, why is everyone using the insecure variant? Well, first, your application has to be signed, which means you have to give Apple 99 dollars a year. Also you can’t specify command line arguments, you can’t pass command line arguments to whatever you’re about to execute. You can use XPC but, this is kinda a pain the butt, I consider myself a decent coder, it took me hours to get it working. And also then it persistently installs something as a launch daemon, this is like massive overkill, if all you want to do is run a simple installation script. And then there’s kinda a catch 22, this you know launch agent has been installed as running as root, you app can’t now actually uninstall it because it’s running with higher privileges so again you have to set up this XPC channel or tell the launch daemon to uninstall itself - just incredibly complicated and usually way overkill.
Alright, so before we end I assume you’re at this talk because you’re somewhat interested in Mac security shameless plug for my Mac security website, but everything here is free so I hope this doesn’t sound like a sales pitch. Ah, in my free time I like to write, ah, security tools, blog about this kind of stuff, um write about about a lot of malware analysis, etcetera. So if you’re interested in the stuff, check it out.
Well, alright that’s a wrap, again, thank you so much for attending my talk - and again if you’re interested in being a security researcher with Synack, er,  check our Synack dot com or come chat with me. So, if there’s any questions, or I’ll be here afterwards, er, I’d love to chat with you more about this.
[applause].
Thank you.