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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
The Problem with Artificial Intelligence in Security
Dr. Leila Powell, Lead Security Data Scientist, Panaseer,  5/26/2020
10 iOS Security Tips to Lock Down Your iPhone
Kelly Sheridan, Staff Editor, Dark Reading,  5/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13173
PUBLISHED: 2020-05-28
Initialization of the pcoip_credential_provider in Teradici PCoIP Standard Agent for Windows and PCoIP Graphics Agent for Windows versions 19.11.1 and earlier creates an insecure named pipe, which allows an attacker to intercept sensitive information or possibly elevate privileges via pre-installing...
CVE-2019-6342
PUBLISHED: 2020-05-28
An access bypass vulnerability exists when the experimental Workspaces module in Drupal 8 core is enabled. This can be mitigated by disabling the Workspaces module. It does not affect any release other than Drupal 8.7.4.
CVE-2020-11082
PUBLISHED: 2020-05-28
In Kaminari before 1.2.1, there is a vulnerability that would allow an attacker to inject arbitrary code into pages with pagination links. This has been fixed in 1.2.1.
CVE-2020-5357
PUBLISHED: 2020-05-28
Dell Dock Firmware Update Utilities for Dell Client Consumer and Commercial docking stations contain an Arbitrary File Overwrite vulnerability. The vulnerability is limited to the Dell Dock Firmware Update Utilities during the time window while being executed by an administrator. During this time wi...
CVE-2020-13660
PUBLISHED: 2020-05-28
CMS Made Simple through 2.2.14 allows XSS via a crafted File Picker profile name.