Difference between revisions of "OWASP JBroFuzz Tutorial"

From OWASP
Jump to: navigation, search
m
Line 80: Line 80:
 
You should see a response received in the bottom part of the 'Fuzzing' panel. Double click (or right click for more options) to see the information exchanged; typically this would be a 302 redirect pointing you to another location. Congratulations, you have just said "Hello" to Google!  
 
You should see a response received in the bottom part of the 'Fuzzing' panel. Double click (or right click for more options) to see the information exchanged; typically this would be a 302 redirect pointing you to another location. Congratulations, you have just said "Hello" to Google!  
  
[[Image:002-JBroFuzz-Tutorial.png|thumb|500px|left|JBroFuzz Hello Google!]]
+
[[Image:002-JBroFuzz-Tutorial.png|thumb|500px|JBroFuzz Hello Google!]]
  
 
Now this would typically be enough under RFC rules, to get a response back; but damn all the bots out here, most websites require further information to respond back. So, in the 'Request' field let's pretend to be a (kind of) legitimate browser by typing:  
 
Now this would typically be enough under RFC rules, to get a response back; but damn all the bots out here, most websites require further information to respond back. So, in the 'Request' field let's pretend to be a (kind of) legitimate browser by typing:  
Line 181: Line 181:
 
By double-clicking on one of these requests, we can see that the web server in question is responding back with no headers, yet returning a full HTML body; this represents the 32222 bytes of response of data we are receiving back. The following screenshot illustrates this:
 
By double-clicking on one of these requests, we can see that the web server in question is responding back with no headers, yet returning a full HTML body; this represents the 32222 bytes of response of data we are receiving back. The following screenshot illustrates this:
  
[[Image:007-JBroFuzz-Tutorial.png|thumb|300px|left|JBroFuzz Output for a Single Request/Response]]
+
[[Image:007-JBroFuzz-Tutorial.png|thumb|300px|JBroFuzz Output for a Single Request/Response]]
  
 
Using the 'Graphing' tab we can proceed to graph the particular requests and responses for this given session.  
 
Using the 'Graphing' tab we can proceed to graph the particular requests and responses for this given session.  
Line 193: Line 193:
 
Once complete, browse to the 'Response Size' tab within the 'Graphing' tab, as illustrated in the screenshot below:
 
Once complete, browse to the 'Response Size' tab within the 'Graphing' tab, as illustrated in the screenshot below:
  
[[Image:008-JBroFuzz-Tutorial.png|thumb|300px|left|JBroFuzz Graphing different 'Response Sizes']]
+
[[Image:008-JBroFuzz-Tutorial.png|thumb|300px|JBroFuzz Graphing different 'Response Sizes']]
  
 
To re-iterate this does not present a security vulnerability in any shape or form; merely the fact that by manipulating HTTP version numbers as part of the request we transmit, we can impact the response that we get back. In this case, what changes is the non-existent header fields, with some HTML content being received back.
 
To re-iterate this does not present a security vulnerability in any shape or form; merely the fact that by manipulating HTTP version numbers as part of the request we transmit, we can impact the response that we get back. In this case, what changes is the non-existent header fields, with some HTML content being received back.
  
 
If I was to guess what is causing this, I would say that some sort of load balancing or content delivery is not happening as it should when non-existent version numbers are being transmitted.
 
If I was to guess what is causing this, I would say that some sort of load balancing or content delivery is not happening as it should when non-existent version numbers are being transmitted.

Revision as of 17:22, 29 July 2009

Contents

JBroFuzz Tutorial

Introduction

“If you can’t fuzz with JBroFuzz, you probably do not want to fuzz!”

Old JBroFuzz Motto


The art of teaching, Mark Van Doren said, is the art of assisting discovery. Fuzzing is a representative discipline towards assisting the discovery of security vulnerabilities, that is just beginning to come of age. Over the last two years, through continuous development, JBroFuzz has attempted to expose the intrinsic beauty of the subject: Constantly submit a vast amount of payloads to a service, device or prompt, waiting for the one response that makes all the difference. This is the mentality that JBroFuzz embraces and attempts to offer back to security professionals.

Fuzzing as a concept goes beyond a conventional work flow or a standard methodology. I would argue that to know how to fuzz well, is to master a new language. Thus, similar to the process of learning a programming (or foreign) language, there are three things you must master:

• Grammar: How fuzzing as a process is structured
• Vocabulary: How to name fuzzing concepts you want to use
• Usage: Ways of achieving everyday effective results with fuzzing

