It's the BIG little things #AdminGeek

Common event:
While using an online application I encountered an error due to a programming bug.

No-quite-so-common event:
The online application belongs to a major national retailer and a system mis-configuration exposes a simple administrative oversight resulting in a serious hacking attack vulnerability...


As of this writing the Office Depot online printing application's web server is not configured to use custom error pages which are more user-friendly and less hacker-friendly compared to showing actual, detailed system error messages.  This issue is easily fixed by changing the very common Internet Information Services (IIS) setting "CustomErrors" from "OFF" to "ON".  It's a little setting with potentially BIG consequences such as in the case of Microsoft Security Advisory 2416728.  If it's the little things that get you, the BIG little things might get you, your team and maybe even your whole company.

Setting "CustomErrors" to anything other than"OFF" for production systems has been a Microsoft "best practice" for many years.  The fact that Office Depot has this set to "OFF" shows that the web management team lacks any sort of automated security oversight system that routinely audits configuration settings and alerts admins to systems with non-compliant settings.

Here's one example link showing the problem configuration:

   http://customprinting.officedepot.com/DesignBrowser.aspx

This oversight opens the door for nefarious individuals to poke and pry at the custom online print system -- a system that routinely handles information that is personal (business cards) and sometimes private (invitations with my kid's name, age and upcoming birthday party time and location).

I expect this kind of slip-up from small shops (and, yes, I've done it myself) but a big corporation has resources for the kind of checks-and-balances validation and security audit efforts all serious IT shops wish for (or should).  Besides providing a lucrative vector for hacking attacks, the exposing of detailed error messaging in an un-managed page (no website chrome or company branding) simply looks bad to the customer as it is exposes exactly what it is:  an unexpected issue with no planned provision for capturing the error and attempting to present some sort of "We're sorry" response.

Lest you think I am nitpicking, here is the final line of the error page's source code (included as code comments in the source):

This error page might contain sensitive information because ASP.NET is configured to show verbose error messages using <customErrors mode="Off"/>. Consider using <customErrors mode="On"/> or <customErrors mode="RemoteOnly"/> in production environments.

See?  Even Office Depot's own web server is dropping unambiguous hints as to how the current setting is worrisome and how easily it can be remedied.


Summary:
Customers' trust level in Office Depot's online systems = diminished.

Time for a security audit and, perhaps, a new web server admin as well.

This is the actual error I encountered.

( Click to see full-size image. )