XSS-Me is one of the tools in the series that helps to find cross site scripting (XSS) vulnerabilities within web applications. The tool works by locating forms within a web page then tries various inputs into those forms to see if the inputs on that page are vulnerable. A screen shot of how the tool should look inside Firefox can be seen below.

Now all you have to do is click “Run all tests” and let XSS-Me do its thing. Keep in mind that XSS-Me will also find any hidden forms within a page as well. So this is how things are suppose to work but you’ll eventually come across a page that has forms but XSS-Me doesn’t detect them, this is because the page you are viewing has frames. A good example of this is Chris Rohlf’s site seen below.

From the screen shot you can see there is a search form at the top of the page but XSS-Me doesn’t detect its presence. This is because the search form is wrapped inside of a frame. A quick little tip to get around this problem is to open the frame in another tab/window. All you have to do in Firefox is right click on the frame then select “This Frame > Open Frame in New Tab”. A screen shot can be seen below.

Once you have the frame in a new tab XSS-Me will detect the form as normal. This can be seen in the screen shot below.

This same technique will apply to the SQL Inject Me tool from Security Compass as well because it also tries to search for forms within a web page.

This tip was passed along to me by Sahba Kazerooni who works at Security Compass. I have no affiliation with Security Compass but I met Sahba and some other Security Compass employees at a conference and they were all down to earth guys who had great knowledge and experience when it came to information security. So thanks for the tip Sahba and hopefully this tip will help others secure their web applications as well.

Basically what’s happening is attackers are using SQL injection, in some sort of automated fashion, to insert Javascript malware into databases of some popular websites, the United Nations for example. Once a user visits an infected website (un.org) they will unknowingly be sent to a malicious site where attackers try numerous exploits to see if they succeed. Keep in mind the user will remain on un.org as if everything is fine and dandy but in the background exploits are being launched.

What’s so scary about these widespread infections is that the Javascript malware will remain on the database until the webmaster removes it. Even then the websites will still be vulnerable to SQL injection so attackers could reinsert malware until the vulnerability is fixed. Also attackers could easily update the location of their malicious site through SQL injection. For example lets say attackers are using http://evilattacker.com for launching their exploits but this URL gets blacklisted, they could then update infected databases with a new URL, say http://maliciousattacker.com. So this type of widespread epidemic is the gift that keeps on giving.

I’ve seen these attacks come across the IDS (intrusion detection system) where users are visiting infected URL’s. Of course attackers could easily move their operations to different URL’s. Some exploit URL’s I’ve seen so far are nihaorr1.com, nmidahena.com, aspder.com, rirwow.cn, and wowyeye.cn. I performed searches to get an idea of the infection numbers, now doing a search for the offending URL won’t give you a 1 to 1 relationship but it will give you a ballpark figure. Take a look at the “Results” numbers in the following screen shots.

Also check out this screen shot from ririwow.cn, you’ll get a laugh from it.

So the ballpark infection just from these three URL’s is 500,000, scary isn’t it. Even if this number is 400,000 off that still leaves 100,000 sites infected. There’s no way at this point to verify the number but this is definitely the largest SQL injection campaign I have ever seen. It’s these URL’s along with others that are hosting the Javascript malware. It’s common to see the attackers use Javascript to open zero pixel iframes so the attack appears hidden. The Javascript files I’ve seen so far are short names with either a single letter or number (e.g. m.js, 1.js, jp.js, etc). So the request that happens in the background will look like http://ririwow.cn/jp.js. In order to see the request one would have to use a local web proxy. Without a proxy you would never see the request. So I’m going to keep my eyes peeled in the coming months to see how this epidemic plays out.

Below are some other good articles related to this topic

Internet Storm Center

Websense

ShadowServer

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.

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.

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.

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.

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.

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.

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.

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.

Figure 8: SQL injection request on Hacme Casino

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

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.

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