JBroFuzz Splash Screen
From the pre-existing information available for JBroFuzz, this tutorial focuses on usage: How to best put a fuzzing tool to good use, either via the UI, or using APIs that JBroFuzz.jar is constituted of. As a result, this document has a small requirement as a caveat; you need to have a beginner level understanding of the Java programming language in order to understand some sections.

There are a number of working examples described here within, which grep for statements such as “public static void main(String[] args)”. The majority of the content relates to reviewing these examples and putting the Java syntax into a fuzzing perspective.

To summarise, this tutorial focuses on customary and effective usage of fuzzing through the JBroFuzz Java APIs and the respective UI. It is targeting (without attacking them) web applications. Without further redo, let’s get fuzzing!

'Hello Google!' (forget 'Hello World')

As the traditional first program that you learn when indulging in a new programming language, 'Hello World!' represents the norm for understanding the basic output operations and syntax (let alone compiler and execution behaviour) of the language in question.

As with most web application security related tools, when I am given the responsibility to run them, often in order to understand how they work, I would first craft a legitimate, single request to a trusted (to be up and behaving) popular Internet location. Needless, to say this request more than on occasion finds itself on Google servers.

So 'Hello World!' for programming languages seems to transform to 'Hello Google!' for understanding how web application security related tools work. Let us see, how JBroFuzz does it.

• Double-click on JBroFuzz and browse to the 'Fuzzing' tab

JBroFuzz is constituted of tabs, typically located in the bottom or top (if you bother to change the settings) of the main window.

The 'Fuzzing' tab is where you craft your request message to a particular host. Once that is in place, you can select any part of the request and proceed into adding any number of payloads. We shall see how in later sections.

• In the 'URL' field type: http://www.google.com/ http://www.google.com

Unlike conventional URLs, the URL field in JBroFuzz is only used for the underlying protocol (HTTP or HTTPS), host name (e.g. www.yahoo.com) and (optionally) port number.

All remaining information pasted or typed into the 'URL' field will be ignored; you are expected to enter it in the 'Request' field below.

Still, if you want to just copy-paste a URL from a browser, hit [Ctrl+L] while you are not fuzzing, paste the URL value that you have copied from a browser and JBroFuzz will automatically do the work for you.

Examples of valid URL values to be put in the

Treat the 'URL' and 'Request' fields as the two stages of a 'telnet' session on port 80; you are effectively using the 'URL' field to specify the equivalent of:

>telnet www.google.com 8088

As equivalent to:

http://www.google.com:8088

or in the case of HTTPS:

https://www.google.com:8088

Naturally, default ports for HTTP is 80 and HTTPS is 443.

• In the 'Request' field type:

GET / HTTP/1.0

And press 'Enter' twice

This is where the body of the message you are sending is to be placed. So anything obeying HTTP/S protocol, such as GET and POST requests, header fields and/or HTML content should be included here.

As part of the process of fuzzing web applications with JBroFuzz you need to have done your homework, in terms of providing a base request message. This message is what will be used later on to add payloads to particular sections of the request.

• Hit 'Start' [Ctrl+Enter]

This will instigate the process of sending a single request to the specified host on a given (or default) port, over HTTP or HTTPS.

Once a connection has been established JBroFuzz will proceed to submit the message you have typed into the 'Request' field.

Finally, JBroFuzz will log all data sent and received into a file; accessing this file is typically a process of double clicking on the output line on the table at the bottom section of the 'Fuzzing' tab.

You should see a response received in the bottom part of the 'Fuzzing' panel. Double click (or right click for more options) to see the information exchanged; typically this would be a 302 redirect pointing you to another location. Congratulations, you have just said "Hello" to Google!

JBroFuzz Hello Google!

Now this would typically be enough under RFC rules, to get a response back; but damn all the bots out here, most websites require further information to respond back. So, in the 'Request' field let's pretend to be a (kind of) legitimate browser by typing:

GET / HTTP/1.0
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) JBroFuzz/1.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-gb,en;q=0.5Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Not forgetting to end the request typed with two returns: Press 'Enter' twice. Again, you should be able to see a line added with the response received back.

Practice sending single requests to a website of your choice by changing the URL and also the 'Host:' field from the 'Request' above. Also try accessing an HTTPS website.

Alternatively, you can use the shortcut [Ctrl+L] to type in your URL, with the 'Request' field filled automatically, based on the URL you have typed.

HTTP Version Numbers & www.cia.gov Headerless Responses

For web applications, very often ill-defined requests submitted over the Internet, will trigger semi-legitimate responses that actually do not obey HTTP RFC protocol specification. Often, even though this is not the case in this example, these responses can lead to the identification of one or more security vulnerabilities.

