Search the Community

IOHIDeous A macOS kernel exploit based on an IOHIDFamily 0day. Write-up here. Notice The prefetch timing attack I'm using for hid for some reason doesn't work on High Sierra 10.13.2 anymore, and I don't feel like investigating that. Maybe patched, maybe just the consequence of a random change, I neither know nor care. The vuln is still there and my code does both info leak and kernel r/w, just not in the same binary - reason is explained in the write-up. If you want that feature, consider it an exercise for the reader. Usage The exploit consists of three parts: poc panics the kernel to demonstrate the present of a memory corruption, should work on all macOS versions. leak leaks the kernel slide, could be adapted to other versions but as-is works only on High Sierra. hid achieves full kernel r/w, tested only on Sierra and High Sierra (up to & including 10.13.1), might work on earlier versions too. poc and leak need to be run as the user that is currently logged in via the GUI, and they log you out in order to perform the exploit. hid on the other hand, gives you four options for a first argument: steal requires to be run as root and SIP to be disabled, but leaves you logged in the entire time. kill requires root and forces a dirty logout by killing WindowServer. logout if executed as root or the currently logged in user, logs you out via launchctl. Otherwise tries to log you out via AppleScript, and then falls back to wait. wait simply waits for a logout, shutdown or reboot to occur. Additionally you can specify a second argument persist. If given, hid will permanently disable SIP and AMFI, and install a root shell in /System/pwned. leak and hid should be run either via SSH or from a screen session, if you wish to observe their output. Building Should all be self-explanatory: make all make poc make leak make hid make clean Download: IOHIDeous-master.zip git clone https://github.com/Siguza/IOHIDeous.git Source: https://github.com/Siguza/IOHIDeous/

As you may have noticed, it has been quite still here for a while. This was related to the preparations for this release: A post disclosing a new type of vulnerability, affecting multiple Anti-Virus solutions. To summaries: Today, I’m disclosing an issue, that can be exploited by any local user to gain full control over the endpoint by abusing the restore from quarantine Anti-Virus feature. And because every new vulnerability needs its own name and logo, I want to introduce you to #AVGater: The Basics But let’s get back on track, by discussing a few Anti-Virus basics. The following diagram shows the inner workings of a typical AV from an unprivileged user’s point of view. There are three different access domains: The kernel mode, the privileged user mode (SYSTEM) and the unprivileged user mode. As shown in the following image, the different components have widely different duties: Within the context of the unprivileged user there is only the AV user interface. By itself, it has no real power, because its executing within a limited user session. However, by talking to the AV Windows service it can do many things a normal user would not be able too. For example it may be allowed to restore files from the virus quarantine (This could be a hint – Couldn’t it?). Additionally there is kernel component. Most likely it’s doing the real work of checking objects for known threat identifiers. The Idea So what’s the real point here? Well, if a non-privileged user would be able to manipulate any of the communication channels that cross security boundaries (unprivileged user mode to privileged user mode or privileged user mode to kernel mode) he could escalate his privileges. But how to do that? In the case of #AVGater, the answer to this question is: By manipulating the restore process from the virus quarantine: As shown in the above video, #AVGater can be used to restore a previously quarantined file to any arbitrary filesystem location. This is possible because the restore process is most often carried out by the privileged AV Windows user mode service. Hence, file system ACLs can be circumvented (as they don’t really count for the SYSTEM user). This type of issue is called a privileged file write vulnerability and can be used to place a malicious DLL anywhere on the system. The goal is to side load this library for a legitimate Windows servers by abusing the DLL Search Order: If this succeeds, arbitrary code can be executed with the help of the DLLMain entry point. But there is still one very important question still unanswered: How is it possible to tamper with the restore process? The solution are NTFS directory junctions. They are basically symbolic links for directories that can be created by anyone with the help of mklink. #AVGater in plain english: By abusing NTFS directory junctions, the AV quarantine restore process can be manipulated, so that previously quarantined files can be written to arbitrary file system locations. Puttin it all together With all this knowledge, we can now paint a complete attack scenario: First a malicious library is moved to the AV quarantine. Then, by abusing directory junctions the original source path is redirected to another destination. Most likely a folder within C:\Program Files or C:\Windows. By restoring the previously quarantined file, the SYSTEM permissions of the AV Windows user mode service are misused, and the malicious library is placed in a folder where the currently signed in user is unable to write to under normal conditions. Because of how the DLL search order works, it is finally loaded by another privileged Windows process. Thereby the code within the DLLMain of the malicious library is executed. Hence, a local non-admin attacker gained full control over the affected endpoint. Here’s a diagram illustrating the whole process: During the preparation for this public disclosure, several different product have been checked for #AVGater. The following vendors have already released their fix. However, there are a few more to come! Who is/was affected? If anyone finds additional vulnerable products, please contact me. I will report them and update this list as soon as they fixed the issue. Getting our hands dirty If you want to know more about how to exploit #AVGator in a real life scenario, I have a good news for you: I already fully documented two exploit vectors: Local Privilege Escalation in Emsisoft Anti-Malware by abusing NTFS Directory Junctions #AVGater Local Privilege Escalation in Malwarebytes 3 by abusing NTFS Directory Junctions #AVGater Additionally, here are the slides of my talk “When your anti virus turns against you” from the IT SECX conference. How to protect myself? Generally, it’s pretty simple: Always install updates in a timely manner. However, as some vendors still need a few more days to release their fix, it may take a little till everyone is protected. Furthermore, as #AVGator can only be exploited if the user is allowed to restore previously quarantined file, I recommend everyone within a corporate environment to block normal users from restoring identified threats. This is wise in any way. Source