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."

Is the target "hackers"?

[i kan reed]

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.

Re:Is the target "hackers"?

[Jaime2]

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.

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:Is the target "hackers"?

[i kan reed]

It's the same rule for computers as other systems:

At some level you have to trust the people who run your systems. Quis cosdet ipsos custodes, ya know?

Re:

[greg1104]

That does highlight this feature is ultimately intended to provide extra security for regular users; it's not targeted at administrators at all. When the "hack" to bypass the feature is so simple, functionally that means that Oracle Data Redaction drops to no extra query level security whatsoever in the fact of things of SQL injection. If I were an Oracle customer, I'd ask for a refund plus significant damages.

I'll admit it: just saying that made me laugh. Good luck with that lawsuit given their license

Re:

[TheCarp]

Except "We pay for a license so we have someone to sue" really means "we want someone to blame". You are right, the idea of an actual lawsuit over anything anyone says that about is true.... however, they will use the someone to blame, both to their customers, and for employees to their managers, managers to their directors etc.

What its really comes down to is they want to be able to say "We are working with support right now" so they don't have to take the heat for not knowing what the issue is right away,

Put in a separate table

[wiredlogic]

Shouldn't you "mask" sensitive data by putting it into a separate table with stricter access privileges.

Re:Put in a separate table

[boristdog]

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?

Re:

[davester666]

/users.html

Re:

[Jaime2]

How would a hashed credit card number ever be useful? You would have a really hard time sending a request for payment to a payment processor if you did.

Re:

[boristdog]

Ideally, the payment processor is the only one who has the hash, the merchant passes the hash they made from customer data on to the processor.
The payment processor doesn't even need to have the CC#. They just need the hash.

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.

Re:

[Anonymous Coward]

Then what's the difference at this point from storing the data in plaintext? If all you do is make sure the hashes match, then all you need are the hashes to commit fraud.

Re:Put in a separate table

[Zero__Kelvin]

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.

Re:

[bws111]

Exactly. Look at it this way: your credit card number already IS a hash of your and your banks identities. That doesn't magically make it secure.

Re:

[boristdog]

BUT you can change the salt, or the hashing algorithm, in case of a breach. You don't have to replace all the CCs, just send out a new salt to the machines. Now the data lost in the breach is useless.

Re:

[Zero__Kelvin]

And how, prey tell, do you plan on calculating the hashes with the new salt? Or did you forget that you only store the hash in your absurd scenario?

Re:

[bws111]

OK, so company 'A' gets hacked and all of their saved credit card information is breached. No problem (according to you), just change the salt! Presto magico, nobody can use the information that was stolen. Which means that EVERY stored credit card number (now 'hash') is invalid, everywhere. Not just compromised cards, every single one. Every recurring payment is invalid. Every pending payment is invalid. Great idea.

Re:

[Jaime2]

The number of possible valid credit card numbers is so small that any hashing solution can be brute forced very quickly, even if each record has its own salt. The only protection would be to make the algorithm secret, but then you've just reduced your system to security by obscurity and as soon as someone figures out the algorithm, you're toast.

Re:

[boristdog]

It's not foolproof, but it is easy to fix a breach. If your CC database gets hacked, you re-hash with a different salt and then send the new salt to the pre-processors, so the hash they send you is now completely different. That way you have effectively changed everyones CC # a lot quicker and easier than sending everyone a new card. If fact, regular re-hashing should be a standard in the CC industry. You keep the same card and card number but the number in the DB will change regularly.

I've actually use

Re:

[Zero__Kelvin]

Please just accept that you don't understand computer security and get on with your life.

Re:

[Anonymous Coward]

How exactly can you "re-hash" the CC number if you don't store it somewhere?

Re:

[bws111]

You have indeed 'changed everyones CC#'. EVERYONE. For ALL CARDS. Every single stored CC number is now useless. Every recurring payment will fail. What an absolutely great opportunity for phishing. Every week or so you can expect to receive a 'there is a problem with your account, please log on and re-enter your CC information, this is for your security' letter. Wonderful.

Joe's Hot Dog shopped got hacked and a few thousand CC numbers were compromised. Let's invalidate every stored CC number in the w

Re:

[aix tom]

Ideally, the payment processor is the only one who has the hash, the merchant passes the hash they made from customer data on to the processor.
The payment processor doesn't even need to have the CC#. They just need the hash.

And where does the customer store that data? Or the printing company that prints the number on the credit card?

Also, if "the hash is all that is needed" when sending something to the payment processor, then you would have the same problems in the long run when you "store the hash" that you have now when you "store the credit card number".

Re:

[sjames]

That would make the hash just an alternate cc number with no security benefit.

Re:

[bws111]

No sane developer does this, because it is worthless. The SSN IS the identifier of the user. Without the SSN, you have no idea who the user is. Use the hash instead of the SSN? Now the hash is exactly as sensitive as the SSN was in the first place. You have added unnecessary complications and have provided zero improvement in security.

