This blog post is in conjunction with the Lost Rabbit Labs - Haktober Event! You should go sign-up for the event, it's going to be a scary good time!
Now back to your regularly unscheduled blog post! As many of my readers might know I am interested in fuzzing for different vulnerabilities. The idea of controlled chaos just gets me excited. Plus there is the added benefit of potentially finding undiscovered vulnerabilities and potentially making some money. In the past we have talked about fuzzing with the popular framework AFL, however today and for this weekend's security talk I will be discussing a different approach. We will be exploring ways to interact with HTTP or other network traffic using the BooFuzz framework.
BooFuzz is touted as Network Protocol Fuzzing for Humans, and it is the fork and successor of the previous network fuzzer Sulley. Forked and modified by the user jtpereyda on GitHub. Why did I choose BooFuzz over Sulley? Besides the obvious that is Sulley is no longer being maintained on GitHub, also BooFuzz seeks to implement extensibility with a single goal in mind. Fuzz Everything. Now that's a project I can get behind.
If you want to install BooFuzz and are on a Pip supported operating system, it's easy! Simply download the Python library as pip install boofuzz. BooFuzz documentation recommends you install BooFuzz within a virtual environment, but if you throw away virtual machines as quickly as I do then it does not really matter. An alternative installation method would be building from source, but you will have to refer to the documentation for that.
The screenshot below demonstrates a bare bones example of a fuzzer template provided to us by the BooFuzz GitHub page.
Before we actually dive in we should take a moment to read and understand the syntax of the framework that is shown above. There are four main components of a fuzzer template. The first is the Session object which will be the center of your fuzzer session. Once the session is created you will pass it a Target object which will receive a Connection object. This is the way BooFuzz sets up for the connections. The next main component is the Initialize function. Every message needs to start with a s_initialize function. Using the screenshot above we see that our message named Request is initialized using the proper function, but then it has a subsection named s_block. The s_block allows us to organize our fuzzer in a more readable fashion, which will be helpful when we start having longer and more complex HTTP requests. The s_group is a way for us to have a specific set of strings to cycle through. For example, in our screenshot above we want to only use valid HTTP verbs so the responses will be correct. Next line has a s_delim which allows us to specify spaces or line breaks. The final line within the s_block subsection we will discuss is the s_string which pushes a string onto the current block stack.
The final two components of the fuzzer template are the session.connect() and the session.fuzz() components which will begin the actual network interaction and begin the fuzzing stages. These are pretty self-explanatory, and are required to do pretty much anything within the fuzzer.
Shortly we will discuss an easier way to create these fuzzer templates for BooFuzz. One of the hardest parts of fuzzing in my opinion is that of finding a target. You can spend a great deal of time interacting with different web applications and web servers to find vulnerabilities. Therefore, for the sake of time and to keep the focus of the blog post on the actual methodology of BooFuzz and not about finding bugs I'm just going to choose an easy target to begin with. For this blog post we will be looking at the extremely buggy web app also known as bWAPP. Again, this blog post is not meant to serve as an installation guide for the vulnerable web app, you can find instructions located on their site. However, I did choose to use the bee-box which comes complete with all the setup already completed. I do not expect to find any real crashes at this time, but we can start with an area where we know some HTTP Headers might be vulnerable. For this example we will turn our attention to the Shellshock vulnerability page.
I had mentioned above that there is in fact an easier way to generate the BooFuzz framework needed to fuzz a web request. For this blog post I will be using the Burp Suite Community edition to capture the request to the page as seen in the screenshot below.
Once intercepted, right click anywhere within the body of the request to get the options menu. You can then select the Copy to file choice. Note: if you choose the Save item selection it will export the request as an XML format which will not work for our use case.
This is what your request should look like after you have saved it to disk. With obvious changes being the Host address and maybe even the User-Agent header information.
I have found a user on GitHub who wrote a quick little Python script to generate a framework using a basic HTTP request. You can find the link to Boo-Gen here! Once we have the boo-gen.py file downloaded and local we can use the following command to generate our fuzzer: ./boo-gen.py -g shellshock.txt -f fuzz.py. Let's break down that command real quick. The -g flag tells Boo-Gen that we are performing a GET request. If your request is a POST simply change out -g for -p. In our example the shellshock.txt is the name of the file that contains our HTTP request, you should change accordingly. The next flag -s the -f fuzz.py this is instructing Boo-Gen to output our template to the file named fuzz.py you can change this to whatever you would like, but keep in mind it might overwrite a file if you were to use the same name as other files on disk. The screenshot below might be a little small to read, but I wanted to ensure I at least showed what the full fuzzer template looked like after generation.
At this point in time we can simply use the fuzzer by invoking python fuzz.py. The first action to happen is that BooFuzz will start a localhost listener on port 26000 for the web UI. Then it will begin fuzzing using different input points. After completion it will hold the web UI open until you hit ENTER.
Let's check the web UI to see what information is displayed. It appears to be very similar to the terminal output, but with the ability to cycle through specific Test Case Logs.
Uh oh... did you accidentally close the web UI and need to go back to the fuzzing results? Don't worry, BooFuzz provides a way to reopen previously generated BooFuzz results. Use the command boo open <run-*.db> to reopen the web UI.
Note: I did run into an issue where the boo command was not recongnized by my user after installing with the pip command. The command boo should be installed in your local home directory, by default it will be the following directory /home/<username>/.local/bin/boo. You can symlink the executable to your local user to help your terminal recongnize the command. The command to symlink will look similar to the following:
sudo ln -s /home/<username>/.local/bin/boo /usr/local/bin/booAlright, so we fuzzed something! However, it didn't feel like it took very long. Isn't fuzzing supposed to take a while? Well if we open backup our fuzzer template and take a look at the variables that were created we see that nearly all of them have the value fuzzable = False at the end. You can change this to True to force BooFuzz to target that line. I'd recommend not fuzzing the whitespace, but sometimes that might be a good idea as well.
Now after changing multiple values we restart the fuzzer, and we see that it is going to take quite a bit more time to complete. As previously mentioned this blog post is more about how to get setup and started fuzzing with BooFuzz instead of about actually exploiting bugs or crashes. Therefore, this brings us to the end of the blog post. Hopefully you see the value in fuzzing HTTP targets. Additionally, if you have availability check out our friends over at Lost Rabbit Labs and their next even Haktober. Until next time, keep on fuzzing!
Sources and Inspiration