When you run Windows Update on Windows 7 (I did not test other versions of Windows) it opens MANY connections to computers on the Internet over port 80. HTTP use port 80 and it is not secure. Not only can data sent with HTTP be spied on, it can also be modified in-flight. That is, what the sender sends is not necessarily what the receiver gets. Secure transmissions use HTTPS and travel over port 443.

Insecure transmission works in both ways. Windows Update not only downloads bug fixes, it also sends data out from your computer. I have no idea what data Microsoft sends back to itself, but any data transmitted with HTTP can be easily spied on by the US Government which is said to listen in on the Internet backbone. On the receiving side, if patches are downloaded via HTTP, they can be intercepted by the US Government to install software on a Windows computer.

The title does not say it all. In addition to not being secure, Windows Update is also buggy with poor diagnostics. I'll start there.

WINDOWS UPDATE BUGS

The buggy nature of Windows Update on Windows 7 last got publicity when it would take half a day to figure out the missing patches. This month, Windows Update was shamed for failing to install the August and September monthly updates because it had failed to update itself first.

A bug fix to Windows Update (KB3177467) was issued in October of 2016, and a system without this fix ran fine until very recently, when Windows Update failed with a 0x8000FFFF error for many people. Woody Leonhard covered the details in Computerworld.

John Wilcox of Microsoft offered an explanation for the problem where he wrote "when we released the Windows 7 SP1 servicing stack update (KB3177467) it was marked 'critical.' " Yet, on August 25, 2018, I tweeted about a Windows 7 system that installed all the available August 2018 patches and then, after the mandatory reboot, wanted to install KB3177467. Nothing said that KB3177467 was critical. I wondered why a two year old patch appeared after installing all the current patches. The 2016 patch was checked by default, but it looked and felt like a Windows Update bug, so I didn't install it.

In writing about the 0x8000FFFF error in Windows Update Woody Leonhard said "Why should you have to hassle with this? I dunno. Why can’t Windows update itself as smoothly as ChromeOS? Or macOS or iOS or Android? I dunno. Why do you have to be aware of the Windows installer’s burps — why doesn’t Windows just fix itself and get on with the business at hand?". Updating their operating system is something the other vendors do reasonably well. But, not Microsoft.

WINDOWS UPDATE UNKNOWNS

Another bug with Windows Update is that it does not know what its doing. I say this because it sometimes fails with an unknown error.

As someone who programs computers, trust me when I say that there is no such thing as an unknown error. There are only stupid and lazy programmers. And whoever programmed this is shockingly stupid as the existence of an error code proves that the error is indeed known. And, even if a particular function fails with a null return code, the programmer still knows which function failed. And, taking a step back, the programmer also knows where in the process of things to do, they currently are. That is, if Windows Update consists of 9 steps, the programmer knows that steps 1 and 2 worked but they failed in step 3. Calling an error unknown is shameful.

Adding more shame to this is that there is a plain text log of Windows Update activity which better programmers would mention and link to when an error occurs.

And, to build a mountain of shame, I know what these two supposedly unknown errors are. I caused them. That's why I have two examples here.

My last blog was about my trying to prevent Cortana on Windows 10 from phoning home. This can not be done through the Windows User Interface, you have to instead block IP addresses. When my router is blocking the IP addresses used by Cortana, Windows Update on Windows 7 fails.

This was easily proven by having the Windows 7 computer connect to a VPN which bypasses all the IP address blocking by the router. I tested multiple times and the result was clear: with a VPN on, Windows Update ran fine. With the VPN off, Windows Update failed with unknown errors. Better programmers would have externalized the fact that Windows Update could not connect to a necessary server.

Wondering what the Microsoft explanations of these return codes are? According to How to solve connection problems concerning Windows Update or Microsoft Update an error 0x80072EE2 probably means that you are having temporary issues. The 0x8024402f error indicates that "External cab file processing completed with some errors." Got that?

PORT 80 CONNECTIONS

All that said, my main point here is that Windows Update on Windows 7 opens many connections to Microsoft servers on port 80. This not only opens Windows users up to spying it could even be worse. Since HTTP connections can be modified in-flight, there is no telling what a malicious actor that sits on the network could do.

How the heck does no one else notice this? Windows 7 has been around for a very long time.

While I am reasonably familiar with networking, I am no expert. Specifically, I am not yet able to do packet sniffing, so I can't tell if a specific connection made by Windows Update is used for reading data, sending data or both. Also, I have not looked at the unencrypted data that travels over a port 80 HTTP connection.

But, I have seen that there are quite a lot of insecure connections made by Windows Update.

My main tool in logging Windows Update network activity has been the TcpLogView program created by Nir Sofer. Specifically, version 1.30. Like all of Mr. Sofer's software, the program is free and portable. You download a zip file, unpack it and then just run the .EXE file. Sofer has been creating great Windows software for a very long time.

