- So let's talk a little bit about fuzzing.
We talked about buffer overflows before
and you know what they were and how to exploit them.
Now we're gonna show how to find vulnerabilities
like buffer overflows,
and one of your primary tools
aside from things like code inspection,
where you're looking at the source code is to use fuzzing.
Fuzzing is testing
that you would feed a program unexpected data,
and that data could be malformed data.
It could be unexpected data, you know,
it could be expecting an IP address
and you feed it an IPv6 address, for example.
And it'll take action based on that input
and it'll do something with it.
And sometimes you could cause the program to crash.
And so fuzzing is also called negative testing.
You also hear it called robustness testing.
And then, in other words,
you're testing how robust the program is
to certain kinds of input
and this unexpected data, like I said, it could be invalid.
It could be just random data.
It could just be garbage,
that comes from a random number generator
that you feed to it.
And you see exactly what happens
and what'll happen is occasionally the program will fail.
It will hang sometimes.
In other words, it'll get into an infinite loop
and just consume a hundred percent CPU.
And in that case what you'll do
is you monitor the program.
And if the program crashes or goes into that state
you'll see what message you sent to the program.
And so in other words, you know the input
that was being sent to the program
and you say, look, something happened,
let's figure out what happened.
And in other cases you could crash.
But when you crash,
it's important to know, am I crashing in the same location?
Is it, you know, is the input maybe different
but is it the same where it make me crash in the same place?
Are these crashes exploitable?
I mean, if it's a null point or de-reference,
that may not be as interesting.
When I say null point or de-reference,
that means I'm actually reading from address zero
which is not mapped into a process typically.
You wanna know whether or not a particular vulnerability
is exploitable.
And if the program crashes
an EIP is set to something you control,
then that's a great day, right?
You found a buffer overflow vulnerability on the stack
and you have direct control of the instruction pointer.
And so there are different types of fuzzers.
We'll start with the dumb or mutation based fuzzers.
And what these do is these take a known good,
well-formed message,
and you somehow change it or massage it,
so that it's changed a little bit and maybe corrupted.
And that collection of known good messages
is called a Corpus.
Now let's say you're fuzzing a JPEG file, which is an image.
And so you would want to have a collection of images
that exercise different parts of the code.
You have smart or generation based fuzzers.
And these have a data model
that you have to program ahead of time into the fuzzer
so that the fuzzer can create the message
sometimes from scratch.
And then further along, you have evolutionary-based fuzzers,
and those fuzzers actually monitor the program itself,
and they glean heuristics from the program
to figure out if you're exercising the code
that you wanna exercise.
So it's constantly checking whether or not,
you know, you're actually running the code
that you expect to run.