Mastodon

A graphic demonstration of information leakage through security misconfiguration

A couple of days back I wrote about how 67% of ASP.NET websites have serious configuration related security vulnerabilities. In the post, I drew on figures collected by ASafaWeb and observed that small misconfigurations in config files could very easily disclose information that could be leveraged to exploit the application.

Quite a bit of discussion ensued through the comments, via Twitter and on Reddit. I found it slightly amusing that some camps felt these weren’t vulnerabilities at all as they couldn’t directly be exploited. Frankly, that’s a semantic argument; there’s a significant risk in what’s classified as “security misconfiguration”, this is why OWASP includes it in the Top 10.

Today I inadvertently stumbled across a perfect illustration of security misconfiguration which whilst not related to ASP.NET, was just what I needed to provide some perspective. This example comes courtesy of kogan.com who just a few hours ago, had a homepage which looked like this:

Django debug info from kogan.com

I’m not going to provide the original sized image because frankly, there’s a lot of info up there I don’t want to be responsible for redistributing (Google cache may well  be taking care of that anyway). What I can tell you is that it consisted of:

  1. The website framework (Django) and version
  2. The identity the error was occurring under
  3. The physical location of the script
  4. The line of code the script was failing on
  5. The version of Python being run
  6. The web server (Apache) and version
  7. The database being used (MySQL)
  8. The host address of the database
  9. The username connecting the database
  10. The password being used to connect to the database
  11. The exact query being run on MySQL
  12. The SMTP server it was using
  13. The username used on the SMTP server

Now this is no lightweight, static brochureware site – this is a full blown e-commerce website. This is a site which actually enables the purchase of electronic goods and ultimately asks customers to trust them with their credit card details.

But this isn’t intended to be a Kogan-bashing exercise, in fact I’m sympathetic because security misconfiguration is dead easy to get wrong. I’m no Django expert but the consensus seems to be that it was a simple case of still running in debug mode in production, which sounds about right:

Never deploy a site into production with DEBUG turned on.

Did you catch that? NEVER deploy a site into production with DEBUG turned on.

One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).

Hey, it happens, and if you deploy enough web apps you’ll eventually do the equivalent of this yourself in your chosen technology.

Despite what it might look like, I’m actually leading somewhere with this: you absolutely must check every aspect of your security configuration post-deploy. It’s so easy for a simple setting to be changed during development, make its way into source control and then arrive with a bang in production. Practices like config transforms in ASP.NET are great mitigations but they’re not fool proof.

Going back to where I started in this post, this is why those security misconfiguration findings in ASafaWeb are so important. This is why you need to treat them seriously and this is why you need those post-deployment checks whether it be via ASafaWeb for your ASP.NET sites or simple manual checks for any technology stack.

So what now for Kogan? Well, that slipup wasn’t momentary; they’d been warned about this the day before and judging by their Twitter stream today, plenty of other people observed the error page in its full blown glory. At the very least, there will need to be password resets all around and frankly I’d be cycling as much other disclosed info as possible while they’re at it. Then of course there’s the issue of what resources were accessed – and possibly manipulated – using the disclosed information so some degree of forensic investigation is going to need to happen too. At best, a whole bunch of time is going to be blown making sure everything check out. At worst, well, use your imagination.

Check your websites, folks.

Security
Tweet Post Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals