More techniques available for poisoned document attacks

By Derek Manky, security researcher, FortiGuard Global Security Team, Fortinet | Sep 28, 2010

0 comments

Digg

 Email

 Print

Attacking systems for sensitive information for the purpose of espionage or monetization is certainly not new. In fact, it's a predictable aspect of crime because in our modern cyber era, digital information flows with ease, as systems become further integrated. The new trend that we continue to observe involves the vehicles that are used for these attacks.

Documents are used frequently by governments, corporations and beyond. There are many forms of documents (PDF, DOC, XLS), with many readers to display and edit these documents. In the eyes of a cyber-criminal, where there is high traffic and data usage, there is an opportunity to attack.

Poisoned document attacks occur when a legitimate document file is altered to contain malicious byte sequences. When the reading software opens the document file, it comes across the unexpected information which subverts the process to the malicious code.

To successfully execute an attack, the attack must be tailored for the reading software. For example, an attack that works on Adobe Reader (PDF) might not work with a FoxIt Reader, and vice versa. Likewise, an attack that works on a specific version of a reader might not work on subsequent versions, since the vulnerability that the attack exploits may have been patched.

Poisoned document attacks have been around for a while. The key difference now is the growing number of techniques (vulnerabilities) that are available to an attacker to execute the poisoned code that lies in a document. Due to a number of hurdles that have been implemented by developers, a successful attack is harder to execute today than it was 10 years ago. For example, technologies such as MS Windows 7's implementation of data execution prevention (DEP) and address space layout randomization (ASLR) have been implemented to stop traditional attack techniques. As software is patched, new security holes must be discovered and exploited.

There are two problems here. First, patch management practices are not always up to par when they should be. Software patches that fix security issues should be patched immediately, since that closes the gap that would let an attacker through. Time and time again, we have observed old (patched) attacks that continue to be successful because of this problem -- the Conficker worm is a great example.

The second problem is that even though attacks today are harder to implement, the amount of resources available to an attacker are far greater than they were before. This means that though the challenge confronting the attacker is more complex, the net effort is less because an attacker may use a network of machines, tools and humans to help create and launch such an attack.

0 comments

Digg

 Email

 Print