So the TCP fuzzing server is somewhat working. There are a few features I’d like to add, but I have been actually putting it to use for the time being and writing an IRC client fuzzer.
So far this supports:
- Ability to read from an input file.
- Saves its spot if a client disconnects.
- Basic functionality like being able to specify IP and port to bind to.
- It is very easy to write a fuzzer for a basic TCP-based client. The IRC fuzzer’s code is roughly 10 lines of Python with a big protocol defining file.
The things I’ve noticed that are going to need to be addressed:
- The server doesn’t display the string that actually made the client quit/crash.
- Some protocols require authentication or some sort of start up procedure. This can kind of be worked around with the few things I’ve tried, but it will be a burden to use this in its current form against a more robust protocol.
- This does not support non-ASCII streams.
- This does not support SSL yet.
- Many client software applications rely on specific responses from a server and will error out or just not process bunk data sent to them. Things such as PING/PONG requests to make sure connections are still active, if not addressed, will cause a client to abort the session prematurely. Some sort of “expect” style definition is needed to handle this kind of issue.
- Writing a protocol definition sucks.
One of the next things I’d like to do is be able to take a packet capture of communications against a protocol and generate a script to use. I have been manually doing this for IRC, and I am not even 2% done yet. I have numerics 001-005, the start of the MOTD, the body of the MOTD, the MOTD footer, and maybe a couple more informational numerics plugged in so far. I still need to do:
- Quite a few more! IRC is not a small protocol.
Being able to parse a packet capture and intelligently pinpoint locations to fuzz, outputting a script that this software could use wouldn’t be too terribly hard. It will probably still not be 100% complete or correct, but it would be a good start and take a lot of the manual effort out of building these.
The more I think about this project, the more that I realize that making some one size fits all solution to fuzz everything is not going to be possible. If I keep going with this, I will end up with dozens of tools to attack a number of programs, protocols, formats, and all sorts of crap. I just hope that I am able to build enough tools to cover testing the things that I care about.