An Autonomous Zone

NTOSpider – I generally use it as a scanner (amongst others) when I’m looking for web app input validation issues, and I’ve thought it to be pretty decent. By no means is it the best one out there – which I’ll talk about in a sec, but it is a scanner that has decent spidering (automatic code coverage) capabilities and decent XSS identification. In my opinion, it’s semi-alright for a point-and-shoot web app scanner (but I don’t think I’ve ever found one that I think is real good).

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.