Categories
http proxy SQL injection

Webscarab Tutorial Part 3 (fuzzing)

Part 2 covered the neat functionality of session ID analysis within Webscarab. Now we’ll focus on another great function within Webscarab, fuzzing. I define fuzzing as testing the input of an application by trying various parameters that the input may not expect. These parameters don’t have to be random, in my opinion it’s best when you tailor your parameters depending on the application. When fuzzing you typically want to inject “command & control” parameters into the input to find the most serious vulnerability. For example if a web application is expecting a social security number I may inject html parameters such as ” < / > ” to manipulate the look, feel, and operation of a web application. I don’t want to delve a whole lot into fuzzing because there are books out there that talk about this one subject. This tutorial is going to focus on using Webscarab to fuzz web applications and find vulnerabilities. Hopefully by the end of this tutorial you will better understand the technical aspects of fuzzing as oppose to the concept of fuzzing, but more reading on fuzzing web applications may be required.

This tutorial will once again be targeting Foundstone’s Hacme Casino which intentionally has vulnerabilities built into the application. Fuzzing can focus on different types of vulnerabilities and parameters within web applications (e.g. XSS, SQL injection, queries, directory paths, etc…), although this tutorial will focus on parameters vulnerable to SQL injection. Foudstone’s documentation lets us know that the username input is vulnerable to SQL injection so we can try fuzzing it with Webscarab to find other possible injections. First we’ll try and login with the username ‘test’ and password ‘test’. This can be seen in Figure 1.

Try logging into Hacme Casino

Figure 1: Trying to login

This will not log us into the application but Webscarab will capture the login process in the summary tab. Once this has happened find the login conversation in the summary tab. After you have found the login conversation simply right click and select “Use as fuzz template”, this will send the parameters and headers associated with that request / conversation to the fuzzing tab. Selection of the login request can be seen in Figure 2.

Right click request to use as a fuzz template

Figure 2: Send conversation to fuzz template

Now navigate to the Fuzzer tab within Webscarab. Here you’ll see all the parameters that are associated with that request / conversation. You could add parameters to the request and see how the web application reacts to different paths, value, or types. You could also delete parameters for simplicity and to also see how the application reacts with those parameters missing. Once you have determined the parameters for fuzzing you’ll need to define a fuzz source. So click on the “Sources” button beside “Start” and “Stop” within the Fuzzer tab. Here you will choose a dictionary style text file that contains parameters you want to fuzz with. I chose a SQL injection dictionary because we know the “username” field is vulnerable to SQL injections. The selection of the SQL injection dictionary can be seen in Figure 3.

Choosing SQL injection dictionary as a fuzz source

Figure 3: Choosing fuzz source

In my SQL injection dictionary I have 66 items, but Webscarab does not have a limit. There are lots of SQL injection dictionaries out there, some are even dedicated towards different platforms (e.g. MySQL, MS SQL Server, DB2, etc…). I got most of my SQL attacks from Andres Andreu’s website Neurofuzz, the dictionary I pulled from can be found here. In this tutorial we won’t be trying to fuzz for XSS vulnerabilities but ha.ckers.org has a now infamous XSS dictionary which is a great resource. Once all dictionary sources are added go to the main Fuzzer tab and assign parameters a fuzz source. This can be done via a drop down menu as seen in Figure 4.

Choosing fuzz source for each parameter

Figure 4: Drop down menu containing fuzz source

In order to prevent a parameter from being fuzzed simply leave the “Fuzz Source” field blank or delete the parameter altogether. In this case the “user_login” is the only parameter that will reiterate through the SQLattack dictionary. The next step is to click on “Start” and let Webscarab try all of your parameters within the dictionary. This means the value “test” will be replaced with values inside the SQL injection attack dictionary and new request is sent to the web server for every attack parameter inside your dictionary. The fuzzer in action can be seen in Figure 5.

Running the fuzzer

Figure 5: Running the fuzzer

Notice the “Total Requests” and the “Current Request”, once the fuzzer has run through all of the parameters in the SQL injection dictionary both of these numbers will be 68. Also notice the ID number 97 on the left hand side of the table, this is the first request of the fuzzing operation. The last request will have an ID number of 164, it’s important to keep track of these request ID’s when reviewing results of the fuzzing operation. I have found myself reviewing requests that weren’t fuzzed and accidentally identified requests as not being vulnerable when in fact they were.

