Showing posts with label proxies. Show all posts
Showing posts with label proxies. Show all posts

Tuesday, January 12, 2010

WebInspect's Manual Step-Mode and daisy-chained proxies

This post is a follow-on from the prior post on how to daisy-chain WebInspect with an intercept proxy.

A powerful penetration testing feature of WebInspect is its Manual Step-Mode crawl, suited for very complicated web applications. When this style of crawling is used rather than the automated crawling methods, WebInspect is actually spawning a hidden instance of the included tool, HP Web Proxy, offering even more daisy-chaining fun for the security expert. During this time, WebInspect listens on a dynamically set port on localhost (127.0.0.1) and opens an instance of MSIE pre-configured to that port. This Manual crawl is very similar to how some freeware web scanners operate, with the professional manually driving the scanner via their browser and the tool parsing and auditing the captured sessions in the background. WebInspect's dynamic port behavior for Manual Step-Mode can also be changed to use a static (expected or known) port rather than a dynamic port, which is very useful if you want to use an alternative browser. When doing this, you must leave the triggered MSIE window open (minimized) because that is what WebInspect actively hooks into and signifies to WebInspect that it is in "Manual mode". However, you can then launch and configure your favored alternative browser to the static port (proxy port) you set previously. The scenario below will detail this further.


Let's look at an advanced configuration. I had a call from a counterpart who was on-site with his client. The WebInspect machine they provided him had MSIE 8 installed, and no matter what he did, the development application they were testing crashed that browser, and it simply refused to work with any non-Microsoft browsers. This would normally not affect WebInspect's automated scanning methods as WebInspect operates as its own stand-alone browser. However, this site was completely ActiveX with browser plug-ins and client-within-a-browser configurations that required a human to use the Manual Step-Mode of WebInspect to "crawl" the site by hand with a plug-in enabled browser. Since he could not downgrade the MSIE browser on the workstation nor automate the scan, he called me and here is what resolved the trouble.

In addition to the WebInspect workstation, the tester was provided RDP access to a second machine which still had MSIE 7 on it. This version of MSIE worked great for browsing the development application without any crashing as had been experienced with MSIE 8, but the machine lacked WebInspect. To audit the application we daisy-chained the two workstations across the LAN, using the little-known static port setting for Manual Step-Mode and then opening the Web Proxy to the LAN rather than just the localhost, as follows.

1. On workstation1, open WebInspect's Edit menu > Application Settings > Step-Mode panel > set it to use a static port not currently in use, e.g. 8081. Leave the IP address field as localhost (127.0.0.1).

2. Start the Step-Mode Manual crawl assessment in WebInspect for the target site, and once it is running Manual mode leave WebInspect and the resulting MSIE8 window alone.

3. Now open HP Web Proxy on the same workstation1.
* Within the Proxy Server settings, configure Web Proxy to use the Manual Step-Mode proxy server that is "upstream" at 127.0.0.1:8081
* Within the General settings, configure Web Proxy to listen on workstation1's actual network IP and port 8080, e.g. 192.168.1.105:8080
* Save these settings and now start the Web Proxy service/listener from its toolbar. The lower left-hand corner of the Web Proxy window will show that it is now Listening and the port being used.

4. RDP to workstation2, open MSIE7 there, configure MSIE7 to use the proxy server at workstation1, e.g. 192.168.1.105:8080

5. Browse the test application from MSIE7 on workstation2, verifying that the WebInspect window on workstation1 is showing captured/audited traffic within its Navigation Pane (Site Tree view).

6. When finished testing from workstation2, return to workstation1, close the MSIE8 window that popped up previously, and click the "Finish" (Step-Mode) button found at the top of WebInspect's Navigation Pane. This halts the Manual Step-Mode crawl. It can be Resumed if needed.
* WebInspect is now ready to proceed to Auditing, if you had the Step-Mode set to "Manual Audit" mode.


Representation for our example:

MSIE7 browser (on 192.168.1.104) > HP Web Proxy (192.168.1.105:8080) > HP WebInspect (127.0.0.1:8081) > network proxy (192.168.1.200:80) > target server (192.168.1.106:443)


What about serving Manual Step-Mode directly to workstation2?

