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."
I mean it sounds like this is just to protect sensitive data from the day-to-day work of your regular old DBAs. They aren't trying to look at the data, and hack into the system to examine it. They just shouldn't unnecessarily be exposed to it.
Shouldn't you "mask" sensitive data by putting it into a separate table with stricter access privileges.
I am becoming gerund, destroyer of verbs.
I was wondering if ever something could be exploited the stupid way movies seem to work, assuming you just guess one letter of the password at a time. CPE1704TK* ... almost got it!
That's true, and funny. It does remind me of another, more well-known "almost got it" attack. For MD5 collisions you keep adding data to the end, getting closer and closer to a match. In fact, that's how the whole hack works. You can't know what will match, but you can generate something that is closer to match. Keep getting closer to match until you happen to actually match.
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.
Or you know encrypting it! credit card numbers should never be held en clair
Database access should be already restricted by firewalls and to in-house developers/administrators. This is just a way to ensure they don't routinely get exposed to private information and then leak it in e-mails, bug reports and so on. It is understood that they can get to data if they are really determined, although database queries are usually audited and most should be deterred by potential consequences.
Ordinary users would access data through middleware that will return appropriate data subsets for their roles in the company. Like, not credit cards for most employees.