Cost of finding vulnerabilities vs developing exploits

Question

From the perspective of someone who wants to develop a zero-day exploit against some software application or target, there are broadly speaking two tasks that the attacker must do: (1) find a new exploitable vulnerability in the software; (2) develop a reliable, weaponized exploit for that vulnerability.

For instance, fuzzing, reversing, and static analysis might help find the vulnerability; but then it takes separate analysis and work to build a reliable exploit.

Which of these two tasks tends to cost more, on average? I'm wondering what do the economics of this look like, and to get a sense of the ratio of costs for these two tasks. I know that if you look at a single vulnerability, the costs will depend on the vulnerability, but I'm asking about the average case. For instance, if we looked at a company that develops exploits, in aggregate, would we expect more of its budget to go towards 1, or towards 2?

Assume we're attacking a widely-used, relatively mature end-user software application.

Answer 1

The relative costs depend very much on what the vulnerability is. To demonstrate this, I'm going to refer to two semi-recent vulnerabilities: the Bash "Shellshock" bug, and the glibc "Ghost" gethostbyname() bug.

Shellshock

The Shellshock bug was caused by an intricate flaw in Bash's function parsing that could be used to make Bash execute code directly out of environment variables. The bug existed for roughly 22 years before it was publicly found.

A check for whether the bug exists looks like this:

$ env X="() { :;} ; echo vulnerable" /bin/sh -c ":"

Now, finding that bug takes either careful scrutiny of the source code, or a good session with a code fuzzer. But as soon as it's reduced to a test case like this, exploits come easily. For instance, if you know a target server is running a CGI shellscript:

$ nc vulnerable.example.com 80 <<__END
GET /path/to/cgi.sh HTTP/1.1
Host: localhost
User-Agent: () { x; }; printf "%s\n\n" "Content-type: text/plain"; /usr/bin/id
Accept: */*

__END

So Shellshock was hard to find, but once found, it was trivial to exploit.

Ghost

The glibc gethostbyname() vulnerability, on the other hand, is a buffer overflow vulnerability that can only happen under certain very specific conditions. An attacker can overwrite at most 8 bytes of memory on 64-bit machines, or 4 on 32-bit machines. The attacker has to set up a specially crafted DNS entry, then trick the target into requesting it.

This bug went unfixed for around 13 years, and when it was fixed it was not recognized as a security vulnerability. The Qualys security researchers who did report it as a vulnerability spent a large amount of time testing individual programs for exploitability. A large majority were not, due to the 8-byte limitation and the particulars of how gethostbyname() is typically used. Note too that simply triggering the bug will generally cause the program to crash: more a denial of service than an exploit.

Their coup de grace, a full remote exploit of the Exim mailserver, is a meticulously engineered Rube Goldberg chain that managed to work around the limitations using specific properties of how Exim happens to organize its memory in specific situations. It's described fully in the security advisory from Qualys, and is too complicated to go into here.

Comparison

I will admit I'm not sure which bug was harder to find. Both sat latent in the code for a long time. Qualys found the Ghost bug "during a code audit"; Stéphane Chazelas found the Shellshock bug by extrapolating from things he already knew about Bash behavior, and an entire series of related bugs were found very quickly once people knew where to look, some with the help of fuzzing tools.

However, the question of which was harder to exploit is much easier to answer. I think it's clear that a very high level of engineering went into finding a way to turn the Ghost bug into a working Exim exploit. Much more work was required than the Shellshock exploit above, which took about 10 minutes to write and test.

Answer 2

Writing an exploit utility is nothing for an experienced programmer. And it's not a software for end-users, so you don't need for a user-friendly interface, no need for fancy things. It's just a quick dirty utility to exploit the vulnerability, so this isn't a big expensive software, it is a tiny cheap software. And you can talk about an ETA. You know when you get your investment back.

Discovering a new vulnerability is much much more harder in a mature software, compared to developing the exploit. And you don't know if you can find soon, or ever, no ETA, you don't know when you get your investment back, or ever. You are searching for something that developers don't want to be exist. There is a competition also, others can discover before you.

If the software is an important one (OpenSSL for example), it gets incredibly hard because of the competition. Because discovering a critical vulnerability equals to inventing a super weapon for cyber wars, like HeartBleed. NSA is probably spending tons of money every year for this kind of researches, and probably they already have some serious 0-days.

So, cost of writing an exploit is negligible comparing to searching for a brand new vulnerability.

Any data? Please see some exploits in https://www.exploit-db.com/ There are vulnerabilities which remained undetected for several years, yet their exploitation is quite simple and easy with 100-200 lines of Python.

3-4 weeks ago, a new vulnerability discovered publicly in OpenSSH before 7.2p2 (all versions; dating back ~20 years), which allows remote authenticated users to bypass intended shell-command restrictions via crafted X11 forwarding data.

And here is the exploit: https://www.exploit-db.com/exploits/39569/ 150 lines of Python.

BTW, don't forget to check your openssh-server package. I have Ubuntu 14.04 installed, and after upgrading packages I still have 6.9p1 version.