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: http://support.microsoft.com/kb/2720211

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 browsercheck.qualys.com 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: http://support.microsoft.com/kb/2720211

 

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

1 comment(s)

Exploit Available for Trivial MySQL Password Bypass

Published: 2012-06-11. Last Updated: 2012-06-11 13:22:10 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

Thanks to Jack for pointing this one out to us. I somehow missed this vulnerability this weekend.

MySQL fixed last week an authentication bypass vulnerability that is trivially exploitable [1]. The effect is that a user has a 1/256 chance of being granted access to MySQL even if the password is wrong. So in short: Brute forcing passwords will always work pretty quickly even if you got the wrong password.

The vulnerability does however depend on how your instance of MySQL was compiled. Chances are that you are not vulnerable, but just in case, there is a patch available, and it shouldn't be too hard to test. Write a script that attempts the same password many  times, and see if you get logged after a while. 

As an additional hardening measure, you may want to consider limiting access by IP address. 

[1] http://seclists.org/oss-sec/2012/q2/493

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

Keywords: mysql
5 comment(s)
ISC StormCast for Monday, June 11th 2012 http://isc.sans.edu/podcastdetail.html?id=2590

Comments


Diary Archives