 So this is one of the most highly coveted speaking slots first thing on Sunday morning at any HackerCon I have done this this slot before And I and I know how much fun it is So let's give Patrick a big round of applause and thanks for taking this highly coveted first thing in the morning Sunday slot All right Aloha and welcome to my talk the mouse is mightier than the sword So my name is Patrick. I work at digital security and very belief briefly We are working on creating cyber security tools for the Mac enterprise I'm also the creator of the Mac security website and tool suite objective C Okay, so today we're going to talk about synthetic events on Mac OS and by synthetic I mean those that are programmatically generated think mouse and keyboard events So we're going to start by looking at components or local security mechanisms of Mac OS that can be attacked via synthetic events We're then going to look at the fairly long history of attacks that utilize synthetic events for example to Bypass local security mechanisms Now of course Apple has responded to these attacks. So we'll now look at how they implement Security mechanisms to detect filter and in some cases attempt to block these synthetic events Well then talk about a recent bug I discovered that allowed me to interact with any component of the uos Synthetically for example to click on security prompts and then we're going to end with describing how to weaponize this bug for example to bypass Security prompts and do all sorts of nefarious things in an invisible manner Okay, so let's start by looking at user interfaces UI components of Mac OS that Attackers or malware may seek to interact with via synthetic events So first here's the attackers conundrum So let's assume an attacker or piece of malware has somehow gotten on to an end system a Mac computer Perhaps via a malicious email attachment a Trojan a zero day or even an evil made attack now It wants to do something Unfortunately, at least for the attackers and malware on modern versions of Mac OS many useful actions will now be blocked and Generate an alert until at least in theory the user interacts with the alert clicking allow or deny So this phase the stage of a cyber attack is kind of where this talk fits in Specifically how to interact or bypass such alerts so that the malicious actions can continue Now we'll take a closer look at a variety of these UI alerts, but we're talking about things like accessing the keychain prompts that protect the loading of Kernel extensions or even installing a system-wide key logger and then we'll also talk about some third-party security tools for example firewalls and their alerts and show out Malware perhaps could synthetically interact with those as well Now this is a good good time to kind of make the point the generalized statement about synthetic events and really kind of Mention how much of a powerful capability they really are because if you have a way to Programmatically interact with these alerts you can generically bypass a ton of security mechanisms It's really a tool agnostic attack. It's really in these cases the UI is the single point of failure So even if the security mechanisms are all implemented in different ways, they all share for example the UI So if you can programmatically interact and just click allow you can bypass a ton of these mechanisms All right So the goal for the attacker then is to either avoid all these these alerts in the first place And we'll show some examples of how to do this or if an alert is shown how to Programmatically interact with it to dismiss it via code So for example, here's a piece of malware and we'll talk about this a little more in detail later But it allows the attacker to interact with the operating system remotely here For example, we see an alert that is displayed when the malware tries to dump the keychain So what a remote attacker can do is send a synthetic mouse event to click for example the allow key here to dump an RSA private key Now of course Apple tries to prevent these synthetic interactions But it's really a cat and mouse game and we'll talk more about Apple's defenses But it should really come as no surprise that Apple keeps losing Okay, so what are attackers or malware targeting via these synthetic events? Well, we briefly already mentioned the keychain So let's take a closer look at this now because it's actually a very common target for both malware and Attackers for obvious reasons. It really stores a ton of sense of information For example private keys passwords Certificates auto fill data and also even sensitive application specific data So until recently you didn't need any special privileges to dump the unencrypted contents of the keychain There was just a single access prompt that was displayed so that was all that was standing between all your passwords and goodies and full unencrypted access For a local attacker or a piece of malware so again if the attacker has the ability to synthetically interact with this keychain prompt All your secrets are essentially theirs Another target that Apple seeks to protect from synthetic events is the security and privacy Accessibility pane which is found in the system preferences application and the reason that this is protected is once an application Has gained accessibility rights they can control other processes like it says on the slide For example, it can inject events or do things like capture keystrokes at the system level Of course, these are very powerful capabilities that malware or an attacker would love to have thus this UI component is protected Another aspect of the OS that a malware or a local attacker may seek to interact with Synthetically our privacy alerts that are displayed for example when you try to access the user's location Their contacts or the calendar events So for example here we can see on the slide if you execute this code to try to figure out the geolocation of the infected system the operating system will block this action and display an alert and In theory only continue when the user clicks allow a Newer target for synthetic events is the interface for approving the loading of kernel extensions So in high Sierra Apple introduced something called user approved kernel extension loading which basically says a user has to Manually approve the loading of a kernel extension So on recent versions of Mac OS kernel extensions have to be signed But one attack vector is an attacker or malware could bring a legitimate third-party kernel extension That is signed but has a vulnerability in it and then load and exploit that So I talked about this previously at Defconn found a exploitable heap overflow in the little snitch kernel extension and It was buggy and yes, it was patched But since I had an old copy of the kernel extension I could still load and exploit that So Apple as I mentioned tries to thwart this attack with this user approved kernel extension loading now Obviously what an attacker would try to do is synthetically interact with the allow button that Apple has put up to block The kernel extension from loading and again if the hacker can just send a synthetic mouse a click event to click this button It would completely bypass this new security mechanism Finally we've got the user interfaces of third-party tools You can think of ones like firewalls or antivirus products and again these tools may detect and block an attacker or malware's activity and So this is obviously something that again attackers or malware would like to interact with so some examples are the Mac OS firewall a Generic ransomware detector. I wrote and another tool called block block which will Detect and prevent persistence So if these tools detect an attacker or the payload what they will do is again Block the attack and display in a prompt to the to the user asking to allow the action or to deny it So what a savvy attacker could do is try to synthetically interact with these alerts? Another thing to point out most of these security tools run with root privileges So an unprivileged piece of malware or an attacker couldn't do things like disable the process or interact with them However, the UI if you want to interact with it that runs in the context of the user session And mostly you don't need special privileges So again an unprivileged attacker if they have a way to synthetically interact with these alerts can completely bypass Generically all these tools without even needing any special privileges All right, so now let's talk about some past attacks So over the years there's been a myriad of attacks that sought to interact with the UI In a synthetic manner and we've seen proof of concepts But also actual malware specimens that implemented these attacks So let's take a look at these now Now we'll dig into these but there are several ways to synthetically interact with UI components and that Apple has tried to Mitigate but that attackers have also used so we'll look at some of these closer Some include Apple Scripts the core graphics Framework and even in some cases simply side stepping the alerts all together So first up is Apple Scripts you might be familiar with this it's a kind of a basic capability normally used for the automating automation of mundane tasks But it's actually rather powerful because it can allow you to interact with other processes For example generating clicks or actions that then will actually appear to originate from the context of the target process So in terms of Apple Script actions For example, you can very easily in a few lines of code just display an authentication prompt For example to locally fish for the user's password. The user might be tricked into believing this is legitimate and provide their credentials You can also do things like bypass firewalls For example, assuming that the firewall trusts the browser via a few lines of Apple Script You can kindly ask the browser to browse to an attacker controlled URL and append any data you want to exfiltrate in a get parameter and again You can do this invisibly now the firewall will likely see this connection But as it's originating from the context of the browser it will be allowed so Apple Script is very powerful now in the context of this talk though We're most interested in utilizing JavaScript to generate synthetic events So here for example, we have an attacker who is trying to dump the contact contents of a keychain either via the API or Using the built-in security utility as mentioned This will generate an access prompt that Apple wants the user and only the user to interact with Now using Apple Script though on older versions of Mac OS You could synthetically click send a click event to this prompt clicking allow on this button So on the slide we have the code to do this and basically you can see we're telling the security agent to click the Allow button you don't need any crazy exploit. You don't need any, you know Complex code root privileges all you need to do is click this button with Apple Script. You could dump everything in the keychain So let's look at some malware that did this all the way back in 2011 so devil robber was a cryptocurrency miner and it contains a file called KC underscore dump dot a SH KC obviously for keychain and if we look at the script we can see it executes two other scripts The first one KD dot sh just invokes Apple's security utility to dump the keychain And again, this will generate a keychain access prompt the second script KC D Just continually clicks the allow always button in the keychain access So again using this Apple Script It can synthetically click the allow button and dump the unencrypted contents of the keychain Which are password private keys etc etc Now probably the most common way that attackers seek to interact with these UI prompts Programmatically is using Apple's core graphics framework and Apple notes You can use this core graphics framework to do things like low-level user input events So yes, you can legitimately generate synthetic events But you can also use this framework to do things like sniff or capture mouse and keyboard events So this is useful as we'll see for example for analyzing malware that generates synthetic events because we want to be able to sniff and record those activities So I created an open-source project named sniff MK and what it does in code is three simple things You specify what events you want to monitor for example keyboard or mouse And then you create what is called the core graphics event tap And you can think of an event tap kind of like when you tap a fiber optic cable get access to the content So once you have this core graphics event tap you can install it and enable it now anytime an operation occurs a mouse event or a keyboard event Either a manual one or a synthetic one. It will be delivered to your event tap and you can record this action Of course also via core graphics you can post synthetic events Which you can do programmatically to click buttons in the UI So for synthetic keyboard events you use the CG post keyboard API While for mouse events you use the CG post mouse events More generically you can also use the CG event posts which can be used to post either mouse or keyboard events So these are the APIs you can use So here's some example code that utilizes the core graphics API's to send a synthetic key press Here we're going to send an enter key So whenever you send a synthetic event you need to see you need to divide it into two parts First you send the down event and then the up event because again this mimics what a user does when they press and release the key Or click the mouse So what an attacker would do would be to perform an event that may trigger an action a UI prompt for example Trying to dump the keychain load a kernel extension or access the user's location and then Synthetically post the event in this case an enter button, which would then click the allow button in the prompt Which would both dismiss and allow the malicious action So let's look at some actual malware that used core graphic events to generate both synthetic mouse and keyboard events So fruit fly was a rather prolific piece of Mac malware was used by the attacker for over a decade to spy on Mac users Unfortunately, a lot of children so in the decompilation We can see that it calls CG event create create mouse event and then also the CG event post So this indicates or looks like this malware has the capability for generating synthetic events So what I did was I created a custom command and control server that allowed me to task the malware So for command number eight, which was tied to what appeared to be these synthetic mouse events I could task the malware and observe what it did So this allowed me to map out the synthetic mouse capabilities of the malware I basically task it with command number eight and then I'd run the mouse and keyboard sniffer And yes, I could detect that this malware had the ability to generate synthetic events Which would allow it to do things like interact with security prompts for example when it wanted to access the keychain Now fruit fly also had the ability to generic to Synthetically generate keyboard events. So again reversing its code We can see it invokes the AX UI element post keyboard event method Which is just a wrapper over the core graphics keyboard APIs Again via the custom command and control server. I could task the malware and observe its actions So for example, I could figure out that command at number 16 was the malware's synthetic key down command Where the command number 17 was then the synthetic key up again This gives the attacker the remote ability to generate synthetic keyboard events either to type on the system or interact with these UI prompts Another example of malware that uses the core graphic events APIs to synthetically interact with the system is Genio, which is probably the most prolific most annoying adware sample or family on Mac OS So we can use J tool to dump its binary and we can look at its objective C classes Now objective C is a very verbose programming language So a lot of times you can actually figure out the names of the methods and the classes So we can see a class named safari extension installer and it has methods such as click on install button It's like okay wonder what that does right So on Mac OS turns out that Safari extensions are stored in the keychain. This means if adware wants to programmatically install a malicious browser Extension, they will have to interact with the keychain access prompts So what the malware does is it is attempts to install this malicious browser extension And then once the keychain access prompt is displayed It will detect the location of this pop-up move the mouse to the allow button click mouse down And then click mouse up allowing itself to be fully programmatically Installed as a malicious browser extension without any user interaction Finally in terms of using core graphics to generate and post synthetic events We have the unsecure proof-of-concept project on github and what it is is it's designed to target third-party firewall and antivirus products Again what it does pretty simply is just looks for the alert windows Gets the coordinates of the allow buttons and then sends a synthetic mouse click event to both dismiss and allow the action Next we've also seen malware and attackers trying to avoid these UI prompts all together You know synthetic events are really cool, but if you can avoid a displaying of alert in the first place That's even better So here's kind of a conceptual example Imagine an attacker or piece of malware wants to connect out from a system that's protected with a firewall perhaps to Export rate some data Now it could perhaps try to synthetically interact with the firewalls rule window to manually add itself via a mouse click But this might be protected by another access prompt because there are ways to secure the UI So what the malware could do though is if it detects that the firewall has a list of trusted processes Stored in some property list or some rules database on the file system if it can directly manipulate that database instead It can add itself to the list of trusted processes and then connect out without having to interact with any firewall alerts altogether So let's look at some malware that kind of did this same thing to bypass the UI and all alerts to capture keystrokes So XSL CMD was a piece of Chinese malware that had some pretty standard capabilities although it had the ability to capture all keystrokes without any UI prompts which is rather odd because normally you have to interact with the UI in some manner to approve this capability So about a year after the malware was discovered OS X vulnerability was independently discovered and reported called root pipe and another researcher went back and noticed that the malware was actually exploiting this same vulnerability a year before So for system-wide key logging as I mentioned you either have to be root or your application has to have accessibility rights So on older versions of Mac OS you gain these accessibility rights by going into the system prompt and clicking on a button that says Enable accessibility rights now when you click this button the operating system will display a prompt and require user or admin credentials So what this malware does though is exploit this root pipe bug again as a zero-day to basically Click this same file. Let's click the same button by simply creating a file underneath it So what happens in the background when a user clicks this file? It creates a file on the file system to indicate basically that that button was checked So the malware just bypasses the UI and creates this file directly using this exploit So once it does that it can access all key presses and install a system-wide key logger again without having to actually interact with the UI Okay, so now it's it's also not just malware though that is interacting with Or bypassing rather the UI to do kind of shady stuff So previous versions of Dropbox actually did something rather sneaky So if you ran the Dropbox installer it would ask for root credentials and then continue its installation However, if you looked at the list of applications that were given access to accessibility rights Dropbox would magically show up Which is odd because on recent versions of Mac OS even if you have root privileges There's supposed to be a secondary access prompt to allow applications to have these rights So Phil Stokes did some interesting research and kind of found why or exactly what was going on So if we want run strings on one of the Dropbox binaries, we can see some interesting strings We can see reference to something called TCC dot DB and we can also see lots of SQL related strings So it basically looks like Dropbox is interacting directly with this system database So what is this TCC dot DB file? Well, if we run the file command on it We can see it's an SQL light database and if we Google around we can see that it's Mac OS's privacy database which among other things keeps the list of Applications that are afforded these powerful accessibility rights So we can confirm this by running FS usage, which is a file mon utility Opening the system preferences and seeing that the application generates file IO events to go read this database So what Dropbox is doing rather suspiciously is directly modifying this TCC dot DB file to give itself accessibility rights and avoiding this second UI alert altogether, which is I think kind of shady Now I wanted to see if other applications or perhaps malware was using this same kind of trick So I hopped on to virus total and just did a search for TCC dot DB And there's a few items that it detected a few game hacks Which kind of makes sense because it might need to move the mouse or keyboard But there was one application in particular that was kind of suspicious And it caught my attention because it claimed to be an Apple binary, but it was unsigned It was a packed and it attempted to modify this SQL database directly. So again clearly very suspicious So I took a closer look at this and it turned out to be a new cross platform backdoor Which is now called cold root So when it's run cold root would execute something called run me dot sh and we can dump this script And we can see that what it is doing is it's directly manipulating this TCC dot DB file to insert the malicious component of the malware into this database so that it can do system-wide key logging So on the right of the slide we can see that when I log into my bank account now The malware is able to capture these keystrokes because it has directly manipulated the accessibility database Again, this is an example of bypassing the UI no need for synthetic events Okay, so that was a fairly comprehensive history of attacks against the UI both that generated synthetic events to for example Click allow buttons and also those that sidestep the UI all together Now obviously this is not something that Apple is stoked about right They design these these alerts and they expect that only the user will be able to Interact with them because if malware can it kind of completely in my opinion defeats the purpose of these alerts So let's look now at what Apple has done to mitigate these synthetic attacks So first on Mac OS modern version Apple script is blocked from interacting with certain security prompts Specifically if we now use Apple script to send a click event The OS will detect that this is a synthetically generated event and will display a warning a security prompt Which cannot be generated or interacted with synthetic send synthetically so now for example if the piece of malware tries to dump the keychain and use Apple script to send an allow click to that allow button the Operating system will detect that this is a synthetically generated click and will block it and log an error message saying this is not allowed So let's look at this a little closer to see kind of how Apple is implementing this So if we execute some Apple script from the terminal to attempt to generate and submit a synthetic event We can see that the TCCD, which is the privacy daemon Will check the signature of the application and again We'll check if that application is in the TCC dot DB Which again is that privacy database and if it's not found it's going to display an alert to the user Basically saying hey this application has not been given accessibility rights I am not going to allow it unless you explicitly approve it and this secondary security alert cannot be interacted with synthetically either Now let's look at what Apple has done to block synthetic events that are generated via the core graphics API's So in short on recent versions of macOS Apple will now display a secondary secure authentication prompt Requesting user credentials when it detects that something is generating synthetic events via the core graphic API's So here's a brief video. I wrote a simple binary that tries to Generate a synthetic event and if we watch it We're basically going to see that as soon as I click the event Apple detects this and shows a secondary prompt which basically says I have detected that this is a synthetic event Before I am going to allow this synthetic event to occur. You have to put in your username and password So again, it looks like Apple has successfully mitigated against synthetic events that are generated by core graphic API's So let's briefly dig into this a little deeper to see how they are implementing this protection So first in the system log We can see an error message that is logged when we try to generate in synthetic event via the core graphic API's So we can grep the file system for this for this string and we can find the library that implements this check So what we do is we reverse engineer this library and we see it make some calls into kernel mode So if we hop into kernel mode, we can see this check is likely implemented in the MPO IO kit check check Hid control check so reading Apple's comments for this we can see it says it determines whether the process can post synthetic events So basically what it's doing is it's checking the entitlements of this process to say hey is this a process that is allowed to generate synthetic events and if it's not it returns an error mode to user mode and Then the operating system will display that secondary authentication prompt which basically says hey You have to provide your credentials before I'm going to process that synthetic event In terms of the privacy database Apple now protects this via system integrity protection or SIP So on the bottom of the slide we can see that if we do an LS to look at the file permissions We can see there's a new permission that is set to Restricted this means this file is now protected with SIP or system integrity protection Which means even if the attacker or the malware has root privileges, they will not be able to modify this file So going back to the cold root malware We can see that the cold root malware will actually check if its modifications to the database were successful And if it fails it will not implement its keyboard Keylogger logic because it won't work So this basically means because of these new security mitigations that Apple has allowed or implemented Even though the malware will still run the key logging will not be successful. So kudos to Apple for fixing that Okay, so to briefly summarize Apple's current protection against synthetic and UI bypasses for Apple script The application must have accessibility rights, which the user must explicitly grant in terms of core graphics Apple now detects and filters those and will ignore synthetic events unless the user puts in their username and password And then in terms of bypassing the UI altogether, they have protected the privacy database with system integrity protection Now there's one important thing to note is that these protections are not applied globally They are only applied specifically by Apple to certain security prompts So we'll see this leaves a window open for other attacks, but also it means third-party developers for example firewall and antivirus Developers they have to implement protections of their UIs individually So let's briefly look at how third-party developers can protect their UIs from synthetic events So I'm an author of a tool called block block as I mentioned block block basically tries to detect and prevent Persistence events. So for example when malware tries to install itself persistently Block block will detect that display alert to the user and basically ask the user to confirm or deny Clearly this alert could be a target for a synthetic attack, right? A malware installer could run detect that block block has detected and displayed an alert and then try to send a synthetic event to dismiss and allow the action So what I do to detect and prevent this is basically subclass the UI button and this allows me to analyze the events that are coming in for example the mouse event That is clicking the allow button What I can do then is I can examine the event and see who is sending it both the processes ID and UU ID So then I can ignore events for example that aren't coming from an Apple sign process or don't belong to the human interface Device daemon. So again if the malware now tries to send a synthetic click to click allow on the block block alert I will detect and ignore this Little snitch which is very popular Mac firewall product for macOS similarly ignores synthetic events in this video demo We're gonna see that I am basically trying to synthetically click on the allow button on the firewall alert Obviously, this is something that malware would try to do to bypass the firewall if it was detected It's a little hard to see on the video But little snitch has detected this and displayed an error message saying simulated input ignored So we can reverse engineer their binary to see how they implement the detection and ignoring of synthetic events They take a similar approach to block block They subclass a UI component and they have a method called is simulated and again They monitor for certain events for example mouse clicks and what they do is they get the source state of that click Now the source state will be set to one if it is a non simulated event So they check that and they also check the pit of the process to identify who is trying to send the event interestingly they also have exceptions for Apple's screen sharing and VNC servers because those events may come in and appear to be simulated because they're coming in over the Network, but little snitch probably wants to allow those Okay, so that wraps up the attack and defenses Apple was happy thinking that they were safe But as we'll see in reality, they were not so now let's look at an attack I discovered that allowed me to interact synthetically with any OS component and do all sorts of nefarious things So my goal is simple I basically just wanted to be able to Synthetically or programmatically interact with these alerts and do things as a normal user like dump the keychain or approve the loading of a kernel extension So I started poking around on Mac OS and after a few minutes I found a feature of the operating system called mouse keys now It's a documented feature is Apple documentation and basically as their documentation says it allows you to use the keyboard as the mouse So they provide a lot of information including keyboard to mouse button mappings So for example, if you want to click if you press the key I or the letter number five on the keyboard If mouse keys are enabled this will be translated to a mouse click So of course, I wondered could these allow me to generate synthetic keyboard events that would then be translated to synthetic mouse events Which would then be allowed So first though we need to programmatically enable mouse keys and we can do this in three steps We first launch the system preferences app We then open the accessibility pane which is different from the Accessibility rights pane which is protected and then we send a synthetic click to enable mouse keys Turns out that this is all doable via Apple script and core graphic foundation APIs Apple doesn't consider these interactions of Sensitive enough so they don't filter or block any synthetic actions So here's a video of this in action. We basically going to open the system preferences Application we're going to go to the mouse settings and then we're going to click enable mouse keys So again a few lines of code. We basically now enabled mouse keys Really not that exciting But now we can see if we can use these mouse keys to generate synthetic mouse events so as I mentioned the Number five on the number pad when mouse keys are enabled will generate a mouse click So the key code for this is 87. So now we have mouse keys enabled I utilized some Apple script and I basically sent this key code 87 to UI prompt and we can see that if we run our mouse and keyboard sniffer that Yes, the synthetic key down and up event are captured But then the system since mouse keys are enabled will translate those to mouse events And since those are translated by the system when they are delivered, they will be allowed So now we have a way to generically generate synthetic events that Apple will allow again It's not some crazy bog, but I'm a huge fan of Utilizing legitimate functionality of the operating system to do nefarious things So let's use this to do some evil stuff first. Let's dump the keychain So step one is we try to execute something like the security utility to start dumping the keychain So I mentioned this will open or display an accessibility prompt that Apple Requires or expects only the user to interact with However, since we have the ability to do this we can simply enable mouse keys and then send a click that will be allowed Which will then allow us to dump the keychain So I wrote a little proof of concept for this it does three things enables mouse keys Dumps the keychain and then clicks allow on the accessibility prompt and this gives us full access to all the users passwords Private keys etc. Again fully unencrypted Next let's use mouse keys to bypass high Sierra's user-approved kernel extension loading again a few easy steps We enable mouse keys. We load the kernel extension Which will be blocked until the user or in our case our attack code clicks allow So once this button is displayed we simply again enable mouse keys and send this click And this will basically be processed by the operating system and allow the kernel extension to load As I often find is the case bypassing these Apple security mitigations is really not that complicated So here's a video of this in action We're basically going to load that signed little snitch kernel extension that has that exploitable vulnerability in that again This will be blocked by the system because it will want the user to manually approve that in code though What we will do is enable mouse keys and then browse to the prompt that has the allow button And then send a synthetic event to click that So that's the full attack and if we do a kext stat We can now see that the system has allowed the kernel extension to load We can now exploit the vulnerability in this signed kernel extension to do things like bypass system integrity protection and get unsigned code running in the kernel Now I'm sure some of you have already thought like okay these these attacks are kind of neat But there's a huge downside to them and that is that they are visible So if you're sitting at your computer and all of a sudden an alert pops up the mouse moves and something gets clicked You will surely know that your computer is hacked like throw it out the window, right? So as an attacker our question becomes how can we do this? Invisibly and it turns out that's pretty easy. We can basically just dim the screen Really not rocket science. So when those special privileges anybody including malware can dim the screen And here's the code to do that Basically you make a few calls into IO kit and you basically pass a brightness level which will reduce the screen to zero Now the key here is that the screen when dim to zero is still fully interactive That is to say we can still fully interact with the UI for example to load the system preferences Enable mouse keys and click on buttons, but of course the user won't see it Now we still have an issue again if you're sitting in front of your computer, you know on Instagram Facebook or you know Writing code via stack overflow and all of a sudden your screen dims again. That's going to be super odd So what we should do is be a little more sophisticated about this So the first thing we can do is we can detect user activity and simply wait until the user is not active So there's a nice API you can call that will give you the number of seconds of the last user activity So we can just query this API in a loop and basically say okay Let's wait until the user has been inactive for 60 seconds and then dim the screen and perform our synthetic attacks For example loading the kernel extension or bypassing the firewall Now even better though we can simply wait until the screen is going to sleep on its own So when a screen sleep action occurs there are two steps So the operating system first sends a can device power off message and dims the screen to 50% Then waits about three seconds before fully dimming the screen to zero and then turning off the display So what we can do as malware is we can detect this initial message and when the screen start screen starts to dim to 50% We can expedite that dim it to a hundred percent and then perform our action before the screen is fully put to sleep So we had a very stealthy way to perform these attacks that the user will not notice All right, so let's start right wrapping this up. I Reported this mouse key vulnerability or bypass to Apple they buy patch they patched it as CVE 2017 715 0 and they're patched did two things first any time the key chain is accessed even by the user This will now require a password, which I think is a good idea Apple also decided to filter mouse keys and now block them for example when you send them to a UI prompt Unfortunately issues still exist even today on the latest fully patched versions of high Sierra First the privacy alerts appear to remain unprotected, which is very strange So as I mentioned when malware for example tries to access your contacts your events or your Location via the location API's this will display a privacy alert However, these alerts are not protected so you can send any synthetic event to that and just click allow my opinion This is rather problematic. What's the point of displaying an alert if you're not going to protect it? Okay, this is even worse, and I'm almost embarrassed to talk about this, but I'm actually more embarrassed for Apple So there's a zero-day vulnerability or flaw in the way they process or filter synthetic events So let's take for example the allow button that has to be clicked in order for assigned kernel extension load So I said okay I want to test how Apple has implemented this protection as I mentioned you have to send two events for a synthetic event You send a mouse key down and then a mouse key up So the way you do this is you invoke the same API, but the last parameter to that is a flag You set it to true if it's a mouse down event And then you set it to false if it's a mouse up event which will complete the action So I wrote the first line of code and then I was lazy and I copied and pasted the second line And I forgot to change the flag I then compiled and ran this code, and I was really surprised when this was allowed So it turns out that if you send two mouse down events for some unknown reason The second mouse down event is translated to a mouse up event by the kernel and since the filtration process Allows mouse up events from the kernel this action is allowed This means that since its inception the fundamental secure kernel loading extension Security mechanism that Apple you know talked all about has been completely broken Now people including myself sometimes talk smack about Apple security mechanisms, but examples like this. I think really Proved that in a variety of cases. It's really trivial to bypass that So, you know, I'm kind of embarrassed as I meant To discuss this bug because it's so trivial and I found it completely by accident But again, it's very powerful allows you to generate synthetic events even on a fully patched system For example to load kernel extensions, which in my opinion is rather a big problem All right, so a final word about synthetic events Hopefully we've illustrated that they are actually a very powerful capability Especially when performed invisibly we can do all sorts of actions bypass a whole bunch of security mechanisms and again in a kind of tool or Security agnostic manner Now as often as you know as off as is often the case with these These attacks. It's really a cat and mouse game So attackers come up with new ways like mouse keys Apple releases new patches Unfortunately, Apple kind of has been struggling good news though in Mojave. They've kind of taken this more drastic approach and said Okay, we're just going to generically block and disallow a ton of these actions For example, they block Apple script and core graphic APIs This is good from a security point of view, but this will block a lot of legitimate applications Now I've been told in feedback that some of my talks are a little negative You know, it's like Patrick you always talk about breaking everything and how Apple keeps messing everything up And yeah, okay, that's a little negative. So I wanted to enter. I wanted to Finish with something that's hopefully a little more positive. So I'm excited to announce a new Mac security conference called objective by the sea We have awesome lineup of Mac security speakers. All the talks will be focused about Mac security It's going to be in an awesome resort in Hawaii Here's some pictures in case you weren't convinced that you should come and it will be November 3rd and 4th And check out objective by the sea comm for information. So that's a wrap I want to thank you again for coming bright and early on this Sunday And I think we're pretty much out of time, but I will be by the stage if you have any questions So thanks again. I really appreciate it