Jammer: A Fuzzer for Automated Web Application Vulnerability Scanners
Hey Hackers! Recently, I was so inspired by Offensive Counter-Measures, that I downloaded ADHD and set up an epic active defense lab. While messing with the tool suite, I noticed it was missing active defense fuzzers, or tools for finding more security flaws in current web application vulnerability scanners. This seemed like a great idea to me, and I immediately started messing with a php script to fuzz scanners with abnormally large responses. To my pleasant surprise, my fuzzing script started overwhelming and crashing web application scanners right out of the gate. So without further adu, I present to you my open source fuzzer for web application vulnerability scanners, aptly named Jammer.
Jammer still needs some work, a lot of work actually, namely in three key areas. The roadmap for Jammer is to increase it's attack string recognition, fuzzing control, and logging capabilities. Currently it has the bare minimum of all the previous traits, which is surprisingly still enough to crash some scanners and provide useful insight to the attack.
The attack string recognition simply means having it detect specific attacks or web application vulnerability scanners, and respond in a way that best induces false positives and/or jams that technique response with fuzz data. This can be thought of as expanding the blacklist, attack recognition list, or list of known attacks.
Fuzzing control means fine tuning and increasing the fuzzing capabilities of Jammer. This means increasing the fuzzing payload characters, increasing the fuzzing payload length, and dynamically changing these values throughout testing. The idea is not just to choke the web application vulnerability scanners on raw data, but reverse engineer and perfect the crash using the fuzzing tool.
Logging capabilities involve detecting when an attack string is triggered, details into the exact fuzzing payload delivered, and followup information on the attackers continuing progress (are they still scanning away or has the tool mysteriously stopped?).
Finally, I encourage you to fork and expand on Jammer! I know I will be adding a lot of the previously mentioned functionality over the coming days. The goal is eventually get this added to the ADHD project, as well as kickstart some research on exploiting security scanning tools.
Jammer still needs some work, a lot of work actually, namely in three key areas. The roadmap for Jammer is to increase it's attack string recognition, fuzzing control, and logging capabilities. Currently it has the bare minimum of all the previous traits, which is surprisingly still enough to crash some scanners and provide useful insight to the attack.
The attack string recognition simply means having it detect specific attacks or web application vulnerability scanners, and respond in a way that best induces false positives and/or jams that technique response with fuzz data. This can be thought of as expanding the blacklist, attack recognition list, or list of known attacks.
Fuzzing control means fine tuning and increasing the fuzzing capabilities of Jammer. This means increasing the fuzzing payload characters, increasing the fuzzing payload length, and dynamically changing these values throughout testing. The idea is not just to choke the web application vulnerability scanners on raw data, but reverse engineer and perfect the crash using the fuzzing tool.
Logging capabilities involve detecting when an attack string is triggered, details into the exact fuzzing payload delivered, and followup information on the attackers continuing progress (are they still scanning away or has the tool mysteriously stopped?).
Finally, I encourage you to fork and expand on Jammer! I know I will be adding a lot of the previously mentioned functionality over the coming days. The goal is eventually get this added to the ADHD project, as well as kickstart some research on exploiting security scanning tools.