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:
- Host IP: n.n.n.n
- Web Server: Microsoft-IIS/6.0
- Powered-by: PHP/5.2.5
- Powered-by: ASP.NET
- DB Server: MySQL
- Current DB: COMPANY_stg
- Data Bases: information_schema
- COMPANY_stg
- 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