My Pen Test

One of the first steps of any web application security audit is to determine what software is installed, which allows you to search for known vulnerabilities at websites like Bugtraq.

The Weblog Tools Collection blog recently had a post asking readers to guess how many WordPress plugins they had installed, with the prize being a pro account on Flickr.

I’m not a big fan of guessing games, so I thought I would write a simple VuGen script to find the answer.

Using the list of plugins taken from my post on content scraping, I got a list of all the WordPress plugin directories and then wrote code to try all of these under http://weblogtoolscollection.com/wp-content/plugins/.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// Determine which plugins are installed for the WordPress blog at weblogtoolscollection.com
Action()
{
	int http_response_code;
	char* file = "C:\\TEMP\\output.txt";
 
	web_custom_request("CheckForPlugin", 
		"URL=http://weblogtoolscollection.com/wp-content/plugins/{PluginDirectory}/", 
		"Method=HEAD", 
		"Resource=1", 
		"RecContentType=text/css", 
		"Referer=http://weblogtoolscollection.com", 
		"Snapshot=t1.inf", 
		LAST);
 
	// Request will either return a 404 (not found) or a 403 (forbidden)
	http_response_code = web_get_int_property(HTTP_INFO_RETURN_CODE);
	if (http_response_code == 404) {
		// do nothing
	} else if (http_response_code == 403) {
		jds_append_to_file(file, lr_eval_string("Plugin found: {PluginDirectory}\n"));
	} else {
		lr_error_message("Unexpected response code %d for %s", http_response_code, lr_eval_string("{PluginDirectory}"));
		jds_append_to_file(file, lr_eval_string("Unexpected response: {PluginDirectory}\n"));
	}
 
	return 0;
}

For the curious, the plugins found were:

• Akismet (akismet) – Not visible to end-users. Probably enabled, even though WP-SpamFree is also installed. Akismet is awesome.
• All in One SEO Pack (all-in-one-seo-pack) – Defnitely active, and running version 1.4.91. The name of this plugin is great, but what it actually delivers is definitely underwhelming
• Bird Feeder (bird-feeder) – Definitely active. This plugin tweets published posts, and the website owner’s twitter feed contains Bird Feeder tweets.
• Delink Comment Author (delink-comment-author) – Probably inactive. I can’t believe that anyone would run such a useless plugin.
• FeedStats (feedstats-de) – Not visible to end-users. Probably enabled.
• Google XML Sitemaps (google-sitemap-generator) – Definitely enabled. This is an excellent plugin.
• Highlight Author Comments (highlight-author-comments) – Definitely enabled. This can be seen in other posts
• HTML Purified (html-purified) – This plugin is a comments filter. I could test for this, but can’t be bothered. Probably enabled.
• Moderation Notify Author (moderation-notify-author) – Not visible to end-users. Probably enabled, as this is a multi-editor/contributor blog.
• MoFuse Wordpress Plugin (mofuse) – This plugin creates a mobile version of your blog. I could test for this, but can’t be bothered. Probably enabled.
• Ozh’ Who Sees Ads (ozh-who-sees-ads) – probably enabled.
• RSS Footer (rss-footer) – I think this is disabled as I can’t see anything that has obviously been added to the start/end of each post in the RSS feed.
• ShareThis (share-this) – Definitely active. I really like this plugin
• Simple Tags (simple-tags) – Probably active.
• WordPress.com Stats (stats) – I don’t think this is active, as I can’t see the JavaScript in the HTML page.
• Subscribe to Comments (subscribe-to-comments) – Definitely active. This is shown in the comment form.
• Tweetbacks (tweetbacks) – Definitely active. This is shown at the bottom of every post.
• What Would Seth Godin Do (what-would-seth-godin-do) – I think that this is inactive.
• Wordpress Thread Comment (wordpress-thread-comment) – I’m sure that WordPress does threaded comments by default now. Probably disabled.
• WP Ajax Edit Comments (wp-ajax-edit-comments) – I think that this is disabled.
• WPBook (wpbook) – Ebmeds your blog in your Facebook page. Can’t be bothered checking. Probably enabled.
• WP-Cache (wp-cache) – Probably enabled.
• WP-DB-Backup (wp-db-backup) – Probably active, and probably allows anyone to guess the filename of the backup and download a copy of the site’s database.
• WP-PostRatings (wp-postratings) – Definitely active, and running version 1.40.
• WP-SpamFree Anti-Spam (wp-spamfree) – This plugin tries to let only user-agents that can execute JavaScript submit comment. It appears to be disabled.
• WP Tuner (wptuner) – Might be enabled.
• Yet Another Related Posts Plugin (yet-another-related-posts-plugin) – Active. Post pages have related posts displayed.
• Hello Dolly (hello.php) – Not visible to end-users. Probably disabled. I don’t know why WordPress still ships with this.

Total plugins: 28
Active plugins: 20
Deactivated plugins: 8

I haven’t bothered to check if any of these plugins have known security vulnerabilities.

As I’ve said before, VuGen makes a great content scraping tool for cases when you want a quick and dirty script to save specific data from multiple webpages.

In this example, I wanted to create a list of all the WordPress plugins available from http://wordpress.org/extend/plugins/ (currently there are 4,245), and save all the metadata about the plugin:

• Number of downloads
• Version number
• Rating
• etc…

Read the rest of this entry »

Princeton researchers released a research paper yesterday which documents Cross-Site Request Forgery vulnerabilities in 4 well known commercial websites (ING Direct, NY Times, Youtube, and Metafilter). It makes for interesting reading.

• Wikipedia article on Cross-Site Request Forgery
• Jeff Atwood of Coding Horror has a blog post on CSRF
• CSRF FAQ at CGI Security

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).