Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

6/24/2012
03:08 PM
Mike Rothman
Mike Rothman
Commentary
50%
50%

Patching Goes Up In Flames

The Flame malware throws the integrity of patching into question, which creates quite a quandary for those trained to patch early and often. This represents a significant inflection point for security -- or does it?

Everyone is talking about how Flame changed the game. The alleged precursor to Stuxnet broke Windows Update by undermining its cryptography in a truly novel way to pretend its installation was a legitimate update from Microsoft. You can check out the specifics of the attack in this great presentation by Alex Sotirov of Trail of Bits.

This is the kind of stuff that happens when guys who build atomic bombs are set loose on computer software.

But how the attackers actually broke Windows Update is beside the point. This not-so-simple attack now puts a critical anchor of your security operations into question. We've all been taught one of the key fundamentals of security is to patch early and often. You probably constantly remind the ops guys that the day after Patch Tuesday is Exploit Wednesday. You read the anecdotes from breach reports showing many successful breaches resulting from attacks on software where patches were already available (sometimes for months). When updates ship from key vendors, you trust them and you apply them. Right?

Even better, Flame was an ingenious attack vector because most of your traditional controls give a pass to patches/updates. Your HIPS and/or endpoint protection sees registry updates, system files, and configuration changes from patching processes, and allows them. That's what patching does, right? Yeah, that's also what malware does. The only difference is you trust updates you get from the trusted software vendor.

What happens when you can't trust the update? The patching emperor no longer has clothes. They were incinerated by the determined attackers with unparalleled resources. Now you start questioning your patching/updating process. And you should be questioning. As if your job wasn't hard enough, now you need to do malware analysis on signed updates from "trusted" vendors? Awesome.

Now to be clear, analyzing patches isn't a radical departure from the patching process Securosis defined a few years back. In that research, Rich Mogull laid out a 10-step process, and one of the steps was to test and approve the patch. Before Flame, that meant making sure it didn't break anything. Now it means you have to also check for malware-like characteristics in updates.

Or not. Let's be realistic that most organizations don't have the resources to keep up with all the patches in the first place. They are underfunded, under-resourced, and don't have the expertise to deal with simple malware available in the hundreds of kits out there (if you know where to look). They spend most of their time cleaning up the mess of frequent malware infections, so even if they were concerned about the undermined trust of a patching process, they don't have the resources to change anything.

On the flip side, organizations that have a detailed and careful updating process likely already do some level of analysis on the updates. These folks are probably the organizations targeted by sophisticated attackers using advanced attacks. They have in-house malware analysis capabilities, and it's just a matter of having those folks analyze the patches (like they do hundreds of other files a week). Sure, this adds another step in the patching process and maybe extends the patching window a few extra days, just to make sure the updates are legit. These organizations also implement workarounds (like IPS rules) to block new patch-oriented attacks until devices can be updated, anyway.

So does Flame really change the game? Not really. Organizations that have the resources now can add another step to their patching processes to protect against an attack vector unlikely to be used by the attackers you need to worry about anyway. In that way, security is like flying in the U.S. The TSA adds a bunch of ineffective controls to stop an attack vector that the bad guys won't use again. Rock on, security theater.

My bottom line is a bit more pragmatic. It's just a reminder that determined attackers will break your stuff. Like with the RSA attack targeting the tokens used by the real targets, nothing is out of bounds. Any controls you use can and will be gamed. And once again, it highlights the need to balance your defenses with extensive monitoring to shorten the window between when the breach happens and when you know it happened.

Mike Rothman is President of Securosis and author of The Pragmatic CSO Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-30477
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of replies to messages sent by outgoing webhooks to private streams meant that an outgoing webhook bot could be used to send messages to private streams that the user was not intended to be able to send messages to.
CVE-2021-30478
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the can_forge_sender permission (previously is_api_super_user) resulted in users with this permission being able to send messages appearing as if sent by a system bot, including to other organizations hosted by the sa...
CVE-2021-30479
PUBLISHED: 2021-04-15
An issue was discovered in Zulip Server before 3.4. A bug in the implementation of the all_public_streams API feature resulted in guest users being able to receive message traffic to public streams that should have been only accessible to members of the organization.
CVE-2021-30487
PUBLISHED: 2021-04-15
In the topic moving API in Zulip Server 3.x before 3.4, organization administrators were able to move messages to streams in other organizations hosted by the same Zulip installation.
CVE-2020-36288
PUBLISHED: 2021-04-15
The issue navigation and search view in Jira Server and Data Center before version 8.5.12, from version 8.6.0 before version 8.13.4, and from version 8.14.0 before version 8.15.1 allows remote attackers to inject arbitrary HTML or JavaScript via a DOM Cross-Site Scripting (XSS) vulnerability caused ...