I’ve got a nice, warm and fuzzy story for you that, I hope, sets the stage for the importance of testing your web applications. Years ago, I accidentally caused an e-commerce site to make a pretty big mistake. I purchased a scuba diving regulator online, but I ended up with three for the price of one. Such a deal, eh?
How did I do this?
Well, it was simple: I put my name in quotation marks on the order form. I have no idea why I used quotation marks. It turns out that the web developer didn’t think anyone else would do that either and didn’t create scripts to filter out quotation out, as the order went through all of the applications and middleware for the e-commerce site.
Somehow, those quotation marks caused the e-commerce system to fold, spindle and mutilate my request, and I ended up with two (apparently) free regulators. Seeing as how each one cost about $600 USD, this was a pretty big deal.
But it turned into a fun situation. The company was very grateful that I returned the two regulators I hadn’t purchased. And when they found out I knew a bit about the web and wasn’t a crook, I got to talk with the developer and go over the problem. That was really fun.
One of the things that the scuba company learned was that they needed to analyze their web applications. They also learned that they needed to do more security analytics. I even recommended that they contact someone who knew how to do some fuzzing. Let me explain.
What is Fuzzing?
Fuzzing, or fuzz testing, is the activity of analyzing code and testing it. Testing the code usually involves throwing unexpected input at the application as it is running. Remember that web server where I bought one regulator and got two for free? It might have been Java or PHP or Python code. If someone had "fuzzed" that code, then they might have caught the problem earlier. But fuzzing is not limited to web applications. You can fuzz any application, including the web browser you’re using right now to view this article.
The goal of fuzzing is to see if that application can handle random, unexpected input. Because sometimes applications behave in unexpected ways, based on user input. A fuzzing application, or fuzzer, may be able to generate a condition where the application defeats the existing security of the host or web server that is running it. For example, that application might cause a buffer overflow or help contribute to a distributed denial-of-service (DDoS) attack.
The more a programmer and a security analyst can work together to identify such conditions, the better a company can move forward with confidence.
Do Fuzzing Applications Really Work?
Well, yes and no. There are a lot of good fuzzing applications out there. But, as they say in the old musical “The Music Man,” you’ve got to know the territory!
Any security analyst (or pen tester for that matter) needs to know everything about how web sessions work. If you don’t understand the protocols used in web transactions, even the coolest fuzzing and analyst applications will be useless to you.
This means you need to understand the following:
- Hypertext Transfer Protocol (HTTP) and TLS-enabled HTTP protocols, including HTTP GET and POST traffic
- How databases and SQL work
- How session IDs are created and how session cookies are created and stored so you can differentiate between important authentication information that you can discover, and all the other useless chatter
- A programming language or two, such as Python or PHP – this is a tall order, but if you learn these things, you’ll be rewarded
In many cases, you really don’t need an actual fuzzer to do this work. I’ve seen analysts and auditors discover amazing amounts of information by using Wireshark and an old copy of netcat.
Types of Fuzzing Applications
Fuzzing applications are useful because they help automate the following activities:
- Mutation: This is where the application takes existing user input and then alters it slightly. As a result, the fuzzer can create new conditions and input them hundreds of times a second. By mangling user input and throwing it at the server, the fuzzer helps red teamers, blue teamers and programmers become confident that an application can handle multiple forms of abuse.
- Protocol Modification: Instead of modifying existing input, generation-based fuzzing delves deeply into the protocols used. It then generates random traffic based on the traffic it discovers.
What Can Fuzzing Applications Catch?
Fuzzing applications can catch anything that a talented analyst or programmer can catch. At least, that’s the intention.
The usual things that fuzzers look for include:
- Invalid (or, unexpected) input, as in the scuba regulator example
- Conditions that lead to injection attacks
- Memory leaks, where an application exposes how a system is allocating memory
- Information leakage, where an application reveals the inner workings of its own operations or the operations of the server where it resides
- Cross-domain scripting, where an application forces a victim (e.g., your browser) to send an HTTP request to a target destination without the victim’s knowledge, resulting in the leakage of sensitive information (e.g., usernames and passwords) or other data that compromises devices and servers
2 Strategies for Fuzzing
Security analysts and auditors can use most fuzzers in two ways:
- Active: Using the application to throw input at a web server and its scripts and then create and mutate input to cause a condition
- Passive: Using the application as a proxy by configuring a web browser to connect through the fuzzer to a remote web server that you are auditing, enabling you to view how a web browser “talks” to the remote web server and look for weaknesses
Common Fuzzing Applications
Here are just a few popular fuzzing applications:
- OWASP Zed Attack Proxy (ZAP): Managed by the OWASP group, the same folks who bring you the OWASP top 10; can do both active and passive scanning
- W3af: Best run on a Linux system, this very useful active and passive scanner can do active and passive scanning
- Peach: Can be used activity and passively; supports a sophisticated framework-based approach, or as a stand-alone mutation-based scanner
- Radamsa: Useful command-line scanner that takes a mutation or protocol-based approach
- ANSVIF: Allows a security analyst to create random input
- Burp Suite: A sophisticated tool that does an excellent job acting as a proxy server to identify web transactions
- Nikto: This application is more of a web scanner, but is often used in conjunction with fuzzing because it allows auditors to see specific flaws in a web server’s configuration and programming
- Arachni: An entire framework that allows sophisticated application querying and fuzzing
Free Tutorial: How to Use Fuzzing Applications
Let’s take a look at OWASP ZAP as an example. I like it, because it’s open source, current and capable. I also like to use W3af, Radamsa, Nikto and Burp suite quite a bit for the same reasons.
Active Analysis with OWASP Zap
Let me give you a couple of quick examples. Below, I conducted an active scan of a particularly vulnerable web server that I configured.
I installed the DVWA web application in it. DVWA is a particularly “broken” set of scripts and pages that people can use to practice their understanding of common web security issues.
The results of my initial active scan are shown in Figure 1.
Figure 1: Viewing my DVWA web server in OWASP Zap
From here, I can then pivot to various activities.
- I could, for example, conduct an active scan on the HttpOnly Flag and see if this cookie can really be used to create an exploitable condition.
- I could also navigate to additional pages and then create mutable scripts and activities to test those pages to see if they can be forced into causing a low-security condition.
I can also launch the OWASP Heads UP Display (HUD), which allows me to navigate through the website and make attack choices based on what I see. I did this by clicking on a site and then selecting Open URL in Browser. Then, the site will open with the HUD overlay.
In the case of Figure 2, below, I’ve logged in to the DVWA website and can start doing a deeper scan.
Figure 2: Starting the OWASP Heads Up Display (HUD) and viewing a page
All I had to do was click the “Continue to your target” button shown in Figure 2, and I could navigate all over the website.
Figure 3 shows a specific page of the DVWA site, showing HUD options that allow me to start specific attacks and scans on this page.
Figure 3: Viewing a Web session using the OWASP HUD
Notice that in Figure 3, OWASP Zap has identified a specific error. All I had to do was click on that error, and I saw the results shown in Figure 4.
Figure 4: Following an OWASP Zap HUD alert, I discovered a SQL injection vulnerability
Notice that in this case, I’ve identified a SQL injection vulnerability. If I wanted to, I could right-click on this vulnerability and conduct further investigations. For example, I could generate some user input designed to exploit that vulnerability.
Passive Analysis With OWASP Zap
When it comes to passive scanning, you need to configure your web browser to connect first to OWASP Zap’s proxy server. As with many proxy servers, the OWASP server runs on port 8080 on my local system. So, I configured my browser (Firefox) to us that port, as shown in Figure 5.
Figure 5: Configuring a web browser (Firefox) to run through the OWASP Zap proxy on my computer
Then, I used my web browser to connect directly to my DVWA server. I navigated to the Command Injection page.
Then, I conducted a simple injection attack by putting in not only the expected input (a simple IP address), but also some unexpected input, as shown in Figure 6.
Figure 6: Exploiting a vulnerability and viewing the results through the web browser
Notice that I added the following code after the IP address:
; cat /etc/passwd
The DVWA scripts are so badly written that they don’t filter out such input. As a result, the web server actually uses the cat command to view the contents of its /etc/passwd file.
This is a fairly significant problem, because it means that an end user can execute arbitrary code on the web server. Figure 7 shows how OWASP Zap passively captured this transaction via its proxy.
Figure 7: Viewing the same attack using OWASP Zap’s proxy server
Notice that in both pictures, you can see the account information for the james account. Using OWASP Zap, in this case, it’s possible to identify the cause of this problem, and work with a programmer to modify the PHP code so that it doesn’t allow anyone to execute remote code arbitrarily.
Fuzzing to Counter DDoS Attacks
Most people think that DDoS attacks involve sending massive amounts of traffic to a web server or some other resource. But that’s not the case. Increasingly, we’re seeing more Layer 7 attacks that involve crashing web servers and other resources. It’s possible to use fuzzers to identity and fix those conditions before attackers exploit them.
Go Forth and Try Fuzzing
There are quite a few fuzzers out there. Some are pretty useful, and some are not. But once you find a good one that is actively maintained, such as W3AF or OWASP Zap, you’ll be able to audit web servers and applications pretty well. That is, as long as you know the territory!
You can read more about fuzzing applications in the Official CompTIA Security Analyst (CySA+) Study Guide or CompTIA CertMaster Learn for CySA+. Comment below about which fuzzer you chose and what you were able to do!
CompTIA Cybersecurity Analyst (CySA+) applies behavioral analytics to networks and devices to prevent, detect and combat cybersecurity threats through continuous security monitoring. It includes the use of tools such as fuzzers. Download the exam objectives for free to learn more about this cybersecurity certification.
