There has never been more focus on security than there is right now, whether it’s from software vendors looking to eliminate flaws in their products, from attackers looking to exploit those flaws or from customers who are sick of having their PCs compromised. And as the focus has intensified in recent months, researchers say that, for a variety of reasons, it has become increasingly difficult to find exploitable client-side bugs–particularly memory-corruption flaws–leading them to dig deeper and find more exotic bugs.
To find evidence of this trend, you need look no further than the DLL-hijacking flaw, the recent LNK bug and even the iPhone bugs used in the Jailbreakme.com incident. None of them was a simple, cleanly exploitable flaw, and in the case of the Jailbreakme.com flaws, involved chaining together several bugs in order to break out of the iPhone’s sandbox, escalate privileges and run code. This is not how it used to be.
For most of the last decade, server-side bugs were the holy grail for both attackers and security researchers. Everyone was interested in finding remotely exploitable vulnerabilities in Web servers, database servers and other back-end systems. This was in the heyday of network worms such as Code Red, SQL Slammer and Nimda, all of which were high on the annoyance scale but didn’t do much in the way of actual damage. None of these worms was designed to steal data or install keyloggers or rootkits that could stay behind for months or years.
But the latter part of the 2000s saw the rise of professional crews of attackers who are focused solely on making money from their activities, and they have almost no interest in server-side bugs. The whole game for them is compromising endpoints full of valuable data, and that means finding and exploiting client-side flaws that get them into machines on their target network. In the course of the last five years or so, this reality has helped draw the attention of security researchers and the internal security teams at vendors, who have combined to identify and fix an untold number of these bugs.
With more people looking and more awareness of the problem of software security, many of the more common buffer overflows and other memory-corruption bugs are being found and fixed before applications are released. And when those bugs do slip through now, there are exploit mitigations such as ASLR and DEP in place in many cases that limit the potential damage from a successful exploit. All of this is making the job of finding exploitable bugs more challenging than ever, researchers say.
“It’s unclear why it’s harder to find exploitable bugs now. But it’s harder than it was. We’ve moved to client sides and now people have moved on to other things like [Adobe] Reader,” said Charlie Miller, principal security analyst at Independent Security Evaluators, known for his research on Mac OS X and iPhone bugs. “It used to be that if you found ten bugs, nine of them would be exploitable. It seems like every year it’s getting harder to write exploits. It keeps getting harder, and now you end up with something that involves Java plus a DLL plus something else. Everything is unserialized now.”
Two recent examples have underscored the idea that researchers–and attackers–are having to dig deeper to find exploitable flaws. The first is the discovery earlier this year of the LNK vulnerability in Windows that enables malicious code to run directly from a USB drive or WebDAV share without any user interaction. The bug was unknown publicly until researchers discovered a new piece of malware called Stuxnet that was exploiting it. The flaw involved the way that the Windows shell handles shortcut icons, and not only was a worm exploiting it, but the worm was in the wild for some time before researchers noticed it and dug into the problem.
The LNK bug is a prime example of the kind of flaw that isn’t likely to be found by fuzzers, scanners or other tools designed to eliminate bugs during development and pre-release testing, experts say.
“We’re seeing a progression away from the traditional memory corruption vulnerabilities and 
towards more logic-oriented vulnerabilities. Logic bugs often result from insecure design decisions (eg. loading DLLs from the same directory as an opened file) that can be exploited by an attacker as opposed to one-off mistakes that allow out-of-bounds memory corruption,” said Jon Oberheide, a security researcher and co-founder of startup Scio Security. “Logic bugs are interesting since they flip the discovery/exploitation equation around. Memory corruption bugs may be easier to find with our modern vuln-disco tools but can be very difficult to reliably exploit, while logic bugs tend to be more difficult to discover with automated tools yet their exploitation is usually trivial and simple in nature.”
The second example is the DLL-hijacking bug that has garnered so much attention of late. Researchers–and Microsoft–have known about this class of vulnerabilities for more than 10 years, but was thought to be of limited use and only exploitable locally. However, research done by HD Moore of the Metasploit Project and Rapid7, and others showed that not only could the bug be exploited remotely, but that dozens of applications are vulnerable to the problem.
The DLL bug is an OS-level problem that does not seem to have an easy fix, experts say. And it seems likely that there are more of these vulnerabilities on the horizon, as both researchers and attackers continue to dig deeper into the applications, browser plug-ins and mobile operating systems that are at the heart of today’s computing environments.
The good news in all of this is the fact that exploit mitigations, software-security efforts and other factors are not just making life more difficult for researchers, but are also raising the bar for attackers looking for exploitable bugs. As a result, the attackers and malware authors are putting more of their effort into scams such as scareware and phishing that rely not on bugs, but the inexhaustible supply of gullible users.
“My theory is that developing reliable exploits is becoming difficult enough that malware authors get more ROI on social-engineering based malware such as rogue anti-virus scams. Vulnerabilities used to be much easier to turn into reliable exploits, whereas now it often takes considerable effort and even then, success is not guaranteed,” said Dino Dai Zovi, and independent security researcher. “This is largely due to the proliferation of exploit mitigation mechanisms in consumer operating systems. Now, attackers must often combine the vulnerability with advanced mitigation bypass techniques in order to produce a reliable exploit.”
Some of the credit for making the process of finding exploitable bugs more difficult must go to vendors such as Microsoft, Adobe and Google that have made an effort in the last few years to add technologies to help prevent exploitation. Mitigations such as DEP and ASLR, which are designed to prevent exploitation of memory-corruption bugs, have made a difference in the exploitability of browser-based flaws. And the addition of a sandbox to Google Chrome and Adobe Reader has had a similar effect, making it more difficult for attackers to use these applications as jumping-off points for further attacks.
“It is encouraging to see that some vendors are wising up to stop playing the vulnerability whack-a-mole game and are focusing on that last factor: protection mechanisms that try to maintain integrity in presence of bugs: Adobe with Reader Protected Mode, Microsoft with Office Protected Mode, Google with Chrome’s sandbox, etc.,” Oberheide said. “It’s a combination of a number of factors across all levels of software security: better development procedures (SDL), hardened toolchains (FORTIFY_SOURCE, RELRO, PIE, stack cookies), better tools for vuln-disco (fuzzers), platform-level mechanisms that impede exploitation (DEP, ASLR), and least-privilege mechanisms that reduce the impact of exploitation (sandboxing).”
But, as Miller points out, exploit-prevention is by no means a solved problem.
“It used to be easier, but now it’s some super-complex thing you have to use to exploit a bug,” he said. “But the thing is that there’s always someone smart enough to do it.”
