After having revived the classic 2015 WSUS attack in part 1 of the series by creating a tool, PyWSUS, that works on Windows 10, we started to wonder if the module could be used for other purposes.
We often see deployments using WSUS where users can set the local proxy for their session.
After having revived the classic 2015 WSUS attack in part 1 of the series by creating a tool, PyWSUS, that works on Windows 10, we started to wonder if the module could be used for other purposes.
We often see deployments using WSUS where users can set the local proxy for their session. If the WSUSpect-proxy module is nothing more than a MITM proxy that modifies some parts of the traffic and we also have the power to proxy our local traffic, we therefore have the power to run WSUSpect-proxy locally to run code as System on our asset.
CVE-2020-1013 Impact
Windows 10 all versions, Windows 7 SP1, Windows 8.1, Windows Server 2008, Windows Server 2012, Windows Server 2016, Windows Server 2019 and Windows Server 1903/1909/2004, when configured to use a HTTP or HTTPS WSUS server is vulnerable to a local privilege escalation from a low privilege account to “NT AUTHORITY\SYSTEM”.
Microsoft tracks which update fixes the problem in this security update guide. Apply based on your Windows version. For example, the latest Windows 10 is tracked by KB4571756 and Windows 10 1709 is fixed by KB4577041. Note that the CVE’s description is wrong but the acknowledgment is for the bug we disclosed. It will likely get fixed with time.
Technical Analysis
While trying to debug the Windows 10 version of WSUSpect-proxy, we noticed that we could simply set Internet Explorer’s proxy to forward the Windows Update traffic through a host that we control. After we had successfully ported the WSUSpect-proxy module to work with Windows 10 machines, we started to wonder if this behavior could be used for other purposes such as local privilege escalation.
In 2016, Steve Breen documented a vulnerability named “Hot Potato”. In short, this vulnerability allows an attacker to abuse Windows system services to conduct an HTTP to SMB relay and escalate privileges. This can be done because the target services, even if they are running as the “NT AUTHORITY\SYSTEM” account, are using the current user’s proxy settings and not the system’s proxy settings.
If you look at the article on this vulnerability, you will see the following statement:
In the newest versions of Windows, it appears that Windows Update may no longer respect the proxy settings set in “Internet Options”, or check for WPAD. Instead proxy settings for Windows Update are controlled using “netsh winhttp proxy…”
This exact statement combined with documentation from Microsoft on WSUS and variability between the behavior of different Windows versions caused many debates during our WSUS research since it clashed with our observations.
If we have the power to modify our local user proxy, and Windows Updates uses the proxy configured in Internet Explorer’s settings, we therefore have the power to run PyWSUS locally to intercept our own traffic and run code as an elevated user on our asset.
Furthermore, since the WSUS service uses the current user’s settings, it will also use its certificate store. If we generate a self-signed certificate for the WSUS hostname and add this certificate into the current user’s certificate store, we will be able to intercept both HTTP and HTTPS WSUS traffic. WSUS uses no HSTS-like mechanisms to implement a trust-on-first-use type validation on the certificate. If the certificate presented is trusted by the user and has the correct hostname, it will be accepted by the service.
This vulnerability was reported to Microsoft in May and was assigned CVE-2020-1013. We developed a tool to automate the exploitation of this vulnerability which we introduce in the next section.
Introducing WSuspicious
WSuspicious is a C# program that takes the place of the user local proxy and forces the computer to look for updates while intercepting the WSUS traffic to inject a malicious payload. As previously stated, this allows a low privilege user to run code as “NT AUTHORITY\System” on the machine.
This tool was tested on Windows 10 machines (1809 and 1909). To work, the module will require a specific set of conditions: the user has the ability to set his local HTTP and/or HTTPS proxy and the user has the ability to execute programs that listen on a TCP port.
According to @msftsecresponse‘s policy, we will wait 30 days before releasing the tool. Be aware that the vulnerability is pretty self-explanatory and therefore this delay should not encourage you to postpone patching the issue
Demo
Once the tool was completed, we tested various environments and payloads in our lab. The simplest one is illustrated bellow. Our low privileges user is using the WSuspicious module with PsExec to start the net localgroup Administrators {username} /add command to elevate his privileges.
Payload Choices and OpSec Considerations
As of right now, a few types of payloads are known to work with the WSUS service. For licensing reasons, the binaries triggered by WSuspicious are not embedded into the tools and must be provided by the users. However, it is not impossible to change the code and bundle the executable directly inside the binary to run the whole thing from memory. Do keep in mind that this could represent a breach of the Sysinternals’ license and is therefore not recommended.
Exec
PsExec is a Sysinternals binary that allows, amongst other things, to execute commands on a remote machine. It is a powerful tool but is often detected when executed in an environment where it is not commonly used by the IT management team.
Using PsExec with WSuspicious can be done like so:
WSuspicious.exe /exe:"./PsExec64.exe" /command:" -accepteula -s -d cmd /c "echo 1 > C:\\wsuspicious.txt" /autoinstall
Detection teams wanting to catch this type of payload should concentrate on the events generated by the tool’s behavior. The tool will connect to a local network share to upload the service binary (windows event 5140 and sysmon event 11), create a new service on the machine that points to the binary that was just uploaded (windows event 4697), and start the service which will, in turn, launch the uploaded binary (windows event 4688 or sysmon event 1)
Keep in mind that the service and binary names can be changed using certain flags. Therefore, flagging the PSExecSVC service name is not an efficient way of catching this payload.
Detecting the creation of the HKEY_USERS\{SID}\SOFTWARE\Sysinternals\PsExec\EulaAccepted registry key could also be useful to to detect this tool if it is not commonly used in day-to-day operations.
BgInfo
BgInfo is another Sysinternal binary that can be used with WSuspicious. This binary allows to run a Visual Basic Script (VBS) displaying information on the machine’s wallpaper. However, the content of the VBS file can be used to execute malicious commands.
Using BgInfo with WSuspicious can be done like so:
WSuspicious.exe /exe:"./BgInfo.exe" /command:" C:\Users\lowpriv\config.bgi /nolicprompt /timer:0" /autoinstall
If BgInfo is not used within the company, simply monitor BgInfo launches (windows event 4688 or sysmon event 1). If BgInfo is used by some assets, ensure that the file launched by BgInfo cannot be edited by low privileges users and monitor launches of BgInfo with unexpected files.
Time Travel Tracer (tttracer)
During our research, we tried to find more binaries that could work with WSuspicious. What we noticed is that the binary had to meet multiple conditions. First, the binary must be signed by Microsoft. Secondly, it has to run by itself without any interruptions. If it asks for some user interaction, the process will hang, and the windows update will stop functioning. Also keep in mind that, if dll’s are required for the program to run, it is more likely to fail.
Knowing this, we made a list of multiple binaries from the C:\Windows\System32 folder and tried some of them. Most of what we tried gave little to no results.
However, the tttracer binary seemed to be promising since the Windows Updates service would allow the program to be installed. After the payload had triggered, the Windows Updates service would simply hang in the “Installing” state.
Some debugging with WMI allowed us to see that the program was launched by the Windows Updates service with our specified payload.
C:\WINDOWS\system32>wmic process where name="tttracer.exe" get name,commandLine
CommandLine
Name
"C:\WINDOWS\SoftwareDistribution\Download\Install\tttracer.exe" cmd.exe /c "systeminfo" tttracer.exe
When we tried to run the tttracer binary from the Windows Update folder, we were prompted to accept the End User licence Agreement. The program simply stops its execution until they are accepted, therefore stalling the Windows Updates service. When the EULA is accepted by the user, the program will set a registry key to avoid re-prompting the user in the future and start the execution of the payload.
C:\WINDOWS\system32>C:\WINDOWS\SoftwareDistribution\Download\Install\tttracer.exe
We have created EULA.TXT in the current folder.
Please review this file before agreeing.
Have you read and do you accept the EULA? Y/N
Our current conclusion is that this payload can be used on a machine where the HKLM:\SOFTWARE\Microsoft\TTD\EULASigned registry key is set to bypass some detection use cases. While this requires specific conditions to be abused and is therefore less useful to attackers than the PsExec or BGInfo payloads, it does show that other less documented payloads can be used to avoid detection.
Further research should be conducted to see if there is a way to accept the EULA dynamically therefore allowing this payload to work in any condition.
Mitigation
Even though this vulnerability did impact HTTPS deployments and was corrected by Microsoft, we still recommend configuring WSUS to use the HTTPS protocol as the network-based vulnerabilities remain.
An additional protection measure could be to use the Windows Components > Internet Explorer > Disable changing proxy settings GPO to prevent users from setting their local proxy.
Timeline
- May 06th, 2020 – The vulnerability was reported to Microsoft on the MSRC portal.
- May 06th, 2020 – A ticket was assigned to the vulnerability
- June 15th, 2020 – The vulnerability was confirmed. A patch date was communicated with the testing team.
- June 26th, 2020 – A US$20,000.00 bounty was awarded under the Windows Insider Preview Bounty Program
- September 8th, 2020 – The patch for this vulnerability was released by Microsoft
Various detection capabilities for this threat have been implemented for GoSecure Managed Detection and Response (MDR) clients. Examples include signatures to detect suspicious WSUS network traffic (for clients with Network Detection and Response) and irregular use of signed Windows binaries such as PsExec (for clients with Endpoint Detection and Response).
Conclusion
Microsoft’s response was overwhelmingly positive and the disclosure process and platform they have put in place could be used as an example by many vulnerability disclosures programs. The mitigation of this vulnerability is a step in the right way to getting rid of HTTP-based WSUS and therefore eliminating the risks associated with it. Our next blog post will explore combining WSUS with other protocols to achieve new types of attacks. Stay tuned!
This blog post series’ content and more is going to be featured in a presentation titled “On the Shoulder of Giants: Reviving WSUS Attacks” at our GoSec virtual event in a couple of weeks. Make sure to attend!
Special thanks to Mathieu Novis, Julien Pineault, Romain Carnus, Olivier Bilodeau, and Laurent Desaulniers for their work on WSUS and their help with WSUSpicious, the blog, and the disclosure process.
