Re: Web application scanner
Date: July 14, 2010 11:40PM
The shellphish guys paper appears to have confirmed my suspicions.
You basically have scanners that maintain a high level of quality:
1) HP WebInpsect
2) Netsparker Pro
3) Acunetix WVS
4) Burp Scanner
The above are my favorites from best to worst, but really it would be nice to have all 4, at least on occasion.
And scanners that do not hold up to today's tech or are just otherwise low quality (again, in order of my most favorite to least favorite):
1) Cenzic Hailstorm (I do like the ability to configure the attacks in Javascript)
2) IBM AppScan (although I hear that the State Inducer tool it comes with is unique and awesome!)
3) NTOBJECTives NTOSpider (I really don't see the fuss about this from RSnake or Larry Suto. Who else likes this tool -- and WHY??? -- it did very poorly in the shellphish report as seen from the Wivet and other results)
4) Qualys WAS
5) WhiteHat Security Sentinel
There are some scanners or scanner-friendly tools that are just damn useful, mostly because they don't cost any money:
1) Casaba Watcher
2) Casaba x5s
3) Google Ratproxy
4) Google Skipfish
5) Websecurify
6) Netsparker CE
7) XSS_Rays
(in no particular order)
I really like how Websecurify is coming along.
I do not like how skipfish works, but I have a new use for it in mind. Basically, stop it from doing all of that crazy content discovery and instead use it to run through Ratproxy patched with the Metasploit WMAP patches (or perhaps the msfproxy). Basically, skipfish will feed the WMAP database so that the WMAP module and the auxiliary modules can be run against the URLs including parameter queries/forms (but not cookies unfortunately). This is mostly useful if you have a huge environment that you want to test really fast, and it works even better if you utilize either existing discovery data or skipfish's internal "-D .site.com" flag.
For penetration-tests, scanners can be useful. I like to run Websecurify and XSS_Rays to hit an XSS and then start exploring manually with a browser (which both tools happen to be a part of already). If the authentication looks weak (i.e. no lockouts), Fireforce is a great tool, especially when combined with pre-existing password re-use knowledge or a copy of the skullsecurity-lists (I like rockyou-75.txt best because it's a lot but not too too much -- although rockyou.txt is my favorite if you want to do an exhaustive test or second test).
If Websecurify or XSS_Rays and manual poking fail to get me a quick XSS (just for even demonstration purposes), then running Netsparker (Pro or CE) in crawl-only mode through Casaba x5s will definitely get you one. As an added benefit, Casaba Watcher can be running simultaneously as x5s, and you may even get a Clickjacking finding out of it. Websecurify has an added benefit here in that it's good at finding CSRF, especially when you run it through a properly configured Ratproxy.
Armed with the capability to become a user of an app (or a sub-part of an app, such as an admin panel), you can now attack other pieces and parts of the web application. Finding admin panels or other places that load local or remote files (file upload especially) is penultimate to finding any other immediate command injection bug.
In order to find these panels (or forums or similar places that do obvious file interactions), I would suggest looking through the `discovery' section of fuzzdb, especially the ones marked with "cgi-x-platform", "interesting-files-", etc and pick at targets like apache, a particular cms, iis, sharepoint, etc. You can often identify your target fairly easy, but these days it seems like most applications run more than one type of webapp on the server (e.g. PHP, ASP.NET and Java Enterprise all at once!), so it's easy to miss obvious stuff. There are not too many application scanners that help here, but I would bet that WebInspect and Appscan perform rather well compared to the others. However, I've seen Netsparker Pro and Acunetix WVS find the same issues that Webinspect or Appscan do with regards to this.
Platform vulnerability discovery is certainly the biggest missing feature in Burp Suite Professional. Let's just pretend that Webinspect is the best in this category simply because they have a policy specific to platform vulns, and you can run it from the command line, extract the XML, and totally automate these kinds of findings really easily compared to most of the other tools. However, it is kind of heavy on the false positives -- even when it comes to discovery of these panels sometimes. The benefit of going through these is that you'll have to dig around for PII or other useful reconnaissance info anyways (especially post-authenticated), so looking for those path traversals and predictable resource locations can be done at the same time -- and you might even find something more interesting than an admin panel! It's times like that that you want a Google Enterprise Appliance that has pre-authenticated as every possible user on every possible web application across the organization. However, the concept of dorking can sometimes be applied to a webapp's own search interface. Dig up all of the goods while you can!
After you find a panel, you probably just want to manually figure out how to load up a script -- usually PHP, ASP, aspx/asmx, or JSP. However, this could also be a JAR or WAR file. In essence, you have to poke around the web server install/config as well as the app or parts of the app. You may need to query OSVDB to find similar bugs (although occasionally you may even find an unpatched well-known admin panel!). You may also want to check for file inclusion or script inclusion type bugs using scanners that support it. Burp does a great job with this in both the scanner as well as manually with the intruder. It's easy to sort and look for errors that could cause this. Generic errors and unhandled exceptions may also lead to a file/script read or write inclusion -- so almost any scanner that's finding those quickly and easily for you (personally, I think that Webinspect and Netsparker Pro do great jobs here) is going to be win and save you time. Metasploit is gaining some traction here as well, especially brute-forcing certain panels such as the Tomcat admin panel. Metasploit Express automates this even further.
So far you've attacked the users and the server (and thus you can start leveraging both to attack each other with lucky-punch attacks). If you do get access to the server, the penetration test can certainly turn into a Metasploit style penetration-test very quickly.
Assuming you've only captured users (and a lot of the users don't appear to be admins of anything) then it's probably best to turn to SQL, XPath, and command injections next in your penetration-test. Netsparker Pro certainly does a great (and fast!) job at enumerating all of the possibilities, but you may want to target some hotspots manually first -- with SQL Inject-Me, TamperData, etc. The skipfish+ratproxy+WMAP method I described earlier would also be nice to try here. As far as XPath and command injection go -- I really think that Burp scanner and intruder+fuzzdb are you best bets.
If you really want to drive home the part about attacking users, you'll want to find more CSRF, Clickjacking, HTTP header injections, open redirects, and session management attacks. Some of this is going to be a lot more manual then the above -- scanners are not exceptional with regards to these attacks. Don't forget about the Burp sequencer functionality, though. The final part here would be testing the authorization models, and this usually works best with pair testers who can spend time sharing session information knowledge while trying to pass parameters and objects around. I think Burp Scanner is exceptional at finding HTTP header injections (although I've heard HHI/HRS as the major benefit of WHS Sentinel if you care enough). Most scanners can find open redirects, but my top 4 choices seem to find them best. XSRFTester (the Fiddler2 plugin) looks fairly decent for finding CSRF.
If you want to gather a lot of information on users, you may want to target LDAP injection or path traversal type attacks. I also think Burp does a great job here.
In Flash or Ajax heavy sites (or ones that employ other external components), this may vary a lot. Burp Suite Professional has a nice search feature to find SWF files, which can be fed to SWFScan. Almost all of the top 10 scanners claim to have some Ajax or Flash support, which is true, but the findings are very wild and vary quite a lot more than you would suspect! Because external components like these can be downloaded, it is nice to get to know them a lot better.
For example, with Flash, start reading the code in SWFScan. If you run into problems with SWFScan, perhaps use IDA Pro with the SWF decompiler plugin. Testing the Flash may be easy or may be difficult. Look for LSOs or other cached Flash content. Check out external content quickly with swfdump -D and grep out URLs. Some other flash decompilers provide nice overviews of the content, which can help you understand the code better. It might be nice to dump the source code into an editor such as Source Insight. Using the OWASP Code Review guide and some other common places can get you at least some knowledge for what to look for beyond what the SWFScan analysis mode gives you. The runtime might do things that scanners can interface with -- such as Burp's AMF capability (and some Burp plugins). I have successfully ran WPE Pro on Internet Explorer to view other SWF-to-server data on the wire. There are a few tools from SpiderLabs and Gotham Digital Science that go a bit farther here, as well.
With regards to Ajax, I suggest pulling down the content locally and running it through AppCodeScan (Blueinfy). It is sometimes very nice to get some runtime knowledge, and the obvious solution is FireBug (although I prefer WiderBug). There are some great plugins to FireBug/WiderBug such as Firerainbow, which does syntax highlighting on the Javascript. I suggest learning how to use the Javascript debugger and profiler. However, AppCodeScan seems to provide a very fast look at the Javascript code, and to boot it's even better when you're running into Ajax proxies such as found along with Java Enterprise or ASP.NET Web Services. I'm not sure about other static analysis or code review tools that support Ajax or Javascript libraries very well, although the Fortify products claim to. If you are looking at a lot of XML or JSON, then the Blueinfy Web2.0Proxy tool makes it a little easier to deal with then going into the Burp XML tabs or similar. However, Burp Scanner does a great job at finding XML injections, but be way as these are some of its most common false positives. If you hit true positives here though, expect Web Services code to "be around". See if you can grab some of it and load it into AppCodeScan, if supported. I'm assuming that Burp Scanner implements very nice SOAP injection capability, although again this is something that appears to vary wildly between all of the scanners. They don't support Web Services rather well, especially not REST.
Java applets are about to be blown apart with some of the upcoming Blackhat talks, such as Stephen de Vries and Arshan Dabirsiaghi. In the meantime (or regardless), you may want to check out your friendly neighborhood Java decompiler or a runtime tool such as Echo Mirage (which has an excellent feature that appears to be built specifically for Java: "Inject Into Process"). Although any HTTP can certainly be reverse proxied through Burp just like with Flash.
Scanners save time and money, but it's best to use them wisely. I hope that some of my wisdom here will help you make the best out of the scanners that you have. I hope that it helps even moreso if you are trying to make a decision on how to fill that missing piece of your penetration-testing automation. Soon, new aggregation tools will solidify some integration pieces between these tools. Already, The Dradis Framework appears to be integrating well with Burp Scanner and potentially soon, Netsparker. HoneyApps Conduit is going to demonstrate some serious long-term effects on the future of commercial scanner success because importing tons of data from 5-10 scanners (plus secure static analysis tools) about tons of apps is going to point to the winners in an obvious fashion. HP AMP has an Open API and currently can connect Fortify 360. The new 1.1 version of O2 is already beginning to assemble integration features that may potentially rival all of the other scanner-integration-frameworks I've mentioned in this paragraph.
Scanners might even be useful when full-knowledge or server access is possible. Most people that I know who have done these assessments for a long time still use scanners for some pieces, even when they have source code -- especially when on a penetration-testing goal time-crunch (or even an open-ended ethical hacking approach where there are no specific goals, but time is at least partially a factor). Scanner technology is going to work well with runtime instrumentation technology such as found in Fortify PTA (Java Enterprise or ASP.NET) or the Chorizo-Scanner Morcilla plugin (for PHP). Other languages don't have this security-flavored instrumentation yet, although they appear to need to so this is a market niche. However, PTA and Morcilla should work with SWF and Ajax as long as the vulnerability is server-side and not client-side.
For SWF/AIR files, applets, or fat applications that implement HTTP or SSL, Burp is the clear winner. If only part of the SWF/AIR file, applet, or fat app is HTTP/TLS, you can see which parts are with WPE Pro, Echo Mirage, or perhaps even Uhooker. Then you can exercise that specific functionality with Burp. One of the nicest features in a web application scanner that I saw recently was Netsparker Pro adding support for Burp import. This brings automated fuzz testing of SWF/AIR files, applets, and fat apps to a new level.
Edited 2 time(s). Last edit at 07/14/2010 11:54PM by ntp.