Test commercial web app scanners for free and without restrictions?

tate@ClearNetSec.com (Tate Hansen) — Mon, 24 Mar 2008 11:54:00 -0600

If your software licensing ethics tend to contort a tad here and there, then you may find the below tricks helpful when you want to evaluate commercial web app scanners. Partaking in these tricks is slippery, and you may fall into ethical perdition, so prepare yourself!

Super simple trick #1: Request search and replace proxy

Fire up a proxy that supports request search and replace.

Let’s say an app restricts you to scan only their target site (e.g. demo.testsite.net), but you want to point the scanner to a different target.

No problema.

As shown above, I typed in demo.testsite.net for Search, and blog.clearnetsec.com for Replace. Every HTTP request passing through this proxy with a Request-URI matching the string demo.testsite.net will get replaced with blog.clearnetsec.com. The result? The app scans my blog.

Note: Super simple trick #1 only works for apps which restrict via the hostname. If the app is smarter and adds IP validation, then move along to Sort of simple trick #2.

Sort of simple trick #2: IPTables magic

This trick can add license evading umpf to your smokin’ renegade style. :)

Let’s say the app tries to validate you are only scanning the sites you're licensed for by checking the target IP addresses (regardless of how the hostnames are resolved). For example, maybe the demo version of the app allows you to only scan IP address 55.55.55.55.

No problema.

One line explanation: Setup a linux box to do routing, configure a VIP, and add two IPTable NAT rules.

The long answer.

Setup a linux box. A linux VMware image works too. Configure the network as normal – give it a standard IP, gateway, list of name servers, etc., as you would when configuring any other box on your local subnet.

Once you got that, then check out the script below.

Follow? If not, I’ll explain in more detail.

Again, the first thing you need is a normal networked working linux box.
There are 4 steps to facilitate a destination IP switch-a-roo:

Configure a Virtual IP. Pick an IP located on a different subnet, don’t pick an IP on the same subnet as the primary IP.
Enable IP forwarding.
Setup a DNAT (Destination NAT) rule to replace the destination IP on the fly. The first IP (e.g. 55.55.55.55) is the licensed locked IP. The second IP is (e.g. 216.241.191.205) is the IP you want to scan.
Setup a SNAT (Source NAT) rule to replace the source IP on the fly. The first IP (e.g. 192.168.1.101) is your workstation IP. The second IP is the primary IP address of the linux box.

The last step there, #4, is overloaded. Once you go through the steps above on the linux box, then you need to change the IP address of your workstation with the app scanner installed. You want to pick a new IP for your workstation which is on the same subnet as the VIP you configured on the linux box. You also want to change your workstation to use the linux box as your gateway to the Internet, so change the default route address to match the IP of the VIP on the linux box.

That should do it. Replace the IPs in the IPTable rules above with the IPs that work for you and scan away.

Note: You can’t always do the IPTables trick by itself; one reason is due to virtual hosting. If only one website is being hosted on the IP, then you probably can do this. If the target IP is hosting lots of domains, then you need to chain the request and replace proxy with the IPTables magic to ensure each Request-URI is for the correct host and domain.

For example, GET http://216.241.191.205/... HTTP/1.1 may not be the same as GET http://blog.clearnetsec.com/... HTTP/1.1

Super Simple trick #3: VMware snapshots

Most everyone is likely familiar with this trick. If you have a web app installed in a VMware image and you have a working license (e.g. trial license), but it expires at a certain time and date, the trick is to create a snapshot of the VMware image with the app in a working state.

Anytime you want to scan, change your host OS clock back to a time that is within the licensing window (or ensure your VMware guest image doesn’t sync the clock with the host OS when you restore the snapshot), and restore the snapshot.

Note: Some apps may call home when first launched, so it helps to create the VM snapshot when you have the app open and ready to scan.

Trick addendum:

For those web app scanners which restrict you from scanning SSL enabled sites, have no hesistation, you can work around that too.

One way is via stunnel. From www.stunnel.org.

Encrypted version with STUNNEL

+---------+      | |     +--------+    +---------+
| non-SSL | -ST- | | --- | Apache | -- | non-SSL |
| enabled |      | |     | WITH   |    | enabled |
| client  |      | |     | SSL    |    | server  |
+---------+      | |     +--------+    +---------+
   CLIENT        NET     WEB SERVER      SERVICE

Note the position of STUNNEL : the "-ST-" in the diagram above. Below is an example stunnel configuration:

client=yes
verify=0
[psuedo-https]
accept = 8080
connect = blog.clearnetsec.com:443
TIMEOUTclose=0

Configure your app or browser to use the stunnel proxy listening on port 8080 and you'll be able to hit the site using HTTPS (via the proxy), but your local app or browser will be only speaking HTTP.

Quick alternate to #1 for Apache fan boys and girls:

Via Apache 2.2.x, with mod proxy and mod rewrite enabled, setup a proxy like so:

ProxyRequests On
<Proxy *>
RewriteEngine on
RewriteRule ^(.+) http://blog.clearnetsec.com/$1 [P] (or something close to this)
Order deny,allow
Deny from all
Allow from all
</Proxy>

Configure your browser or app scanner to use this Apache proxy server and all Request-URIs passed through will be re- written to target http://blog.clearnetsec.com/.

YMMV. Have fun.

An example of why human effort is helpful when assessing web applications

tate@ClearNetSec.com (Tate Hansen) — Fri, 13 Apr 2007 16:37:00 -0600

It can take some digging to discover if you’ve successfully injected any code into a web application. I was using the ALL-FUZZ-STRINGS that comes with Suru (added additional strings from sources like ha.ckers.org XSS Cheat Sheet) to run through a list of popular input validation attacks.

Suru is a Man In The Middle (MITM) proxy that sits between the user's browser and the web application.

I was keying on the fuzzy logic results window in Suru which helps the assessor determine if any attacks were successful.

The Fuzzy logic trigger box is used to fine-tune the results received during a fuzzing run. The user has multiple options that range from content extraction to brute force fine-tuning. The results from the fuzzing run can be mined or filtered for false positives, positives or false negative findings.

Here is a screenshot of the some of strings that are included in the ALL-FUZZ-STRINGS

During this phase of testing I was interested to see if any of the XSS type attacks succeeded. The fuzzy logic results window shows calculated scores that are derived from running an equation on each response and on a base response.

In order to conduct Fuzz logic or content extraction runs, Suru needs to compare the results to a base response. For example, if we need to brute force an application we need to compare a failed attempt with a successful attempt to gauge successes or failures.

I was surprised when all of the scores were basically the same – implying that none of the attacks caused a response which was measurably different from the base response. I already knew XSS/code injection vulnerabilities existed in this part of the application.

Upon a little investigation, it was clear the reason why Suru’s fuzzing scores were remaining more or less the same. For this particular web application, the response page created from submitting values was simply an acknowledgement of the POST request.

This response page was always the same -- there was no deviation from the base response. But by manually crawling the site and clicking on deeper links, I ran across a link where the injected code was executed and displayed in the response. One of the attacks was successful.

The take-away here is that it is important to manually walk the web application after performing XSS, code injection, etc. attacks to really see if any were successful. The attacks may cause the web application to respond with the exact expected attack string (i.e. if you put in as part of the attack the string “URL=javascript:alert('XSS-IS-HERE');”, then you can scan the HTML response for the string “XSS-IS-HERE”), but the web application may modify the string enough to evade automated checks yet still be vulnerable.

And in the case above only discovered by manually crawling the app to see where the attack successfully surfaces.

ClearNet Security: Tag Suru

Test commercial web app scanners for free and without restrictions?

An example of why human effort is helpful when assessing web applications