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.
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-03-08
Dell iDRAC8 versions prior to contain a host header injection vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by injecting arbitrary ‘Host’ header values to poison a web-cache or trigger redirections.
PUBLISHED: 2021-03-08
Maxum Rumpus 8.2.13 and 8.2.14 is affected by a command injection vulnerability. The web administration contains functionality in which administrators are able to manage users. The edit users form contains a parameter vulnerable to command injection due to insufficient validation.
PUBLISHED: 2021-03-08
Maxum Rumpus 8.2.13 and 8.2.14 is affected by cross-site scripting (XSS). Users are able to create folders in the web application. The folder name is insufficiently validated resulting in a stored cross-site scripting vulnerability.
PUBLISHED: 2021-03-08
A flaw was found in keycloak in versions prior to 13.0.0. The client registration endpoint allows fetching information about PUBLIC clients (like client secret) without authentication which could be an issue if the same PUBLIC client changed to CONFIDENTIAL later. The highest threat from this vulner...
PUBLISHED: 2021-03-08
PowerScale OneFS 8.1.2,8.2.2 and 9.1.0 contains an improper input sanitization issue in a command. The Compadmin user could potentially exploit this vulnerability, leading to potential privileges escalation.