Tougher times for exploit developers, but more at risk

Posted by Gunter Ollmann on October 27, 2008 at 12:51 PM EDT.

Vulnerabilities are getting harder to exploit. Not all vulnerabilities, and not all of the time, but in general, those juicy vulnerabilities that would provide an attacker remote control of a host through a default network service running on a current generation operating system – they’re the ones getting considerably harder to exploit (reliably).

At least, that was the premise of a few discussions I’ve had over the last month at a handful of security conferences and wanted to share with you today.

Now, before I dive in to the detail, a little context first. I’m not talking about Web application vulnerabilities (in fact I once argued that Web application vulnerabilities weren’t vulnerabilities at all – just 'Easter eggs' that the developers didn’t really know about), but rather compiled binary applications with memory corruption vulnerabilities that could be exploited through ‘traditional’ heap and stack overflow processes. I’ll also exclude for the time being those other (increasingly rare) vulnerabilities that just allow the attacker to use the binary application in an unexpected way – such as "features" designed to allow an application to download an update, but can be manipulated to download anything and place it anywhere on the host (don’t you just love those kinds of vulnerabilities?).

Back to the meat of this blog entry…

So, I was at the OWASP 2008 conference in New York (presenting on Multidisciplinary Bank Attacks) and I bumped in to Dave Aitel (who was presenting on Memory Corruption and Buffer Overflows), and then a couple of weeks later I was at the Virus Bulletin 2008 conference in Ottawa (presenting on Intentions of Capitalistic Malware and later, covering for a colleague, How Secure is your Virtualized Network?) and bumped in to Thomas Dullien (aka Halvar Flake), and ended up having a near identical chat about how it’s getting tougher to be an exploit developer.

Both Dave and Halvar, as respected experts in reverse engineering and exploit development, have made a several comments over recent years about how difficult it can be to develop exploits for the latest generations of mainstream operating systems. In fact Dave’s presentation ended with his infamous Giraffe image – representing the evolutionary steps needed to succeed in tougher times (e.g. as things get tougher to reach, you need to invest in specialized equipment and talents (the Giraffe’s long neck))-- sorry Dave if I bollixed up your interpretation.

Memory Protection

The basic premise of the discussions was that it’s getting more and more difficult to craft a reliable exploits because of the various implementations of memory protection – which in turn makes it more and more expensive to develop those exploits.

The techniques developers have available to them to help thwart the reliable execution of an exploit are many (even if they go out of their way to write buggy code themselves). Heap and stack cookies (/gS), SafeSEH, process isolation, system call ACLs, ASLR and DEP/NX/W^X/PAX etc. all increase difficulty, while advances in automated code review and the use of managed languages raise the bar even further.

Now, not all of these apply to each and every operating system out there in public circulation, but most of them (and a few extras) are packed in to the latest operating systems that the general Internet population uses. As such, for a reliable exploit to be developed, the exploit writer has to contend (and overcome) each of these memory protection technologies.

But you should note that there are plenty of guides and whitepapers out there on how to defeat and bypass just about all of the memory protection technologies out there. So, it’s less of a question being thwarted by technology, and more about knowing how to cascade all the bypass techniques to achieve exploitation.

While I’ve heard some people mistakenly think of this as having to “get all the stars in alignment”, I’d be inclined to point out that an experienced reverse engineer and exploit writer doesn’t rely upon astronomy – instead, they can be trained to do this.

Exploitation is Expensive

Therein lies the rub, and where Dave’s giraffe enters the picture. Because the knowledge bar continues to rise, it’s getting increasingly difficult to start a new career as an exploit writer. Yes, there are public courses out there which will teach you how to write exploits – but surely you’ve also noticed that these courses focus on old operating systems (e.g. Windows 2000)? -  OS’ without the latest advances in memory protection.

Back in the “old days”, knocking out an exploit could be done with relative ease. In the 1998-2002 timeframe, the vast majority of juicy buffer overflow vulnerabilities could have had exploit code produced within hours – or a few days at most. Nowadays, writing an exploit for the same type of vulnerability – but one that now must work on Windows Vista and fool its memory protection technologies – is a much more daunting task, and can take several man-months to produce.

What all this means is that training up a skilled exploit writer is an increasingly time consuming and expensive exercise, and that those skills are migrating away from the “bedroom warriors” (i.e. script-kiddies and teenage hackers) and on to professionals that have likely invested in multiple years of training.

For example, any commercial security company looking to internally train-up a reverse engineer capable of writing exploit code for vulnerabilities in the latest enterprise operating systems will likely have to invest in 2-3 years of training – so, a ballpark cost of something like $250,000+

So, while the good news is that those skills are getting rarer and more costly to acquire (and consequently we have less to worry about from an exploit code publishing perspective), the bad news is that there is a growing (and profitable) market for both their talents and their output.

Exploit Currency

OK, so exploitation is getting tougher, the skills necessary to write those exploits are getting rarer, and the costs of “getting started” and training as an exploit writer are on their way to getting prohibitively expensive. Does that mean that in another 5 years or so we won’t have to worry about new exploits?

I can imagine a future where the number of “damaging” public exploits are few and far between (in fact, when was the last time you spotted a new sexy self-propagating worm?), corporations begin to feel more secure with their protection investments, and there is less pressure on the major software vendors to implement newer and more advanced memory protection systems.

However, I’d be wary of that final level of complacency. Sure, it’s likely that less people will have the skills necessary to write a reliable exploit of any significance, but it doesn’t mean that the threat fades to history. What it does mean is that those skills increasingly only become accessible to those organizations capable of training and funding a reverse engineering and exploit development team.

While those “organizations” encompass the major security vendors, and increasingly government-funded cyber-warfare divisions, it needs to also include the latest incarnations of organized cyber-crime syndicates.

If there’s one thing that can be said of organized cyber-crime, it’s that they’ll go where the money is. And, today, there’s an increasingly valuable market for reliable exploits. We’ve all observed the market for vulnerability information develop and mature, but frankly the exploit market is the one that we need to watch. I think that, as the value of exploits continue to rise, we’ll see less public and ostentatious use of exploit material – and instead, we’ll see more guarded and targeted use of exploit materials – as the purchasers will try to extract maximum value from their (sizable) investment.

Don’t Forget

But let’s not forget that not all vulnerabilities are created equal, and not all exploits are that difficult to construct. For example, consider last week’s Microsoft MS08-067 Server Service vulnerability. Ignoring the fact that exploit material was already circulating in the form of malware beforehand, but it only took a few hours for some commercial exploit development teams to knock-up a reliable exploit upon learning the nature of the base vulnerability.

On top of that, while memory protection mechanisms play a critical role in thwarting some of the exploitation vectors, they can be bypassed – or they may have been missed out entirely by the software developer for some historical reason.

But that’s why security vendors like IBM invest in their own teams of reverse engineers and train up on the latest exploitation techniques – and will continue to do so. There’s a reason why X-Force has been capable of protecting against exploitation of MS08-067 since August 2006 :-)