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.

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

Lock Picked with Toilet Paper Tube