Righto, when you're doing a bit of reverse engineering on an app, one of the most boring jobs has got to be sending stuff ("things") to an entry point of the app to see how it reacts. Depending on what you're after (finding buffer overflows, format strings, and all that jazz), the type of stuff you send will vary, not just in the content but also in the quantity, especially if you're chasing a buffer overflow. And when it comes to quantity, it's best to do some good old-fashioned fuzzing instead of manual requests.
In the case of overflows, it's more about the quantity than the type of content, and you've got a few options for sending "things" to the app - you can do it manually, run some Python/Perl scripts from the console, write your own script, or use some already-developed tools for the job: fuzzers.
Scenario:
I've cooked up a little scenario for ya; a remote app that's got a weak spot when it comes to buffer overflow (it's stack-based), and you can get to it through the old TCP/9999 port.
This port's the only way in, so we can give it a good scan, see what version of the service is running, and check if there's any juicy vulnerabilities we can exploit. But if that doesn't pan out, we've gotta just start chucking stuff at the port and see how the app reacts.
Alright, so in this case, we can use good ol' netcat to get access to the app through the port. When we do that, the app tells us we can get some help by typing in the HELP command. Easy as!
Manual requests to the application:
Rightio, our real intention here is to figure out what kind of info we need to send to the app and how much of it. You can see in the blue bits there a bunch of commands from the app - these are the ones we'll use to send our stuff and try to trigger that buffer overflow.
So like I said before, we can make manual requests to the app. In that last image, we added a bunch of digits and then a heap of "A" characters to the HELP command. The app reckons that command ain't implemented. We could keep trying with more stuff, different commands and all that, but as you can probably imagine, doing it all manually is a real slog and gets pretty monotonous after a while.
More quantity with Python / Perl:
To make it easier to send a heap of info to the app and try to trigger some kind of error or even a crash, we can use languages like Python or Perl straight from the console. In my case, I'm using Kali as the "attacker" machine.
So a real simple way to send more info to the TCP/9999 port of the app is to use Python to generate a bunch of characters and then pipe that straight to netcat. Let's say we want to send 200 "A" characters - instead of typing them all out, we can use Python to spit them out and then send that to the app port with netcat.
We could just use an "echo" command to send the output to netcat, but that'd be the same problem as before:
Code: Select all
echo «HELP 1234567890AAAAAAAA» | nc 192.168... 9999But we can actually tack the output of a Python command right onto the end of that echo command.
As you can see in that image, using Python to send a heap of data to a remote app is a piece of cake. In that last example, we sent 5000 "A" characters, and you can see the app's response is different compared to when we only sent 50 or 500 "A" characters.
Using a fuzzer: zzuf
Alright, let's take a look at how we can use the main man himself, the fuzzer called zzuf, to help us out with this whole fuzzing business. Zzuf will let us randomly alter the content of what we're sending, which can be just as important as the quantity.
In fact, we're gonna use zzuf for exactly that - to randomly muck around with the info we're sending, since we've already seen how easy it is to generate the content using Python or Perl.
So, in a real simple way, we're gonna use Python to create a text file that's got the "HELP" command followed by a heap of "A" characters - let's say 500 of 'em.
We already have a file called fuzz.txt.
Now with zzuf what we are going to do is to randomly alter the content of the file, let's see an example:
In that last image, we can see that on the first run, zzuf randomly altered the output when we did a "cat" on the file. But hang on, there's a problem - it's also changed the third byte, turning our "HELP" command into "HENP", which isn't what we want at all.
Luckily, zzuf's got a way to deal with that. We can use the -b parameter to tell it where to start modifying the content. In the second zzuf run, we used -b6- to start altering from the sixth byte, so it doesn't mess with the "HELP" part.
We can also set the rate of modification using the -r parameter. For example, if we want to change 50% of the content, we'd do:
Code: Select all
zzuf -b6- -r0.5 cat fuzz.txt