Fuzzy Bugs Online

Fuzz techniques for attacking web applications

solution Fuzzy Bugs Online

In general, fuzzing means to try many inputs, well-formed or otherwise, in an application, protocol or other interaction with a computer, that it might trigger an unexpected behavior. Web fuzzing in particular is an automated, computerized technique to find bugs and vulnerabilities within a computer system. If you think protecting your site is a matter of simply blocking the most common types of malicious requests, think again. Read on for more.

Injecting SQL into a vulnerable site

A fairly common situation is a website providing the ability to search, add, and remove information from a database. But introducing this kind of feature demands great care in how you set up and access that database.

Let’s look at bWAPP, which has a movie database, and allows us to search for a given title:

bWAPP screenshot - movie search

Figure 1. bWAPP’s movie search site

It looks like the site takes the user’s input as a POST request, then searches the database for that request, and finally prints back the result in table form. We can tell it’s a POST request since there is nothing in the URL that hints GET (consider that the huge POST title wouldn’t be there in a real app).

Let’s check that using the OWASP ZAP proxy. Indeed, we can see and confirm that the request is POST:

POST request when you search for a movie.

POST /sqli\_6.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11;
Linux x86\_64; rv:52.9) Gecko/20100101
Goanna/3.4 Firefox/52.9 PaleMoon/27.7.2
Content-Length: 24

Now we can intercept this request using ZAP and edit the title=the bit above, changing the by some SQL. For example, if we change it to:

Naive SQL injection.

Iron Man' OR 1=1;

Because the 1=1 is always true, making the overall condition true, we should get all entries in the table.

But it doesn’t happen. We get an error:

Error: You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right
syntax to use near '%'' at line 1

Well, at least now we know for sure they are using MySQL, because we can see it in the error message.

There are infinitely many strings (sequences of characters) we could try to use in order to complete the unknown SQL query the server is asking from the database.

What if we could try a bunch of them, at the same time, automatically?

Well, that’s what ``fuzzing'' is all about.

Web application fuzzing

There are other kinds of fuzzing: desktop application fuzzing using command-line or graphical interfaces (testing combinations of buttons, inputs, etc.), protocol fuzzing, file format fuzzing, and more.[1]

In this article we will focus only on web application fuzzing which is the semi-automated, pseudo-random manipulation of URLs, forms, user-generated content[1], requests, etc. We may tackle other kinds of fuzzing in future articles.

For a given fuzzing attack, the most comprehensive and sure-fire way to succeed would be to try every possible input. For example, if we’re fuzzing an input string, we should try every possible string, beginning with the empty string. This is due to the fact that sometimes programs have unexpected reactions to odd input, like the bug found in Mac OS last year, where you could log in as root by pressing the login button enough times (see CVE-2017-13872 for more info).

Get started with Fluid Attacks' Red Teaming solution right now

But this "try everything" approach is not really feasible or practical: the space complexity of such an attempt would be enormous. Thus we must bound the so-called 'explorable solutions space'. This is usually achieved by limiting the input attempts to values that have a statistically higher probability of triggering a bug. These are known as 'fuzz vectors'. In our case, they would be SQL queries. Some examples from OWASP:[2]

' OR 1=1;--
' OR 'a'='a
Admin' OR '
HAVING 1=1--
' OR username LIKE char(37);
' ; DROP TABLE temp --

Your fuzzer of choice will probably provide a healthy dose of fuzz vectors, as does ours, the OWASP ZAP Fuzzer. All we need to do is

  1. select the string we want to fuzz,

  2. invoke the fuzzer,

  3. select the 'payloads', i.e. the fuzz vectors, and

  4. run the fuzzer.

ZAP includes several of those by default; we will use the SQL injection vector from jbrofuzz:

"Running ZAP fuzzer"

Figure 2. How to run ZAP fuzzer

Successfully injected SQL queries are marked with the state "Reflected" in the list:

"bWAPP fuzz testing - reflected SQL injections"

Figure 3. Reflected SQL injections in fuzz attacks

Here we see a fuzz attack is only as good as its payloads or fuzz vectors. Only the most trivial injections succeeded, i.e. the ones of the form

whatever' OR (something truthy)

which simply show all entries in the table movies.

When fuzzing, this is both a blessing and a curse. Usually, they don’t, but occasionally the simplest injections reveal unexpected outcomes, and when they do, they are real surprises such as the Apple bug mentioned above.

Comparison with manual injection

With information about the app and the database structure, we can inject more effective queries. For example, suppose you’ve found out that there is another table called users and we want to see what’s in there.

If we try to inject the following query:

%'; SELECT * FROM users;

we get an error, because the database management system does not allow query concatenation.

If we try with union instead:

%' UNION SELECT * FROM users;#

we still get an error, because the tables don’t match in size.

Suppose, for the sake of the example, that we also know (or guess) the names of the columns and select the most interesting ones:

%' UNION SELECT id, login, password, email, secret,
activated, admin FROM users;#

Then we get the most of the users' info (passwords are hashed, but can be recovered).

"bWAPP SQL injection screenshot showing passwords"

Figure 4. Succesful manual SQL injection

By itself fuzz testing cannot replace human expertise in the equation but it adds an important additional point of view. As seen in the Mac OS example, its greatest weakness can be a potential source of great surprises. We have merely glimpsed the tip of the iceberg here, but hope you find this short introduction helpful.

At Fluid Attacks, we help our clients manage their vulnerabilities in web applications, so that they are continuously secured against SQL injections and other kinds of risks. To learn more, contact us



Subscribe to our blog

Sign up for Fluid Attacks’ weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by Luis Villasmil on Unsplash

Tips for choosing a vulnerability management solution

Photo by JC Gellidon on Unsplash

Definition, implementation, importance and alternatives

Photo by Jason Krieger on Unsplash

Keep tabs on this proposal from the Biden-Harris Admin

Photo by Tamas Kolossa on Unsplash

Vulnerability scanning and pentesting for a safer web

Photo by Alexander Ant on Unsplash

Definitions, classifications and pros and cons

Photo by John Schnobrich on Unsplash

Is your security testing covering the right risks?

Photo by Marino Linic on Unsplash

How this process works and what benefits come with it

Photo by Saketh Upadhya on Unsplash

Get an overview of vulnerability assessment

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.