The way David approached the XSS vulnerability scanning cuts down on the amount of requests being made to the web application as well as the number of false positives as compared to other scanners that I’ve checked out.

Like all web application scanners when trying to detect non-persistent XSS Grendel substitutes a known parameter value for a value that includes javascript code. As mentioned in my previous posts it might change something like this:

param=123

to something like this:

param=123/><SCRIPT>alert(’XSS’);</SCRIPT>

Generally when the scanner sees the signature included in the response (/><SCRIPT>alert(’XSS’);</SCRIPT> in the above example) then they’ll flag it as a possible XSS vulnerability.

Now for the most part a web app scanner will have many, many different XSS signatures (different javascript-type parameter substitution values) that it will try on a particular parameter value. For instance, for the sake of thoroughness a web app scanner might have 40+ different XSS signatures that it will try for each and every parameter that it records going to the application to detect XSS.

Like I mentioned most scanners are extremely inefficient and noisy in the sense that they’ll continue to submit as many requests as there are XSS signatures until it flags a particular request as being vulnerable to non-persistent XSS. So if there are 53 XSS signatures a typical scanner will submit 53 requests per parameter (again, unless it flags a request within the 53 signatures that it sends as being vulnerable).

If you’re scanning an application that has a lot of parameter values (like hundreds or thousands) being sent in a request, as most applications do, this can end up being a lot of traffic being sent to the application being scanned.

If you’re scanning a staged or development environment this usually isn’t too much of a concern but if you’re scanning a production environment – this can cause concerns. One of the biggest problems with sending out all of the XSS signatures per parameter in an application (besides bandwidth and resource saturation) is form submissions that generate emails. For certain form submissions on a number of applications, such as a “Contact Us” form the submission information is emailed to a particular person or persons within the organization who is in control of the application. This generates one email per request sent to the particular form.

This means if you have a form that has 10 parameters and your app scanner has 53 XSS signatures you’ll have at around 530 emails being sent to someone – keeping in mind this is only for XSS detection. You’re likely to have a whole lot more submissions being sent and emailed to someone when you’re scanner is looking for other issues like SQL injection vulnerabilities, CRLF vulnerabilities, directory traversal vulnerabilities, etc. At the end of the scan it’s very, very possible someone will open their mailbox and have thousands of junk emails from scanning the site.

So – what does David do different when discovering XSS with Grendel? Before throwing each XSS signature at every parameter Grendel will first send a random value (a token) as a parameter value with a fixed 4 digit prefix (keep in mind that in order for an application to be vulnerable to non-persistent XSS it first has to echo back the parameter value in the response).

So it’d be something like this:

param=fds5fds34

Each response is searched for the prefix. The fixed four digit prefix (fds5) doesn’t change throughout the scan – which makes it easier to look for tokens in responses. If the prefix is found then the six characters following it are looked up (that way you don’t have to search for every token in the response).

If Grendel sees the token being returned in a response only then will it continue to send the XSS attack signatures. This cuts down on the amount of “useless” XSS attack signature requests being made to the web server. If the application doesn’t echo back a token value – then it’s not going to be vulnerable to non-persistent XSS in the first place.

Not only is this a lot better for production sites, it cuts down on scanning time because less meaningless requests are being sent to the application.

Another thing that David has done to reduce false positives with XSS is he’s implemented the Rhino javascript engine from Mozilla into his scanner. This way a XSS vulnerabilitiy is cataloged with Grendel only if the response triggers the javascript engine to fire.

This cuts down on XSS false positives tremendously. As a neat bonus he’s included a module called input/output flow that records any request that responds with a token value – just in case there is a posibilitiy of a XSS issue being present but the supplied XSS attack signatures was not able to trigger the javascript engine.

Grendel was released at DEFCON last year and becuase of his hectic work schedule he hasn’t updated it much in the last few months but I hear he (and a few others) are working on it now and should have a new release really soon.

You can find it here: http://www.grendel-scan.com/

Cheers,

ChuckB.

I figured it was a bold statement when I said “I mean to build a web app scanner generally isn’t rocket science,” and I thought it might ruffle the feathers of some who have vested time into a really robust web app scanner project. Now, I’m sure that Caleb didn’t get too bothered by my post – but his response included the following “…at the surface it may seem like that but there is nothing farther from the truth. It is one of the most complicated pieces of technology I have ever had to deal with. Its not as simple as parsing out HREFs and sticking single quotes in params.”

He was referring to a scanner I referenced in sentence I wrote: “There’s actually a really good how-to write your own web app scanner in the O’Reilly book “Network Security Tools, Writing, Hacking, and Modifying Security Tools.” The code for that one is available here.” Which pretty much does – just what Caleb said it does – not too much. It’s simple and limited, but the right basic theory is there for a good and solid web app scanner.

