News Database Security
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.
More Security Insights
- A Smarter Approach: Inside IBM Business Analytics Solutions for Mid-Size Businesses
- Collective intelligence: Capitalizing on the crowd
- Informed CIO: SDN and Server Virtualization on a Collision Course
- Strategy: Building and Maintaining Database Access Control Permissions
- Mobile DevOps: Achieving continuous delivery with multiple front ends and complex backends in Banking, Financial Services, and Insurance
- How Cloud Facilitates an Agile Contact Center
[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.