Here are the details provided by TcpLogView for the opening and closing of a connection between the computer it is running on and another computer on the Internet.

The most important field, for this blog, is the Remote Port which, in the example above, is 80.

In testing, I would not use the computer for anything else while Windows Update was running, but the operating system is always doing things in the background which makes it hard to insure that particular outbound connection was from Windows Update.

Many Windows services run under the control of svchost.exe and, at any given time, there are many instances of svchost.exe running. Fortunately, TcpLogView provides the Process ID which can be used to confirm that the connection was initiated by Windows Update. The Microsoft Process Explorerprogram identifies each instance of svchost by Process ID and also shows the specific service running under the control of svchost.

In the example above, process 552 opened the connection. Below, we see from Process Explorer that service wuauserv (Windows Update) has multiple HTTP connections to the computer at IP address 8.253.135.241 (see the Remote Address column).

While most of Windows Update runs under svchost, the installation of the .NET Framework patches does not. As shown below, it gets installed by program Setup.exe running out of a temporary folder. This program too, makes connections on port 80, in this case to IP address 23.39.141.162.

Now the good stuff. Below is a full network trace by TcpLogView of a single Windows Update run. First, it detected missing patches and then I told it to install just one patch, the September 2018 .NET Framework update. The two blacked out log entries were not from Windows Update. I have outlined in red every time Windows Update opened a connection to a computer on port 80. In all, it did so nine or ten times (I'm not sure about the IPv6 connection).

Another example below, shows the log and Windows Update side by side. Just to determine the missing patches, it opened 3 connections on port 80, once to IP address 23.56.172.193 and twice to IP address 13.107.4.50. In addition, it made two outgoing connections on port 443.

AFTER THE SEPTEMBER PATCHES

After having installed all the September 2018 patches, I rebooted and ran Windows Update again. My final example, below, shows the log of all network connections that Windows Update made, both looking for new patches and installing the one it found. In all, there were six connections on port 80.

What missing patch did it find after having installed the September updates? None other than KB3177467 from October 2016; the missing bug fix to Windows Update that recently caused people grief installing the August and September updates.

Windows Update seems to always start off with a port 80 connection. In my very limited testing, I have seen this initial connection to IP address 13.107.4.50 and to 23.43.56.115.

Is this a scandal?

I think so. I can't imagine any reason that Windows should be making insecure HTTP connections on port 80. I see it as malpractice. But, since I am not with 60 Minutes, there is every reason to expect this insecure behavior to continue.

Chromebook please.

AND MORE    (added Sept 25, 2018)

On a different Windows 7 machine, I installed all the September patches, rebooted and then installed the missing bug fix to Windows Update. Then, I rebooted and ran Windows Update yet again. This time, it found no missing patches. Here is the log from this final go-round:

With nothing to do, Windows Update made five insecure HTTP connections on port 80 and two secure connections on port 443. Below is a simplified log of every opened connection. llnw.net is a Content Delivery Network known as Limelight Networks.

13.107.4.50    port 80 191.234.72.190 port 443 69.164.1.134   port 80 (https-69-164-1-134.lga.llnw.net) 69.164.50.132  port 80 (cds1338.lga.llnw.net) 69.28.185.66   port 80 (cds1161.lga.llnw.net) 13.107.4.50    port 80 191.232.80.60  port 443

Connections opened by Windows update with nothing to do

MSRT VIA HTTP    (added Oct 1, 2018)

I now have proof that MSRT downloads via HTTP on port 80. MSRT is the Microsoft Malicious Software Removal tool. It is updated once a month and is always part of the monthly updates for Windows 7. On a Windows 7 machine, I told it to only install the September 2018 MSRT and the download ran very slowly, despite being only 46MB. Both from TcpLogView and Process Explorer it was quite clear that during the long time it took to download MSRT, the only connection that Windows Update had to the outside world was to 205.185.216.42 (map2.hwcdn.net) on port 80. You can see this below in a screen shot that shows Process Explorer in the lower half. It shows HTTP and the computer name rather than numbers.

- - - - - - - - - - - - - -

Leave a comment at AskWoody.com.

September 25, 2018: Over at AskWoody.com, Microsoft expert Susan Bradley linked to an article, How to solve connection problems concerning Windows Update or Microsoft Update by Microsoft that says "Windows Update agent uses port 80 for HTTP and port 443 for HTTPS to obtain updates." As the old joke goes: it's a feature rather than a bug. Interesting that Microsoft confesses, but the point remains, that using insecure HTTP rather than secure HTTPS is a bad thing and there is no excuse for it. Bradley also wrote that "You can block outbound port 80 and windows update will work just fine," which was not in the article. I hope to verify this soon, not that it really changes much.

September 25, 2018: Updated the section about Windows Update Unknowns and added the new AND MORE section.

 

Viewed 14,283 times since September 24, 2018 (6/day over 2,280 days)