DHS website falls victim to hacktivist intrusion

Filed Under: Featured, Security threats

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 was studyinthestates.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.dat instead.

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.

Surely some mistake?

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!

Running a web server at home?

Why not try out the free Sophos UTM Home Edition?

You get web and email filtering, web application firewall, IPS, VPN and more for up to 50 IP addresses. You can also protect up to 12 Windows PCs on your network with Sophos Anti-Virus!

(Note: registration required.)

, , , , , ,

You might like

6 Responses to DHS website falls victim to hacktivist intrusion

  1. futguy11 · 656 days ago

    Not surprised, as this happens often, not just to DHS.

  2. Guest · 656 days ago

    Oh boy, somebody could read the file names listed in a directory. BFD. And http headers show some software versions aren't at the latest patch levels. My gawd the sky is falling.

    Yawn.

    Guess the hackers couldn't get anything real, must've had the door slammed in their face so this is the best they could do.

    Not losing any sleep over this, it's far from Stuxnet or Zeus. How are your own systems? Do you even know?

    • Bob · 656 days ago

      Knowing what software a server is running allows one to find known vulnerabilities for that particular software version. It can also give a general idea as to how well-maintained a server is or isn't.

      One could do more than just read file names. Files could be accessed; passwords could be acquired. Those passwords could allow privileged access, and typically to other systems, too.

  3. spryte · 656 days ago

    There is not much new here.
    Anyone can use their favourite search engine to do this...

  4. Rodney · 654 days ago

    Well they may have a special Redhat bundle of Apache where 2.2.3 has sub-patches to 2.2.3.56

  5. Day by day hackers become more smart as compared to police because they are well aware of the area is effective for hacking and get into their hands.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog