LAS VEGAS–David Litchfield for many years was one of the top bug hunters in the game and specialized in causing large-scale headaches for Oracle. When he decided to retire and go scuba diving, there likely were few tears shed in Redwood City. Litchfield recently decided to resurface, which is good news for the security community and users but may not cause a celebration among Oracle engineers.
There were few more proficient vulnerability finders during the 2000s than Litchfield, a self-taught researcher who found dozens and dozens of critical flaws in products up and down the Oracle catalog. While many of his peers focused on browsers and Web servers, Litchfield specialized in digging into the guts of Oracle’s database products and breaking them in new and creative ways. In the days when Oracle touted its security as Unbreakable, Litchfield made a habit of proving otherwise.
Recently, he decided to take up the task again. After taking a long break from security research and spending a lot of time in close proximity to great white sharks, Litchfield began looking at Oracle’s security again, specifically a new data redaction service the company added in Oracle 12c. The service is designed to allow administrators to mask sensitive data, such as credit card numbers or health information, during certain operations. But when Litchfield took a close look he found a slew of trivially exploitable vulnerabilities
“It’s a great idea. The problem is, of course, it’s trivial to bypass,” he said during a talk at the Black Hat USA conference here Wednesday. “If Oracle had followed any sort of SDLC instead of just paying lip service to it, every one of these flaws would’ve been caught. It’s kindergarten stuff.”
Litchfield found several methods for bypassing the data redaction service and tricking the system into returning data that should be masked.
“The first method uses the RETURNING INTO clause with INSERT, UPDATE and DELETE operations. The RETURNING INTO clause allows data to be returned into a variable after a DML operation. This can be used to bypass Oracle data redaction,” he wrote in a paper outlining the flaws.
A second method he found is essentially a brute force attack on the data in a redacted column in a database.
“Another way to gain access to the data is with an iterative inference attack. It is possible to access data in a SELECT’s WHERE clause. This gives an attacker the opportunity to essentially guess or brute-force the data in a redacted column using a WHERE data LIKE predicate. Consider the following PL/SQL procedure. This simply tests the value of a given character at a given offset into the string. When it gets the first character correct it moves on to the next character and so on until all 16
characters of the credit card have been ascertained,” he said in the paper.
Litchfield said that the methods he found were so simple he doesn’t even feel right calling them exploits.
“There are issues that are trivial to find. They’re still not learning he lessons that people were leaning in 2003,” he said. “It’s 2014 and yet I’m still able to sit down and in the space of a few minutes find a bunch of things that I can send to Oracle as exploitable.”
The data redaction bypasses that Litchfield found have been patched, but he said he recently sent Oracle a critical flaw that enables a user gain control of the database. That flaw isn’t patched yet but is in the pipeline.
