WSUS enables IT administrators to deploy the latest Microsoft product updates. Updates are downloaded from Microsoft's update servers and stored locally on the WSUS server. From here, admins can approve the updates for deployment to their internal clients. Windows clients (desktops and servers) can check the local WSUS server for updates that have been approved and can download and install them from there. Clients report back to the WSUS server with the updates that they have installed and this allows the admin team to ensure that the necessary updates have been applied.
By default, clients will communicate with the WSUS server using insecure HTTP connections. In their presentation at Black Hat USA 2015, Paul Stone - Principal Consultant at Context and Alex Chapman showed this can allow an attacker to inject malicious updates, giving them complete control over the affected client.
An attack could be carried out in two ways; the first was via the network by performing a man-in-the-middle (MITM) attack against HTTP WSUS traffic. The second method was for a low-privileged user on a WSUS client machine to change the user proxy settings and re-route the WSUS traffic through a local malicious proxy.
Context also released a proof of concept tool, WSuspect-Proxy to show the exploitation of this issue.
At the time, Microsoft stated that organisations should enable HTTPS for WSUS to guard against this (full instructions are available on the Microsoft Tech Community website). In 2015, enabling HTTPS would prevent both the network MITM and local proxy attacks.
In May 2020, Microsoft were informed by researchers at GoSecure that the WSUS client service was now accepting certificates from the current user certificate store. This meant that the vulnerability originally highlighted in 2015 by Paul and Alex could be exploited locally by a low privileged user even if HTTPS was in use by WSUS. This issue is being tracked under CVE-2020-1014. With the September 2020 cumulative update, Microsoft are making changes to the way user proxies are handled by Windows Update to mitigate this issue.
There are two types of proxy that can be set on a Window host; a user proxy, which is set for just the current user, and a system proxy, which is set for the entire system. Users can set their own proxy settings using Internet Options within the Windows Control Panel. Administrators can also update this via Group Policy, but it is usually possible for a user to update their own proxy settings. The system proxy on the other hand, can only be set by an administrator either locally using an elevated command prompt, or via setting a registry key via Group Policy. Full details on setting the system proxy are available here on Microsoft's support website.
If the Windows Update service is set to use HTTP for server communications, Windows clients will no longer utilise the user proxy settings. Instead, it will only use the system proxy, if one is set. This means that if you rely on user proxies in your environment, and your WSUS server uses HTTP for communications, client computers will not be able to communicate with the WSUS server and will therefore no longer receive updates.
If your organisation is affected by this, there are three possible solutions, only the first of which is secure:
- Configure the WSUS server to use HTTPS. This is the only option that will prevent network-based attackers from installing malicious updates on WSUS clients.
- Configure the system proxy settings to allow WSUS clients to reach the server. However, if you keep using HTTP to fetch updates, your machines are vulnerable to compromise by an attacker with network access.
- If you must use a user proxy in your environment, there is a workaround from Microsoft. A new Group Policy setting has been added that will allow Windows Update to fall-back to using a user proxy.
It is important to be aware that if your Windows client machines are not using HTTPS to fetch WSUS updates, they are vulnerable to compromise by local (or possibly even Internet-based) attackers.
If your environment uses HTTP for WSUS communications and relies on a user proxy, your client computers will not be able to communicate with the WSUS server after installing the September 2020 cumulative update.
Microsoft highly recommends using HTTPS for all communications and using a system proxy on client computers if a proxy is required. Even if the September 2020 will not cause breaking changes for your organisation, we would recommend taking the opportunity to ensure all your WSUS deployments are configured to use HTTPS.