Security, et al

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6036/growing-threat-from-friendly-fire-from-vendors/

After we learned that Flame exploited Microsoft’s Auto Update infrastructure, I pointed out that if attackers were able to compromise Microsoft, a leader in patch management, it couldn’t be long before bad guys exploited the update infrastructures of other vendors who are far behind Microsoft – like Adobe…  And that’s exactly what happened a couple weeks ago.

One of Adobe’s internal servers was hacked.  This server performed code signing for several Adobe applications.  Code signing on the Windows platform is called Authenticode.  It’s a way of digitally signing programs so that when you download what you believe to be Acrobat Reader from Adobe you can be sure that it really is Reader and not some piece of malware. 

Once they hacked this code signing server at Adobe, the attackers used it to sign an unknown quantity (at least 3) of malware files which were later used in some apparently limited, targeted attacks.  Adobe decommissioned the server, informed customers, released updated versions of Adobe apps signed by a new certificate and finally revoked the compromised certificate days later. 

It’s important to understand that the risk in this particular case was not any vulnerability inside Adobe products already installed.  The risk was that your computers might trust malicious software they encounter because it had a completely valid signature from a trusted publisher.

Why then was it necessary to update your Adobe apps?  Adobe never really got into details on that.  They were pretty vague, saying something about “negative impact on user experience”.  My research indicates that once Adobe revoked the certificate in question, User Account Control (UAC) and AppLocker among other things would balk when you tried to run or install Adobe apps signed with the old certificate. 

Adobe’s whole handling of the mess left me and a lot of my colleagues with a bad taste in our mouth.  It really felt like their priority was protecting their application’s usability over user security.  They are where Microsoft was years ago when IIS was getting hacked all the time and whenever I used the words “Windows security” in that sequence, people would say “isn’t that an oxymoron”?  Microsoft almost lost the king of the server hill to Linux and Apache but then Bill Gates came out with Trustworthy Computing.  This was a major turnaround for a man and a company who once said users would never pay for quality.  Microsoft developers stood down on development work for weeks of training and then went back to their source code searching for security vulnerabilities.  They implemented new coding standards and completely revamped their patch process.  Patch Tuesday brought order to the chaos of unpredictable patch releases and things got a lot better for the good guys. 

For a while.  Microsoft’s improvements created a vacuum in the ISV world and the bad guys turned their attention there.  Now we have the Acrobat, Flash, Shockwave, Java, iTunes, 3^rd party browser security patching mess we find ourselves in now.  This has been going on for several years without much discernible improvement. 

What’s new is that in an ironic twist of fate the bad guys are exploiting software update infrastructures – the very infrastructures our vendors are trying to protect us with. 

There’s consensus among the people I talk to that we can’t trust software vendors to automatically update our systems.  We can’t trust them to keep their infrastructures secure.  After all, everyone is vulnerable to advanced persistent threats (APTs).  But when companies are hacked it’s usually their own data that gets compromised.  But with ISVs, it’s their users.  Like one of my community members said, if your ISV sneezes you get the pneumonia.

That’s bad enough but I also don’t think we can trust ISVs act 100% in our best interests when handling security incidents that expose us, their users, to risk.

If we can’t trust on those 2 points, there’s 2 ways we can’t trust ISVs.  First, we can’t trust them to automatically update our systems.  We’ve got to disable all of these automatic updates and take centralized control of patch management.  In fact I propose the following 8 Software Patching Commandments:

1. Thou shalt not depend on vendor automatic updaters
2. Thou shalt not allow patch/installation based on code-signing certificates
3. Thou shalt control which patches go down and when
4. Thou shalt be able to deploy patches within hours
5. Thou shalt be able to deploy patches in phases
6. Thou shalt not be blind to patch deployment status
7. Thou shalt patch software from multiple vendors
8. Thou shalt patch applications on all your operating systems

Second, we can’t trust code signatures.  It may be from Microsoft or Adobe, then again it may be a forged signature hiding some really bad malware.  You can’t trust users not to run malware and it’s evolving to fast.  That means we need to take centralized control of what executes on all servers and endpoints.  There’s no substitute for application whitelisting and that technology has really improved.

There’s great technology for both of these centralized control needs and I don’t see any way around the need for it because we can’t trust the classic mechanisms in place.

Oh, one other point about trust.  Don’t trust vendors when they say the great majority of you are safe because these attacks are very targeted and limited in nature.  That’s fine as long as you aren’t the one being targeted. All of them say this including Microsoft but I’ll quote Adobe: “We have strong reason to believe that this issue does not present a general security risk. The evidence we have seen has been limited to a single isolated discovery of two malicious utilities signed using the certificate and indicates that the certificate was not used to sign widespread malware.”  That is damage control talk. 

If you want more on the Adobe code signing hack and how it demonstrates the need for centralized, multi-vendor patch management and application whitelisting watch my webinar: Code Signing Debacle 2.0: A Hacked Adobe Server and Its Impact on Us All.

This article was first published at Lumension’s Optimal Security blog: http://blog.lumension.com/6036/growing-threat-from-friendly-fire-from-vendors/