Vulnerability Fishing

Dave G. | May 9th, 2006 | Filed Under: Disclosure, Industry Punditry

I once quoted Dave Aitel as comparing vulnerabilities to Sea Bass, and since I still like that analogy, I am going to extend it. I think there are two extremes of effective vulnerability fishing, harpoon fishing and fishing with dynamite. They have distinctive styles, and even patterns of discovery.

dynamite fishing

Dynamite:

  • Finds symptoms before cause
  • Less likely to find complex vulnerabilities
  • Covers wider attack surface faster
  • Fares well against code that has already been manually audited

Harpoon:

  • Finds cause before symptoms
  • Less likely to find bugs not apparent in code
  • Investigates attack surface in depth
  • Will fare better in well tested code

The vulnerability identification curve is totally different. When put head to head, Dynamite tends to have a steeper vulnerability identification curve. In other words, Dynamite will start finding vulnerabilities sooner. Dynamite will also tend to stop finding vulnerabilites sooner. Harpoon will find that subtle conditions that automated tools (e.g. fuzzers) are less likely to find, simply because it requires specific conditions to exploit. Consider the ISS Sendmail Remote Signal vulnerability. For that matter, most of the vulnerabilities found by Mark Dowd in recent years were probably found with extensive code review. He clearly fishes with a thermal laser… guided by satellites.

Of course, few pen testers/vulnerability researchers are exclusively one or the other. There is no doubt you want both approaches being done on any penetration test.

ps: This post was originally titled Monkey With A Gun vs. The Sniper. Both are pretty dangerous, but it is biased. Besides, I’m reasonably sure I am smarter than a monkey.

Viewing 6 Comments

    • ^
    • v
    The dynamite and harpoon fishing illustration is powerful and right on the money. But in these times the Mark Dowd/random world class researcher with satellite guided thermal lasers illustration is more interesting. The fact is that even as expertise is still as vital and important to successful vuln research today as it was a decade ago, tools and time saving techniques for "harpoon fishers" are becoming just as critical. Will this trend compress the vulnerability identification curve (cool term btw) for the harpoon fishers a little bit going forward? I think it will; but it will never be as compressed as the curve for dynamite fishing.
    • ^
    • v
    Josh:

    re: tools... I agree! I think we have already seen some movement in that direction. Tools like IDA Pro/BinDiff let researchers dig into places a lot faster than what we had 10 years ago. What other kinds of tools do you (or others!)think are missing in this space that would assist in the process that dont exist today?
    • ^
    • v
    But Dave, we're all monkeys :) Just hairless monkeys with improved communication skills and cognative reasoning (which more often than not fails the Pepsi challenge amongst the general populous).

    I agree though, you are probably smarter than a monkey.
    • ^
    • v
    Interestingly enough, Dave, Dino and myself all failed the Pepsi challenge.
    • ^
    • v
    "What other kinds of tools do you (or others!)think are missing in this space that would assist in the process that dont exist today?"

    I'll take a stab at this.

    Open Source:
    A _working_ SLINT-esque set of extensions for compilers would be a good start.

    Closed source:
    A utility that used input function footprinting to track the flow of user supplied data through proces memory that also cross-referenced the validity of heap memory, malloc chunk headers, and the integrity of the registers in a given stack frame.

    'I know that memory at 0xXXXXXXXX has been populated with user supplied content, let's tag every reference to the memory location in the text segment, and back trace up the function heirarchy until we figure out all the different ways we can manipulate the data to trigger functions which are accessing the offending address.'

    (Ed. Note: Yes, I did just refer to user supplied data as offensive, because it is, pun intended.)

    I'm guessing it would almost be like teaching a runtime debugger to generate and 'read' a flowgraph, and then ascertain the different input syntax criteria that would activate different function call paths within the application.

    This could theoretically be accomplished by 'tagging' functions which reference user defined memory, finding and tagging all references to the functions themselves, asctertaining all the conditional jump/branch statements that have to be satisfied for the desired call-flow to hit the offending function. At this point, we've essentially figured out exactly how we should be fuzzing in the first place.

    (Ed. Note: Yes, functions processing, and copying user supplied data are also offensive. Necessary, but still offensive ;) )

    Auto-exploit generation anyone?

    If someone could manage to do that, you'd basically be adding a satellite guided thermal laser with a scope onto your fuzzer.

    Actually, if what I've outlined here is actually possible, you could have the debugger do runtime fuzzing autonomously ;)

    I think I'd call it "Smart Fuzzing", "Non-Blind Fuzzing", the Frank Zappa-esque "Not-so-fuzzy Fuzzing", or "AutoFuzzing". I was never good at naming these things.

    This does seem a bit grandios to be plausibly implementable though. Your thoughts?
    • ^
    • v
    I failed the spelling test on cognitive.

Trackbacks

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