The Mouse is Mightier than the Sword
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Wardle, Patrick
In today's digital world the mouse, not the pen is arguably mightier than the sword. Via a single click, countless security mechanisms may be completely bypassed. Run untrusted app? click ...allowed. Authorize keychain access? click ...allowed. Load 3rd-party kernel extension? click ...allowed. Authorize outgoing network connection? click ...allowed. Luckily security-conscious users will (hopefully) heed such warning dialogues—stopping malicious code in its tracks. But what if such clicks can be synthetically generated and interact with such prompts in a completely invisible way? Well, then everything pretty much goes to hell. Of course OS vendors such as Apple are keenly aware of this 'attack' vector, and thus strive to design their UI in a manner that is resistant against synthetic events. Unfortunately they failed. In this talk we'll discuss a vulnerability (CVE-2017-7150) found in all recent versions of macOS that allowed unprivileged code to interact with any UI component including 'protected' security dialogues. Armed with the bug, it was trivial to programmatically bypass Apple's touted 'User-Approved Kext' security feature, dump all passwords from the keychain, bypass 3rd-party security tools, and much more! And as Apple's patch was incomplete (surprise surprise) we'll drop an 0day that (still) allows unprivileged code to post synthetic events and bypass various security mechanisms on a fully patched macOS box! And while it may seem that such synthetic interactions with the UI will be visible to the user, we'll discuss an elegant way to ensure they happen completely invisibly!
 So this is one of the most highly coveted speaking slots first thing on Sunday morning at any hacker con 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 Digida 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 gonna start by looking at components or local security mechanisms of Mac OS that can be attacked via synthetic events We're then gonna 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 OS Synthetically for example to click on security prompts and then we're gonna 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 Atrogen 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 this 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 keylogger 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 geo location 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 macOS 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 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 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 context contents of a key chain 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 macOS 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 complex code, root privileges All you need to do is click this button with Apple script You can dump everything in the key chain 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.sh Kc obviously for keychain And if we look at the script we can see it executes two other scripts The first one kd.sh just invokes Apple's security utility to dump the keychain And again this will generate a keychain access prompt The second script kcd 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 a 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 APIs 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 key chain 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 Fruitfly was a rather prolific piece of Mac malware Where it 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 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 the 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 Fruitfly 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 number 16 was the malware 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 macOS So we can use JTool 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 macOS 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 attempts to install this malicious browser extension And then once the keychain access prompt is displayed It will detect the location of this popup, 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, 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 altogether 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 expel trait 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 the 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 OSX vulnerability was independently discovered and reported called rootpipe 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 rootpipe bug again as a zero-day to basically click the same file 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 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 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 exactly what was going on So if we run strings on one of the Dropbox binaries we can see some interesting strings We can see reference to something called TCC.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.DB file? Well if we run the file command on it we can see it's an SQL-like database And if we Google around we can see that it's Mac OS' 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 filemon 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.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 onto VirusTotal and just did a search for TCC.DB And there was 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 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 Coldroot So when it's run, Coldroot would execute something called runme.sh And we can dump this script and we can see that what it is doing is it's directly manipulating this TCC.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 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 altogether Now obviously this is not something that Apple is stoked about, right? They design 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 macOS, modern version, AppleScript is blocked from interacting with certain security prompts Specifically, if we now use AppleScript 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 synthetically So now, for example, if the piece of malware tries to dump the keychain and use AppleScript 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 how Apple is implementing this So if we execute some AppleScript 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.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 APIs So in short, on recent versions of Mac OS, Apple will now display a secondary secure authentication prompt requesting user credentials when it detects that something is generating synthetic events via the core graphics APIs 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 APIs 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 a synthetic event via the core graphic APIs So we can grab the file system 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 IOCIT 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 If it fails, it will not implement its 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 keylogging 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 In the 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 BlockBlock, as I mentioned BlockBlock basically tries to detect and prevent persistence events So for example, when malware tries to install itself persistently, BlockBlock 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 A malware installer could detect that BlockBlock 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 UUID 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 BlockBlock alert, I will detect and ignore this A little snitch, which is a very popular firewall product for macOS, similarly ignores synthetic events In this video demo, we're going to 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 BlockBlock, 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 1 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 was 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 macOS and after a few minutes I found a feature of the operating system called mouse keys Now it's a documented feature, it's 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 5 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 sensitive enough so they don't filter or block any synthetic actions So here's a video of this in action, we basically go 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 a 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 bug, 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 As 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 tag-clode 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, okay, 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 with no spressual 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 dimmed 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 starts to dim to 50%, we can expedite that, dim it to 100% And then perform our action before the screen is fully put to sleep So again, a very stealthy way to perform these attacks that the user will not notice Alright, so let's start wrapping this up I reported this mouse key vulnerability or bypass to Apple They patched it as CDE 2017 7150 And they're patched in two things First, anytime 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 APIs, 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 In 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 to 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 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 prove that in a variety of cases it's really trivial to bypass that So 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, it 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 Alright, 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 the case with 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 Yeah okay, that's a little negative, so 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.com 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.
 So this is one of the most highly coveted speaking slots first thing on Sunday morning at any hacker con  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 Digida 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 gonna start by looking at components or local security mechanisms of Mac OS that can be attacked via synthetic events  We're then gonna 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 OS  Synthetically for example to click on security prompts and then we're gonna 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  Atrogen 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 this 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 keylogger  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 geo location 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 macOS 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 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  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 context contents of a key chain 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 macOS  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 complex code, root privileges  All you need to do is click this button with Apple script  You can dump everything in the key chain  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.sh  Kc obviously for keychain  And if we look at the script we can see it executes two other scripts  The first one kd.sh just invokes Apple's security utility to dump the keychain  And again this will generate a keychain access prompt  The second script kcd 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 a 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 APIs 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 key chain 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 Fruitfly was a rather prolific piece of Mac malware  Where it 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 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 the 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 Fruitfly 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 number 16 was the malware 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 macOS  So we can use JTool 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 macOS 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 attempts to install this malicious browser extension  And then once the keychain access prompt is displayed  It will detect the location of this popup, 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, 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 altogether  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 expel trait 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 the 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 OSX vulnerability was independently discovered and reported called rootpipe  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 rootpipe bug again as a zero-day to basically click the same file  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 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 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 exactly what was going on  So if we run strings on one of the Dropbox binaries we can see some interesting strings  We can see reference to something called TCC.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.DB file? Well if we run the file command on it we can see it's an SQL-like database  And if we Google around we can see that it's Mac OS' 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 filemon 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.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 onto VirusTotal and just did a search for TCC.DB  And there was 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 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 Coldroot  So when it's run, Coldroot would execute something called runme.sh  And we can dump this script and we can see that what it is doing is it's directly manipulating this TCC.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  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 altogether  Now obviously this is not something that Apple is stoked about, right? They design 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 macOS, modern version, AppleScript is blocked from interacting with certain security prompts  Specifically, if we now use AppleScript 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 synthetically  So now, for example, if the piece of malware tries to dump the keychain and use AppleScript 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 how Apple is implementing this  So if we execute some AppleScript 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.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 APIs  So in short, on recent versions of Mac OS, Apple will now display a secondary secure authentication prompt requesting user credentials when it detects that something is generating synthetic events via the core graphics APIs  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 APIs  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 a synthetic event via the core graphic APIs  So we can grab the file system 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 IOCIT 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  If it fails, it will not implement its 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 keylogging 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  In the 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 BlockBlock, as I mentioned BlockBlock basically tries to detect and prevent persistence events  So for example, when malware tries to install itself persistently, BlockBlock 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  A malware installer could detect that BlockBlock 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 UUID  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 BlockBlock alert, I will detect and ignore this  A little snitch, which is a very popular firewall product for macOS, similarly ignores synthetic events  In this video demo, we're going to 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 BlockBlock, 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 1 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 was 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 macOS and after a few minutes I found a feature of the operating system called mouse keys  Now it's a documented feature, it's 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 5 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 sensitive enough so they don't filter or block any synthetic actions  So here's a video of this in action, we basically go 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 a 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 bug, 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  As 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 tag-clode 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, okay, 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 with no spressual 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 dimmed 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 starts to dim to 50%, we can expedite that, dim it to 100%  And then perform our action before the screen is fully put to sleep  So again, a very stealthy way to perform these attacks that the user will not notice  Alright, so let's start wrapping this up  I reported this mouse key vulnerability or bypass to Apple  They patched it as CDE 2017 7150  And they're patched in two things  First, anytime 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 APIs, 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  In 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 to 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 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 prove that in a variety of cases it's really trivial to bypass that  So 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, it 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  Alright, 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 the case with 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  Yeah okay, that's a little negative, so 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.com 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.
DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_0_59.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_60_527.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_528_575.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_576_623.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_624_671.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_672_719.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_720_779.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_780_827.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_828_1187.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_1188_2795.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_2796_3143.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_3144_5843.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_5844_6227.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_6228_6707.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_6708_7163.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_7164_8555.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_8556_9455.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_9456_9503.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_9504_10319.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_10320_12203.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_12204_14147.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_14148_14615.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_14616_15203.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_15204_16871.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_16872_18215.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_18216_19379.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_19380_21191.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_21192_21827.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_21828_22991.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_22992_24839.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_24840_25991.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_25992_27875.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_27876_28583.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_28584_30095.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_30096_31115.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_31116_32603.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_32604_33587.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_33588_34223.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_34224_35315.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_35316_36179.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_36180_36959.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_36960_37319.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_37320_38099.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_38100_39299.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_39300_40403.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_40404_41195.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_41196_41759.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_41760_43355.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_43356_44795.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_44796_46151.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_46152_48023.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_48024_48719.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_48720_49871.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_49872_50375.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_50376_50723.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_50724_51803.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_51804_52607.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_52608_52775.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_52776_52823.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_52824_52907.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_52908_52955.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_52956_53087.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_53088_54227.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_54228_54587.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_54588_55331.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_55332_55775.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_55776_56627.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_56628_57095.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_57096_57263.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_57264_57467.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_57468_57551.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_57552_57719.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_57720_58427.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_58428_59231.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_59232_60311.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_60312_61367.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_61368_61415.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_61416_62111.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_62112_62927.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_62928_65723.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_65724_66215.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_66216_66983.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_66984_67739.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_67740_67943.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_67944_68411.png DEF_CON_26_-_Patrick_Wardle_-_The_Mouse_is_Mightier_than_the_Sword_gLrB7enpbiw_68412_68471.png