Today we showcase a new web application scanner called Netsparker, and believe us when we say that we put this app through the ringer.
There’s a big distinction between testing a tool against dummy apps in a lab and using it first hand against a large environment. Luckily for us we got to do both.
Over the course of a month we ran several engagements and specifically watched Netsparker’s performance compared to other tools we normally use in the assessment process (w3af, Grendel Scan, Nikto, Wikto, Websecurify, Paros, Burp, etc). We have to say, we are very impressed. Netsparker not only caught vulnerabilities that other scanners missed but also had excellent remediation and a documentation section for most of its findings.
For injection it does a full-scale attack, testing every parameter it can spider (which it also does very well), and, although this lengthens the testing time, it also awarded us with some valuable injection findings. Netsparker is developed by Mavituna Security, and more specifically our guest, Ferruh Mavituna.
Ferruh, thanks for joining us today.
You’re welcome. Thank you for this opportunity.
Can you give us a quick bio on yourself and your history in the web application space?
I’ve been in the web application security field for about 8 years now. I started as a developer (ASP, C++ then VB) and moved to web application security. I’m originally from Istanbul. Back in those days web application security wasn’t considered a big deal and there weren’t many people in the area, so I found myself working for the Turkish Army and Turkish Police as a security trainer and consultant.
In 2003 I co-founded a penetration testing company focused on application security in Turkey, which failed miserably. We couldn’t see that the industry still wasn’t ready for it. This was the time that I first started getting interested in web application vulnerability scanners. After that failure, I got back to work as a freelance consultant and worked for many companies around the world. Then I moved to London and started to work as a penetration tester and security researcher for a company with a great team.
What inspired you to create Netsparker?
As I said, since 2003 I’ve been interested in automated vulnerability scanning and exploitation, hence I developed many pet projects in the meantime (XSS Shell, XSS Tunnel, FSF – Freaking’ Simple Fuzzer, WebRaider, BSQL Hacker, etc.) and also many others that never saw daylight.
The real tipping point though happened when I started to work as an “office penetration tester.” This means that you test at least 2-3 applications every week, which is a lot of work to do and you need a tool to automate some stuff.
Yes, we had tools but they were just not good enough. They gave false positives and missed issues that are slightly rare such as Blind SQL Injections or rather unusual Cross-Site Scripting issues. This was frustrating because you know, it’s technically possible to do all of these, yet after so many years they still hadn’t done it and were showing no intention of doing it.
That’s when I decided to develop my own tool. This was about 2006. Initially it wasn’t a commercial project. It was yet another pet project of mine.
How big is the development team on the project?
Development team is rather small. It’s only me and another developer. He’s a pure developer though, not a security/programmer guy like me 🙂
But aside from me and him, we have two QA testing guys both of which are skilled in the security field and focused on our test environment as well as usability quality and stability of Netsparker.
Can you tell us about Netsparker’s false positive free design? From a high level, how do you accomplish this?
To be honest, the idea is simple: “If you can exploit, it can’t be false positive.” That was the design decision. That’s what you do as a penetration tester, right? So that’s what Netsparker does. It exploits (in a safe way, not any more dangerous than any other scanner out there).
Obviously in reality, it’s not that easy. You have many challenges, it’s not easy to automatically detect the injection point of an SQL Injection in a grouped query and exploit it, but that was the whole idea of “making the next generation web application security scanner.”
However it’s not perfect yet, as it’s still quite hard to deal with applications such as Gmail where you have one page and the whole application driven by the current DOM context.
What are some of the exciting new features you are working on at the moment for release?
Recently we finished a cool LFI exploitation feature. If Netsparker identifies an arbitrary file reading vulnerability in the application, it allows the user to right-click and download the whole target application’s source code and make a local copy of the target application in the user’s file system. I thought it would make LFI exploitation much easier, because Netsparker already knows all URLs in the application.
A new feature that we are working on is also about exploitation. We already have shell support for SQL Injections and now we are implementing a similar feature for other vulnerabilities where such an attack can be possible. So soon LFI/RFI, Remote Code Execution, Remote Code Injection will be exploitable in a similar manner.
Can you give us a brief on your exploitation module?
We have several exploitation modules and keep adding more. It’s quite straightforward. Assume that Netsparker identified an SQL Injection; then when the user clicks on the vulnerability, it shows a button called “Get Reverse Shell.” During the detection stage it already detected if the application is connected to the database as a privileged user. So it knows that it would be possible to get a reverse shell out of it.
Then you just click and get your shell, that’s pretty much it. The same goes for LFI. When you click on an LFI vulnerability, a new panel pops up. This panel allows users to get known files from the target OS, download known configuration files or the user can specify a filename manually. At this stage the user doesn’t need to know how to construct the injection, add a null byte to the end or how many dot dot slashed they need, all they need is to type the name of the file they want to read. Netsparker already knows how to exploit it.
Basically it’s all about making a penetration tester’s life easier and allowing rookie users to exploit stuff without requiring them to be a rocket scientist 🙂
How would you compare to Netsparkers unique advantages to current commercial tools?
• False Positive Free
• Embedded Exploitation Engine
• Better coverage on many important custom issues such as SQL Injection
How is Netsparker at handling injection flaws, and using encoding to bypass common security practices, and using different methods to inject SQL (blind, error based, etc)?
In this office, we are truly obsessed about coverage, no matter what it is, blind, error based, Boolean based, etc. Netsparker will find it. If the developer applies some easy blacklisting, the same applies.
We do have some signatures to bypass some common, badly written blacklistings, filtering and IDSs, however there is a fine line between the number of requests that you can do and the benefit that you would get. As of now, we only added signatures that are really common such as an integer based SQL Injection which strips single quotes. It’s still vulnerable and Netsparker will find it.
We are working on an improved policy model where users can enable extra signatures based on their target. So if the user has enough time to send a couple of more thousand requests for a rare possibility of bypassing a protection, they can choose to do so.
How current is the vulnerability database and from where does it draw its vulnerabilities?
Actually this is one of the sore points of Netsparker. We don’t have a vulnerability database. Other than common configuration issues such as “ASP.NET Trace.axd” or “Apache Multiviews Enabled,” Netsparker doesn’t check for known vulnerabilities.
Currently we are only focused on vulnerabilities in custom applications, however we did so good in our tests many reported vulnerabilities can be identified by our engine anyway.
Although there are some issues where you can’t find the injection point without the source code, in this case Netsparker will fail to identify those.
How is the development of detection of Cross-site Request Forgery and File Include vulnerabilities coming?
File include vulnerabilities are finished. We now detect LFI and RFI issues. We even detect if an LFI can be used to execute code in the server-side by using common LFI to RFI tricks.
CSRF is a little bit trickier. In theory detecting CSRF is very easy, but in reality it’s so prone to false positives. Without understanding the actual context of the application and the impact of the request reporting, which is what many others do, CSRF issues are quite difficult to properly pin down.
For example these requests can be an indicator of CSRF:
But you wouldn’t confirm it unless you are human. It’s easy to report every POST request without token as CSRF, but we don’t want to do that. Until we have it right and report it almost false-positive free, we are not planning to add it.
How well does Netsparker map to the OWASP goals and visions?
It can help developers to understand the real impact of vulnerabilities due to easy usage of exploitation features. This is very important, because, unless you show them, they think you are talking about some theoretical stuff. It can help testers to test better, but after all it’s a black box scanner and OWASP is more about secure development and source code level solutions.
Netsparker can help developers to identify issues during the development stage. In our recommendations we tend to refer users to OWASP for more information about the identified issue and the remedy of it.
Are there any plans to include both directory and authentication brute-forcing?
We already added directory / file brute-forcing, and authentication brute-forcing is definitely in the pipeline.
What are the distinct reporting advantages of Netsparker?
Not many yet 🙂 We have one killer feature though. You can use C# scripting to generate your own custom reports. We have a reporting API that allows you to write C# code and drop it into the reports folder. Netsparker will run it and generate the report for you.
Other than that, our reporting is quite straightforward; although another cool thing about reporting is that you can actually report some exploit data. For example, by default SQL Injections are reported with “version” information extracted from the database. This gives a sense of reality to the report.
How is the Netsparker team approaching a comprehensive test of session analysis?
Currently other than some basic checks, we don’t have any session related analysis. In the long term, we are planning to add some more checks about session management security. Privilege Escalation tests, form authentication bypass, session randomness quality, etc.
All in all we identified lots of risk with our Netsparker tests. It complimented our manual analysis and far surpassed some of our regualr tools. The caveat of such an easy-to-use and comprehensive tool is that it can never replace the kinds of risks a pentester (or community of pentesters) can identify manually.
We look forward to the integration of scheduled scans, project importing and exporting, session based tests, and a tied vulnerability database. Thanks to Ferruh for a chance to check out a next-gen web app scanner!