 Mahalo. So welcome to my talk on XPC and a bug named root pipe. As he mentioned, my name is Patrick. I have worked at a bunch of acronymed places. I'm currently the director of R&D at CINAC. So CINAC does crowd sourced vulnerability discovery with vetted security researchers. Basically anyone can sign up to find bugs in our customers' websites, mobile apps, IoT devices and even networks. Our customer security isn't that good so we end up paying out a lot of money to our researchers which I think is pretty cool. So if this is something that's of interest to you, check out CINAC.com or come chat to me after the talk. All right, so what is this talk going to cover? We're going to start with a brief overview of XPC. We're then going to talk about a privilege escalation bug that was named root pipe. We're going to talk about some malware that was then discovered that actually preceded the public disclosure of the bug and so it was exploiting it as a zero day. We're then going to talk about Apple's initial patch, how they blotched that patch, how I was able to bypass that to re-exploit the vulnerability on a fully patch system and then briefly talk about Apple's final patch which seems to maybe squash the bug. All right, so usually credits are given at the end but there are a lot of really good OSX security researchers who I've learned a lot and who are kind of partially responsible for the content of this talk so I just wanted to acknowledge them up front. So first is Ian Beer. He works at Google Project Zero. He's given a lot of talks on XPC, found a lot of really cool bugs. So pretty much everything I've learned about XPC is from Ian. Emile, who has a last name that I don't know how to pronounce, actually found root pipe so obviously a lot of credit goes to him as well. And then Pedro, he did some initial analysis on Apple's original patch which kind of got me inspired to look at it a little more. And then finally the book that taught me most of what I know about OSX internals was written by Jonathan Levin so if you guys are kind of interested in this I would highly recommend this book. All right, before diving in since we're in Vegas I think it's good to possibly, sorry, define any possibly ambiguous terms. So in the context of this presentation when I'm talking about implants I'm talking about malicious persistent code. I'm talking about hooking, I'm talking about intercepting function calls, installing a hook or a detour. A Trojan is a malicious program, something that is malicious but pretends to be benign. And then injection is all about getting code into a remote process. And then finally a back door in the context of this presentation is code that provides undetected remote control of the computer. All right, so with those out of the way I want to start with a brief overview of XPC which is a modern inter-process communication mechanism on OSX. Since root pipe is an XPC related vulnerability I think it's important to understand what XPC is and how it works. So XPC as I mentioned is an IPC mechanism with two goals, privilege, separation, and stability or fault tolerance. So basically each XPC component is its own unique process. So this allows obviously a lot more fine grain controls because each process can have its own unique sandbox which gives it really fine level control over what access it can have. In terms of stability or fault tolerance, again, since each XPC component is a separate process, if that process crashes or has a bug that won't necessarily impact the main application or the other XPC components. The operating system could just restart that component automatically. XPC is used extensively by Apple in both frameworks and applications. So you can just grab the file system looking for XPC components. In terms of frameworks, for example, we can see WebKit. WebKit is obviously used by browsers such as Safari and does things like rendering and plug-in hosting. Again, it makes sense to use these or put these in separate processes, separate XPC components because if you think about it, there's been a ton of rendering bugs, exploits, vulnerabilities. So if this isn't a separate really tightly locked down sandbox process, even if the attacker gets arbitrary code execution, they're not going to be able to do anything really useful like persist malware or do some command and control. They're going to have to break out of the sandbox. Also, again, in terms of stability, for example, if a plug-in crashes, if the plug-in hosting is in a separate process, that's not going to impact the main browser. It might just say, hey, plug-in was unable to load, but it's not going to crash Safari proper. Another example, applications. Again, iPhoto has a bunch of XPC components, again, related to rendering and converters. Again, this makes a lot of sense from a security point of view and stability point of view. If iPhoto is doing some rendering or doing some converting and that crashes, that's not going to impact the main iPhoto.application. All right, so here's a more detailed example. Allow us to kind of dig into XPC a little more. So say we have an example application that does three things. It downloads zip files from the Internet, unzips them, and then displays the images that are in this zip file. Normally, we would write this as a single standalone binary that does all three tasks. What we can do, though, is we can convert this to XPC. Basically, break out its logical components. So here you can see we have a download XPC component, so this will be a separate process, and then we have an unzip XPC service, which will also be a separate process. So as I mentioned, each process can have its own set of privileges. So for the download XPC service, sure, this has to talk to the network, but there's no reason this has to talk to the file system. So we can put a sandbox constraint that says, this process is not allowed to talk to the file system. We can walk down the unzip XPC service even more, saying it should not be able to talk to the network or the file system. So this means if an attacker is able to find a vulnerability in the unzip component and they get arbitrary code execution, can't really do anything useful. They can't persist malware. They can't talk out to the network. They then have to break out of the sandbox before they do anything useful. So, again, it just adds an extra layer of stability. Also, again, in terms of stability, fault tolerance, if any of these components have a bug and crash, that's not going to impact the main UI of the application. You can say, hey, unzip failed, but it's not going to be taken down if the, for example, the unzip XPC service crashes. So conceptually, how does this all work? Well, basically you have a client component, in this example, the XPC application. And what it does is it sends message requests to the XPC components or the XPC servers. These XPC servers or services will listen for messages, optionally authenticate clients that connect to them and then process or handle their requests. Now, this should sound similar to, you know, something we're more familiar with, kind of the client server networking model. There's a ton of parallels where you have clients talking to servers, authentication, all that kind of stuff. So conceptually, very similar. Message handling is processed by the operating system. Some of Ian's talks go into great detail about the low level details of XPC. Basically it's sent as mock messages. The operating system and the kernel takes care of everything. But from the application layer you can basically just send a message and it'll get to the end point. So it's pretty easy to make an application or to make an XPC component. So make an XPC service. Basically what you do if you have an application in Xcode, Xcode being Apple's IDE, you can just add a new target and then for your target type you select XPC service. This will create the required files with some boilerplate code. And then also when you click build it will be automatically packaged up into your application. Makes it really easy to deploy. One thing to mention, we can see a bundle identifier. This is a string that is used by the client, the application to find the XPC service at runtime. Again if we create parallels to this client server networking model, this is kind of like the URL of the server where it's DNS name. Again this allows the client and the operating system to find the XPC service that the client wants to connect to and talk to. So how does an XPC service listen for client connections? Well it does a few things. So first it creates this NSXPC listener object, sets its delegate which is just a callback object and then invokes resume. This delegate object has to conform to the NSXPC listener delegate protocol and implement a method called listener should accept new connection. This authentication method is called automatically any time a client connects and allows the XPC server to examine and validate and allow the client. Again this is all kind of similar to a server socket doing a bind listen accept. So now with this all set up and running XPC clients can connect to the XPC server. Of course the server or the service should expose some useful functionality. So here for example again going back to our downloader application, this is the download image method. So once this is implemented the XPC application will be able to connect to the XPC service and invoke this remote method. Again if there's a bug or a crash in this method it won't really affect the main client component of the application. All right so back to the XPC application, the client. To use the service, the service we've now created, it needs to do two things. It needs to connect obviously and then invoke the remote methods. So it connects via the NSXPC connection in it with service name and takes that bundle ID I mentioned. So it basically passes the name of the XPC server that it wants to connect to. This will return an NSXPC connection object. So then what you do is you call the NSXPC connection object's remote object proxy method. This returns a exported proxy object from the other side of the connection. So this is basically the server's remote object that's vended to the client. Now the client has basically a local copy of the remote object and it can invoke methods directly on that object as if it was a local object. That will be executed in the context of the remote XPC service. All right so that's kind of the boring part. That's XPC basics. Let's dive into root pipe which as I mentioned is an XPC related privilege escalation bug. Now what makes root pipe so interesting at least to me is not just the bug but its timeline. So we can see that the bug was discovered by Emil in October of last year where he responsibly disclosed it to Apple. I tested the code all the way back to OSX 10.5 which is leopard, snow leopard and found that those operating systems were actually still vulnerable. I didn't have older versions but if you look at some code it appears that this vulnerability was actually introduced in the original release of OSX which was in 2001. So subsequent slides will actually go into some other details. We'll see some malware that exploited this bug as a zero day and then we'll also talk about Apple's patching attempts. All right so let's start by first looking at the vulnerability. So there's this private XPC service called write config. It can create files. Specifically it exposes a remote method named write config dispatch create files with contents. Nothing too special yet. The problem is or was any user even guests can connect to this write config XPC service which runs as root and then create files and the user can specify the path, the contents and the attributes. Obviously this is really not good. So for example we can create a copy of a shell and set the SUID bit and then since that shell is going to be copied as or created as root, simply executing it will give us root privilege. Really doesn't get much easier than this. All right so now let's detail exactly how we can connect to this write XPC service and invoke the vulnerable method. So kind of go into the details of what happens under the hood when we perform this exploit. So while we could talk directly to that remote XPC service, the write config XPC service which has that vulnerable method that allows anyone to create a file, it turns out that there's some client code within an Apple private framework called system administration that we can utilize. This just is kind of another layer of abstraction but makes it easier to talk to the remote XPC service. So step one we need to get access to a write config client object. As its name suggests this is a client object that's built specifically to talk to the write config XPC service. So specifically we call the write config clients shared client class method and this will return us a singleton instance. All right so now with this client object we can connect to the remote write config XPC service. We do this via the write config client authenticate using authenticate authentication sync method. If you look at the disassembly for this method you can see some of the low level XPC functions we talked about. So for example you can see a knit with service name. So under the hood this method actually makes that connection to the remote XPC service. Now as I mentioned when you make an initial connection to an XPC server service component it's going to authenticate you first. Now one of the vulnerabilities or issues with this bug that actually allowed guest users to exploit it was the fact that you could pass in nil for this authentication object. And objective C if you have a nil object and you execute methods on this this doesn't throw a null pointer exception it just kind of goes off into the ether. Now as we'll see actually older versions of OSX did not allow nil to be passed in as this parameter. And you had to be an admin to create an authentication object to pass. So actually older versions of OSX were more secure. Go figure. All right so now we've authenticated we want to invoke the remote method to create that SUID file. Remember you need to get a proxy object which is the exported object from the server side of the connection. And then once you have this then you can invoke remote methods on it as if it was almost like a local object. So the right config client has a remote proxy method which gives us back a dispatcher object. And then we can pass requests to the remote object. So again since we're using this kind of local abstraction we don't get the remote object directly we get a local dispatcher object. But basically when we invoke methods on this dispatcher object it'll get sent to the remote XPC service. All right so locally you ask the dispatcher object to create a file with the create with file content method. Under the hood a little more goes on this invokes the forward invocation method of that local dispatch object. As we see in this yeah it's going to do some forward invocation it's then going to get the remote proxy object itself and pass our methods. So again end result we call the remote method we want the vulnerable method on this local dispatch object it'll transfer it over to the remote object and create our attacker file. So putting these steps all together we can create a shell or any other file as root with any attributes like UID bits or anything else we want. So then the steps just to reiterate are first we get an instance of the right config client object. Then we authenticate which again anyone can do even guess users. We then get this local dispatch object and finally using this local dispatch object we invoke the remote method that allows us to create the file. Now if we execute this all we can monitor what goes on at least at the file level by running a tool such as FS usage which shows file IO. So first we can see our application which is just called root pipe that's triggering the exploit. We can see it makes a copy of the shell. We use KSH because that allows itself to be run as root. And then if we look we can see right config this is the remote XPC component the private XPC component that has the vulnerability. We can see it creating a copy of that file and then chmodding and choning it so that it has the SQID bit set. So older versions just to briefly mention they do require you to be an administrator. The default user on OS X has these privileges so again this is still a privilege escalation because it allows an attacker to get root privileges without having to specify username and password. All right so recall the timeline. Emil found the bug in October reported it to Apple but turns out there was some malware that was actually exploiting this vulnerability as a zero day before Emil's discovery. So XSL CMD is an OS X persistent back door. It was submitted to virus total in August 2014. Of course no AVs detected it but a few months later FireEye came out with a report I guess they did some back end analysis on this file. Basically determined that it was a new piece of APT related OS X malware. As I mentioned standard back door provides a decent some sufficient features provides the attacker the ability to create a reshell screen capturing and then key logging which will be important in a second. Now one interesting thing is in the report there was no mention of any local privilege escalations. I don't think they were withholding it I just think their analysis completely missed it. That's my opinion. So after Apple patched the vulnerability Emil wrote a nice blog kind of detailing the bug and someone went back and was doing some analysis on this malware and actually found out that this malware appeared to exploit the same bug. Which kind of intriguing. We don't see a lot of OS X malware and then we don't see a lot of OS X malware that actually has zero day privilege escalation vulnerabilities built in. So why was malware attempting to escalate its privileges? So on OS X user mode code can capture key presses if the access for assistive devices is enabled. Now you can enable this via the UI under system preferences but you have to be root to do this. So as a normal user if you click on the check box to enable this it's going to throw up a prompt and you're going to have to put in your username and password. So you can as I mentioned do you do this via the UI and if you monitor what this does under the hood it basically creates a file named accessibility API enabled in var.db that contains a single character A. This is just a marker file that the operating system checks and basically if that file is there it says okay user mode code can do key logging. It can intercept or capture key presses. So if we look at the disassembly for the malware we can see it is actually creating this file. So in other words it's using the root pipe vulnerability as a zero day to create this file so that it could do key capturing and key logging. Kind of cool. All right so I mentioned again Emile reported this bug to Apple in October. It took him about six months to release the initial patch which as we'll see was insufficient. Eventually they did release a new patch so I think they may have finally got it right but it's kind of a rocky road to get there. So the first thing Apple did which I think somewhat of a fail was they decided not to back port their patch and in the quote they released they basically said eh it's too much work. However Pedro, OSX Reverser released a dilib for Mavericks which again was an OS that Apple decided not to patch. That would monitor for connection attempts and basically ignore untrusted clients. I think it's kind of funny or sad when independent researchers can help secure users more than the vendor. Anyway so Apple did patch Yosemite which is good and so let's look what that patch did. Basically they left the right config XPC service completely intact. They left that function that can create files completely intact. Basically what they did or what they said was we're only going to let Apple processes talk to this. So it's like almost they added a security guard at the door that basically said hey if you want to talk to me you want to create a file I'm going to check your badge, your ID and basically say hey if you're not Apple you know GTFO. So in the diagram we can see if untrusted or unsigned code a hacker tries to connect to this XPC service it's going to block it now not let them in. But if an Apple process tries to connect the security guards can be like yeah sure you can connect and you can create whatever file you want. So recall when a client connects to an XPC service the listener should accept new connection method will be invoked. This allows as I mentioned the server to examine the client and allow or deny. So what the patch did it checks that the clients have a new entitlement which is com.apple.private.admin write config. And we'll talk about entitlements in a second but let's first take a closer look at this authentication method. So we can see what it does is it grabs the client's authentication token. This is something that the operating system automatically generates when you try to connect to remote XPC service. And as far as I know you can't spoof it. It then checks if the client has this entitlement the com.apple.private.admin write config client. And if it doesn't have this entitlement it basically you know doesn't let it in. So again you can kind of think of this as a security guard checking badges at the club and if you're not an Apple employee you don't have the right entitlement it's not they're not going to let you in. So what are these entitlements? Well they're basically just embedded blobs that are in the code signature of an application. And they confer capabilities or permissions. So it's a way to kind of tag an application and give it special permissions. Kind of like specifying what employer they are. So again when the security guard checks it can determine if they're allowed or denied. So Apple's patch look weak to me. Instead of appearing as a security guard it looked more of like a mall cop. So I had a long flight home from infiltrate and I always wanted to do something cool on an airplane besides obviously hacking the airplane. So I took a little bit of a closer look at Apple's patch and it turns out that it was insufficient. So this is a brief video. Basically see I execute the LS command. Okay cool it's showing up there. I look for a file named Phoenix. It's not on the root file system. I try to create it. I'm not root so it tells me to take a hike. I then execute a small Python script that does a few things. It says it's done. I relist this file and we can see that now it's been created in the root directory. If we LS it we can see that it's owned by root. Which makes sense because that XPC service is owned by root as well. And then we can see any contents I wanted in this file can be put in this file. So at the time this was on a fully patch system after Apple released their initial patch. So I want to walk through how I was able to bypass Apple's patch. What failed and then what worked. My goal was simple. Since the XPC service and that vulnerable function was left untouched I just wanted to be allowed to talk to it, to connect to it, to authenticate it. And since authentication was based 100% on the binary connecting. If the binary is trusted any code within that binary is able to talk to it as well. So if you can inject malicious code, get it to load a malicious plugin, anything like that. The operating system, the check, only was checking that the main binary that was connecting was entitled. So this is what I tried and will kind of go through all of these. I first tried to create my own entitlement, tried to spoof that. I tried to infect signed trusted entitled binaries. I tried doing some runtime process injection, hijacking entitled binaries and then finally trying to load malicious plugins. So we'll look at each of these closer. So the first thing I tried to do was to add the com.apple.private.admin.write config entitlement to my own binary. Again, this is what the security guard at the door is basically checking. If you have this entitlement you will be able to talk to the XPC service and then still retrigger the vulnerability. So in Xcode you can specify entitlements. So I was like well let me try to put this new Apple private entitlement and it'll let me compile my binary but as soon as I executed the OS told me to you know GTFO. Basically said hey you claim to have this Apple entitlement but you know I can't verify you. So I'm not sure exactly how this verification all works but I imagine since it's a private Apple entitlement it can probably detect that I'm not a verifiable Apple binary so it can kick me out. So basically it can be like this is a fake ID. You're not really an Apple binary therefore you can't have this private Apple entitlement. So since I can't fake the entitlement I have to abuse a legitimately entitled binary. Now not all Apple binaries are entitled so these entitlements kind of like an extra layer of more fine grain permission control that be slapped on certain binaries. So what I did was I wrote a small Python script that could enumerate all the binaries on the operating system on my file system and give me a list of which ones were entitled. This gave me about 50 or so and again these are the trusted binaries that are allowed to connect to the remote XPC service. So my goal was then to try to coerce any of these to load my arbitrary malicious code because again once I'm in the trusted context of any of these processes I can then reconnect to the XPC service and re-trigger the vulnerability. So the first thing I then tried to do was simply infect an entitled binary. Unfortunately the mock O-loader verifies that digital signatures of binaries are intact. So here we can see me trying to infect the directory utility application which is entitled and thus allowed to talk to the XPC component. But you can see that when I execute it the loader basically says hey the digital signature is no longer valid and just kills the process right out. Now it turns out on OSX you can unsign binaries and then they are still allowed to execute. But when you unsign a binary it basically removes the entitlements as well because the entitlements are part of that digital signature. So that really doesn't gain you anything either. I then tried to coerce the loader to load a malicious dilib into an entitled process. So OSX has some environment variables. For example it has the LD, DYLD insert libraries environment variable that tells the loader to load a malicious or any dilib at low time. This is kind of like LD preload on UNIX or Linux systems. But it turns out that environment variables are ignored for entitled binaries. So here's the source code from the OSX's dynamic linker and loader DYLD. And we can see it calls a method that's named prune environment variables. And the Apple comment says for restricted binaries delete all DYLD and LD library path environment variables. So what is an restricted binary? Well it's a binary that has the SUID bit set or it's also an entitled binary. So basically the mock loader will strip away and ignore any environment variables if the binary is entitled. And since we're targeting entitled binaries because we need that entitlement to connect to the XPC service it's basically going to ignore this so this doesn't work either. So then try DYLIB hijacking. DYLIB hijacking kind of neat attack. I talked about it yesterday at DEF CON, well this conference. And basically what you can do is you can if you find a vulnerable application you can coerce it to load a malicious DYLIB even if the DYLIB is unsigned. Unfortunately I guess a limitation of this hack is you need to find a vulnerable application or you can only exploit vulnerable applications. You can't hijack arbitrary applications. So I wrote a tool that could look for all binaries on the file system that were vulnerable to a DYLIB hijack but unfortunately none of the binaries that were vulnerable had the entitlement. So this didn't work either. I then said I'd try runtime code injection to inject malicious code into an entitled process that was ready running. So the way you do code injection on OSX pretty simple, it takes about five steps. You first get a task for the PID. This is kind of like access to the remote process. Once you have this you can inject shell code, you can allocate memory for stacks, you can create remote threads. Unfortunately in order to get access to this remote process even if it's running as the same user you need to be root. So basically Apple says if you're doing any kind of code injection you've got to be root. Which from a security point of view my opinion makes complete sense. So since we don't have root, we're trying to get root, this also doesn't work. I then tried to find an entitled application that could load plugins. I figured maybe I could plant a malicious plugin and then get loaded. And then again once I'm loaded I'm in this trusted entitled binary and then my malicious plugin can reconnect to the XPC service and re-trigger the vulnerability. So here we have the directory utility. It's entitled which means it can talk to the XPC service which is good. And it appears to support plugins. Specifically if we look at its application bundle we can see an internal folder that's named plugins. So I was intrigued. So I disassembled directory utility binary and you can see it invokes a method named load plugins in directory. If we run a file monitoring tool again FS usage which monitors file IO we can see that when you execute the directory utility what it does is it goes through all plugins in its internal bundle folder and yes loads and execute them into memory. Again seems promising. So I then tried to install a plugin by copying it into the directory utility's plugin directory. Now since directory utilities is a system application it's actually owned by root so you have to authenticate to even install a plugin. But let's forget this fact for a minute because basically I want to say if I found some way to copy in or install a plugin would directory utility load my plugin. I mean it's an unsigned malicious plugin maybe directory utility is doing some extra checks. So I manually authenticated installed it and then when I executed you can see that directory utility found my plugin and even though it was unsigned it loaded and executed. So we're kind of closer. I mean we can get this entitled binary to load unsigned malicious code that then can talk to the remote XPC service. But since we need to be root to install the plugin since directory utility is root you know this is really not any closer at all. But if we can get directory utility to not be owned by root we can then copy and install a plugin execute it and then in theory be able to re exploit the vulnerability. So it turns out we can change the ownership of the directory utility and thus we can install a malicious plugin game over. So this is how I bypassed Apple's initial patch three easy steps really not that complicated. So first you copy the directory utility into the temp directory. On OSX when you copy a file to the temp directory its permissions get changed to the current user. So it gets changed from root to me. So this means now I can put plugins into its applications bundle because now I own the application. So we drop a plugin there and then we simply execute directory utility. This loads the malicious plugin even though it's unsigned and then our malicious plugin can make the XPC request to the remote XPC service. Again the security guard at the front door is going to check and say hey wait a minute I'm not allowing anyone just to come in and re exploit this. He's like who are you with? And I'm like well I'm with directory utility. So security guard goes and checks directory utility says okay yes you are executing within directory utility. Okay directory utility is an Apple application and it contains the correct entitlement so go ahead you're able to do that. So this means we can trigger the exploit once again. So here's the Python code for it. Super basic. Wish all privileged escalations were this easy. Basically three simple steps. So again you can see Python code. We copy the directory utility applications to the temp directory. This makes it owned by us. We copy in the malicious plugin. Again we're not modifying the digital signature of the application we're just planting a plugin in its plugin directory and then we execute it. This will give us root. So I reported this bug to Apple. They fixed it in OSX 10.10.4. CVE 2015 3673. When I posted the video showing that I was able to bypass that I didn't want to release details before Apple fixed this. But this inspired Emil the original founder of root pipe to look as well and he actually found the same issue. So he shares the CVE with me which is kind of cool. So here's some control flow graphs that kind of illustrate Apple's patches. So we can see in the original version of OSX 10.10 this is the listener should accept new connection function. Again this is what is authenticating clients. So we can see at the very beginning there's no authentication. This is a control flow graph. There's no checks being done. Basically anybody even if you're a guest is allowed to talk to the XPC servers. In 10.10.3 this is their initial patch. You can see they added some more checks. As we just showed these were insufficient. And then finally in OSX 10.10.4 you can see the complexity of their checks got way more. As we'll see I think they got it right. But this kind of shows how hard it is to get things right. I would hope Apple would have got the initial patch right. They didn't. But you know security is hard. So I don't want to pick on them too much. So briefly looking at Apple's most recent patch we can see it does a few things. We can reverse engineer it to figure out what it's doing. So the first thing is they add some extra private entitlements. I think this just gives them more fine grain control over who's allowed to connect. Most importantly though they say the binary that's connecting has to live in either system or slash user. Now these are both owned by root. So our attack generically is thwarted. We can't copy out these applications, change anything. We also can't put plugins or malicious code in any of these directories because these are owned by root. And again we don't have root. We're trying to get root. So I don't see any immediate issues with the patch. But as Pedro states there's still the fundamental issue that the whole fix seems kind of brittle. So as Pedro says the problem is of their fix is that there are at least 50 plus binaries which are entitled which are still allowed to talk to the XPC service. So a single exploit in any of these binaries and the system is owned again because there's no fundamental fix inside right config. So I really wouldn't be too surprised if someone found again a way to exploit this. All right so we've seen that OSX contained a trivial privilege escalation that perhaps was introduced in the very inception of OSX in 2001. We saw malware that exploited this as zero day vulnerability and Apple's initial patch in my opinion was, well it was crap. So these things scare me. I love my Mac but I don't want to get hacked. So I briefly want to talk about some free security tools that I run to protect my Mac that I share with others to hopefully protect their Macs as well. So my side hobby I run a small OSX security website. I have a nice little malware collection including the one I mentioned today XSL.CMD that exploits this vulnerability or exploited this vulnerability as a zero day. I found it hard to find a good collection of OSX malware. People who have these samples generally don't like to share. So I try to make a nice collection that anyone can download and play with. And as I mentioned some tools to protect my Mac that I figured I should share. So I briefly just want to share them with you guys today. So the first two I wrote is called knock knock. Simple goal when I say knock knock it should tell me who's there. It basically tells you all software that's persistently installed on your computer that will get automatically executed whenever you restart your computer or log in. Conceptually exactly the same to auto runs on Windows. But in my opinion looks a little better. My favorite feature is probably the virus total integration. The tool doesn't actually tell you if something is malware or not. It's malware agnostic. It just shows you what software is persisting. Which is good because then if some new malware comes along and persists, which all OSX malware I've seen does, it will be able to show it to you as well. But with the virus total integration this is kind of nice because for known malware it can detect and flag this. You can also submit files to the virus total, view the scan results. Kind of cool. Now the only limitation in my opinion to knock knock is that it's reactive. It doesn't provide real time protection. So I wrote another tool that can provide that. So I wrote block block. Now knock knock tells you who's there. Block block tells you when someone is moving in. Basically it provides real time, run time protection, monitoring known persistence locations. You can kind of think of it as a firewall for auto run locations. So anytime something persists itself or installs itself, it'll pop up and you'll get a little warning that you can either confirm or deny. I released this beginning of January but it's been kind of cool because as new OSX malware samples are released I've been able to test them and they've all been generically detected by this tool. So here we can see hacking implants, persistent OSX implant. This basically means if you had already been running block block and hacking team tried to target it, you would have got a pop up. Now, you know, my mom and dad are still going to click allow but as security conscious users hopefully we would at least examine this and in this scenario click block. Another piece of malware that was released a few days ago, Stefan Esser released a zero day vulnerability. A few days later there was some malware that was exploiting it. This in my opinion is a very good example of why it's not good to irresponsibly disclose bugs. The malware authors were just like adware writers, they're not sophisticated adversaries, they're going to be finding their own O-day. So as security researchers when we release O-days, there is negatives to that. And in this case, you know, there's adware authors that are now targeting, you know, innocent Mac users with this privilege escalation vulnerability that Apple is working on to fix but it's not yet patched. So again, though, if you were running block block, even though it wouldn't detect the exploit, it's not designed to detect exploit, you would be protected because when the malware, even though it's running its route, goes to persist, you get a nice little pop up. All right, the last one I want to talk about, another one I just released that Black Hat is called task explorer. This is conceptually similar to process explorer on Windows. In my opinion, it's kind of a better activity monitor, again, for security conscious users. Got some nice features, for example, you can see all the processes that are running that aren't Apple, that aren't signed, so you can quickly filter those out. It shows you the signing information, so you can see if things are unsigned, virus total integration, and then in the bottom pane for each task or process that's running, you can see the loaded dilibs, the files, the network connection. So I actually used this tool to help me find this vulnerability because what I did was I ran it and then I looked at the plugins that were loaded by director utility. And then when I planted my malicious plugin, I could see that it got loaded. All right, so let's wrap this all up. Just some brief conclusions. So first, my humble opinion, I think OSX security is kind of lame. You know, there's a lot of public zero days, Apple's malware mitigations can be bypassed. Yeah, then there's probably a lot of trivially exploitable bugs such as root pipe that are out there. And again, since root pipe was kind of in the inception of OSX, you know, again, that bothers me. So it's a great idea to audit all things. And security researchers, I think that's one way we can kind of help out Apple or at least selfishly make our Apple computers more secure. So it's a great idea to audit these XPC interfaces. Right? Apple kind of thought that since this was a private XPC interface, maybe no one will look at it. But as soon as someone started poking around, there was a trivially exploitable bug that was found. It's also a good idea to really thoroughly analyze OSX malware. The initial FireEye report did not mention the ODAY that was in it. I believe that they just missed it. But again, it's a good idea to analyze OSX malware. There's not that much OSX malware out there, so let's do a good job. And then finally, when a security vendor releases a patch, we've seen Microsoft do this in the past, too, I think it's good to audit this patch to make sure does it really address the issue. You know the bad guys are doing the same thing, the nation state guys, the advanced adversaries. So again, I think we have some responsibility to audit these things because unfortunately we can't really count on the vendor at this point. All right, so thanks for your time. You can email me. I'm on Twitter. These slides should be up shortly to download. And also check out CINAC.com if you guys want to get paid to do some legal hacking. So we have about five minutes. Are there any questions? Yes, sir. So the malware actually only used it or I only saw the malware using it to enable key logging, which was surprising. They I thought could have used it far better to do more surreptitious but it's, you know, I think they used it for what they needed. So the malware, yeah, just basically seemed to use the exploit only to enable key logging. Yes. So the question was the DOD, I think it was the NSA, used to release articles or documents how to lock down how to secure your Mac. And they haven't done this for a certain number of years. This question is why. I'm not sure, yeah. I would like to see that, too, because they were saying, I have no idea why they don't do that. Sorry. I'll email some of my NSA contacts and ask them. I don't think they talked to me anymore. But they just heard that, so maybe we'll get an answer anyways. All right. Well, thank you guys. I really appreciate attending. Email me or chat to me if you have any other questions.