DHS website falls victim to hacktivist intrusion

Hacktivist group NullCrew recently announced a succesful intrusion (though intrusionette might be a better word) against a website in the DHS.GOV domain hierarchy.

DHS, of course, is the United States Department of Homeland Security.

The intrusionetted site wasstudyinthestates.dhs.gov, intended to help foreigners find out if and how they might be able to study at US schools, colleges and universities.

It looks as though the site was vulnerable to what's known as a directory traversal vulnerability.

That's where you construct a URL that persuades the server to navigate to a part of the web server you aren't supposed to be able to access, and to retrieve content from there.

Imagine, for example, that your webserver hosts a file that is available via the URL http://example.org/private.dat, but to logged-in users only.

If the server were to see an unauthorised GET request for /private.dat, you'd expect it to deny the request.

But your server needs to be careful that it doesn't let itself get tricked, for example by a request to retrieve a file such as /subdir/../private.datinstead.

If you start examining the filename from the left, it doesn't look like a file in the root directory, because there's a directory name (/subdir/) first. But the ensuing ../, which denotes "parent directory to the one I am in at the moment", leaps back up one level, thus cancelling out the initial step downwards into subdir.

Filenames with paths that lead upwards in your filing system are always a risk. By climbing upwards, an attacker may be able to wander "up-and-over-and-down" into otherwise-forbidden parts of your web server's directory tree.

In really bad cases, attackers might even be able to hoist themselves out of your web server's directory tree altogether, and into the rest of the filing system.

This might give them access to password and configuration files for the operating system itself, or for other software running on the same server.

Poor handling of upward-leading filenames seems to have been what was wrong on the Study in the States website.

It looks as though a PHP script responsible for a download repository was incautious in its argument handling. A URL of the sort:

http://example.org/known/dir/download.php?file=somename.dat

could be abused with a request like this:

http://example.org/known/dir/download.php?file=../../private.dat

This, it seems, caused the ill-configured download script to navigate upwards in the web server's directory tree, retrieving from the inside a file that would have been blocked if it had been downloaded directly from the outside.

The fault seems to have been patched now, but if NullCrew are to be believed (and let's assume they are), this hole was used to fetch the WordPress configuration file, apparently including the backend database location and password. This configuration file was then published on a publicly-available drop site.

Sadly, if the HTTP headers returned by the Study in the States website are telling the truth, there's still some more patching to be done.

The site reports that it's running Apache 2.2.3 on Red Hat, and PHP 5.3.3. As I write this, those versions should really be PHP 5.3.20 and Apache web server 2.2.23.

Why not use this as a call to action for your own web servers in 2013?

• Make sure you're updated with the latest security fixes for all back-end components you use. Attackers read the vulnerability mailing lists, so they already know how to break in to your unpatched servers.
• Consider running a Web Application Firewall (WAF) to scour inbound web traffic for bogus or risky-looking requests. This helps to shield your web servers from as-yet-unknown attacks.
• Perform regular penetration tests against your own web properties to make sure that tricks such as directory traversals are blocked and logged.

A quick look at your web server logs will almost certainly reveal a large number of (probably automated) attacks based on weird-looking URLs that the attacker hopes will sneak past your defences.

It's not a matter of if, or even of when, you might get attacked. If you're inviting inbound web requests, you're already under attack!