Pentesting 101: Web Fuzzing

According to the Interwebs, fuzzing involves sending random data to software until something happens or something reveals itself.  Fuzzing a web server is not much different really other than I wouldn't call it random data.  We're essentially taking lists of words, throwing them at the web server in different ways, and we're looking at the response.

In my opinion, fuzzing is an art form because it's a matter of using the right tool, with the right list, in the right way, to get the right response.

From where we left off in our last Pentesting 101 on Nmap, we find a web server:





The first tool we're going to use is Nikto.  Most of these tools are similar but they are different enough that you might find yourself using several of them in the enumeration process. 

The Nikto syntax is fairly simple:

Nikto -h http://192.168.86.179

The -h flag is for host.  

Running our scan:




Nikto shows us not much more than we already know.  The server is running WordPress.  

The next set of tools we're going to use will require wordlists.  Kali Linux comes with various wordlists and the group in the directory shown below is a solid starting point for creating your list.  As a side note, I'm not sure why some of these are separate but with a stock Kali image, I combine them, add a few lists of my own, sort them, remove duplicates, and then call it:  final.txt

We're going to combine these lists as follows:

sort -u /usr/share/wordlists/*.txt > /usr/share/wordlists/final.txt

Getting a word count, we run:

wc -l /usr/share/wordlists/final.txt

We see that our wordlist contains over 300,000 words:




Now that we have our list, let's start fuzzing! 

DirBuster is a really popular fuzzer but one that I love as much as I hate.  What you choose as your 'go to' fuzzer is really a matter of preference for what works best for you.  For me, I've spent a lot of time yelling at DirBuster and I've learned to live without it.  

When we look at the UI:




There are a few things to note:

  • We need to point it at our target.
  • By default, it's switching between HEAD and GET requests. This behavior is not natural and sometimes you'll need to use GET requests only -- to appear more browser-like.  If one could call thousands of requests per minute -- natural.
  • The number of threads is where DirBuster gets into trouble. If we're restricted on the number of threads were able to use, the "Time to Finish" can end up being days.  In an attempt to provide an example, I'm currently scanning a live server with DirBuster.  I had to reduce the number of threads to 10 to keep it from failing and the amount of time to finish shows over 54 days.  Not ideal.
  • We need to choose a wordlist.
  • We can choose to include or exclude directories and files.
  • We can choose whether or not to scan recursively. Personally, I turn this off on the initial scan.  Once it finishes the initial scan, I choose which directories I'd like to dig into. Otherwise, it just increases the amount of time on the scan.  That's not limited to DirBuster, that's all of the tools we're going to use.  More directories to scan, more time.  
  • Once we get all of our options setup, we hit Start.

DirBuster starts fuzzing:





And like clockwork:





We get our error -- which is why I don't use this particular fuzzer all that often.  We can change the threads in an attempt to get it to play nice:





When it's running well, I prefer to view the Results - Tree View pane:





With this particular server, lowering the thread count does not solve the problem and as you can see, it's showing 9+ hours to finish.

Our next tool, Dirb, a command line fuzzer. 

In my opinion, Dirb works ok but its limitation is when we feed it large wordlists -- then it chokes.  It has its advantages which is why it's still something I'll use from time to time.  The syntax is pretty straightforward:  




As you can see, by default, it scans recursively but we can turn that off:





In the above, we're scanning for directories.  If we give it the -X flag with a file extension, we can scan for files:





Moving on to my preferred, free, scanning tool, GoBuster.  

gobuster -u http://192.168.86.179 -w /usr/share/dirbuster/wordlists/final.txt -s '200,204,301,302,307,403,500' -e

As I mentioned previously, using the right tool, with the right wordlist, we can find that hidden gem.  This is a modified version of the "final.txt" wordlist we created earlier.  If DirBuster would have run without failure, we would have ended up here sooner. 




What we were unable to find with the previous tools, GoBuster finds within minutes.  Pointing it to the /s3cret directory initially yields nothing:





But if we play around with different file extensions, we can uncover:





It's also worth noting that sometimes we're able to browse the directories and we don't even need the tools:





Accessing the credentials.txt file, we find:





Adding my final thoughts before I close out Web Fuzzing.  It's important to understand that when we're using a web browser or these tools, we're providing information to the server which could be parsed or logged.  Or more importantly, it could be used to identify friend from foe.  For example, using the Firefox browser in Kali, if we capture the connection with Netcat, we see the user agent, Mozilla:





If we look at the Apache web server logs, we see the DirBuster user agent:





As a defensive measure, we can continuously parse the logs for DirBuster, Nikto, etc., and we can automatically ban IP's based on the user agent. 

When we view the options for DirBuster, we locate the betraying source:




In attempt to mask our identity, we can change the user agent:





Rerunning our scan, we now appear in the logs as:





This change isn't exclusive to DirBuster, we can do this with most fuzzers:





I feel like this is just scratching at the surface and I can't emphasize enough about how we use these tools to work in parallel for slightly different purposes.  Given certain situations, one tool will work better than another.  DirBuster is a fantastic tool when it works but when it doesn't you'll want another tool.  Given the limitations of the stock Kali web fuzzing tools, at least as far as the tools I've used, you might find yourself moving outside that tool set to find another, like GoBuster.