WARNING! These scripts come with no disclaimer and may not work out-of-the-box without configuration.
Happy New Year, everyone!
Ok, now that that is out of the way...
@seclilc was talking about ffuf and screenshotted one of the more fun terminal outputs that it can generate.
This made me think of how often I have been re-routing output to /dev/null by adding 1>/dev/null to the end of commands.
Being able to visually watch ffuf work, and trust that it is working correctly, is a magical thing.
But surely, we are all bogged down by 'too much output'.
Often, the hacking tools we work with do better at generating output for use with another tool, not so much being nice visually.
We're hackers, not UI designers! Sure, we like our slick black bg terminals and ASCII art script titles, but code is code beneath the hood, and less is more!
Having to manually configure ffuf is also a chore. Eventually, you might figure out the kinds of flags that you always wanna work with/use, always wanna tweak, as well as never want to use.
One thing I began doing was filtering by status codes, but eventually started seeing that even though one endpoint may yield multiple status codes, each status code itself could yield different page content, so I might want to include content from a given status code, but find a way to automate filtering out "junk" results.
Enter my two scripts: smallfuzz.sh, and ffuflags
You can install ffuflags from pip by doing:
pip3 install ffuflags
You don't need ffuflags to use smallfuzz, just uncomment out the next two lines and comment out the 3rd in the script...
echo "Enter some new flags for the big fuzz..." | notify -silent;
read NEWFLAGS;
#NEWFLAGS=$(python3 -m ffuflags -i /home/$ME/ffuf/out_small/$2-get.json);
ffuflags is my attempt at automatically generating flags/parameters based on the results of a previous scan.
My technique is simple: fuzz with a very small (128~) wordlist, then generate new flags based on the various properties like word count, byte count, and line count.
Other metrics could be used, but this way I am able to distinguish between, for instance, status 200s that are actually real pages versus status 200s that are actually 404s (this happens a lot and it makes sense why in large apps with big WAFs).
So, you'd hit your target fuzz with smallfuzz.sh like:
$ ./smallfuzz.sh "https://www.evildojo.com/FUZZ" "out-0" "";
This says "do a small fuzz on this site with this fileroot and no extensions".
In the script itself, you can tweak which wordlists you work with. Other people might use smaller or larger lists. Figure out what works best for you!
Here is an asciicast of the script in action.
What you'll see is an initial fuzz of my website, followed by a 2nd fuzz with both a larger wordlist AND additional filter flags in order to reduce false positives.
I did this because ffuf's very own autocalibration flags seem to cause problems in running initial fuzzes. My luck has been much better approaching it this way.
Remember that not every tool is the magic bullet for a job, even though we often talk this way online. Actually learning the ins-and-outs of a tool is important for understanding one's own best way to use a thing. People often put content online for educational purposes, but often do not run into these edge-cases themselves, hence why things like this can be glossed-over.
This isn't the first time that I've done wrapper scripts for various aspects of the web app bug hunting process. Previously, I've released my amass setup, which was featured in Intigriti's Bug Bytes #154, and will get around to blogging about my whole process (as I find more bugs of course).
Here is my trash af social media and website:
https://www.evildojo.com
https://twitter.com/therealdarkmage
https://twitch.tv/darkmage666
https://www.linkedin.com/in/darkmage
Thanks, and take it easy y'all!
Top comments (0)