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:
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 4069 Posts ISC Handler Jun 11th 2012 |
Thread locked Subscribe |
Jun 11th 2012 8 years ago |
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 dnd.ca 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. |
Anonymous |
Quote |
Jun 11th 2012 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!