Time to ban dangerous apps? Exploring third-party app security

Most of us have already made and forgotten our New Year's resolutions, but for those who may be looking for a good security-related pledge for 2012, here's an idea: ban attackers' favorite third-party applications and save your organization some headaches.

You don't have to have a perfect defense. It just has to be one step better than the attackers.

Dan Guido

For all the heat Microsoft has taken over the years, it's steadily improved the security of its client computing platforms, especially Windows 7. Attackers have a much more difficult time attacking the OS directly as compared to Windows XP. That's why malicious hackers have increasingly shifted their efforts to five popular third-party applications, most notably the Java Runtime Environment (JRE), Adobe Flash, Adobe Acrobat and Reader, Internet Explorer and Apple QuickTime.

The exploits and the malicious actors responsible for them are never going away, so I say why not ban dangerous apps? If the threat isn't going away and suitable low-cost replacements can satisfy users, isn't the approach worth consideration?

Research indicates that a limited number of exploits in just a handful of widely used third-party applications are responsible for nearly all successful enterprise malware infections on Windows clients. According to research released in September by Copenhagen-based research firm CSIS Security Group A/S, a three-month study of real-time attack data showed as many as 85% of all virus infections occurred as a result of automated drive-by attacks created with commercial exploit kits, and nearly all of them targeted the five applications noted above.

So are these applications inherently insecure? Not really. Frederik Braad, head of operations for CSIS, told me there are two key reasons why they pose an opportunity for attackers.

"What makes them interesting to attackers is their almost ubiquitous nature," Braad said. "They're installed almost everywhere, and they are easy to execute from a Web-based environment."

The other reason, Braad said, is that enterprises struggle to promptly implement security patches for third-party applications. Even when application vendors promptly identify and address security flaws, he said most organizations can't or don't employ them within 2-3 weeks, which is often all the time an attacker needs to work the flaw into any one of several popular exploit kits and roll out a new drive-by attack method.

It's not that these applications are hard to patch; far from it. While CSIS offers a free tool called Heimdal Agent to help home users patch their third-party applications, Braad said most enterprises struggle with the process. He said even though widely used software systems management platforms like Microsoft System Center or IBM Tivoli can adeptly handle the rollout of third-party security fixes, organizations either struggle to quickly identify and test high-priority security patches, or simply don't make it a priority.

"You need to really assess the importance of security patches individually if you want to maintain a good balance between security and stability," Braad said. "And that's the issue: This raises extra complexity because suddenly you need a lot more knowledge about when certain builds are being exploited in the wild, and that complexity is hard to handle."

However, there's an emerging school of thought that suggests focusing on which applications to patch, and even use, is an approach that's doomed to fail.

"From the defender's point of view, every single piece of software you have is crap," said Dan Guido, adjunct professor at the Polytechnic Institute of New York University. Guido is also the security researcher behind the Exploit Intelligence Project (.pdf), a two-year effort that applied an intelligence-driven approach to malware defense to identify the most effective ways to thwart mass malware.

Guido said new vulnerabilities are published constantly, but vulnerabilities mean little unless they can serve as the basis for an effective exploit. "It takes real effort to write a modern exploit that works on a current version of Windows, and there are ways you can prevent yourself from being exploited while using exploitable software."

According to the findings of the Exploit Intelligence Project, which analyzed trends in mass exploits during 2008 and 2009, implementing just five or six key configuration changes would have secured enterprises against nearly all of the exploits attackers used during that period.

For example, Guido said enterprises can avoid many memory-related exploits simply by implementing memory-protection safeguards like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR), features now built into the latest versions of Windows and the Microsoft Visual Studio compiler for application developers. Similarly, he said turning off unnecessary and highly exploitable functions inside certain applications, like disabling Java when a Web browser accesses the Internet zone (and optionally allowing browsers to use Java on intranets and with internal applications) can also choke off many exploits before they can do harm.

"You don't have to have a perfect defense," Guido said. "It just has to be one step better than the attackers." 

By focusing on these key controls, Guido said enterprises can not only stop worrying about which applications face a greater exploit risk, but they can also scale back security patching efforts.

"By taking a more proactive approach, a lot of these updates for minor patches become superfluous because a lot of the exploits being used don't work against your applications anymore," Guido said. "It becomes far more important to focus on major version changes, like upgrading Adobe Reader from version 9 to version 10 because version 10 has a sandbox, but I can mitigate the exploits covered by all the minor patches by using advanced memory protections, so if I don't want to patch those minor issues, I don't need to."

As you can imagine, it was harder to convince Guido that some of these third-party applications simply have to go away, but Braad largely agreed with my premise; he said transitioning an organization away from commonly exploited applications and using less popular alternatives would prevent some exploits because many of them target the libraries specific to those applications. If everyone suddenly had the same idea, he noted cautiously, those alternative applications would become targets and the benefits would decrease.

Ultimately it would be great if organizations didn't need to consider which applications aren't worth the risk, and for that reason most would be wise to consider the lessons learned from the Exploit Intelligence Project. Even though banning the use of attackers' favorite third-party applications is essentially security through obscurity, and would no doubt rile up a few end users in the process, dodging the vast majority of malware infections seems like a great New Year's resolution to me.

Eric B. Parizo is senior site editor of TechTarget's Security Media Group. His rants can also be heard each month on SearchSecurity.com's Security Squad podcast.

This was first published in January 2012