My Pen Test

In my first post I gave a very brief overview of the web security testing products offered by HP. Unfortunately people’s understanding of where the products should fit into the software development lifecycle is still weak. This is even the case inside HP.

Here is a current slide from HP Software…

The obvious, glaring problem with this diagram is that WebInspect is being promoted as a tool to be used in Production. As someone who has spent a long time working in highly technical areas of testing, I have some huge problems with this, and most of my clients will not like this either.

The bottom line is…if you use WebInspect in Production, you are a cowboy and have no place in enterprise-class IT.

1. If you are waiting until after Go-Live to test something, then YOU ARE DOING IT WRONG! Hopefully you don’t wait to test for functional or performance problems until after you have rolled out your application to your customers. End users will probably not notice if your website has security problems, but if customer data is stolen, then there is no way to get it back. Unlike other defects, you can’t fix theft of customer data by releasing a patch (you can only prevent it happening again).
2. Defects found in Production are much more expensive to fix than defects found earlier in the software lifecycle. The earlier you find (or prevent) the defect, the less it costs to fix. DevInspect helps prevent security probems during the Build phase through code analysis and by providing secure components, but it does not allow you to conduct a thourough audit of your web application. WebInspect should be firmly targetted at the Test phase (I will discuss QAInspect shortly). Also, if you find problems in Production and the development team fixes them, then it will be necessary to run another round of functional and performance testing to verify that nothing has been broken by the security fixes.
3. When WebInspect does a crawl and audit of a website, it tests input points by submitting data. Larry Smith likes to tell a story about a company that used WebInspect in Production, and ended up generating 60,000 emails, and previously I mentioned that a Google search for one of the values that WebInspect uses for form submissions returns ~87,500 results.  You do not want to create garbage data in your Production database. This might not be a problem if you have a basic brochure-style website with no points for user input, but if you run an important website with online ordering (the sort of website you really must security test), then garbage data will cause lots of headaches.

The obvious question is “Isn’t QAInspect already targetted at the Test phase? Why does WebInspect need to be used during this phase too?”. Well, I’m glad you asked…

First, let’s have a look at comparative pricing of these products for a single seat perpetual license. QAInspect is around 25% of the price of WebInspect, so obviously WebInspect is offereing something that QAInspect is not.

QAInspect is geared towards users who are not expected to have any understanding of web security testing. It is a fully automated push-button testing tool that is launched from Quality Center. It will scan an application for known vulnerabilities and execute heuristic attacks for some classes of problem (like SQL injection). There are many vulnerability types that are impossible to create automated tests for, and that is where a skilled security tester armed with a copy of WebInspect really shines.

This leads to some conclusions…

1. DevInspect is good for preventing security problems during the Build phase (code analysis, secure components). Like QAInspect, it can also perform a crawl and audit of the web application for known vulnerabilities and some classes of problem (using heuristics). It is a low-cost product, so each web developer could be given a copy. It would be useful for preventing/detecting web security problems early, but it has no chance of finding some classes of vulnerability.
2. WebInspect allows a skilled user to perform a thorough security audit of a web application through automated scanning and tool-assisted testing. This ideally happens in a test/pre-Production environment before a new version of the software is released.
3. QAInspect is simple enough for anyone to use but, as it is a fully automated solution, will not detect every class of security defect. It is cheap enough that it makes sense for a project (that uses Quality Center) to buy a copy so that they can run a regular regression test for security problems.
4. As the crawl and audit part of DevInspect and QAInspect will miss certain classes of defect, it makes sense to do a pass or two with WebInspect with a skilled security tester driving it. This fact also makes it highly irresponsible to sell either of these products to a company that does not already have WebInspect.
5. So…use DevInspect to find problems early in the lifecycle. Once the software is close to feature-complete and stable enough for functional testing, then it would be great to do bring in your expensive security testing guru and do a pass with WebInspect. As you don’t want to keep an expensive security tester hanging for too long, you can get your regular testers to run regular overnight regression tests on each build. The security tester will need to be available to investigate any defects found, and eliminate any false positives from the report. Before deploying the application, a final pass should be executed with WebInspect. Any future releases will be regression tested using QAInspect and, depending on what has changed, can be fully regression tested using WebInspect (or WebInspect could be used to do focussed tests on new functionality).

Something that confuses new users to WebInspect is that the Web Macro Recorder will not record any requests to http://127.0.0.1 or http://localhost. This can cause much head scratching for someone who just wants to try something out on their local machine.

The simple solution to this is to add an entry to your hosts file, and use the alias instead of localhost.