Once the fuzzer has made all of the requests a review of the results is needed to see if any of the attack parameters succeeded in a SQL injection. I do this simply by going back to the summary tab and opening up the first conversation of the fuzzing process. I then manually step through every conversation involved in the fuzzing operation and look for any “interesting differences” between responses. The phrase interesting differences is in quotation marks because fuzzing and looking for SQL injections is not an exact science but knowing how an application normally deals with the input will be helpful in determining what should and should not be expected in a HTTP response. Let’s take a look at some of our fuzzing conversations to get a better idea of discovering differences. Have a look at the first fuzzing request, note the value of the “user_login” parameter in the request and the value of the “Location” in the response. This can be seen in Figure 6.

First fuzzed conversation

Figure 6: First fuzzed conversation

Here it’s seen that the first value in the attack dictionary was actually used for the username value, good to know Webscarab is functioning properly. The top of Figure 6 shows that a POST request is sent to /account/login to check the credentials of the user, since the first SQL injection is not a valid user the response is to redirect back to the login screen. Keep in mind when looking at these conversation screen shots that the top half of the figure is the request and the lower half is the response. It can be deferred from this conversation that if an invalid username is inserted into the web application the response will be a redirect to the login screen. So when looking through the other SQL injected conversations it would be a good idea to look for a redirect to another location or an error message. It’s always a good idea to look for database error messages when trying to find SQL injection vulnerabilities within a web application. Stepping through the other conversations I notice something different, this can be seen in Figure 7.

Successful SQL injection

Figure 7: SQL injection changed redirect location

Looks like on conversation 103 one of the SQL injections in the attack dictionary changed the location of the redirect to /lobby/games. Let’s throw the injection value back into the web application and see what the response may be. The request can be seen in Figure 8.

SQL injection on Hacme Casino username

Figure 8: SQL injection request on Hacme Casino

The response to this SQL injection can be seen below in Figure 9.

Successful SQL injection

Figure 9: SQL injection response (Great success!)

Looks like the SQL injection gave us access to Andy Aces’ account. This occurred because we added the phrase “or 1=1” (which is always true) to the end of the SQL query that authenticates the users to Hacme Casino. The reason Andy Aces’ account was hijacked is because his name is the first one in the database. Guess having the last name Altman could be bad for me as well? Looking through the other conversations there appears to be another SQL injection that worked as well, this can be seen in Figure 10.

Another successful SQL injection

Figure 10: Another successful SQL injection

The hits just keep on coming. This may seem to easy but there are plenty of web applications out in the wild that don’t validate input and let malicious users manipulate their application and backend databases. SQL injections within a web application can be a serious vulnerability depending on the data held within the database. Had this scenario been real a malicious user could have taken over Andy Aces’ account and had his way inside the online casino.

The fuzzing functionality of Webscarab makes web application vulnerability assessment a more automated process. Manually entering all of those SQL injection attacks can take a very long time. There is a downside to the dictionary approach though, your dictionary may not be as creative as a malicious user. Some people believe that a fuzzer should generate random input and that you should try thousands of requests in order to properly test a web application. Thousands of random requests could be better but stepping through those requests to determine validity can make for a long day. Although if one were to take the random input approach Webscarab has a solution for stepping through those results, the Compare and Search functionality. I may dive into the Compare and Search functionality at a later date, these functions can really speed up the process of web vulnerability assessment. Also keep your eye open for a video tutorial of Webscarab coming soon, you could always subscribe to my feed for the latest and greatest.

Once again I hope this tutorial was helpful in showing you the great features of Webscarab, as always your comments and feedback are welcomed.

travis@home:~$ more references

Owasp Webscarab fuzzing tutorial

Rogan Dawes documentation for Webscarab

Foundstone Hacme Casino

43 replies on “Webscarab Tutorial Part 3 (fuzzing)”

Kiran,

Scripting could be coming up in the future. I don’t have any direct experience scripting in Webscarab but that is also a great feature within Webscarab. I really want to put together a basic video of Webscarab first before going into the more advanced features. If you have any direct experience Kiran I would love to hear how you have implemented the scripting feature. Thanks for the comment.

Please continue this series. Your screenshots and step-by-step approach make your tutorials perfect for getting started with WebScarab. You should put a link to this on material on the OWASP site.

Thanks Rupert,

I’m definitely gonna keep up the series, as I said in my previous comment I’m probably gonna do videos on the articles I have written so far. Hopefully after that I’ll stretch my legs on some of the other functionality within Webscarab.

I am also gonna put some of this information into the Wiki over at OWASP, soon as I get off my lazy behind.

Thanks for the nice series to webscarab. I found it quite helpful in get myself going with it. 🙂

Tom,

I’ll be posting more videos on how to use Webscarab as well, let me know if you find those helpful as well. Thanks for the positive feedback.

does the SQL attack dictionary alter information in the database? or you have used a sample that does not do so?

kim,

in order to alter information in a database you will have to issue commands such as DELETE, INSERT, UPDATE, etc. these commands are in the attack dictionary i linked to on neurofuzz.com but they are stand alone commands. so the odds of them modifying information in the database is slim but you could remove them to be on the safe side.

when performing sql injections into a form its usually going to be in the WHERE clause of a sql command, so issuing a command such as SELECT COLUMN FROM TABLE WHERE DELETE isn’t going to anything but generate an error. you would have to combine the DELETE command with something else such as SELECT COLUMN FROM TABLE WHERE 1=1; DELETE TABLE;. i hope this answers your question, but to be on the safe side i suggest you go ahead and remove those dangerous attacks because you may not always inject something into the WHERE clause. you never know how the query is structured on the server side. happy injecting!!!

securitycompass.com has also created a Firefox extension that can test for sql injections as well. the good thing about this extension is that it’s free, open source, and you can modify the fuzzing dictionary. it will automatically find all form inputs (hidden as well) and inject your entire dictionary into all form inputs for that particular page. it doesn’t show the individual responses like Webscarab does but it does output a report showing injections that may have worked. its a quick way of automating the process right inside Firefox. check it out.

http://www.securitycompass.com/exploitme.shtml

Yr tutorial was of great help. Not only did it clear the concept on the usage but also gave a very good insight to penetration testing’s most tedious job of trying out each and every exploit. Fuzzer seems to be very helpful.

Thank You.

Hi.
I like your tutorial.
Why do not you post the table of contents as centralized place to find all tutorial’s parts?
User have now idea how parts of tutorials are available and how to get to desired part.
Best Regards, Alex.

that’s a good point Alex, i’ve been meaning to do that. i’ll add that functionality soon where you can click on archives by month and year. i may also add a section on popular posts so that people can quickly access those (e.g. webscarab fuzzing tutorial).

in the meantime one can click on older posts to the left and newer posts to the right at the top of the page. hope this helps for a temporary solution. also thanks for the feedback Alex.

Hello Travis,
I love your tutorial, I get to ‘make love’ with my webscarab and web app as a n00b. You should continue this tutorial. I’ve shared this to my friends who are also trying to test their web applications for possible exploits. Uhmmm, I’ve got one question though, as a newbie, I’m having a hard time with fuzzing because the memory below (the one below with the green background) is set to 63mb only. How do I set it to a much bigger space so that I can test a lot of SQL attack dictionary? Really nice tutorial. 🙂

Best regards,
Monk

monk,

thanks for the positive feedback. your question on the memory usage is a good one and unfortunately i dont know the answer. you could email Rogan Dawes, one of the core developers. he’s a pretty receptive guy and should definitely have the answer. a link to his info is below.

http://dawes.za.net/rogan/

also make sure you dont have a kafillion conversations captured, this seems to slow down all proxies not just webscarab. i often have to start fresh after capturing a large number of conversations.

Hi Travis

Thanks for the super tutorial on scarab. I was wondering though, could you post your complete dictionary of 66 SQL hacks for the blind injection. I’m currently working on a SQL scanner, and the complete list would be extremely helpful.

Very useful information.
I am a beginner with security testing and am assigned task to intercept requests of another machine. E.g. If Webscarab is running on “Test1″ machine then i have to intercept requests of “Test2″ machine which is a different machine. Is there a way to accomplish this?
Thanks in advance.

Abhi

abhi,

i’m assuming you mean “Test2” is going to google.com and you want “Test1” to intercept that request? i’ve never tried that but it seems that would be possible but only if “Test1” and “Test2” were on the same LAN. also “Test1” and “Test2” would have to be connected to a hub (Layer 2 on OSI model) instead of a switch/router (Layer 3 OSI model). if “Test1” and “Test2” were connected to a switch/router you could ARP spoof to accomplish this as well. just a thought, let me know if you’re able to accomplish this.

