Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security //

Database Security

02:18 AM

Nightmare On Database Street: 5 Database Security Horror Stories

Chilling stories from penetration testers, database pros, and security consultants in the field

Database security may not be quite as sexy as a teenage party in a classic horror film. But when it's done wrong, technology executives, CEOs, and customers alike would shiver at the consequences.

Don't think so? Then read just a few of the horror stories laid out by some of the grizzled penetration tester vets we quizzed here. Their exploits show how scary bad database security can really be.

[Will mobile biometrics be an IAM driver? See You're Nobody Without Your Mobile Device.]

1. Credit Card Button Of Doom
During one particular penetration testing engagement, Ron Schlecht, Jr., managing partner for BTB Security, was looking at an application that allowed his team "to do all sorts of hideous things."

One particular component stood head and shoulders above everything else, though. It was a small "credit card" button within the application user interface that allowed certain managers to view one guest's credit cart number at a time. While it didn't offer bulk access on its face and might possibly fill a business need, Schlecht says his team felt it needed to dig deeper into this button.

When his team clicked on the button, they found the client application generated a SOAP query and the server responded with a B64 encoded string.

"No other communication with any other server, just this B64 string," he says. "So that means the end client was doing the decrypting. Really?"

Looking further, his team decompiled the application and found that it was using DES with an alphabetically sequential key of seven characters and a space.

"So we pulled down the 'encrypted' CC table for this database and hacked together a Perl script to decrypt all the goodies," he says, explaining how they were able to get bulk credit card decryption using that supposedly one-off button.

2. FISMA Fright Night
In his work as a penetration tester of an application with a "highly sensitive" FISMA rating at a three-letter federal agency, Chris Stark showed his client how dangerous default database portals can be.

"The architecture for this application was top-notch, with multiple DMZs and crazy network segmentation," says Stark, senior security consultant at Foundstone.

And yet on his first day scanning the database and the most trusted network, he found a Web portal for managing the database that nobody used.

"This was bad, and you could administer the database via this Web interface," he says. "What was worse was that I was able to use the portal to test default credentials, and discovered that the default credentials could be used to log into the database as SYSTEM and change any and all schema."

According to Stark, this kind of configuration would make it super easy for the attacker to run an Oracle query through the Web interface to create a local privileged OS account thoroughly own the system.

3. Attack Of The Killer Kiosk
In one particular instance, Jeff LoSapio, partner at Stratum Security, found a new and gnarly way for SQL injections to be used against retailers -- within their in-store kiosks. On a penetration test gig, he was pitted against one such kiosk that did price-checks based on bar codes.

Only instead of presenting the kiosk with normal old bar codes, they converted SQL commands into bar codes, printed them out, and scanned them.

"When placed under the scanner, we were able to perform SQL injection against the price-check Web application and dump the entire contents of their database, and could execute commands on the database," he says.

Not only that, his team was able to change prices of high-ticket items so that they'd ring up at bargain prices at the register.

"Anyone in the store could access the price check kiosk and give themselves huge discounts," he says.

4. PCI Ghost Database
On assignment for a client with multiple retail locations all over the U.S., Stark spent time examining the servers that hosted many of the back-end applications that supported the POS and other store-related functions. Each of these servers hosted a MSSQL server with a major database that contained encrypted credit card numbers from POS transactions.

"This client was very confident in their database security and had no issues with me performing database security discovering and vulnerability scans against the MSSQL server," he says.

In spite of their confidence, when Stark went digging he found something interesting: another database on one of the store's MSSQL servers that no one knew about.

"After some MSSQL queries looking for credit card holder data, I discovered that a table in this database contained more than 10,000 unencrypted credit card numbers," he says. "It was an old prior version of the POS back-end, and [was] never removed from the MSSQL server when they upgraded!"

5. Slaying With SQL Injection
Penetration testers frequently make quick work of database defenses through SQL injection, and Jeromie Jackson is no different. He has left a trail of carnage in his path through ample use of these attacks. For example, there was the time when he was brought in to take a look at a newly created Student Information System that a school had launched with much fanfare and excitement prior to his arrival.

"About 10 minutes into it, a SQL injection vulnerability was found that allowed me to not only download their most critical assets, but also identify foster children, those given discount lunches, and so on," says Jackson, security practice lead at Nth Generation.

And another time at an insurance organization that had similarly just built a "whiz-bang" system for policy and rate quoting and issuance, within an hour of testing Jackson managed to find a SQL vulnerability that gave him access to the company's entire policy database since its inception in the mid-1980s.

Most fun for him, though, was the time he and his team were able to execute a SQL injection in the application that supported the physical security of a client's building.

"We created a user account into the system, and then we were able to tromp through the interface, disabling the alarms and cameras at night," he says. "It was great for a red-team engagement!"

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
12/2/2012 | 10:39:52 PM
re: Nightmare On Database Street: 5 Database Security Horror Stories
From what I read, his activity was done mainly from within the organization.- Did the author actually do the testing via the web or outside the office terminal (for POS testing, from the store terminal).-
Yes, all loopholes should be blocked, and agree that irrespective of the way the problems were found, they must be corrected.
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
Enterprise Cybersecurity Plans in a Post-Pandemic World
Download the Enterprise Cybersecurity Plans in a Post-Pandemic World report to understand how security leaders are maintaining pace with pandemic-related challenges, and where there is room for improvement.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-09-19
All versions of Apache Santuario - XML Security for Java prior to 2.2.3 and 2.1.7 are vulnerable to an issue where the "secureValidation" property is not passed correctly when creating a KeyInfo from a KeyInfoReference element. This allows an attacker to abuse an XPath Transform to extract...
PUBLISHED: 2021-09-19
loop_rw_iter in fs/io_uring.c in the Linux kernel through 5.14.6 allows local users to gain privileges by using IORING_OP_PROVIDE_BUFFERS to trigger a free of a kernel buffer, as demonstrated by using /proc/<pid>/maps for exploitation.
PUBLISHED: 2021-09-19
All versions of package com.jsoniter:jsoniter are vulnerable to Deserialization of Untrusted Data via malicious JSON strings. This may lead to a Denial of Service, and in certain cases, code execution.
PUBLISHED: 2021-09-18
Teleport before 4.4.11, 5.x before 5.2.4, 6.x before 6.2.12, and 7.x before 7.1.1 allows forgery of SSH host certificates in some situations.
PUBLISHED: 2021-09-18
Teleport before 4.4.11, 5.x before 5.2.4, 6.x before 6.2.12, and 7.x before 7.1.1 allows alteration of build artifacts in some situations.