On Monday (August 27, 2018) a Local Privilege Escalation (LPE) 0-day was released which reportedly affects Windows 10 and Server 2016, at a minimum. We investigated this to understand the vulnerability, the current Proof of Concept (PoC) exploit, and wanted to write it up in terms which explain the actual risk to organizations.
The main things to know are this:
- This is an LPE, which means
- It needs to be chained with other attacks to be meaningful
- It makes a bad situation (server/end user compromise) much worse
- It allows an unprivileged user to gain SYSTEM level access
- The attacker needs to start with code execution in a Medium integrity process
- In practical terms, it means unlocking the ability to potentially dump password hashes with tools like mimikatz, modify boot settings, gain additional persistence such as installing rootkits, and so forth
- The current PoC is just an example, as is typical with PoCs
- Does not demonstrate the full capabilities, just one exploitation option
- Being able to detect the PoC does not mean you can detect other attacks
- The PoC is limited to 64-bit versions of Win 10/Server 2016; there is no indication that the vulnerability is also limited in this way
Next we will go over the vulnerability, how the PoC is exploiting it, and ways to detect this. Finally, we’ll explain why this should not be a big deal when looking at the big picture, and what strategic steps organizations should have taken or can take in order to mitigate the damage.
The Vulnerability
The actual vulnerability is a logic error, and honestly, it was a fantastic find by @SandboxEscaper. She also has a very good write-up of the technical details included in the .rar file which contains the exploit. Rather than repeat that here, I’ll just summarize: There’s a task scheduler service which has an Advanced Local Procedure Call (ALPC) endpoint which will change the permissions (DACL) of C:\windows\tasks\UpdateTask.job to whatever the caller specifies. This file does not exist by default, which would mean that the user would have to create it. It’s also important to note that this API is only available from Medium integrity processes or higher. It is not available from Low or Untrusted processes, which means this can not be used to break out of a sandbox or Job group which enforces those process integrity levels.
This doesn’t seem so bad on the surface, at least on a single-user system, since the user already had the ability to change the DACL of their own file. The problem is that this file can be a hard link to any other file, and the service does not check to see if the caller owns or has permission to modify the Access Control Lists of the file before changing its permissions. This means, if the user can make a hard link to a file, and the SYSTEM user is able to update the DACL to that file, the user can change its permissions. SandboxEscaper was nice enough to help people determine what files you can take control over with a small powershell script (enumerate.ps1).
This seems undesirable, but the questions remains: how does one use this to elevate privileges? Once you find the file you want, and change the permissions, you can just replace that file with one of your choosing by giving yourself Write access to the file. If someone else runs a program which loads a DLL that you replaced, your code can be executed with their privilege level. It doesn’t have to be a DLL, it could be any file. If it’s a multi-user system, maybe the goal isn’t even to gain execution: it could be to read or modify files that you shouldn’t have access to. There are a wide range of possibilities that this unlocks.
There are a number of options on how this could be exploited to gain elevated privileges. Using the list of files from enumerate.ps1, interesting targets can be found in program files, which may be run by other users – potentially even administrators. However, what would be really great would be to overwrite code which will be used by a system driver, which is exactly what the PoC does.
The PoC Exploit
The punchline of the proof of concept is that printconfig.dll is overwritten and then the print spool service is called, which causes the service to load that DLL which is what gains the attacker code execution as the SYSTEM user.
There are some practical issues when trying to exploit this vulnerability, which is typical. It used to be that SYSTEM could write to pretty much everything, but now there are a lot of critical files which can only be modified by trusted installer, not SYSTEM. In addition to the aforementioned requirements for the user to have read access and SYSTEM to have write access, the file must not be in use, as Windows does not allow overwriting a file which is in use. This is not a security mechanism, just an old design decision from decades past. Still, it means the attacker needs to find a file which is not currently in use but will be loaded by a privileged process later, on top of all the requirements already described. These are exactly the types of technical details which make exploitation tricky sometimes, and are often overlooked by those who stop after finding the bug and do not go through with writing a real exploit. SandboxEscaper identified all of this in her write up.
The PoC exploit simply launches a command prompt and runs notepad. Using tools like process explorer, it’s clear that it is running as SYSTEM and was spawned by the print spool service.
Detection
If you are an endpoint protection company, you should be monitoring for anomalies like DLLs under C:\Windows being overwritten by anything other than the processes used in windows updates.
End users are really at the mercy of their endpoint protection vendors. Setting up a tripwire-like defense which monitors all important files for changes and notifies an administrator when they do isn’t reasonable because the attacker can just replace a DLL, gain execution, then restore the original in a matter of seconds. Odds of the check to see if the file was tampered with running between replacement and restoration are negligible. Catching this comes back to hooking into Operating System level APIs to run these sorts of checks when a file is opened, or modified which is effectively how many antivirus and endpoint protection solutions work. Kernel-level hooks have greater success, but are still subject to gaps in file watchlisting.
However, just because the initial detection is very difficult, it doesn’t mean that defenders are completely out of luck. The attacker is probably going to install some payload which does a lot more than just launch notepad. If their payload uses the network, there are many options ranging from traffic flow, DNS requests, periodic beacons to C2 servers, detecting enumeration such as internal port scanning or scanning for network shares, and so on. This isn’t actually detecting exploitation, it’s detecting the payload which is run afterwards, so how effective each tactic is will be dependent on the specifics of the payload. For payloads which are only intended to disrupt, they may not use the network at all. Depending on the computer, they could go out of band. For example, if it’s a laptop, and the attacker is physically close to the computer, they could use bluetooth, or configure the wifi card to act as an Access Point and have the attacker connect to it directly. With SYSTEM access, it’s likely possible to disable any endpoint detection which would pick up these types of activities.
Mitigation
The good news is that organizations should already be prepared for these attacks. While this specific vulnerability is new, the idea that an attacker may be able to elevate privileges is not. Just like there’s typically an assumption that some computer will get infected at some point, likely because someone downloaded and ran untrusted code (phishing being the most common entry point), there should also be an assumption that they might be able to take over one computer.
It’s important to have the boots on the ground detecting, containing, and cleaning up infections like this when they occur, but the real solution is to design systems and workflows to accommodate the possibility of infection and an LPE. Following the principles of segregation and least privilege have proven to be effective ways at mitigating the damage of incidents, which history has shown seem to be inevitable for any sizable organization.
A quick, concrete example is a hiring manager who needs to read resumes from complete strangers. This is their job. Saying “don’t open email attachments” is not an option. It’s the security team’s job to enable people to get things like this done in a safe manner. One option would be to give this person a VM they can use to open attachments, and provide a reasonable workflow for getting the attachments into the VM. QubesOS makes this easy by launching a disposable VM for every email attachment automatically, but there are other solutions which may be more appropriate for your environment.
In addition, organizations should implement defense in depth to protect as many layers of the space as possible. Since this vulnerability was identified specifically within the newest Microsoft operating systems, modern protections should be employed during development (such as Application Sandboxing) as well as during system deployment (such as Virtual Secure Mode enclaves and other Virtualization Based Security features like Credential Guard).
Response
If this is detected somehow, just follow your incident response plan. This is typically to quarantine the computer from the network to avoid anything from spreading or phoning home. Find the user/computer, and start the forensics process to determine when it was infected, what network resources were accessed, and so on. It’s important to remember that the information pulled off the computer can not be trusted and should be verified with other sources. For example, if it appears to be infected yesterday, and the first thing the payload did was access all shares, there should be an audit log on the file shares to corroborate the story being told by the infected computer.
Conclusion
This is a clever new attack, but it is not a new type of attack. It is just a concrete example of a risk that organizations should be able to handle based on their threat model and risk tolerance. The PoC can be used to test your defense products, and since the source was also released, it can be modified to determine how easy it is to bypass the detection.
If you want help with modifying the exploit to test your defenses, or advice on how to mitigate the damage of these types of threats, feel free to contact us.