Search/ GitHub
PW-038HygieneGroup Policy and SYSVOL

Tier Zero computers take updates from WSUS over HTTP

Group Policy points Tier Zero computers at a WSUS server over plain HTTP, so anyone on the network path can hand them an update of their own.

Category
Hygiene
Severity
High.
Typical owner
Windows server team, with the AD team
Data needed
The GPOs' policy files in SYSVOL, which only the built-in collector* reads, or the Tier Zero settings files from each server. With SharpHound data the rule doesn't run, and that is not a clean result.
MITRE ATT&CKT1557T1072
Most useful toDefensive engineersIdentity and access engineersOffensive operators
On this page

In plain language

Windows Update can take its updates from an in-house WSUS server. When Group Policy gives that server as an http:// address, nothing proves the answer to an update check really comes from it.

Anyone who can sit on the network path can answer instead, with an "update" that Windows installs as SYSTEM, as long as Microsoft signed it, and common admin tools are. On a domain controller that is the whole domain. The fix is to serve WSUS over HTTPS and change the address in the policy.

What Pathwarden flags

A GPO that applies to domain controllers, CA servers or other Tier Zero computers points Windows Update at a WSUS server with an http:// URL (Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location). The computers then check for updates, and download them, over plain HTTP.

Pathwarden reads the setting from the GPOs' Machine\Registry.pol files in SYSVOL (the values WUServer and UseWUServer under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate), and works out which GPO wins on each computer from the GPO links above it. Only Pathwarden's built-in collector reads these files: with SharpHound data this rule can't run, and that is not a clean result.

How attackers use it

Over HTTP nothing proves that the answer to an update check comes from the WSUS server. Anyone who can sit on the network path (ARP or DHCP spoofing, a rogue WPAD proxy, a compromised switch) can answer with an "update" of their own. Windows Update runs it as SYSTEM, as long as it is signed by Microsoft, and tools such as PsExec are (WSUSpect, pywsus, SharpWSUS). On a domain controller that is the whole domain.

Find it with Pathwarden

Data needed: The GPOs' policy files in SYSVOL, which only the built-in collector* reads, or the Tier Zero settings files from each server. With SharpHound data the rule doesn't run, and that is not a clean result.

In the web UI or the HTML report, open the Findings tab and expand PW-038: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-038
# the step-by-step guide on this page, offline
pathwarden guide PW-038
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-038

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

  • The finding is inferred: a WMI filter or security filtering may keep the GPO off some of the computers it lists. Check with gpresult /r on one.
  • Switching to HTTPS needs a certificate on the WSUS server that the clients trust, with the server's name as the URL spells it.
  • Every client of the GPO changes at once, not only the Tier Zero ones.

How to fix it

Option A: WSUS over TLS

  1. Request a certificate for the WSUS server's name and bind it to the WSUS Administration site in IIS (port 8531).
  2. Require SSL on the ApiRemoting30, ClientWebService, DSSAuthWebService, ServerSyncWebService and SimpleAuthWebService virtual directories, then run WsusUtil.exe configuressl <server name>.
  3. In the GPO the finding names, change both URLs (update service and statistics server) to https://<server name>:8531.

Option B: a WSUS server for Tier Zero only

Give the Tier Zero computers their own WSUS server, run and administered from Tier Zero, on the Tier Zero network, over TLS as in option A. The WSUS server is then part of Tier Zero (PW-025 says so until it is declared).

PowerShell

PowerShell
# What a computer uses now (run on a domain controller)
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
    Select-Object WUServer, WUStatusServer
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' |
    Select-Object UseWUServer

# The setting in the GPO
Get-GPRegistryValue -Name '<GPO name>' `
    -Key 'HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ValueName WUServer

Verify the fix

After gpupdate /force on a Tier Zero computer, WUServer starts with https:// and wuauclt /detectnow (or Settings > Windows Update) finds updates. Collect again with the built-in collector: the finding is fixed. A collection that didn't read SYSVOL keeps it open, as can't tell.

Roll back

Put the http:// URLs back in the GPO. Clients pick them up at their next Group Policy refresh.

References

  1. https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#25-secure-wsus-with-the-secure-sockets-layer-protocollearn.microsoft.com
  2. https://www.gosecure.net/blog/2020/09/03/wsus-attacks-part-1-introducing-pywsus/gosecure.net
  3. https://labs.nettitude.com/blog/introducing-sharpwsus/labs.nettitude.com
  4. MITRE ATT&CK T1557: Adversary-in-the-Middleattack.mitre.org
  5. MITRE ATT&CK T1072: Software Deployment Toolsattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.

↑↓ to moveEnter to openEsc to close