Oracle Database Redaction Trivial To Bypass, Says David Litchfield 62
Posted
by
timothy
from the let-me-ask-that-another-way dept.
from the let-me-ask-that-another-way dept.
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"? (Score:3)
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"? (Score:5, Insightful)
Re:Is the target "hackers"? (Score:5, Informative)
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"? (Score:4, Insightful)
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: (Score:3)
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: (Score:3)
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 (Score:2)
Shouldn't you "mask" sensitive data by putting it into a separate table with stricter access privileges.
Re:Put in a separate table (Score:5, Insightful)
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: (Score:3, Funny)
/users.html
Re: (Score:2)
Re: (Score:2)
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 (Score:5, Informative)
Re: (Score:1)
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 (Score:5, Interesting)
Re: (Score:3)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:1)
How exactly can you "re-hash" the CC number if you don't store it somewhere?
Re: (Score:2)
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: (Score:1)
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: (Score:2)
That would make the hash just an alternate cc number with no security benefit.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Monthly recurring charges require the plaintext CC number. They could encrypt the ccnumber (and probably should) but they can't just hash it.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
That is to say that sensitivity is a spectrum, not a Boolean status?
Encrypt it (Score:2)
Finally an exploit that simulates the movies! (Score:1)
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 (Score:2)
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... (Score:4, Interesting)
Re: (Score:2)
Re:In the industry... (Score:5, Insightful)
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 (Score:2)
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: (Score:1)
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.