Data Redaction is one of the new Advanced Security features introduced in Oracle Database 12c. The service is designed to allow administrators to automatically protect sensitive data, such as credit card numbers or health information, during certain operations by either totally obscuring column data or partially masking it.
But according to David Litchfield, a self-taught security researcher who found dozens and dozens of critical vulnerabilities in Oracle's products, a close look at this Data Redaction security feature help him found a slew of trivially exploitable vulnerabilities that an attacker don't even need to execute native exploit code to defeat the feature.
David Litchfield is a security specialist at Datacomm TSS and the author of The Oracle Hacker's Handbook, For many years, he was one of the top bug hunters in the game and specialized in digging into the Oracle's database products and breaking them.
Data redaction feature is actually a "great idea", Litchfield said during a talk at the Black Hat USA 2014 conference on Wednesday. But unfortunately, the feature is so thoroughly riddled with basic security vulnerabilities that it is trivial for attackers to bypass it.
"If Oracle has a decent security development lifecycle in place anyone would have found these flaws and stopped them in tracks, Litchfield said. "Anyone with a modicum of SQL would have found these bugs."
The database security expert found many methods to bypass the data redaction feature and tricking the system into returning data that should be actually masked in Oracle Database 12c.
Litchfield then started giving a live demonstration of some of many flaws he had discovered in Oracle's data redaction feature, some of which were previously documented in his paper PDF.
The first method is to use the "RETURNING INTO" clause after a DML operation. This clause allows data to be returned into a variable - a big failure on Oracle's part that he said could be used to bypass Oracle data redaction, which would have been discovered by conducting only a penetration test.
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 and so easily done that he doesn't even feel right to call them exploits.
"There are issues that are trivial to find. They're still not learning the 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 bypass flaws have been patched, but Litchfield said he recently sent Oracle a critical flaw that enables a user gain control of the database, which isn't patched yet but is in the pipeline. This shows that its Java security problems still persist.
