Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Oracle Database Redaction Trivial To Bypass, Says David Litchfield

timothy posted about 3 months ago | from the let-me-ask-that-another-way dept.

Oracle 62

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

Sorry! There are no comments related to the filter you selected.

Is the target "hackers"? (2)

i kan reed (749298) | about 3 months ago | (#47622589)

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"? (0)

Anonymous Coward | about 3 months ago | (#47622627)

If your bottom feeder DBA's are accidentally exposed to it, bank on your competitors hacking crew downloading and exploiting it.

Re:Is the target "hackers"? (4, Insightful)

Jaime2 (824950) | about 3 months ago | (#47622781)

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"? (5, Informative)

Sockatume (732728) | about 3 months ago | (#47622863)

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"? (3, Insightful)

i kan reed (749298) | about 3 months ago | (#47622923)

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

Anonymous Coward | about 3 months ago | (#47624005)

you mean Quis custodiet ipsos custodes? [wikipedia.org]

The answer is Sam Vimes.

Re:Is the target "hackers"? (2)

greg1104 (461138) | about 3 months ago | (#47623677)

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 contract. "We pay for a license so we have someone to sue if things go wrong" is my favorite of the silly things some people say when advocating commercial software. Only in Soviet Russia do you sue Oracle.

Re:Is the target "hackers"? (2)

TheCarp (96830) | about 3 months ago | (#47624361)

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, even if its unreasonable for them to.

Re:Is the target "hackers"? (0)

Anonymous Coward | about 3 months ago | (#47625495)

I mean it sounds like this is just to protect sensitive data from the day-to-day work of your regular old DBAs.

I always thought Bob in the database group was shifty looking,

Put in a separate table (1)

wiredlogic (135348) | about 3 months ago | (#47622609)

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

Re:Put in a separate table (4, Insightful)

boristdog (133725) | about 3 months ago | (#47622669)

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:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622707)

User convenience? Most sites do this so you don't have to type your credit card number every time you buy something

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622847)

So in your world, user convenience has higher priority than security? Why not post all data for all users on /users.html. That's convenient. Users can find their passwords right there if they forget them.

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622927)

In your world, where the fuck does the bank store your credit card number?

Re:Put in a separate table (3, Funny)

davester666 (731373) | about 3 months ago | (#47623907)

/users.html

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47627565)

You'll find that in The Real World, convenience trumps security the vast majority of the time.

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47625535)

As someone who works in an industry that makes heavy use of stored credit cards, I can tell you this: You don't need to store the card number *at all*, encrypted or not. We collect the credit card number once, obtain a proxy value for the card, and store the proxy, the encrypted expiration date, and the plaintext last four of the card. We don't even store the hashed card number. We do payment card transactions with nothing more than this *all fricking day long*, fully within PCI regulations, and the only portion of our code that is required to be audited is the proxy API.

At *worst*, the customer has to enter the CVV number at time of purchase, and not even always that (we don't store the CVV in any form).

Re:Put in a separate table (1)

Jaime2 (824950) | about 3 months ago | (#47622713)

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:Put in a separate table (1)

boristdog (133725) | about 3 months ago | (#47622809)

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 (5, Informative)

Jaime2 (824950) | about 3 months ago | (#47622897)

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:Put in a separate table (1)

Anonymous Coward | about 3 months ago | (#47622915)

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 (4, Interesting)

Zero__Kelvin (151819) | about 3 months ago | (#47623003)

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:Put in a separate table (2)

bws111 (1216812) | about 3 months ago | (#47623081)

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:Put in a separate table (1)

boristdog (133725) | about 3 months ago | (#47623183)

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:Put in a separate table (1)

Zero__Kelvin (151819) | about 3 months ago | (#47623577)

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:Put in a separate table (1)

bws111 (1216812) | about 3 months ago | (#47624703)

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:Put in a separate table (1)

Jaime2 (824950) | about 3 months ago | (#47626835)

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:Put in a separate table (1)

boristdog (133725) | about 3 months ago | (#47623175)

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 used a system like this for processing financial data (not CC data) to keep the data associating account numbers with passwords as difficult as possible to breach. Both the account number and password are hashed. We would change the salts at the broker end every 3 to 5 weeks and keep a record of the past two salts in case some broker equipment didn't get the last update. So if our DB got hacked we didn't have to make everyone change their password or account number.

As far as I know they are still using that system.

Re:Put in a separate table (1)

Zero__Kelvin (151819) | about 3 months ago | (#47623367)

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

Re:Put in a separate table (1)

Anonymous Coward | about 3 months ago | (#47624843)

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

Re:Put in a separate table (1)

bws111 (1216812) | about 3 months ago | (#47625225)

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 whole world! No economic harm from that, no indeed.

Re:Put in a separate table (1)

aix tom (902140) | about 3 months ago | (#47623709)

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:Put in a separate table (1)

sjames (1099) | about 3 months ago | (#47623895)

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

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622719)

There are third-party systems that you may need to integrate with that need the data. You can't just say "hash the SSN". If you need to send an EDI transaction to the IRS, you need the SSN.

If there were simply solutions to this, they would have been done a long time ago. Perhaps the world is just a bit more complex and less perfect that what your life experiences would lead you to believe.

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622859)

Do like every other sane developer does: Compare the hash of the user entered SSN to the hash you've stored for that user. If it matches, submit it. Save yourself the embarrassment of a huge privacy leak, and just do this please.

Re:Put in a separate table (1)

bws111 (1216812) | about 3 months ago | (#47623151)

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:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47623173)

No sane developer does this, because it is worthless. The SSN IS the identifier of the user.

Sorry, but no competent developer should be using the SSN as the ID of the user.

Most places shouldn't even be using it at all.

Re:Put in a separate table (1)

Zero__Kelvin (151819) | about 3 months ago | (#47623605)

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

Re:Put in a separate table (1)

mjwalshe (1680392) | about 3 months ago | (#47623237)

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:Put in a separate table (1)

boristdog (133725) | about 3 months ago | (#47622879)

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 just one of them. The Peter Principle is in full force if you work in government.

Re:Put in a separate table (1)

CastrTroy (595695) | about 3 months ago | (#47622939)

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:Put in a separate table (1)

bws111 (1216812) | about 3 months ago | (#47622987)

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:Put in a separate table (1)

boristdog (133725) | about 3 months ago | (#47623231)

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 remedies to large data breaches here, not single experiences. Yes, your data is at risk while your tax form is in the mail or in the hands of an IRS employee, but as soon as it goes into the DB the associative data should be hashed. You don't eliminate breaches this way, you make them easier to deal with.

Re:Put in a separate table (1)

Zero__Kelvin (151819) | about 3 months ago | (#47623643)

"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:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622791)

Except hashing isn't a viable solution for those who might actually have to do something with that data, rather than just verify it. For PIN's and passwords, there are darn few scenarios where you will NOT want to hash it. Credit card numbers and SSN's may need to be used. A credit card number may need to be reused for recurring billing arrangements. An SSN may be needed for financial reporting purposes.

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47622941)

What use would hashing a PIN be, if an attacker could feasibly exhaust the search space of it? As soon as your PIN becomes unlimited in length and allows alpha characters, it becomes a password...

Re:Put in a separate table (2)

Capslock118 (936446) | about 3 months ago | (#47622901)

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:Put in a separate table (1)

hawkinspeter (831501) | about 3 months ago | (#47622949)

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

Re:Put in a separate table (0)

Anonymous Coward | about 3 months ago | (#47623247)

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?

WUT?!?!?!?!

How the hell would your bank know your credit card number then?

You: "I lost my credit card."
Bank: "Umm, what was the number on it?"

Jeez. Grow a brain.

Re:Put in a separate table (1)

sjames (1099) | about 3 months ago | (#47623881)

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

Re:Put in a separate table (1)

cheater512 (783349) | about 3 months ago | (#47627463)

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:Put in a separate table (1)

thieh (3654731) | about 3 months ago | (#47622677)

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

Re:Put in a separate table (1)

i kan reed (749298) | about 3 months ago | (#47622701)

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

Encrypt it (1)

mjwalshe (1680392) | about 3 months ago | (#47623217)

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

Finally an exploit that simulates the movies! (1)

Anonymous Coward | about 3 months ago | (#47622655)

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 (1)

raymorris (2726007) | about 3 months ago | (#47622763)

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... (4, Interesting)

phillk6751 (654352) | about 3 months ago | (#47622787)

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:In the industry... (1)

Jaime2 (824950) | about 3 months ago | (#47622833)

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... (4, Insightful)

Rob Riggs (6418) | about 3 months ago | (#47623373)

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.

Re:In the industry... (0)

Anonymous Coward | about 3 months ago | (#47624739)

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

I work in IT in the pharma industry. I know for a fact this has been used to "sanitize" databases of privacy, PCI and HIPAA data to make databases usable for validation purposes. Decisions approved by very senior developers and managers because it was quick, easy, and cheap.

Missing the point (1)

iamacat (583406) | about 3 months ago | (#47623637)

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.

Re:Missing the point (1)

Anonymous Coward | about 3 months ago | (#47624713)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?