DevOps Zone is brought to you in partnership with:

Troy Hunt is a Software Architect and Microsoft MVP for Developer Security. He blogs regularly about security principles in software development at troyhunt.com and is the author of the OWASP Top 10 for .NET developers series and free eBook of the same name. Troy is also the creator of the recently released Automated Security Analyser for ASP.NET Websites at asafaweb.com. Troy is a DZone MVB and is not an employee of DZone and has posted 63 posts at DZone. You can read more from them at their website. View Full User Profile

Security is Hard, Insecurity is Easy: A Simple Misconfiguration Risk

05.29.2013
| 2589 views |
  • submit to reddit

One could argue that security is hard. Not all aspects of it, mind you, but the prevalence of website hacks would seem to indicate that plenty of people are struggling to get it right.

On the other hand, insecurity can be very easy. What I mean by this is that sometimes it can be the smallest change to a website that blows the security wide open.

Last week someone passed me a private note about Black and Decker, or more to the point, they passed me a link to an unsecured ELMAH log. For the uninitiated, ELMAH logs and their discovery via Google is something I’ve written about before. In fact in this very case it was someone simply searching for some info on ELMAH that lead to this discovery – it’s that easy.

Now I want to stress that this is not intended to be all about Black and Decker and before posting this I did privately contact them and they have now correctly secured the logs. In fact there are tens of thousands of Google results for publicly exposed ELMAH logs so clearly this is a very prevalent risk. Let me first share the video on what you can do with exposed ELMAH logs then I’ll come back around to the point of this post:


That should put things into context regarding the risk of exposed ELMAH logs and it goes well beyond just session hijacking. For example the risk includes access to:

  1. Customer email addresses as they’re stored in the cookie
  2. IP address of users (including of individual customers per the previous point)
  3. Passwords (these are also sometimes stored in cookies)
  4. Referrers (discloses entry points into the site)
  5. Any other data on the site that is accessible if the session can be hijacked

Keep in mind that there are tens of thousands of log entries in this particular site so there’s quite a profile an attacker could have built up.

Here’s the point I want to make: a frankly massive security hole like exposed ELMAH logs can occur as a result of the smallest configuration change and it begs the following questions:

Is there any continuous security scanning of the site? This was a very basic error and in fact my own very basicASafaWeb scanner could have caught this on a daily scheduled scan and reported it within 24 hours of the risk occurring. Other commercial products could have identified a far broader range of risks but the point is that security scanning needs to be continuous, not just a one off, not on an annual basis, not just on major changes but all the time.

Who can release changes? You’ve gotta wonder if a case like this was just a junior dev not realising what they were doing. Mind you, I’ve seen plenty of experienced devs make similar mistakes but it begs the question: just how easy is it to slip something through into a production? Is anyone actually overseeing the process? Or does one person have a few beers on a Friday afternoon and push the “publish” button?

What’s the post-release review process? It’s extremely easy for configuration related vulnerabilities to slip through during the release process. For example a developer just wants to quickly check the details of an obscure error in a production environment so they release with verbose errors (i.e. turn off custom errors in ASP.NET) and promise themselves they’ll lock it down later. The release process should ideally catch this and set off all sorts of alarms.

Are you contactable for when things go wrong? I hadn’t planned on including this section originally but given the way things played out (more on that another time), it does illustrate an important point. It was extremely difficult to get in touch with anyone from Black and Decker using social media and published email addresses and I eventually got through to them in a very round-a-bout fashion. It’s very hard for people to do the right thing and disclose privately when they can’t get in touch with you!

Black and Decker presented a good opportunity to illustrate the risk because of their sheer scale. This is a multinational organisation pulling in $6B a year and employing 27,000 people and something so simple slipped past them, is it any wonder that so many companies with such fewer resources struggle? And I’ll stress again – there is (unfortunately) nothing very unique about them having a risk of this nature – it’s alarmingly common as it’s so simple to do. Insecurity is indeed, easy.

Published at DZone with permission of Troy Hunt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)