Before I break all this down and go on – let me first say that I don’t think there’s an automated solution on the market (and there likely won’t ever be) that can find every vulnerability in your web application. There are things that scanners are good at picking up, input validation problems like xss and sql injection, directory listing stuff, CRLF injection, etc. And there are things that they aren’t too good at picking up, like logic based errors which grant you some sort of privilege escalation or give you access to something you shouldn’t have – like a sensitive file (the scanner might not know that you shouldn’t have access to that file) that is specific to that custom application.

Another metric that is typically used when judging the effectiveness of an automated web app scanner besides how well it finds vulnerabilities (and how many vulnerabilities it finds) is application coverage when crawling a site. For instance, when you are looking for vulnerabilities in an application you want to make sure that you’re looking at all of the pages and/or functionality of the application. If you (or the automated crawling functionality of a scanner) miss parts of the application and those parts of the application don’t get tested – then that’s a problem. Therefore, I always like to have a two-pronged approach when blackbox testing. I like to crawl the site manually and have a good crawler hit the application and feed the requests to a scanner, that way if one method misses something – hopefully the other method will have picked it up – this way we can be sure we’re maximizing application coverage to the best of our ability.

That being said – I don’t think that testing web apps should ever be an automated or manual kind of a process, but more of an automated and manual kind of a process (that is, if you really care about the overall security posture of your application). I don’t think there’s too many experienced web app pentesters out there who would disagree with me on that one.

However, let’s focus on some things that web app scanners are good at, like finding XSS and SQL injection vulnerabilities – and talk about possible tools (scanners) that one might use to accomplish this (for free). And with a little modification to these free tools, such as incorporating some of the concepts discussed below, one could possibly garnish better/more results (XSS, SQL injection vulnerabilities being identified) than some scanners out there that cost you thousands of dollars.

So going back to what I think scanners are good at, like fuzzing parameter values to look for things like XSS and SQL injection problems.

First off, the basic and fundamental way web app scanners work – is they essentially send a request to the application, then they look at a response to see if the request the scanner made affected the application in some way and made it send something back that it shouldn’t have (in a way that could be a potential security problem or vulnerability).

I’ll talk about a few examples that are probably the two most common (and arguably the highest impact) vulnerabilities in web applications that most scanners look for, XSS and SQL injection.

Let’s talk about XSS – the basic (easy, yet effective) way most scanners look for XSS is they send a request to the web server – and they replace or add on to the original value of the parameter with some potential javascript code – then see if it gets echoed back in a response. For example, a scanner might change something like this:

param=123

to something like this:

param=123″/><SCRIPT>alert(’XSS’);</SCRIPT>

Then they simply perform a regex on the response looking for /><SCRIPT>alert(’XSS’);</SCRIPT>. If they see it – then they’ll flag it as a possible XSS vulnerability. Really not too hard.

Now there are some applications or web app firewalls that filter things like <SCRIPT>, <IMG>, etc. so what you can do is add say, RSnake’s XSS list for filter evasion (a list of signatures) to what your scanner adds or substitutes for parameter values. Simply cycle through that list of signatures until (if and when) you come across one that gets echoed back in a response. RSnake’s cheat sheet can be used as a starter for signatures. As you play with web apps more and become more acquainted with filter evasion and XSS you can just add those to your list of signatures in your scanner.

Now I do have a friend who is working on a scanner that is a bit more sophisticated in detecting XSS, in that it will eliminate false positives and cut down on the number of overall requests (like not having to cycle through the whole list of XSS signatures on every parameter being submitted to the web application). But I told him I won’t talk about it too much until after he releases it at Def Con. However, even though his technique is more efficient – the above technique is what 99% of web app scanners do when looking for XSS – and this method works quite well, even though for some reason – there’s a lot of expensive web app scanners out there that can’t even get this part right, and manage to screw this part up somehow.

SQL injections are a little more complicated to look for in a scanner, but not much – remember, this isn’t rocket science.

There’s basically two different kind of SQL injections – regular (verbose database messages) and blind SQL injections.

To check for regular or verbose SQL injections – you send a request, like using a single tick ( ‘ ) as a parameter value, or at the end of a parameter value and look for the response.

Using our example of param=123 we might substitute the original value for something like paramm=123′1

If you get some database error message like this in the response then chalk it up as a possible SQL injection:

Microsoft OLE DB Provider for ODBC Drivers error

So there could be different back end databases that they might be using so you might want to look for other error messages from different databases other than MSSQL like Oracle, IBM DB2, MS Access, PostgreSQL, MySQL, etc.

