Ref.: Gray Hat Python

The framework is coded entirely from Python and is open source.

Developed by Pedram Amini and Aaron Portmoy from Tipping Point, Sulley is a fuzzer packed with interesting capabilities. Such as packet-capturing, crash reporting and VMware automation. It also has the capability to restart the target application in the event of a crash. Then continues on with the fuzzing process.

For data generation, Sulley uses a block-based fuzzing, the same method used as Dave Aitel’s SPIKE. So if you’re familiar with SPIKE, you shouldn’t have much trouble with this fuzzer. In block based fuzzing, you build up a general skeleton for the protocol or file you are fuzzing. There’s going to be an example later in this post.

One great feature this fuzzer has over others, is the ability to show the CPU’s registers at the moment of the crash. Sulley comes with PyDBG, and once the framework installed it uses this to monitor the process you are fuzzing. Another one is Sulley’s ability to monitor the network (using pcapy), capturing every “fuzz” sent to the target. Creating one pcap file for each attempt. This way you can follow your progress, or review your fuzzing session. Lastly, you can even see the fuzzing progress via an HTML page. The page shows you which variable it’s currently fuzzing and it’s progress.

Sulley Primitives

Sulley uses the s_strings() directive to denote that the data contained is a fuzzable string. So we wantd to fuzz an email address, we’d declare it like this in our skeleton:
This tells Sulley it’s a valid value, so it will fuzz that string and exhaust all reasonable possibilities. Once it’s finished, it will revert to it’s original value and continue fuzzing the rest of the declared values down the file.

This is just a small string that helps break up larger ones. If we take our email example from above, the delimiter would be the “@” sign. This is how we’d passe this primitive on to Sulley:
Like the s_string() primitive, the delimiter is also fuzzed. In this example, odds are the “.” is a value we really don’t need to so we can tell Sulley to not fuzz it like so:
s_delim(“.”, fuzzable=false)

The values passed to a static string, remind unchanged (or un-fuzzed I suppose).

So let’s take a look at a complete, yet small and simple, skeleton file. In this example, we’ll look at the FTP protocol.

# import all of Sulley’s functionality
# We’ll call this file ftp_ability.py
from sulley import *

s_delim(” “)

s_delim(” “)

s_delim(” “)

You can see, it’s pretty simple. This file basically feeds Sulley with starting values and it takes it from there. Fuzzing the fields you denoted as fuzzable. In this case; the username, password and STOR command. Depending on the target FTP server, you’ll add and/or remove commands. Not every FTP server will have “STOR”, and not all of them have “LIST” … So this is where you’d supply a valid list of commands.

Now that we’ve seen our blocks, lets take a look at the session file. The file that starts the whole fuzzable process.

from sulley import * # import everything from Sulley
from requests import ftp_ability # this is our ftp_ability.py file from requests folder

def receive_ftp_banner(sock):


sess = sessions.session(session_filename=”audits/ability.session”)
#Target IP xxx.xxx.xxx.xxx
target = sessions.target(“xxx.xxx.xxx.xxx”, 21)
target.netmon = pedrpc.client(“xxx.xxx.xxx.xxx”, 26001)
target.procmon = pedrpc.client(“xxx.xxx.xxx.xxx”, 26002)
target.procmon_options = { “proc_name” : “Ability Server.exe” }

sess.pre_send = receive_ftp_banner #grab the banner

sess.connect(s_get(“user”)) # Notice our commands from the previous file

# This tells Sulley user must be authenticated to use this command



Because most FTP servers send a banner, we tell Sulley to wait for it before fuzzing any data.
The next thing, is the session file which keeps track of our overall session. This allows us to stop and restart our fuzzing where we had previously left off.
After that we define our target with the appropriate IP and port number. In this case, a FTP server.
After defining the target, we tell our network sniffer to set itself up on the same host and listening on 26001.
Last we tell our debugger is listening on the same host and that is listening on 26002.
We chain in the authentication commands and tell Sulley to start fuzzing.

To start the fuzzing process, we need to have Sulley installed on 2 machines (I find it less confusing this way). The attacking and victim machines.
From the target machine
1: start the process we want to fuzz (this case Ability Server)
2: attach the process monitor to our server.
C:\sulley>python process_monitor.py -c c:\ability.crash -p “Ability Server.exe”
3: attach the network monitor to our network card and have it sniff for specific traffic. The -P parameter is to store your pcaps file. You must create this folder first. You can use a mapped drive too.
C:\sulley>python network_monitor.py -d 1 -f “src or dst port 21” -P z:\

From our attacking machine
1: execute the session file from Sulley’s root directory
C:\sulley>python ftp_session_ability.py

Once the process has started, you can point your browser to the attacking machine’s IP on port 26000 to get a progress report. You need to manually refresh the page. Once the application crashes, you’ll be able to see the crash report on the page. Enabling you to see what/where was overwritten in the CPU’s registry.

You can get the install executable here
And the PDF here
Here’s a video on kioptix.com demonstrating all of this. Using the same files and vulnerable application mentioned above. Thanks to dookie for pointing out a few mistakes of mine while I was setting up Sulley for the first time. Also the Gray Hat Python book that gave me a good push with this.

Next week, fuzzing the wife to get.. wait wrong blog.

Comments are closed.