Your tutorial was of excellent help for me to get started on webscarav. It was simply superb.It would be very nice if u can cover other functionalities( like xss/crlf,compare,scripted etc) in webscarab too.
Thanks for the simple,lucid explanation in all the 3 tutorials.

sree577,

thanks for the positive comments. i do plan on posting more in the future. i just recently took another job teaching so my time is limited. subscribe to my feed and hopefully you’ll see more posts sooner than later.

Hi Travis,

I was Testing an application through Webscarab in remote login which was deployed in “http://training:8080/xyz/” but unable to test.

On running the Web scarab i got following errors:

WebScarab encountered an error trying to retrieve

GET https://training:8080/daytrader/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, */*
Accept-Language: en-us
UA-CPU: x86
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: training:8080

The error was :

Unrecognized SSL message, plaintext connection?
at com.sun.net.ssl.internal.ssl.InputRecord.handleUnknownRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at org.owasp.webscarab.model.Request.writeDirect(Request.java:233)
at org.owasp.webscarab.model.Request.writeDirect(Request.java:214)
at org.owasp.webscarab.httpclient.URLFetcher.fetchResponse(URLFetcher.java:241)
at org.owasp.webscarab.plugin.proxy.CookieTracker$Plugin.fetchResponse(CookieTracker.java:130)
at org.owasp.webscarab.plugin.proxy.BrowserCache$Plugin.fetchResponse(BrowserCache.java:101)
at org.owasp.webscarab.plugin.proxy.RevealHidden$Plugin.fetchResponse(RevealHidden.java:100)
at org.owasp.webscarab.plugin.proxy.BeanShell$Plugin.fetchResponse(BeanShell.java:229)
at org.owasp.webscarab.plugin.proxy.ManualEdit$Plugin.fetchResponse(ManualEdit.java:243)
at org.owasp.webscarab.plugin.proxy.ConnectionHandler.run(ConnectionHandler.java:223)
at java.lang.Thread.run(Unknown Source)

Could you pls help me to solve my problem or any other site where i can post my problem.

Thanks

Harjeet

Hi Travis

I am not getting any pop up window on security certificate for my application. Even though I clicked Intercept botton ON/OFF.Can you pls tell me wat to do?

Thanks
Harjeet

Hi Travis
I work on OWASP livecd Austin terrier Feb2009. When I tried webscarab as a sql scanner I didn’t found the entry of Location
please replay ASAP
thanks in advance

I added sql dictionary and started scanning then I went to conversations to check if the expression will take me to another page, I didn’t found “Location” 🙁

mohamed,

not all web applications use the “location” field in their headers. it just so happens the example i used does. when looking to see if the sql injection was successful it’s better to look in the body of the response (aka the very bottom pane in webscarab). if you see any errors or something that looks out of place then you may be able to perform sql injection. it’s not an exact science but be on the look out for a response that is abnormal. does that answer your question?

Hi Travis,

Many thanks for your informative posts,

While working on my project instead of fuzzer i used XSS/CRLF functionality available in webscarab, the difference that i found was

In fuzzer you have to select the attack vectors against the listed parameters one at a time, so if in case of 5 different parameters you have to repeat the fuzzing task 5 times (This reply is purely according to my experience, i welcome if someone found a nice method to do it)

Assume that particular URL methods are vulnerable to XSS/CRLF attacks then I bet, that particular URL will be picked up by the XSS/CRLF section, the beauty of this method is
assume that you have five parameters, you just have to update “Edit Test Strings” (add some more attack vectors, one below one) and click on Check button, all parameters will be auto injected and you will find the response.

Here no need to inject parameter by parameter as it in case of fuzzer.

If you are already updated this feature somewhere else then that’s awesome, or else I request you to update it.

Correct me if I am wrong

Note: If parameters are vulnerable then you will definitely get a response or else there will be no response.

Hi Travis,

When I have started using webscrab it was working fine but now everytime I start the webscrab I am getting the following error:-

Exception in thread “Listerner-xxx.xx.x.xxxx” java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknow Source)
at org.owasp.webscarab.plugin.in.proxy.Listener.run(Listemer.jave:128)
at java.lang.Thread.run(Unknow Source)

Any idea how to resolve this issue..machine is 32 bit with OS7.

Sunny,

I’m not sure but I’m seeing an “OutOfMemoryError” so maybe check and make sure you have enough memory free when you go to run webscarab.

Hey, Can you please discribe the diference between injection and possible injection in webscarab?

Leave a Reply

Your email address will not be published. Required fields are marked *