Windows Update - Interception

Question

I'm trying to monitor the HTTP requests/responses made when performing a Windows Update.

I have a Windows 8 machine configured with a proxy in IE. I've also imported via netsh for winhttp:

netsh winhttp import proxy source=ie

The proxy is running on another machine on port 8080 and is configured to intercept SSL.

I have tried both with Burp proxy or with a normal Squid proxy (using ssl_bump). The root CA certificates are installed on the Windows 8 machine, in the Local Machine store, under Trusted Root CAs. If I browse from IE or Chrome I can access https sites without a warning (as the presented server certificate is signed by the proxy CA).

However, if I try to use Windows Update I get an error:

"There was a problem checking for updates"

This is a known issue, Bluecoat advise adding an exception for SSL interception for Windows Update:

https://kb.bluecoat.com/index?page=content&id=KB3959&actp=RSS

Microsoft make the same recommendation for TMG:

http://support.microsoft.com/kb/949104

So it seems like the Windows Update service doesn't just check the certificate in the usual way, it actually verifies against a different CA list, or specifically requires a certain server certificate from the Windows Update site.

The question is, how can I work around this, so that I can see the HTTP requests made by Windows Update?

Answer 1

Among possible updates are updates of the default contents of the trust store itself. If Windows was using the default trust store then any CA in that store could edit a forged update which would evict its competitors. It could also alter about any part of the OS. For an OS, the path for updates is very sensitive. It would be quite risky to give the power of updates to a hundred or so of CA, not all of which can be really trusted to do their job properly (mishaps have happened, not often, but yet...).

What you might try is to add your fake certificate for the Windows Update SSL server into the "trusted publishers" store (the one for the "local computer"). Include the fake server certificate itself, not the Burp-controlled CA which issues fake certificates on-the-fly (I don't know if Burp can use a specific non-dynamic fake certificate for a given server). This store is normally for validating signatures on drivers, not for SSL servers, but given the way Microsoft handles certificates, this may work and do what you want (I don't have a Windows machine handy to try that right now).

If the Windows code does not use an easy-to-access trust store, but instead hardcodes the list of acceptable certificates for the Windows Update server, then you will have to resort to DLL modifications, like malware writes do for a living. The OS will try to actively defend against that.