Application Security // Database Security
10/25/2012
02:18 AM
Connect Directly
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
lsatenstein
50%
50%
lsatenstein,
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.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.