Also, we could try different encoding on our single ticks like CHAR(39), 0xbf27, amongst others.

Besides single quotes (or ticks) we can also try to sneak in things like semi-colons ( ; ) and double dashes ( — ) and their encoded equivalents to try and generate database error messages.

Blind SQL injections are a little bit different beast in that we don’t just regex a response looking for a database error message, but rather we look for a change in behavior of some sort from the application.

There are basically two different types of blind SQL injections – conditional and time delays.

We’ll cover how to test both really quick.

For the time delay blind SQL injection detection you simply add something like this to the original parameter value:

‘;WAITFOR+DELAY+’0:0:10′– (MSSQL)

This tells the SQL backend to wait for ten seconds before responding. So a way to implement this in a scanner is you make a regular (non-fuzzed) request with no “waitfor delay” manipulation in the parameter value, then you calculate the time it took to make a regular request (let’s say it takes 950ms). Then, go ahead and send the time delay fuzzed parameter value (such as param=123′;WAITFOR+DELAY+’0:0:10′–). If you get a response right away – then, mark the parameter as not vulnerable, if you get a response from the webserver that took 10 seconds or later (you can calculate in the time it takes for the request such as the 950ms) then you can mark that as being a possible time based SQL injection vulnerability.

One can also use other time based queries for different databases other than MSSQL, such as the following:

SELECT pg_sleep(10); (PostgreSQL)

BENCHMARK() function (MySql)

Also – we could try adding parenthesis and such to escape from SQL subqueries like the following:

param=123;waitfor+delay+’0:0:10′–
param=123);waitfor+delay+’0:0:10′–
param=123′;waitfor+delay+’0:0:10′–
param=123′);waitfor+delay+’0:0:10′–
param=123));waitfor+delay+’0:0:10′–
param=123′));waitfor+delay+’0:0:10′–

Also – we would want to try the encoded equivalents of semi-colons (%3B), dashes (%2D), plus signs (%2B), etc. with all of these queries.

Next, we have conditional blind SQL injection vulnerabilities to hunt for. For this type of SQL injection vulnerability identification the scanner must also look for some behavioral change from the application.

According to webappsec.org the following is how to detect blind conditional SQL injection vulnerabilities:

A common way to detect Blind SQL Injection is to put a false and true statement into the parameter value.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=1

should return the same web page as:

http://example/article.asp?ID=2

because the SQL statement ‘and 1=1′ is always true.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=0

would then cause the web site to return a friendly error or no page at all. This is because the SQL statement “and 1=0″ is always false.

They’re not far off, by issuing a series of true/false type queries in a request (parameter value) then we can see if there is any difference behaviorally with the application – sometimes in a “false” query you get an error page, sometimes other types of changes in the response.

Easy enough, so for a scanner we can just do something like the following:

param=123′ and ‘1′=’1

and

param=123′ and ‘1′=’2

If we get a different page for each response – then we could chalk that up as being a possible vulnerability and worthy of looking into.

We could also use different true/false queries such as:

param=123′ or ‘a’='a

param=123′ or ‘a’='b

or even better, just substitute some random string for ‘a’ and another random string for ‘b.’

There are other things – that one could look for in (and add to) a web app scanner such as command injection, directory traversal attacks, CRLF injection, CSRF, session problems like session fixation, etc. but, again – it’s all fundamentally based on the concept of making a request to the application, then checking the response to see if the request the scanner made affected the application in some way and made it send something back that it shouldn’t have (in a way that could be a potential security problem or vulnerability).

I did mention that there was something out there that one could get for free that is a really good starting point for a good scanner. Here it is: sts-scanner. It is pretty limited in it’s functionality – much like the original ExtendedScanner, as a matter of fact it’s based on the ExtendedScanner. But with a few tweaks – like adding some more XSS signatures and adding some of the SQL injection scanning logic mentioned above (it already includes some of it, plus things like column enumeration when it finds a sql injection) – I would put money on it against any of the expensive (or non-free) web app scanners out there when it came to looking for things that it was designed to look for.

Cheers,

Chuck B.

The web app scanner market is really odd. For some reason, the market just can’t seem to get it right. I’ve worked at places that have had head-to-head comparisons of all the major web application scanners because they had built a proprietary scanner (but it wasn’t for sale – they sold a service that used the scanner) and would have these comparison tests every once in a while to see how their product stood against the competition. Now, I didn’t really run the tests myself because I was doing billable work (mostly web app testing) at that moment, but a friend at the company working right next to me was doing the comparison testing – so he’d share the results with me whenever I continually look over his shoulder and asked about them.

