News

Oracle's data redaction security feature riddled with flaws

Brendan Blevins

A security researcher long known as a thorn in Oracle's side has detailed rudimentary vulnerabilities in a security feature present in one of the company's flagship products, which he said serves as a reminder that the company takes a haphazard approach to security.

At the Black Hat USA 2014 conference, database security expert and renowned bug hunter David Litchfield set about demonstrating some of the many flaws he recently uncovered in

Requires Free Membership to View

data redaction -- a security feature that Oracle has touted in Oracle Database 12c, the latest version.

Data redaction essentially serves as a way to mask sensitive information, so when a database query is returned that contains sensitive information such as Social Security numbers, credit card numbers and other personally identifiable information, that data is replaced by X's if it falls within a specific column. Data outside the redacted columns is returned as normal.

Data redaction is actually a "great idea", Litchfield said, but unfortunately, the feature is so thoroughly riddled with basic security flaws that it is trivial for attackers to bypass it.

"If Oracle had followed [Microsoft's security development lifecycle], the flaws I'm going to be speaking about would have been caught," said Litchfield. "The stuff I'm going to talk about is not rocket science. No one should be releasing this stuff in their flagship product."

A security researcher long known as a thorn in Oracle's side has detailed rudimentary vulnerabilities in a security feature present in one of the company's flagship products, which he said serves as a reminder that the company takes a haphazard approach to security.

At the Black Hat USA 2014 conference on Wednesday, database security expert and renowned bug hunter David Litchfield set about demonstrating some of the many flaws he recently uncovered in data redaction -- a security feature that Oracle has touted in Oracle Database 12c, the latest version.

Data redaction essentially serves as a way to mask sensitive information, so when a database query is returned that contains sensitive information such as Social Security numbers, credit card numbers and other personally identifiable information, that data is replaced by X's if it falls within a specific column. Data outside the redacted columns is returned as normal.

Data redaction is actually a "great idea", Litchfield said, but unfortunately, the feature is so thoroughly riddled with basic security flaws that it is trivial for attackers to bypass it.

"If Oracle had followed [Microsoft's security development lifecycle], the flaws I'm going to be speaking about would have been caught," said Litchfield. "The stuff I'm going to talk about is not rocket science. No one should be releasing this stuff in their flagship product."

Litchfield then set about giving a live demo of the flaws he had discovered, some of which were documented in a recent paper. The first method is to use the "RETURNING INTO" clause after a DML operation, which allows data to be returned into a variable -- a failure on Oracle's part that he said would have been discovered by conducting a penetration test.

Another flaw could allow attackers to access data in a "SELECT'S WHERE" clause by brute-forcing numbers through an iterative inference attack, basically setting a range of numbers that can be guessed until the correct one is returned. Litchfield demonstrated how attackers utilizing such a method could easily obtain a credit card number in a matter of seconds, as they would only need to go through a range of zero to nine for nine numbers.

In cases where a column is automatically updated, Litchfield said it was even possible to update the ID column with the same value -- meaning not really making an update at all -- which returns unmasked data.

"Anyone that works at Oracle for the last year and understands SQL should have spotted [these flaws]," said Litchfield.

Oracle not learning decade-old security lessons

Litchfield said his presentation on data redaction flaws was meant not only to document current Oracle security issues, but also to reinforce that the company seemingly refuses to learn the long-accepted security lessons.

On January 15, 2002, then-Microsoft Chairman Bill Gates sent out his now-famous Trustworthy Computing memo to employees of the Redmond, Washington-based software giant, in which he emphasized the importance of building more security products after the company had been battered by numerous vulnerabilities in previous years. That memo resulted in the creation of Microsoft's security development lifecycle and a steady decline in the number and severity of bugs in products such as Microsoft SQL Server.

Just months before Gates' memo, Oracle CEO Larry Ellison said that his company's products were "unbreakable" as part of a marketing campaign, an unwise move that immediately drew the attention of hackers like Litchfield and resulted in the number of vulnerabilities being spotted in Oracle's software to soar.

Litchfield said that the difference between Gates' memo and Ellison's unbreakable claims laid the groundwork for Microsoft's stringent approach to security, at least on the server side, and Oracle's flailing security tactics. Litchfield recounted numerous instances where he discovered a vulnerability in an Oracle product, dutifully reported it to the Redwood City, California-based company, then waited months for a patch that, when delivered, could be bypassed just as easily as before.

And still, despite Litchfield and other researchers picking apart Oracle's code for more than a decade, Oracle's Ellison said in January that the company's database product "hadn't been broken into for a couple of decades by anybody" -- a claim that Litchfield said Ellison should have known was untrue because an Oracle database was at the heart of the PlayStation Network breach, one of the most famous security incidents in recent memory.

As embarrassingly easy as those data redaction flaws are to exploit, Litchfield warned that they are just the tip of the iceberg when it comes to Oracle's security issues. He added that he currently knows of an undisclosed critical flaw that stems from a database setting that would allow an attacker to gain full system admin privileges, but when he queried Oracle about the setting, the company couldn't even explain why it existed.

"It's scary that there is no documentation internally as to why this setting has been made," said Litchfield.

Litchfield closed by noting that there are likely more methods for bypassing data redaction than he hadn't discovered, and considering that a product like Oracle Fusion comes in a 72 GB package -- which translates into a huge attack surface -- he said other Oracle products are probably suffering from similar issues. As a result, Litchfield said that Oracle's enterprise customers should heed the advice previously delivered by Oracle's own chief security officer and vote with their checkbooks.

"We're in the year 2014, and they're still not learning the lessons that people learned in 2002," he said. "I'm using data redaction as proof they haven't made any improvements."