In this example we test for the responses received for invalid HTTP version numbers on a particular website, namely www.cia.gov, over https. Now a word of caution here; please do not attempt to fuzz web applications that you do not have the authority to do so, especially over the Internet.

Still, for the purposes of this tutorial exercise, we will subject a web server to no more than a dozen or so requests. These requests would be otherwise identical, if it was not for the HTTP version number incrementing by a value of 1 on each request.

In terms of having the authority to do so, well this is identical to hitting 'Refresh' in your web browser a dozen or so times, while you are browsing to www.cia.gov. I do not consider this remotely close to any form of hacking, cracking, or proper fuzzing; web servers across the globe receive a lot more abuse than this on a daily basis.

Finally, by the time you are reading this, the particular issue described might have been fixed. So here goes:

• Within JBroFuzz, select:

File -> Open Location [Ctrl+L]

Type: https://www.cia.gov and hit enter. This is depicted in the following screenshot:

JBroFuzz Open Location

Hitting 'Enter' should automatically populate the 'URL' field and the 'Request' field within the 'Fuzzing' tab. What you see is the base request that we intend to add fuzzing payloads to. Before we do so, let us make one small alteration first:

• Modify the first line of the 'Request' field to:

GET / HTTP/0.0

Our objective is to enumerate the supported by the web server (in this case www.cia.gov) HTTP version numbers, following the two digit format that it has. We could be a lot more agressive here and test for buffer overflows and all types of injection; that would be out of line without the authority to do so. Instead we are going to see how JBroFuzz will iterate through the values of 0.0 to 1.4 by means of adding a Fuzzer to our base request.

• Highlight the second zero from the line 'GET / HTTP/0.0' and right-click, selecting 'Add'. This is depicted in the screeshot below:

Adding a Fuzzer to the HTTP version number

• From the appearing 'Add a Fuzzer' window, select as 'Category Name', in the most left column 'Base' and as 'Fuzzer Name' in the middle column 'Base 10 (Decimal) Alphabet.

• Click on 'Add Fuzzer' on the bottom right of the window

Adding a Fuzzer

This should add a Fuzzer of length 1 that iterates over the decimal (i.e. base 10) numbers 0 to 9. If we have added a hexadecimal Fuzzer instead of a decimal one (i.e. base 16) the iteration would from 0 to F. If we had selected two digits instead of one and proceeded to add a decimal Fuzzer, the iteration would be from:

00
01
..
98
99

From a User Interface (UI) perspective you should see a line added to the 'Added Payloads Table'.

• Click 'Start' [Ctrl+Enter]

This process will send 10 requests to the specified web server changing only first line of the request to:

GET / HTTP/0.0
GET / HTTP/0.1
...
GET / HTTP/0.8
GET / HTTP/0.9

While this is ongoing, you can sort the results by 'No' in the 'Output' table in the bottom of the 'Fuzzing' tab. This should enable you to see what request is currently being transmitted and received in real time.

Once complete, change the first line of the 'Request' field to read:

GET / HTTP/1.0

• Click 'Start' [Ctrl+Enter]

The resulting output should resemble the following screenshot:

JBroFuzz Output from a Fuzzing Session

Straight away we can notice a difference in the response size: For HTTP version numbers 0.0 to 0.9 we are getting back what seems fairly big in size responses; 32222 bytes in size worth of responses, given that HTTP protocol version 0.0 to 0.8 do not officially exist!

By double-clicking on one of these requests, we can see that the web server in question is responding back with no headers, yet returning a full HTML body; this represents the 32222 bytes of response of data we are receiving back. The following screenshot illustrates this:

JBroFuzz Output for a Single Request/Response

Using the 'Graphing' tab we can proceed to graph the particular requests and responses for this given session.

• Within the 'Graphing' tab, click 'Start' [Ctrl+Enter].

• Select the directory corresponding to the Output folder we have used for this fuzzing session. This will typically be the last one.

• Right-click and select 'Graph'

Once complete, browse to the 'Response Size' tab within the 'Graphing' tab, as illustrated in the screenshot below:

JBroFuzz Graphing different 'Response Sizes'

To re-iterate this does not present a security vulnerability in any shape or form; merely the fact that by manipulating HTTP version numbers as part of the request we transmit, we can impact the response that we get back. In this case, what changes is the non-existent header fields, with some HTML content being received back.

If I was to guess what is causing this, I would say that some sort of load balancing or content delivery is not happening as it should when non-existent version numbers are being transmitted.