Exploits v. Vuln Checks

Dave G. | April 28th, 2006 | Filed Under: Matasano

nCircle has a blog post on the difference between writing exploits and writing vulnerability checks (think nessus). The basic summation is that they are two different skillsets that aren’t necessarily present in the same person, and that maybe one is harder than the other.

Or, in other terms, vuln check writing is more of a ’strategic’ pursuit, whereas exploit writing is more ‘tactical’. If we (for the purposes of argument) associate ‘exploit’ writing with attacks, and ‘vuln checks’ with defence, then this premise is backed up by the empirical observation that an attacker only needs to be succesful once, whereas a defender needs to be successful *all* the time to avoid security breaches.

Worst use of strategic vs. tactical ever.

I have written both vulnerability checks (ISS, Network Associates (and some private Nessus checks)) and exploits. While they are different, I wouldn’t go as far as to say that they are different skillsets. They are two approaches to the determining whether or not a vulnerability checks. When written by professionals, the goal is do it in a way in which no one noticed that the test ever happened. Crashing a service, or triggering an IDS alert is probably bad whether you are a vulnerability scanner or an attacker. In some cases, I think writing good vulnerability tests can be harder than writing a good exploit. In others, exploits are harder. I think in the case of one-shot exploits, vulnerability tests that do not involve banner grabbing (which should almost certainly NEVER be used), can be incredibly difficult to write.
Finally, with products like ever-Cool Core Impact and Immunity’s CANVAS, the lines between vulnerability test and exploit is blurred. They are all a pain in the ass to write, and I am glad I don’t do either professionally.

Viewing 3 Comments

    • ^
    • v
    "Worst use of strategic vs. tactical ever."

    Why do you say that? I thought it was pretty good ;) Think about it from a militaristic perspective.
    • ^
    • v
    I agree, the initial analogy makes some sense; however, the way he uses offense/defense methodology to justify it seems kind of silly. The way I see it, you'll have to test for vulnerabilities long after the better majority of systems exhibiting the bug have been patched.

    It seems the breakdown in the analogy is that vulnerability checks are both a strategic AND tactical approach to the vulnerability problem at large, while exploits are merely a tactical approach.

    It pays to know in the long term what systems are still vulnerable, so there's always a use for the check-based scanner. As the number of affected machines, for a given vulnerability, decreases so does the value of the exploit.

    I agree with Dave's observation that checks and actual exploits are better viewed as alternative ways of approaching the same problem, as opposed to trying to classify one approach as a short term solution, and one as a long term solution is convoluting the facts, and more so than necessary.

    If you need to choose between the two, vulnerability checks (that actually work) are an inherently better approach to internal asset assurance inventory than working exploits are; and strictly because of the fact that they retain their value pre-exploit, pre-patch, post-exploit, post-patch. The same can not be said for a working exploit. Not to mention the fact that the majority of bugs you are going to be able to exploit remotely, usually do not involve a memory layout that allows you to successfully exploit a vulnerability without corrupting some stack/heap data.

    Also, relying on successful exploitation, or service failure, to ascertain exposure to a vulnerability is a momumental fuck up of epic proportions.

    -ds
    • ^
    • v
    dear mr. -ds , regarding your last comment:
    "Also, relying on successful exploitation, or service failure, to ascertain exposure to a vulnerability is a momumental fuck up of epic proportions."

    That is an interesting thought, I remember reading about it more that 10 years ago when Farmer and Venema published a paper titled "Improving the security of your site by BREAKING into it", someone should tell them they've been wrong for a decade.
    I guess nothing has changed in the infosec industry since 1996 then and I should start looking for a job in the firewall or av industry.
    As for the value of exploits pre,post and forever after patch deployment (or ex-ante and ex-post as my friendly lawyer likes to say) all I can say is that patches not always patch, sometimes they are not even properly deployed, sometimes they are properly installed but the box remains vulnerable due to lack of proper reboot, sometimes they are removed, overriden by others or the bugs they patch are not necessarily the same ones they claim to patch so it may be useful to have exploits laying around just to check that you are right (it sounds reasonable, but maybe its just me being stubborn and wanting to check things by myself instead of trusting the patch issuer or great patch deployment system as I've been told to do)

    I did not understand the following part of your post, would you explain what you meant?

    "Not to mention the fact that the majority of bugs you are going to be able to exploit remotely, usually do not involve a memory layout that allows you to successfully exploit a vulnerability without corrupting some stack/heap data."

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus