Popular websites leaking system status information, private data and even passwords

Filed Under: Data loss, Featured, Privacy, Security threats

Websites leakingSecurity researchers have discovered that thousands of popular websites are putting their users' data at risk by leaking internal status information.

The sites in question include a host of well known names and should-know-betters including Ford, Tweetdeck, Webex, Php.net and Staples.

Most of the sites are only leaking enough information to give attackers a window into their server's internals - something that might be a useful stepping stone in formulating a more complex attack.

But as Dan Goodin illustrated in his article at Ars Technica in a few cases the doors are being flung wide open. Some of the sites are exposing information that an attacker could use to compromise or gain access to a website such as session IDs, passwords and in one case the address of an unprotected admin panel.

A screen shot of Ars Technica showing a server status page leaking passwords

The organisations in question are all running websites using the popular apache web server but haven't restricted access to its server status module mod_status. According to Apache (my emphasis) their server status module:

...allows a server administrator to find out how well their server is performing. A HTML page is presented that gives the current server statistics in an easily readable form.

The leaky websites were first discovered by web security firm Sucuri, who performed an automated scan of 10 million websites and found 2,072 that hadn't hidden their server status pages.

HD MooreThis was followed up by an even more revealing scan by HD Moore, chief architect of the Metasploit penetration testing software framework. He pulled a list of the top 100,000 websites from Alexa and repeated the scan.

Moore found 1,774 with exposed server status pages, about 12 that were leaking session IDs and 6 that were leaking passwords.

So long as you're not one of the users whose passwords are being exposed you might think this isn't so bad, after all the overwhelming majority of sites scanned weren't leaking passwords.

But Moore's scan only took 45 minutes. Organised criminals don't care about failure rates they care about getting a return on their investment and the time, cost and effort in scaling Moore's scan to hundreds of millions of websites is likely to be negligible.

For some organisations making a server-status page publicly available is a deliberate and considered step but for the majority its no more than a failure to observe the principle of least privilege.

If users don't need to see server status information they shouldn't be able to see it.

Adopting the principle of least privilege saves you from having to anticipate how attackers might use apparently harmless information against you.

If you're running the apache web server and you don't need mod_status you should disable it.

If you do need to run mod_status then the apache.org website has a full and complete explanation of apache's authentication and authorisation options.

The mod_status page itself also details how to restrict access to a particular domain or network.

, , , ,

You might like

5 Responses to Popular websites leaking system status information, private data and even passwords

  1. V. Wood · 1066 days ago

    "The mod_status page itself also details how to restrict access to a particular domain or network." This is the most important comment in the whole article. However, the link brings up a "page not found" error.

  2. Iain Collins · 1064 days ago

    The WTF here is not that mod_status is running - it's that things like passwords and Session ID are being passed in a URL, which opens up multiple vectors for exploitation.

    Advising people to stop using mod_status as a way to fix this isn't the right message - better advice is "Don't put Session ID's or passwords in a URL, ever.", which is the root of the problem.

    Instead, POST forms (application/x-www-form-urlencoded), HTTP headers and cookies should be used to exchange authentication credentials and to set Session ID's.

    The closest thing you should ever need to have to a session ID in a URL is a token for cross domain auth (e.g. single sign-on, such as with oath). Ideally these tokens should have a short lifespan.

    • markstockley · 1064 days ago

      Hi Iain,

      I'm not advocating that people stop showing server status just to prevent leakage of passwords through URLs - I was trying to use that as an example of the kind of unintended consequence that results from failure to follow the principle of least privilege.

      Passwords in URLs is an obvious example of a vulnerability but the value of the principle of least privilege is that it protects you from vulnerabilities you haven't found (which you'll appreciate is harder to illustrate).

      That said I could certainly have made a separate point about passwords in URLs so let me correct that here by agreeing with you let me also pick up on an important point that you missed in your own advice.

      If you're passing sensitive information in HTTP requests - passwords, session IDs, personal information or anything else you need to keep secret - then your first priority is to encrypt the request by sending it over an HTTPS connection instead.

      Secret data in an HTTP request is vulnerable whichever part of the message it's in. There is no security inherent in POST data, HTTP headers or cookies and relying on them as a form of security is a recipe for disaster. If a request is in plain text then any part of it can be read by anyone who can trap the message.


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

Mark Stockley is an independent web consultant who's interested in literally anything that makes websites better. Follow him on Twitter at @MarkStockley