Slashdot Mirror
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."
No, passwords, SSNs, PINs and Credit Card numbers should be hashed before inserting into any table. There is NO reason for anyone to save that data unhashed.
To compare data, just hash what the customer enters and compare the hashes. Why is this so hard for 99.9% of companies to understand?
You mean regular DBAs like the next Edward Snowden? Inside threats are important and are one of the reasons this feature exists. LitchField did what he does best; he showed that the product doesn't quite live up to the marketing material.
As a developer in the industry here I can honestly say nobody in our industry would be dumb enough to use this tool. Security is very important, and i'm sure PCI compliance would be a huge issue. Unless under a dual-control situation and 4-5 physical doors from the outside world, no un-masked CC# exists except on physical card. Yes, it would be nice for that service for software developers to use as a tool for display....like in my case, to provide cleansed data to the screen without manually cleansing data....but the issue is that PCI will dictate where that data can exist, and if it's uncleansed and accessible to a DB admin or software dev, there's too much visibility. They look at it from the standpoint that if a single person has access by themselves then they're likely to steal them. I don't see why they would automatically allow search within masked bytes (at least if it's ultra sensitive).....I can understand if maybe there's a setting like (sensitive to search) so that CC#'s couldn't be brute forced, however a search for a person's last name where all but the first letter are masked would probably be okay.
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...
No kidding!!! What do you say at this point?
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.
If the card company accepts hashes then having the hash is no different than having the card number. In other words, no, it isn't nor should it be, done that way.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun