A fuzzing technique will try every possible type of random input to an application to see if a security problem can be found with the application’s programming. In this video, you’ll learn how fuzzing works and I’ll demonstrate fuzzing with an application in my lab.
<< Previous Video: Vulnerability ScanningNext: Secure Coding Concepts >>
Fuzzing is a very interesting vulnerability testing and application testing technique. It’s one that you may hear referred to as fault-injecting, robustness testing, syntax testing, or negative testing. But they all mean the same thing.
They all mean that we’re going to send a random amount of data into an application. Maybe an application is expecting a field where you might put your name into the application. Maybe you put anything but a name. Maybe you put all kinds of different information into that field to see how the application is going to respond.
You’re looking for the application to have some type of exception. Maybe you crash the application on the client side. Maybe you find that the server crashes. You’re going to find something that’s a little bit different than what you might expect.
The idea is that if you can find an exception, you’re finding a way that this input is not being validated by the application, that may give you additional access to do other things. Maybe you can create a denial of service with that. Maybe you can create a way to see information in the database that the application would normally never provide to you.
This technique is one that was created in 1988. There was a class project at the University of Wisconsin. Professor Barton Miller came up with this project, the “Operating System Utility Program Reliability.”
And this was really the Fuzz Generator. This was the first time people really sat down and put together a project that would really take an application and put it through its paces. Specifically, in this case, it was operating systems and the applications that were running an operating systems. And that’s where fuzzing was born. And we were able from there to create an entirely new set of testing that we could do with our applications.
Since then there have been many new frameworks created for fuzzing that focus on certain application types or certain platforms or even certain operating systems. We can even see that when we’re working with these frameworks that they are very time consuming to use. They’re very resource heavy. You have to go through a lot of iterations, because usually your application isn’t going to break.
So you have to try a lot of randomization. You have to try different things on different fields. Maybe there’s more than one way to put information into an application. We might want to try every single method to get information into that app.
The fuzzing engines– many of them– have a set of tests that are high probability. There are certain things that applications tend to do very badly at. A lot of these fuzzing engines have been built to try to take advantage of those first. So if you can get some of the high probability problems with fuzzing, then you may be able to save yourself a lot of time.
There is one that you can download and try. This is from the Carnegie Mellon Computer Emergency Response Team, CERT team. It’s called the CERT Basic Fuzzing Framework or BFF. And they even have a VMware image you can run from cert.org/download/BFF/ to try some fuzzing on an operating system yourself.
This basic fuzzing framework virtual machine is set up with an application inside of it that is already susceptible to a number of fuzzing techniques. And if we just run this window– we’re going to run this application, run this virtual machine– it’s going to launch and automatically start the fuzzing process. And it’s going to keep trying different fuzzing techniques to try to find a place where the application fails, stops talking, it breaks in some way.
Once the operating system begins, what you’ll start to see is the fuzzing process start on the right side. And then you’re going to see on the left side any opportunities or any places where the fuzzing actually fails. And it will give you the process ID of when it starts to fail.
So as it goes through all of the different fuzzing, you’ll start to see on the left side a lot of different pieces start to load. There we go. There’s another opportunity where the application broke.
All of this information is logged. And you can go back into the log. This framework even comes with a number of reports that you can run to see exactly what was given to the application to cause this particular problem.
And from there, of course, you would drill down further and try to take advantage of some of those fuzzy techniques. Obviously, not a simple thing to perform. And as you can see, very time consuming. But it’s a great way to determine how secure your applications might be.