If you read my previous article on daisy-chaining WebInspect and Web Proxy, I must point out here that the Manual Step-Mode settings do permit the local LAN to be served directly if the localhost IP address is replaced with the workstation's own live LAN IP address. However, in this scenario, we wanted the ability to monitor the browser traffic from workstation2 within the Web Proxy window on workstation1. This would help diagnose and connectivity troubles, if that traffic was not able to pass through WebInspect and then back from the test application. This offered the added bonus that the captured Web Proxy sessions could be saved as a proxy sessions file (*.PSF) for review at a later time. Those sessions could also be saved as a Start Macro which could be used later in an attempt to run the WebInspect audit automatically rather than manually. Sometimes this automated trick works, sometimes it does not, depending on the application itself, but having the option to try is very useful.

Tuesday, January 5, 2010

HP WebInspect and proxy daisy-chaining

This is my inaugural posting, so here goes. I am all new to this, and yadda yadda yadda, let's get started. (disclaimer) I have worked with and supported WebInspect, QAInspect, DevInspect, and the Assessment Management Platform for several years. If I abbreviate these products in any postings as WI, DI, QAI, or AMP, you will just have to forgive and read on. Also, I like to share.

HP WebInspect is an advanced penetration testing tool used solely for auditing and exposing vulnerabilities in web sites. It works on the HTTP/S protocol only, for any active port on the target server. One useful technique that is often over-looked by WebInspect users is the ability to daisy-chain the tool through various HTTP intercept proxies. This can be the included Web Proxy ("SPI Proxy") tool, Paros Proxy, BURP Suite, Charles proxy, et al. The value in doing this activity is usually to monitor the scanner's traffic in real-time, or to trouble-shoot when the site is behaving strangely and you need to find out why in order to adjust the scan settings.

The most basic process for configuring this daisy-chain is detailed below. These instructions are based on using the included HP Web Proxy, and the exact setting details can be found within its Help guide. This should also be adequate detail to guide the configuration of your alternative proxy tool of choice.

1. Open the Web Proxy tool (from the Start Menu or WebInspect) > Edit menu > Options.

2. Web Proxy defaults to listening on 127.0.0.1:8080. Verify that here, or change it, and Save. If you need to use a network proxy to reach the target, configure that on the Proxy Servers tab, and then Save.

3. Start the proxy service using the "Play" icon in the toolbar. Minimize or resize the Web Proxy tool as desired.

4. Open WebInspect > Edit menu > Default Scan Settings > Proxy panel.

5. Configure the scanner's proxy to match the port that is listening, e.g. 127.0.0.1:8080.

6. Save the scan settings and run your scan. Verify the traffic is being captured within Web Proxy window. Web Proxy offers a Scroll Lock button to help with its scrolling display.


Representation for our example:

WebInspect (localhost) > HP Web Proxy (127.0.0.1:8080) > network proxy (192.168.1.200:80) > target server (192.168.1.106:443)


The one trouble with daisy-chaining WebInspect is that now the intercept proxy is the weakest link in your assessment. If the scan will take 8 hours and will parse many megabytes of traffic, it is probable your proxy engine will fail and halt the WebInspect scan prematurely (default and configurable setting). No worries, you can always restart your proxy tool and Resume the scan, but that situation can be a pain. The good news is that if you only wish to monitor a small part of the scan, that is also possible. To do this, Pause the assessment > click on the Edit menu > Current Scan Settings (not the Default Scan Settings) > Proxy panel > alter the proxy setting to NO longer use your intercept proxy > Save settings > Resume the scan > verify that now no traffic is being captured in your proxy window.

This sort of daisy-chaining can go all day, so long as you use different ports for all of the services. For example, we could configure the Proxy Server options within Web Proxy to go to another "upstream" proxy tool (local or remote), such as Paros Proxy or a second instance of Web Proxy. Just remember to keep their ports separated if running all of them on the local machine, such as using 127.0.0.1:8080 for Web Proxy #1 and 127.0.0.1:8888 for Web Proxy #2. Why would you want to do this multiple proxy hopping? There are various trouble-shooting reasons which I will not detail now, but the capability is there if you need it.