With the September 2020 cumulative update for Windows 10, we introduced changes that help improve the security of devices that scan Windows Server Update Services (WSUS) for their updates. This post will describe those changes, outline the actions you need to take to ensure your devices continue to scan for updates, and offer basic recommendations to help you better secure the devices in you organization.
Secure by default
First, beginning with the September 2020 cumulative update, HTTP-based intranet servers will be secure by default. To ensure that your devices remain inherently secure, we are no longer allowing HTTP-based intranet servers to leverage user proxy by default to detect updates. If you have a WSUS environment not secured with TLS protocol/HTTPS and a device requires a proxy in order to successfully connect to intranet WSUS Servers—and that proxy is only configured for users (not devices)—then your software update scans against WSUS will start to fail after your device successfully takes the September 2020 cumulative update.
Recommendations for greater security
To help ensure the security of your WSUS infrastructure, Microsoft recommends using the TLS/SSL protocol between your devices and your WSUS servers. The Microsoft Update system (including WSUS) relies on two types of content: update payloads and update metadata. Update payloads are the data files that contain the software update components that make up the update. Update metadata is all the information that the Microsoft Update system needs to know about the updates, including which updates are available, which devices each update can be applied to, and where to retrieve the payloads for each update. Both types of content are crucial and they both need to be protected to help keep your computers secure and up to date.
Update payloads are protected against modification by multiple means, including digital signature checks and cryptographic hash verifications. HTTPS provides a proper chain of custody which the client uses to prove the data is trusted.
When a device receives updates directly from Microsoft Update, that device receives update metadata directly from Microsoft servers. This metadata is always transmitted via HTTPS to prevent tampering. When you use WSUS or Configuration Manager to manage your organization's updates, the update metadata travels from Microsoft servers to your devices via a chain of connections. Each one of these connections needs to be protected against malicious attacks.
Your WSUS server connects with Windows Update servers and receives update metadata. This connection always uses HTTPS, and the HTTPS security features guard the metadata against tampering. If you have multiple WSUS servers arranged in a hierarchy, the downstream servers receive metadata from the upstream servers. Here, you have a choice: you can use HTTP or HTTPS for these metadata connections. Using HTTP; however, can be very dangerous as it breaks the chain of trust and can leave you vulnerable to attack. Using HTTPS enables the WSUS server to prove that it trusts the metadata it receives from the upstream WSUS server.
In order to maintain the chain of trust and prevent attacks on your client computers, you must ensure that all metadata connections within your organizations – the connections between upstream and downstream WSUS servers, and the connections between the WSUS servers and your client computers – are defended against attacks. To do so, we highly recommend that you configure your WSUS network to protect these connections using HTTPS. To learn more, see Michael Cureton’s post Security best practices for Windows Server Update Services (WSUS).
Even with HTTPS configured, it is still very important that you utilize a system-based proxy rather than a user-based proxy if a proxy is needed. When using a user-based proxy, a user, even one without elevated privileges, could intercept and manipulate the data being exchanged between the update client and the update server.
Recommendations for those who absolutely need user proxy
If you do need to leverage a user-based proxy to detect updates while using an HTTP-based intranet server, despite the vulnerabilities it presents, make sure to configure the proxy behavior to "Allow user proxy to be used as a fallback if detection using system proxy fails."
Group Policy path: Windows Components>Windows Update>Specify intranet Microsoft update service location
Configuration Service Provider path: Update/ SetProxyBehaviorForUpdateDetection
Next steps
If you are an IT administrator who currently manages an HTTP-configured WSUS environment and relies on user-based proxy for client scans, please consider taking one of the following actions as soon as possible. If none of these actions are taken your devices will stop successfully scanning for software updates after the September 2020 security update.
Options to ensure that devices in your environment can continue to successfully scan for updates:
Continue reading...
Secure by default
First, beginning with the September 2020 cumulative update, HTTP-based intranet servers will be secure by default. To ensure that your devices remain inherently secure, we are no longer allowing HTTP-based intranet servers to leverage user proxy by default to detect updates. If you have a WSUS environment not secured with TLS protocol/HTTPS and a device requires a proxy in order to successfully connect to intranet WSUS Servers—and that proxy is only configured for users (not devices)—then your software update scans against WSUS will start to fail after your device successfully takes the September 2020 cumulative update.
Recommendations for greater security
To help ensure the security of your WSUS infrastructure, Microsoft recommends using the TLS/SSL protocol between your devices and your WSUS servers. The Microsoft Update system (including WSUS) relies on two types of content: update payloads and update metadata. Update payloads are the data files that contain the software update components that make up the update. Update metadata is all the information that the Microsoft Update system needs to know about the updates, including which updates are available, which devices each update can be applied to, and where to retrieve the payloads for each update. Both types of content are crucial and they both need to be protected to help keep your computers secure and up to date.
Update payloads are protected against modification by multiple means, including digital signature checks and cryptographic hash verifications. HTTPS provides a proper chain of custody which the client uses to prove the data is trusted.
When a device receives updates directly from Microsoft Update, that device receives update metadata directly from Microsoft servers. This metadata is always transmitted via HTTPS to prevent tampering. When you use WSUS or Configuration Manager to manage your organization's updates, the update metadata travels from Microsoft servers to your devices via a chain of connections. Each one of these connections needs to be protected against malicious attacks.
Your WSUS server connects with Windows Update servers and receives update metadata. This connection always uses HTTPS, and the HTTPS security features guard the metadata against tampering. If you have multiple WSUS servers arranged in a hierarchy, the downstream servers receive metadata from the upstream servers. Here, you have a choice: you can use HTTP or HTTPS for these metadata connections. Using HTTP; however, can be very dangerous as it breaks the chain of trust and can leave you vulnerable to attack. Using HTTPS enables the WSUS server to prove that it trusts the metadata it receives from the upstream WSUS server.
In order to maintain the chain of trust and prevent attacks on your client computers, you must ensure that all metadata connections within your organizations – the connections between upstream and downstream WSUS servers, and the connections between the WSUS servers and your client computers – are defended against attacks. To do so, we highly recommend that you configure your WSUS network to protect these connections using HTTPS. To learn more, see Michael Cureton’s post Security best practices for Windows Server Update Services (WSUS).
Even with HTTPS configured, it is still very important that you utilize a system-based proxy rather than a user-based proxy if a proxy is needed. When using a user-based proxy, a user, even one without elevated privileges, could intercept and manipulate the data being exchanged between the update client and the update server.
Recommendations for those who absolutely need user proxy
If you do need to leverage a user-based proxy to detect updates while using an HTTP-based intranet server, despite the vulnerabilities it presents, make sure to configure the proxy behavior to "Allow user proxy to be used as a fallback if detection using system proxy fails."
Group Policy path: Windows Components>Windows Update>Specify intranet Microsoft update service location
Configuration Service Provider path: Update/ SetProxyBehaviorForUpdateDetection
Next steps
If you are an IT administrator who currently manages an HTTP-configured WSUS environment and relies on user-based proxy for client scans, please consider taking one of the following actions as soon as possible. If none of these actions are taken your devices will stop successfully scanning for software updates after the September 2020 security update.
Options to ensure that devices in your environment can continue to successfully scan for updates:
- Secure your WSUS environment with TLS/SSL protocol (configure servers with HTTPS).
- Set up system-based proxy for detecting updates if needed.
Continue reading...