So (for those who need me to spell it out for them), to record a macro for the HP WebTours website on my local machine (http://127.0.0.1:1080/WebTours/), I added the following line to my hosts file (C:\WINDOWS\system32\drivers\etc\hosts)…

# HP/Mercury WebTours website alias
127.0.0.1 webtours

The Web Macro Recorder then successfully records all requests to http://webtours:1080/WebTours/.

I live in a bad neighbourhood…well, okay, not a really bad neighbourhood but its close proximity to the CBD and its abundance of funky bars, galleries and restaurants is neatly balanced by a high concentration of government housing that seems to go hand-in-hand with junkies panhandling outside the supermarket, groups of people drinking in the street during the day, and the occasional stabbing near the public housing estate.

Anyway, living in my neighbourhood means that people keep trying to break into my car. I usually know if they have been successful when I find my car unlocked in the morning with the ashtray open and the contents of the glovebox tossed onto the passenger-side floor. Obviously they are looking for small change to feed a drug habit, rather than trying to steal the whole car.

I wasn’t terribly concerned by this until a particularly incompetent thief broke both my car doorlocks when they tried to open the door with a screwdriver. I had to climb into the car through the boot.

So I decided that I would make my car immune to that kind of attack. I installed a central locking kit and disconnected the key lock from the rods inside the door. For good measure I filled the keyholes with epoxy, so there wasn’t any tempting hole for screwdriver-wielding miscreants.

About a week later, I found that someone had jammed a screwdriver in the lock anyway. They hadn’t been able to get in, because the lock wasn’t connected to anything, but they had managed to bend the door paneling around the lock.

After some amateur panel beating, it was time for a rethink. I made little signs saying “no money in car” and stuck them on the window above each lock. I superglued a 1 cent coin over the top of the keyhole and covered the keyhole with electrical tape that matched the car body colour, and finally, I left the glovebox and ashtray open to show that there was nothing worth stealing inside the car.

Another week later, I found that someone had ignored my signs, peeled the tape off the lock on the driver’s side, pried the 1 cent coin off the lock, found that their screwdriver trick didn’t work in the driver’s side door, walked around to the passenger side and peeled off the tape on that side before giving up.

So what lessons can we transfer to web security?

1. The thieves weren’t targeting my car in particular, they were just trying the same exploit (screwdriver in door lock) on every car in the street. The majority of website hacking attempts are due to someone trying a single known exploit on many websites, rather than targeting a single website with many potential exploits. This is because…
2. …the cost of attack is low. An attack on many websites that focuses on a single exploit is cheap because it can be automated, and once something is automated, it can be re-used for close to zero cost. Trying car door handles as you walk down the street is a low-cost attack as it is quick and has low probability of being caught (contrasts with breaking a car window which would have a higher attack cost as it will attract attention). As the attack cost is so low, a sign which says “no money in car” may not be much of a deterrent, just as I find IIS-only exploit attempts in the logs of my Apache web server.
3. The damage caused by an unsuccessful exploit attempt is usually zero for a web site. Seeing IIS-only exploits in my Apache log doesn’t worry me. Once I modified my car so that its locks could no longer be broken by a screwdriver (expensive and time-consuming to fix), then attempts to break into my car stopped worrying me.

1. HTTPS will protect your application. Just because a user’s browser displays a lock icon when they visit your website, doesn’t mean that your website is secure. HTTP over SSL (HTTPS) only encrypts the traffic between the user and the web server, which prevents snooping of the user’s traffic. It does not prevent a user sending malicious requests to the web server.
2. A firewall will protect your application. Firewalls are great; you can lock down every non-essential port on your server. But you can’t prevent people from accessing port 80 (or 443) or you will have the worlds least-used web server. If port 80 is open, malicious requests can be sent to your web application.
3. A locked down server build will protect your application. You can disable all non-essential services on your server, and you can run your web server or application server under a restricted account that cannot read or write to any files outside the web folder, but . vulnerabilities introduced by developers, rather than
4. A web Intrusion Detection System will protect your application. nuh uh
5. No one will target your application. (do you appear on a search engine?)
6. Using off-the-shelf software will protect you. patch levels. when they go down, they go down big. Not a big fan of reinventing the wheel. common components.
7. Writing custom software will protect you. no secure languages. secure components. heuristic attack. - I see a field

Akamai, who provide transparent mirroring of web content for high-traffic websites, see a large sample of Internet traffic. They have started to report on some of the trends they see in their traffic patterns (while some not so subtle points about how good they are). Their first report covers Q1 2008 (January - March). The report is available from http://www.akamai.com/stateoftheinternet/ (registration required). Here are some of the security-related things that I found interesting

• Approximately 2% of all inter-domain Internet traffic was DDoS traffic (does not include spam, phishing, scans or other malicious traffic).
• The “Anonymous” DDoS attack on the Church of Scientology website generated 220 Mbps of attack traffic at peak. This was a comparatively small attack, but received attention in the mainstream media.
• In January, an automated SQL injection attack compromised 70 000 sites including .edu, .gov, and several websites belonging to Fortune 500 companies. 11, 12
• Drive-by install (2 examples).

Lock Picked with Toilet Paper Tube

WebInspect is definitely not a stealthy tool; and that’s fine, because you shouldn’t be secretly auditing anyone’s website. Here are a few of the signs that WebInspect leaves when doing a crawl and audit of a website.

WebInspect Scan Signature: The webinspect scan signature is a request that webinspect sends to the server with the text SCANNED-BY-SPI-DYNAMICS-WEBINSPECT-WWW.SPIDYNAMICS.COM. This will be found in the webserver logs, identifying that a scan has taken place.

In the web server logs, the request may look something like this…

127.0.0.1 - - [03/Feb/2008:18:44:08 +1000] “GET /—-SCANNED-BY-HP-WEBINSPECT—- HTTP/1.1″ 404 -1 “http://127.0.0.1:1080/” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)”

You can disable this feature by opening Policy Manager and unchecking Audit Options > WebInspect Scan Signature.

Posted Form Values: WebInspect will submit various values to any forms it encounters. One of these values is “777-777-1911form@value777.com” (87,500 Google results). The form values that WebInspect uses can be modified using the Web Form Editor program.

If you would like to run a crawl and audit without posting any form values (I can’t really see the point of doing this though), then you can uncheck Auto-fill web forms during crawl in the Scan Settings > Method window.

Attacks in web server logs: In addition to the WebInspect Scan Signature, WebInspect will leave plenty of evidence of its activities in the web server logs. A good example is a GET request for “/SPIfingerprint404chk”, which is used to try to identify the target’s web server based on the returned 404 error page. Any of these individual attacks can be disabled using the Policy Manager (not that you would want to do this).

Super-fast posting mode…

• Slashdot review of Google Hacking for Penetration Testers
• The book on the publisher’s website
  http://www.syngress.com/catalog/?pid=3150
• Google Hacking database (from the author)
  http://johnny.ihackstuff.com/ghdb.php
• Google Hacking on Wikipedia
  http://en.wikipedia.org/wiki/Google_hacking
• Author’s website
  http://johnny.ihackstuff.com/
• Direct download of the PDF of the book (33MB) (removed)
  http://www.scribd.com/word/download/319798?extension=pdf
• Flash-based online reader of the book (removed)
  http://www.scribd.com/doc/319798/Google-Hacking-for-Penetration-Testers
• New version of the book to be released sometime soon

Update: a new version of the book has been released, and is available from Amazon.

For those who want to have a look at what WebInspect can do, there is a free 15-day trial available. Note that you will need to provide a valid email address to receive your trial license key, and you will also need to install SQL Server 2005 or SQL Server 2005 Express Edition (free download from Microsoft [36MB]).

There is a test website you can scan for vulnerabilities at http://zero.webappsecurity.com, which is fortunate because this is the only website you can scan with your trial license…

Also, you may wish to turn off some of the resident protection software that is part of your anti-virus package, as it may block some of the WebInspect tests.

On June 19, HP announced in a press release that it had signed an agreement to acquire SPI Dynamics, a software company specialising in web security testing tools. The deal was finalised on August 1, and it is only now that theses new tools are reaching the wider pool of technical people (like me) at HP partner companies.

Purchasing SPI Dynamics nicely compliments HP’s November 2006 purchase of Mercury, who were best known for their defect management, functional test automation and performance testing tools. IBM has a similar portfolio in the software testing space, with the Rational products and their recent purchase of SPI’s main competitor, Watchfire, who created AppScan.

Here is a quick rundown of the SPI Dynamics product suite…

• Assessment Management Platform (AMP) is basically an “enterprisey” interface for their vulnerability scanning software. Manage and schedule regular scans across all of your company’s applications and report the results in a dashboard.
• WebInspect is their flagship product. DevInspect and QAInspect use the same engine, but WebInspect offers far more power than these tools. WebInspect will crawl a website and audit it for common classes of security defects such as SQL injection and cross-site scripting. A penetration tester can manually test for vulnerabilities with the application by viewing and modifying server requests.
• DevInspect is aimed at web application developers; it integrates with Visual Studio or Eclipse-based IDEs to perform analysis of Java and .NET source code for vulnerabilities. It will also audit the application from the web interface using the WebInspect engine.
• QAInspect is aimed at testers, and is pitched as a fully automated tool that testers can use without having any training or knowledge of security testing - push a button, scan the application, and get a report with detailed information about each vulnerability found. QAInspect integrates with both HP Quality Center and IBM Rational ClearCase.
• Web Application Security Services - SPI Dynamics also do service work. Presumably this will be absorbed into HP’s Professional Services group.

The 2007 SANS Top 20 Security Risks report noted that vulnerabilities in web applications account for almost half the total number of vulnerabilities being discovered in the past year, so there is clearly a huge number of opportunities to use this toolset to find problems before they are exposed to anyone with a web browser and a penchant for hacking web applications.

I’m looking forward to playing with WebInspect some more; and I’m planning on sharing some of the useful things I find on this website. If you’re interested in web security testing, you should subscribe to my RSS feed or check back soon.