Ticking Time-Bombs: Production Data in Non-Production Systems

Friday, August 03, 2012

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

This is a little touch of irony... but almost exactly 2 years ago I wrote on this very blog about the dangers of using real data as test data in a post titled "What we're all forgetting".  

A few weeks ago we got news via the Twittersphere that a certain fast-food company was SQL Injected and the output dumped to the Internet.  

It's on pastebin, so you can find it if you really want, but I picked up on a small subtlety while reading down through the dump (which comes from a tool call Havij, which is a SQL injection tool) which I wanted to share:

  1. Host IP:             n.n.n.n
  2. Web Server:     Microsoft-IIS/6.0
  3. Powered-by:     PHP/5.2.5
  4. Powered-by:     ASP.NET
  5. DB Server:       MySQL
  6. Current DB:     COMPANY_stg
  7. Data Bases:     information_schema
  8.                 COMPANY_stg
  9.                                   DATABASE_data

Does anything strike you about that snip?  The tables dumped out were all called COMPANYNAME_stg.TABLENAME, so unless I'm reading this wrong this is consistent with a staging database... aka - non-production.  

The attacker didn't paste out whether they successfully listed out the DATABASE_data table so I'll leave that alone.  Two quick questions jump to my mind... 1) why is there a potentially non-production database accessible from the production website?, and 2) does it have real data?

I can't even begin to count how many times I've seen this in my 3.5 years doing proof-of-concepts as a software security SE.  We would demonstrate Webinspect's effectiveness by uncovering and pulling data out from what should have been a non-production data store or application.  

"But that's in staging, not in production" was something I heard rather frequently.  While it's not really OK to have a vulnerable application sitting out on the 'net, at least if it's in "stage" mode it shouldn't have real data... right?  Unfortunately this wasn't the case in many of the incidents I experienced... and while I certainly can't tell you for sure whether this is the case in this breach... evidence would seem to suggest that.

On that note - I think it's time to remind ourselves that anything that is accessible should be well protected.  A weakly defended/protected application in stage bodes poorly for the security of that application in production... wouldn't you agree?  Unless of course we're playing the bolt-on security game - in which case... it's an even worse indicator.

There is absolutely no excuse for using real, production data which contains protected information in a non-production system... unless you're going to treat that system as production-level sensitivity.  Here's the key, as one of my Twitter connections said earlier today "production data = production system"... and that's correct.  Here are 3 quick tips for keeping this ticking time-bomb out of your organization:

  • Perform data masking: Whether you're presenting data to a non-privileged user, or to a non-privileged system, it should not be the full protected data element.  There are ways to statically (or even dynamically) data-mask and keep the data usable.  Just because you can't use a real social security number doesn't mean your application can't be tested because it needs a 'valid' SSN, that's a requirement for your developers to code to.
  • Highest common denominator: The sensitivity of an application is the composite of the application, the data, and the environment... unfortunately  the highest common denominator wins.  If the system is in a low-security environment, working with a low-security application using real sensitive data the composite sensitivity (risk level, criticality) is high.  This should be well understood across your organization from IT to business analysts.
  • Audit exposure: Your environments (whether it's on the developer's desktop, on an internal network, or in a public cloud) should constantly be audited for data sitting around. Failure to account for and secure sensitive data is a silent ticking time-bomb your organization should be aware of.

What do you think the odds of this problem going away in 2 years is?  Right... probably pretty low.  Awareness is key.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
12498
General
Information Security
SQl Injection Databases Application Security Best Practices Data Loss Prevention Network Security breach SecDev Data Masking
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.