Oracle Database Redaction Trivial To Bypass, Says David Litchfield

msm1267 (2804139) writes "Researcher David Litchfield is back at it again, dissecting Oracle software looking for critical bugs. At the Black Hat 2014 conference, Litchfield delivered research on 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 that bypass the data redaction service and trick the system into returning data that should be masked."

Re:Is the target "hackers"?

[Sockatume]

Exactly.

Considerations When Using Oracle Data Redaction with Ad Hoc Database Queries

You may encounter situations where it is necessary to redact sensitive data for ad hoc queries that are performed by database users. For example, in the course of supporting a production application, a user may need to run ad hoc database queries to troubleshoot and fix an urgent problem with the application. This is different from the application-based scenarios described in "Using Oracle Data Redaction with Database Applications", which typically generate a bounded set of SQL queries, use defined database accounts, and have fixed privileges.

Even though Oracle Data Redaction is not intended to protect against attacks by database users who run ad hoc queries directly against the database, it can hide sensitive data for these ad hoc query scenarios when you couple it with other preventive and detective controls. Because users may have rights to change data, alter the database schema, and circumvent the SQL query interface entirely, it is possible for them to bypass Data Redaction policies in certain circumstances. You can address this problem by restricting database privileges and by coupling Data Redaction with other Oracle Database security tools, as follows:

Oracle Database Vault can prevent database administrators from performing harmful operations.

Oracle Audit Vault and Database Firewall can:

Monitor and block malicious database activities.
Prevent rows from appearing in query results of non-authorized users.
Alert you about suspicious activity that was audited by the database.
Remember that the Oracle Database security tools are designed to be used together to improve overall security. By deploying one or more of these tools as a complement to Oracle Data Redaction, you can securely redact sensitive data even from users who are running ad hoc queries.

Also, note that Oracle Data Redaction hides sensitive information based on database columns. It works best in scenarios where the sensitivity of the data is determined mainly by the column in which it is stored. When an Oracle database displays query results, Data Redaction redacts the rows of data queried from a given column if an enabled Data Redaction policy is defined for the column and the policy expression evaluates to TRUE; otherwise the column's actual data is displayed.

http://docs.oracle.com/databas... [oracle.com]

Re:Put in a separate table

[Jaime2]

In the payment card industry, this is called a token, not a hash. The difference is that a hash can be algorithmically generated from the source material, while a token cannot. Because there is no forward link outside the entity that generated the token to go from card to token, the tokens can be different at each merchant, making a loss of token much less of a problem than a loss of hashes would be. It's also 100% infeasible to break the token generating algorithm since there isn't one. In my experience, tokens are simply generated sequentially (skipping those that don't pass Luhn check). Another beauty of tokens is that they can pass validity checks for credit card numbers, so they can be handed to third-party software and treated just like card numbers, but without the risk of breach.