Shielding Targeted Applications

When we discuss exploit prevention, we often talk about ‘targeted applications.’ This term refers to end-user applications which can be exploited by hackers for malicious purposes. There are a few requirements that define these applications.– They receive external content: In order to deliver the exploit, the attacker must be able to provide the user with specially crafted content that contains the malicious exploit (a.k.a. weaponised content). This can be for example an HTML web page that contains a hidden Java applet, or an email attachment (like a Word document, Excel Spreadsheet, or PDF document) that contains hidden code. This code executes when the application (i.e. browsers, Java, Word, Excel or Adobe Acrobat reader) opens the content, and exploits vulnerabilities in these applications to download malware on the endpoint.  If an application does not receive external content, it would be impossible for the attacker to deliver the weaponised content and the exploit.

– They have vulnerabilities: Vulnerable applications provide the attacker an opportunity to develop an exploit. Some applications contain more vulnerabilities than others. And some vulnerabilities are easier to exploit. An application that has many exploitable vulnerabilities will be targeted more often. Zero-day vulnerabilities, which are vulnerabilities that are unknown to the public, are more likely to be successfully exploited because there is no patch available. But zero-day vulnerabilities are not a requirement. Interestingly, known application vulnerabilities are still exploited because many users do not apply security patches in a timely manner.

– They are common applications: common applications that can be found on most user endpoints are targeted more often than uncommon, specialized applications. Of course the more common the application is, the wider the attack surface it provides.

– There are exploits available: Exploit code must be developed in order to exploit the application vulnerability. If the vulnerability exists, but no exploit code was developed, the risk remains theoretical.

Considering the listed requirements for targeted applications, it is not surprising that the most targeted end-user applications are: the browsers, Java applications, Adobe Acrobat, Flash, Word, Excel, PowerPoint and Outlook. These are all common applications found on most user endpoints. They all receive external content that can be “weaponised.” They all contain vulnerabilities: most of them are known but periodically we hear about zero-day vulnerabilities. And exploit kits that contain exploit codes are widely available.

If we take for example the RSA breach, according to the blog RSA posted, the attacker used a spear-phishing campaign to deliver a weaponized attachment to employees. The spear-phishing email included a weaponised attachment – an Excel spreadsheet, containing a zero-day exploit object. It exploited an Adobe Flash vulnerability (CVE-2011-0609) to silently install a customized remote access Trojan known as the Poison Ivy RAT.  Both Excel and Adobe Flash are common targeted applications that can be found on most user endpoints.

Any advanced threat protection and exploit prevention technology must ensure that these targeted end-user applications are not successfully exploited. Since these applications are very different from each other, special controls may be required for each application. For example – Java applications are vulnerable to both native exploits (execute at the memory level) and applicative exploits (execute in the user space by breaking out of the JVM sandbox). Solutions that apply granular controls at the OS level to protect against native exploits would not be able to protect against applicative exploits.

by Dana Tamir, director of enterprise security at Trusteer