Microsoft Update Security

Published: 2012-06-11
Last Updated: 2012-06-11 17:06:38 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

One of the important features of last weeks Microsoft certificate patch was that the bad certificate was apparently used to subvert the Windows update process. The complex Windows update architecture represents a huge target to any attacker, and it has held up quite well so far. I do not expect any issues related to the lost certificate this week. However, this would be the last chance for the attacker to use these certificates, and it is a good opportunity to talk about patch security on the day before "black tuesday".

 I do recommend that you apply the certificate patch released a week ago today if you haven't done so already. This way, no patch signed by the bad certificate should be accepted tomorrow. Patch tuesday is one of the best dates to launch such an attack as you do expect patches anyway. Don't forget the WSUS patch:

A couple of rules to harden your patch process:

  • Avoid patches while "on the road". Apply them in your home / work network whenever possible. This doesn't eliminate the chance of a "Man in the Middle" (MitM) attack, but it reduces the likelihood. If you are on the road for extended periods of time, use a VPN connection. In particular hotel networks and public hotspots frequently use badly configured HTTP proxies that can be compromised and many users expect bad SSL certificates (because of ongoing MitM attacks... ironic, but well, sadly true) in these environments.
  • Always validate patches. For Microsoft, this means using Microsoft update which will validate the digital signature applied to patches. The bad certificate broke this process. But it is still a very difficult hurdle to overcome for an attacker.
  • Do not accept patches from unknown sources. This includes CDs/DVDs you receive unsolicited, and of course the famous USB stick you found in the parking lot. For Windows, only use Windows Update.
  • Patch Tuesday is also an opportunity to verify that other software you own is patched. Secunia PSI does a good job with that for home users, Mac users have "MacUpdate" (for a small annual fee). Qualys provides which works great in particular for home users / less experienced users.
  • If you run your own WSUS server, make sure it is hardened and uses appropriate SSL certificates

Any other measures you apply to ensure the integrity of your patch process? Post a comment! In general, I usually advice people not to emphasize speed too much when it comes to patching. Instead, make sure you have a well tuned reliable and repeatable process. The biggest problem in my opinion (aside from organizations that don't patch at all) are patches that didn't get applied because it was never verified if the patch was actually applied, or patches that break systems because they didn't get tested sufficiently.

A patch is not applied until you verified that it got applied. Follow vendor guidance to check if the patch was applied, and if appropriate, check using a vulnerability scan.

 Also see:


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

1 comment(s)


I'd like to stress here that one should apply the same scrutiny to all systems. It might seem to be common wisdom today that you should not install some random binary foo from the internet on your system. Still I see a lot of IP addresses, ranging from to eastern european banks (ok that's whois information, could be completly bogus), downloading some rpm binary packages form my private website.
Those are unsigned and mostly provided to ease deployment for myself, because I know that I can trust those packages to some extent. Well as long as I trust the machine serving those files.

For everyone else I provide .src.rpms and a git repo to clone and review before you install the package with root permissions and later run unknown code with root permissions. But those are only downloaded by about one percent of the people downloading the binary.

On some days I think I should drop the binary packages from the public part of the site, but then again I'm sure someone else will provide binary packages some day and those who download them for convenience don't care anyway.

Diary Archives