It was kind of a funny thing. One was always better at picking up XSS than another, Some other one was good at picking up SQL injection, while some weren’t, one was always better at code coverage when using an automatic crawl functionality, some wouldn’t work well in certain authentication scenarios, etc., etc.

I mean – web app security is a hot market these days, and rightfully so. Most (not all) organizations (for the external infrastructure) generally have firewalls up blocking most un-needed services. They’re aware of shutting down extraneous services, incorporate some sort of patching solution, etc. but almost all have a web site.

As time goes on, and security awareness goes up, rules or laws instituted making companies liable for compromises, things like finding an mssql server on port 1433 with a weak password, anonymous ftp, un-patched webservers become less and less common in an external environment.

But again, almost every company has a port 80 or 443 open with some application somewhere. Web applications provide, by far, the largest external attack surface in an organization – there’s typically hundreds of user-controlled parameters going into the application, which are all a potential threat. Plus, a lot of the time there’s all kinds of interesting things when web apps get exploited, like user names and passwords that can be used for other services throughout the organization, credit card numbers, personal identification information, and more. And luckily for people who are into (in)security, most of the time it’s custom code written by people who know nothing about security – and don’t have that much experience, as opposed to other services that they have externally facing that generally have a lot less attack surface and have been written by some well-known company or a community, tested a lot and have more-or-less stood the test of time (like most PPTP or SSH servers).

So I could never understand – with the market so hot (like – if you’re a security company and you’re not selling web application work when you are offering the service then something is seriously wrong with your sales team) why a company or open source project has never got it right.

Why not try out all the web app scanners on the market, take the features, techniques, signatures of the ones that perform certain functions the best (or better than the others) and combine them into one tool? Someone could make real decent money doing that. I’d almost be tempted myself – but I it’s just not something I’m really interested in. Look at how much money IBM/WatchFire’s AppScan and HP/SPI Dynamics WebInspect pull in for them – and their products really aren’t that great, like at all.

I mean to build a web app scanner generally isn’t rocket science (or even computer science most of the time). There’s actually a really good how-to write your own web app scanner in the O’Reilly book “Network Security Tools, Writing, Hacking, and Modifying Security Tools.” The code for that one is available here.

But for some reason I think that the developers for web app scanners think that they don’t need to check out the competition before they release something – they must think that whatever they’re doing, it must be the best way. Otherwise we wouldn’t have so many people charging a lot of money for low-quality web app scanners on the market.

So – back to NTOSpider a bit: of course, there’s no one automated scanner that’s going to be an end-all-be-all solution for webapps – (there’s just way too many business logic types of flaws in applications to have a non-intelligent scanner catch these types of things). But it does a decent job I guess for what it was meant to do – mainly fuzz parameters.

However, I do usually throw a couple different webapp scanners at an app either before or during manual analysis to catch any low-hanging fruit and to let me know where I might want to concentrate some exploit efforts on (like, for instance on a possible sql injection finding).

I know, I know – I’ve heard some pentesters say that they aren’t supposed to mention that they use automated tools like nessus or webapp scanners – they do all manual testing.

However, IMHO there is definitely a time and a place for scanners. I’m not saying they should *strictly rely* on them and only run a couple of scanners on a test and call it quits (because you *will* miss a lot of cool findings) – but I do run automated scanning tools on just about every single test I perform (like nmap).

So, again I do think that there are things that webapp scanners are really good for – fuzzing parameters (in the case of webapps, scanners are usually really good at catching XSS, sql injection points, and CRLF). When fuzzing anything it is generally done in an automated fashion – keeping in mind it usually does take a lot of manual effort to generate meaningful fuzzing data sets to get the best results possible – but once you have meaningful data sets to fuzz with it should be an automated process.

The process of fuzzing stuff is actually kind of what a computer is meant to do. The four basic functions of computing come to mind – input, processing, output and storage. The combination of these functions is exactly what we do when fuzzing!

I think scanning tools probably got a bad rap from the community when “pentesters” started using/condoning automated tools for their complete efforts of the pentest like running nessus on a network or a webapp scanner on a web application and calling it quits. Now just running automated tools on some application, system or network is not a pentest in any sense of the word, any decent pentester will tell you that – but in the same sense I feel that there is some backlash against these very same tools from others in the community. I can kind of understand – no automated tool can take the place of an experienced pentester. On the other hand I think these very same tools can definitely bring informative issues to the table when testing.

Now that I have in some sense justified (at least in my own mind) scanning tools for particular purposes I guess I’ll get to the original point of this post – which is someone else actually likes NTOSpider (even the though the both the report and the metrics that Larry Suto use are pretty wack):

Cheers,

Chuck B.