Enable WSUS (Windows Server Update Services) encryption with TLS certificate (even Let’s Encrypt)

The following are the steps to configure TLS/SSL on server/s running the Windows Server Update Services. The traffic encryption of WSUS traffic with endpoint users is useful and highly recommended, also because

WSUS is a Microsoft service that deploys updates on the computer park depending on the organization’s needs, which is essential for a secured infrastructure. Easy to use and to install, it is possible to adapt it according to the different patch policy of every organization. However, the service’s purpose is to install softwares (patches in that case) on a large number of operating systems. The functionalities and the server position in the network could lead to a dangerous situation.

In 2015, Alex Chapman and Paul Stone published a proof of concept tool to poison Windows updates while executing a Machine-in-the-middle (MITM) attack as part of their BlackHat presentation titled WSUSpect – Compromising the Windows Enterprise via Windows Update, introducing the attack for the first time.

In a normal operation mode, the WSUS server presents updates to the client in the form of update files signed by Microsoft, but relying on HTTP opens the update server to MITM attacks which allows injecting malicious update metadata. This metadata is unsigned, meaning there is no integrity protection to prevent tampering.

In few words, during the metadata exchange, a MITM attack could tamper responses to the SOAP requests SyncUpdates (software) and GetExtendedUpdateInfo, modyfing the URL of the "update" (usually bginfo and/or psexec or psexec64, all signed by Microsoft, and passing parameters (no integrity checks are made on these parameters) to execute specific commands using NT AUTHORITY\SYSTEM (a strong administrative account available on all Windows platforms) and basically opening potential backdoors on the target system.

WSUS enables system administrators in organizations to centrally manage the distribution of updates and hotfixes released by Microsoft to a fleet of systems. The attack consists in abusing the default configuration of WSUS: when first configuring the service, usage of HTTPS is not enforced, as shown in the folowing picture:

When clients sync with WSUS, all metadata, about updates, exchanges between the client and the server are done using the Simple Object Access Protocol (SOAP). By exploiting the lack of integrity of the SOAP calls transmitted over an unencrypted HTTP channel, an attacker performing a MITM attack can tamper responses to the SOAP requests SyncUpdates (software) and GetExtendedUpdateInfo, which are two steps during handshake between clients and WSUS servers.

Let's remember that that the metadata exchanged is unsigned, or better, there is no integrity protection to prevent tampering.

This guide assumes you have a working instance of WSUS installed and configured, using default ports.

Generate a SSL certificate

First of all we need to login to your WSUS server, then open Server Manager, then select and open Tools -> Internet Information Services (IIS) Manager.

Once opened Internet Information Services (IIS) Manager we can click on our server and select Server Certificates:

If we want to use our own PKI environment (internal CA), we can proceed as follows; let's click Create Domain Certificate on the right side:

Let's fill in the requested information on the Distinguished Name Properties page and click Next:

Select your certificate authority and enter a friendly name (this can be anything), and then click Finish:

If we need to submit a certificate request to an external certificate authority like Goaddy, Verisgn, Comodo, etc., we will have to follow these steps: click Create Certificate Request on the right side, and then we will out the Distinguished Name Properties and click Next:

Change the Bit length to 2048 ,or higher (better),and click Next:

Select a location on where to place the CSR file that will be generated by the wizard and click Finish.

At this point, send the request to your certificate authority (like GoDaddy, Verisign, or your own internal certificate authority). You should receive back a .cer file once the claim has been fulfilled. Once done, let's click on Complete Certificate Request on the right side:

Let's select the .cer file that your public certificate authority provided you, type in a friendly name (this can be anything), select Web Hosting for the certificate store, and click OK:

Once inserted our certificate in IIS Manager, we need to bind the TLS/SSL certificate to our network adapter, so let's expand our server, expand Sites, and select WSUS Administration; once done that we will select Bindings... on the right side and finally select the https site and hit the Edit... button:

Now, this is the moment in which we will select https for the type, select the TLS/SSL certificate we created above and finally click OK:

Now Close the Site Bindings window:

Enforcing Encryption on WSUS

Now, we need to enforce SSL encryption on the following virtual roots:

• ApiRemoting30
• ClientWebService
• DSSAuthWebService
• ServerSyncWebService
• SimpleAuthWebService

Expand WSUS Administration and foreach of the directories above, complete the following steps:

1. Select the virtual site.
2. Double click on SSL Settings.
3. Check Require SSL and leave Client certificates to Ignore.
4. Click Apply in the top right corner.

And now the screenshots to reinforce these steps:

Now we need to execute a command to tell WSUS to use SSL, so we open up an elevated command prompt, then we navigate to your WSUS installation folder, C:\Program Files\Update Services\Tools, and then we execute the following command (replace your server with the correct FQDN):

wsusutil.exe configuressl myserver.mydomain.local

WsusUtil returns the URL of the WSUS server with the port number specified at the end. The port will be either 8531 (default) or 443. Verify the URL returned is what you expected. If something was mistyped, you can run the command again.

Restart the WSUS server to make sure all changes take effect. You should be able to bring up the WSUS management console if all went well.

Configure Clients to connect to WSUS server with TLS/SSL (Group Policy)

To configure your clients to connect via SSL/TLS to the WSUS server via Group Policy we need first to login to your domain controller, then open up Server Manager and finally open up Group Policy Management:

Expand Computer Configuration -> Polices -> Administrative Templates -> Windows Components -> Windows Update, then double click on Specify intranet Microsoft update service location:

Change the intranet update service url to https and specify port 8531 and then click Apply.

After doing a gpupdate /force on your local machine, then do a wuauclt.exe /updatenow to finally check for Windows Updates. If windows successfully completes checking for updates, you are good to go.

The Powershell Way

The following code, in Powershell, will create a self-signed certificate, then will export the public key, then will specify the new SSL certificate, it will enable the "Require SSL" option for all the web services under WSUS Administration and it will apply the new configuration to WSUS role. Finally, it will update the GPO to use the new URL as endpoint for all Windows clients.

Obviously, after the execution of the following code, once customized to your own need, it will be still needed to deploy the self-signed certificate also to domain Windows clients (using GPO) to inform them that it is trusted and delivered by a trusted, internal in this case, authority.

######## 1. Create a self-signed certificate
$SelfSignedHT = @{
 DnsName = "$($env:COMPUTERNAME).$($env:USERDNSDOMAIN)".ToLower()
 CertStoreLocation = "Cert:\LocalMachine\My"
}
New-SelfSignedCertificate @SelfSignedHT
$cert = Get-ChildItem -Path Cert:\LocalMachine\My -SSLServerAuthentication
 
######## 2. Export its public key
Export-Certificate -Cert $cert -Type CERT -FilePath ~/documents/cert.cer
 
######## 3. Import the public key in the Trusted Root Certificate Authorities store
Import-Certificate -FilePath ~/documents/cert.cer -CertStoreLocation Cert:\LocalMachine\Root
 
######## 4. Select this certificate in the SSL bindings
$cert | New-Item IIS:\SslBindings\0.0.0.0!8531
 
######## 5. Require SSL for the following virtual roots only:
'SimpleAuthWebService','DSSAuthWebService','ServerSyncWebService','APIRemoting30','ClientWebService' | ForEach-Object {
 Set-WebConfigurationProperty -Filter 'system.webserver/security/access' -Location "WSUS Administration/$($_)" -Name sslFlags -Value 8
}
 
######## 6. Switch WSUS to SSL/TLS
& 'C:\Program Files\Update Services\Tools\WsusUtil.exe' configuressl $("$($env:COMPUTERNAME).$($env:USERDNSDOMAIN)".ToLower())
 
######## 7. Change your GPO to point to the new URL
$key = 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
$uri = 'https://{0}:8531' -f $("$($env:COMPUTERNAME).$($env:USERDNSDOMAIN)".ToLower())

Get-GPO -All | Foreach-Object { 
 if ($_ | Get-GPRegistryValue -Key $key -ValueName WUServer -EA 0) {
  $_ | Set-GPRegistryValue -Key $key -ValueName WUServer -Value $uri -Type String
  $_ | Set-GPRegistryValue -Key $key -ValueName WUStatusServer -Value $uri -Type String
 }

Let's Encrypt and WSUS (or any other IIS site)

As we most of us already know, Let’s Encrypt is a free, automated, and open certificate authority brought to you by the Internet Security Research Group (ISRG). It entered public beta in September 2015 and completed it successfully on April 12th,2016, issuing more millions of certificates for other millions of websites. The project is sponsored by Mozilla, Akamai, Cisco, Chrome and many others.

The two main requirements to use Let’s Encrypt are:

1. The domain name needs to point to the WSUS Server IP where the Let’s Encrypt ACME client is installed.
2. ACME client.

The first point is very important because ACME agent checks that the WSUS server hosting the WSUS Administration Site is the one listed in public DNS.

Let’s Encrypt will create, renew and bind the cert to the IIS website without you needing to change anything manually, but still we will need to have and use the following client program, called Win-ACME Client.

Download ACME Win-ACME Client

To start the process, download and unzip the latest WIN-ACME client from the providing link: https://github.com/win-acme/win-acme.

IMPORTANT NOTE: the WIN-ACME clients need .NET Framework 4.7.2 component installed.

Open the elevated command prompt, go to C:\inetpub\letsencrypt directory and run wacs.exe. This will launch an interactive Let’s Encrypt certificate generation and binding to IIS site wizard. To quickly create a new certificate, select N: – Create new certificates (simple for IIS).

wacs.exe

Next, you need to select the certificate type. In our example, there is no need to use a certificate with aliases (multiple SAN – Subject Alternative Name), so just select an item 1. Single binding of an IIS site. If you need a Wildcard certificate, select the option 3.

Then the utility displays the list of websites running on IIS and prompts you to select a site to issue the certificate for (it should show WSUS Administration Site).

Specify your email address to which notifications about certificate renewing problems and other critical messages and abuses will be sent (you can specify multiple email addresses separated by commas). It remains to agree to the terms of use and Windows ACME Simple will connect to Let’s Encrypt servers and try to automatically generate a new SSL certificate for your website.

The process of generating and installing SSL Let’s Encrypt certificate for IIS is fully automated.

By default, domain validation is performed in the http-01 validation (SelfHosting) mode. To do this, you must have a domain DNS record pointing to your WSUS server. When running WACS in manual mode (full options), you can select the validation type – 4 [http-01] Create temporary application in IIS (recommended). In this case, a small application will be created on the IIS web server through which Let’s Encrypt servers will be able to perform domain validation.

IMPORTANT NOTE: During the TLS/HTTP validation, your WSUS server must be accessible from the Internet by its full DNS name over HTTP (80/TCP) and HTTPS (443/TCP) protocols. To reduce surface attack you could setup your firewall to open, scheduling, for example, a rule in Windows Server (creating a schedule that will enable/disable a command like the following: netsh advfirewall firewall set rule name="MyRule" new enable=yes/no and set the schedule to run every 58/59 days), these ports.

The WACS tool saves the private key of the certificate (*.pem), the certificate itself, and a number of other files in the C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple. Then it will install the Let’s Encrypt SSL certificate generated in the background and bind it to your IIS site. If there is an SSL certificate installed on the site (for example, self-signed cert), it will be replaced with a new one.

Certify (https://certifytheweb.com/)

Another very good solution to activate WSUS with Let's Encrypt, but the same process can be done for any other IIS website that has been properly exposed on ports 80 and 443 on Internet, is using Certify The Web, by Webprofusion.

This handy and awesome tool can manage multiple IIS sites and do both DNS-1 and HTTP-1 validations, completed with scheduled renewal. The Certify UI pretty much reflects the terminology of a Vault, contact (email really) and domains and certificates and the UI reflects this hierarchy. You can create new domains and then attach new certificates to each domain. You can also use this UI to renew, export and apply the certificates directly into IIS Web Site bindings (and obviously WSUS Administration).

This tool has a Community Edition (with only the limitation of a small number of certificates requests possible) and other professional edition to install the software on more servers and having unlimited managed certificates per server, but the Community Edition will be very good if you will have just to use 1-2 TLS certificates for internal/external web portals.

Download

A detailed report about WSUS security risk when used in http-only mode (no https enforced) in a Windows-based enterprise.