Re:

[Zero__Kelvin]

Nobody said to use the SSN as the Primary Key, or what you as a layperson call "the ID".

Re:

[mjwalshe]

Outside of a small number of applications No sane developer uses SSN numbers - I worked for a large company one and we collectively where read the riot s act about misusing NI numbers with the implication that it was a severe disciplinary offence to use them out side of a tiny number of use cases.

Re:

[boristdog]

Surprisingly enough, I used to work at the IRS and still have many friends who do.

We could hash all SSN/EIN data at the IRS and just deal with hashes, but the entrenched management there still does everything the old way. Why can't the EDI transaction just hash the SSN and have the IRS compare the hashes at the IRS end? Because the highly political management is too stupid to understand this.

There are many reasons I have left cushy gov't jobs, the lack of technological understanding by the higher ups is j

Re:

[CastrTroy]

It would be trivially easy to build a rainbow table anyway. And it couldn't even be salted, because the IRS and the communicating systems would have to agree on a salt, which would make any salt used useless. Once a rainbow table was created, any advantage you get from hashing the numbers would be useless.

Re:

[bws111]

Huh? Surely for an IRS transaction the SSN is the identifier of the person. What are you going to compare the hash with? How would you know who the person is to compare the hash with if all you have is the hash? So instead, the hash becomes the identifier, and thus becomes exactly as sensitive as the SSN was in the first place.

Re:

[boristdog]

No, the SSN is on the tax return or form, still highly insecure. The data associated with the SSN in the IRS DB is linked to the hashed SSN.
So unless someone actually has the tax form (trivial for a few forms, difficult for massive amounts of forms) they cannot associate you with your SSN or your tax data. A corrupt IRS employee (and there are many) can easily enter one SSN into their application and get all your tax & income data. But they can't download EVERYONE's data easily.

We're talking about re

Re:

[Zero__Kelvin]

"Surprisingly enough, I used to work at the IRS and still have many friends who do."

I'm not surprised at all. You have shown yourself to have a very special combination of cluelessness and arrogance that invokes images of the IRS in my head in fact.

Re:

[Capslock118]

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?

ACH processing requires sending bank account information to the ACH along with how much to bill the individual. Many other forms of automated payment processing formats also require credit card numbers sent - this is all happening with flat files. If you expect credit card numbers to be hashed in your database, then you need to convince the receiving end of that data that they do not need the source to send that data.

Re:

[hawkinspeter]

You'd need the credit card number if you need to process a credit for a customer.

Re:

[sjames]

Monthly recurring charges require the plaintext CC number. They could encrypt the ccnumber (and probably should) but they can't just hash it.

Re:

[cheater512]

Do tell me how you use a hashed credit card number? You can't give a hash to a payment gateway (arguably a major failing). Plus a hash of a credit card (known format) would be pretty easy to break.

I think you mean encrypt. Hashes are one way.

Re:

[thieh]

Or "really sensitive data" should only exist in airgapped machines incapable of being accessed from the outside world

Re:

[i kan reed]

That is to say that sensitivity is a spectrum, not a Boolean status?

Encrypt it

[mjwalshe]

Or you know encrypting it! credit card numbers should never be held en clair

Finally an exploit that simulates the movies!

[Anonymous Coward]

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!

haha. MD5 is similar

[raymorris]

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.

In the industry...

[phillk6751]

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.

Re:

[Jaime2]

They implemented it the way they did so they can sell it as a drop-in solution that requires no coding changes. Unfortunately, a security technologies don't matter as much as processes do, so this product, like all other silver-bullet products, will never be all that good.

Re:In the industry...

[Rob Riggs]

As a developer in the industry here I can honestly say nobody in our industry would be dumb enough to use this tool.

Bullshit. As a (former) developer in the industry (still a developer; no longer in the industry) I can honestly say plenty of people in your industry would be dumb enough to use this tool. Especially when some wide-eyed "Oracle DBA(sm)" tells them "I heard about it at Oracle World -- of course it's secure." Seriously -- it is not like retailers hire the best and the brightest. And virtually every online retailer I deal with keeps my CC information on file. Most of them are hard-working, understaffed developers just trying to get the job done and do the bare minimum to meet PCI compliance -- because that is what management wants.

Missing the point

[iamacat]

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 th

Re:

[Anonymous Coward]

The key here is to ensure that it remains WELL UNDERSTOOD that this is fake security, not real security.

It's like the guard on a skill saw, yes, I could get around it if I needed to, but it is there to protect me from doing a stupid thing, not to protect the saw from me. As long as it is understood that this guard doesn't protect anyone (but myself) from me, it is a good thing. Once people start treating it like a security mechanism instead of a guard, it becomes dangerous.