Operations
3/2/2016
11:00 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Why Your Security Tools Are Exposing You to Added Risks

The big lesson from 12 months of security product vulnerabilities: there's no foundation of trust in any piece of software. They all represent a potential new attack vector.

There is a deep and amusing irony when products that are supposed to make you more secure are themselves subject to serious vulnerabilities. This isn’t particularly surprising considering that writing complex and secure software continues to be something humanity struggles with. Avastium’s ill-conceived and poorly executed browser is a good example, as Tavis Ormandy recently pointed out. Another recent example courtesy of Tavis was the trivial remote command execution and read-all-your-passwords feature from a Trend Micro browser plugin.

The popular opinion is that anti-virus is broken, and while this is true, it isn’t the entire story. In addition to AV not catching all threats, it is also creating them. Anti-virus attempts to safely parse countless file types in a non memory-safe language. This is one of the challenges that has bedeviled developers since someone’s initial fever dream told them it would be a good idea. It is the idea that AV companies have run with since the 1990s and we in our foolishness have bought into and made a regulatory necessity like when we all bought JNCO jeans. 

The thing many are now realizing is that “defense in depth” is a double edged pantaloon, since it also expands the attack surface. With anti-virus vendors struggling to stay relevant, they’re forced to differentiate themselves by getting into areas they should stay away from. Why would Trend Micro or Avast want to meddle with a browser? Writing a browser is exceptionally difficult to do securely. Your AV company shouldn’t be making software security decisions based on quarterly revenue projections, but it is. Someone at those companies probably said it was a bad idea, but they got overruled.

Another hard truth: your AV solution is a rootkit belonging to the country where development occurred. Contrary to recent events, having your enterprise compromised by the Russians is not part of anyone’s strategic plan. Good rootkits follow the “nobody but us” rule of backdoors but AV tends to be a different kind of rootkit where most continuing development tries to violate that rule.

But AV isn’t the only problem. Any security tool, the ubiquitous Wireshark for example, has been prone to vulnerabilities. These will be harder to identify and mitigate because teams inherently trust these tools as the foundation of how they do their jobs. These vulnerabilities are a common blind spot in defense in depth strategy that need to be accounted for. 

So what is the solution?

The overall lesson from the last 12 months of security product vulnerabilities is that whenever a new piece of software or device enters your network you must ask “what are the consequences of someone using this against me?” Once you’ve listed those consequences the next step is to eliminate, mitigate, monitor and contain as many of them as possible.

To start with, focus on the security tools you actually need. Instead of heaping mountains of security related software onto end user PCs, engineer a solution where a user can click on anything (because they will) and the impact will be something you can live with. From a security perspective, Windows users should have three pieces of software installed: some type of (domestic) AV that only does AV, Microsoft’s EMET and a monitoring daemon that will export logs and watches for new unrecognized binaries/DLLs. 

Focus on segmentation/compartmentalization too. Deploying Qubes OS enterprise wide would be an engineering Mt. Everest, but their compartmentalization through virtualization idea is the way of the future. One of Qubes OS’s basic theses is that every desktop application gets its own dedicated VM through Xen. In such an environment, effective exploits need to function in a very limited time window and include a hypervisor escape. 

Put more emphasis on faster incident response rather than prevention, but remember, monitoring tools can have flaws too. Our brothers and sisters on the defense side of the security spectrum have shifted their liturgy to embrace the idea that being compromised is no longer an “if” but a “when.” And those of us on the side of darkness have been insufferably chortling ever since, as though this is a declaration of defeat. Moving away from the antiquated signature-based model to one focused on meta analysis to detect suspicious behavior is a better overall strategy. We’ve seen this work in our own consulting practice at Immunity. A well engineered and analyzed monitoring infrastructure is a formidable opponent.

The battle doesn’t end when the first host is compromised and defenders have some distinct advantages they can capitalize on. Minimizing the attack surface on hosts and networks and making those attacks more costly is a big step. Effective monitoring can only come from deep knowledge of the environment and its patterns, which attackers won’t typically have.

Remember that there is no foundation of trust on any piece of software; think of each of them as a potential vector. Plan your incident response around this idea, maximize your advantages as a defender and become a hard target.

Related Content:

 

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

Dave is CEO of Immunity Inc., an offensive security firm that serves many Fortune 500s, major financials and federal agencies. The company provides penetration tests and develops pen-test tools like Canvas, Silica, Innuendo and Swarm. Immunity is a past contractor with ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AlexMcG
100%
0%
AlexMcG,
User Rank: Apprentice
3/3/2016 | 8:22:58 AM
Re: Agree, but...
Hi there! We tried pretty hard to make this not seem like scare mongering. Our point here is that defense tools have bugs and we're advising people to account for that. As with the rest of security there's no real magic solution. So what we purpose is dealing with it in context. Let's take the TrendMicro bug as an example and assume some fictional enterprise has it installed everywhere.

This bug was in an extraneous feature, I don't want an AV that runs its own webserver on my host. Our advice is choose an AV that doesn't do silly stuff like that. So lets assume we can disable all those extra features, now we're left with this big chunk of C/C++ that tries to parse every file type you've never heard of that regulation says we have to keep on our hosts. Ok, if I can't get rid of it I can at least make attacking it more expensive for common bug types in C/C++ with Microsoft's EMET. Though as we've seen recently thanks to FireEye there are ways around that for dedicated attackers but attackers have to spend a lot of time to find those. How do we then deal with an attacker who is willing to do that leg work? We monitor our hosts for surprising new binaries/DLLs as attackers typically want some type of persistence.


In following that advice we have: reduced our attack surface by turning off AV features we don't need, increased the cost to attackers to attack us via bugs in the core part of the AV engine, and increased the odds that if we are successfully compromised we'll know about it. That's pretty reasonable substantive advice for how to deal with vulnerabilities in your defensive tool chain. I hope that readers don't come away with the impression that all security software is bad, I hope they come away with the idea that NO complex software is without vulnerabilities and they need to plan accordingly.
robep00
50%
50%
robep00,
User Rank: Apprentice
3/3/2016 | 7:39:26 AM
Re: Agree, but...
I agree with Dave and  Alex in this article.

I don't think it's about scaremongering more then accepting a hard reality. A reality that is forcing changes in the approach to security as we are writing about it.

For example, file analysis could be performed off site instead of on the host like some anti-virus engines or security solutions are already doing. By limiting and making the security product as lightweight as possible, the increase in attack surface is minimal compared to the potential increase in security posture.

 
Whoopty
50%
50%
Whoopty,
User Rank: Ninja
3/3/2016 | 7:01:24 AM
Agree, but...
As much as I agree with this post and it's important that people realise anti-virus is not a set-it-and-forget-it tool, this gives us a lot of concerns without much in the way of a meaningful solution. It smells like scaremongering. 

The last thing we want is people thinking that it would be better to do without security software altogether.

Does anyone have a good solution to AV? Even if international alternatives are a bad idea, US and UK made security software is just as beholden to intelligence agencies there as the foreign alternatives are.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Five Emerging Security Threats - And What You Can Learn From Them
At Black Hat USA, researchers unveiled some nasty vulnerabilities. Is your organization ready?
Flash Poll
10 Recommendations for Outsourcing Security
10 Recommendations for Outsourcing Security
Enterprises today have a wide range of third-party options to help improve their defenses, including MSSPs, auditing and penetration testing, and DDoS protection. But are there situations in which a service provider might actually increase risk?
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
Cybercrime has become a well-organized business, complete with job specialization, funding, and online customer service. Dark Reading editors speak to cybercrime experts on the evolution of the cybercrime economy and the nature of today's attackers.