LAS VEGAS – A reactive approach to software security, namely following the security research community’s lead, has proven to be a winning strategy for Oracle Corp. in recent years.
"Then Larry Ellison said his products were unbreakable. I laughed and laughed. My brother (Mark) and I had found 36 flaws within 24 hours of the announcement."
Since 2008 the database giant has steadily trimmed the number of critical buffer-overflow vulnerabilities in the Oracle database server. Longtime thorn David Litchfield, however, may have forced Oracle to reassess its software security strategy after his talk Thursday at the 2012 Black Hat Briefings.
Litchfield demonstrated several working exploits against the Oracle database server’s indexing architecture, low-hanging fruit that Litchfield said has largely been ignored by attackers and Oracle—until now.
Litchfield, one of the industry's top database security consultants, demonstrated several proof-of-concept attacks, during which he was able to elevate his privileges to the DBA level, giving him the ability to manipulate database indexing records remotely via SQL injection.
Three of the exploits he demonstrated were able to beat vulnerabilities reported and patched as long as two years ago: CVE-2010-0902 (an unspecified OLAP vulnerability), CVE-2010-3512 (an unspecified Core RDBMS component vulnerability) and CVE-2012-0552 (an unspecified Oracle Spatial component vulnerability). He also demonstrated another exploit against an unpatched vulnerability that has been reported to MITRE Corp.'s Common Vulnerabilities and Exposures database (CVE) as well.
“If the back-end [indexing] is vulnerable, that means if you’re two years out of date with your patching, which is a common situation, then we can exploit this to gain DBA privileges by creating an index as PUBLIC,” Litchfield said. By creating the PUBLIC index, anyone -- even users accessing the database via a Web application -- would have DBA privileges.
“The difficulty is that it has to be a deterministic function,” Litchfield said. “So, for example, we can’t just use an auxiliary inject function directly because they’re non-deterministic. So there are a couple more hurdles.”
Database indexes help DBAs sort through what could be trillions of records looking for a particular piece of data. No one in the research community has looked at the security of the index architecture to a large degree, and to an equally large degree, databases remain unpatched.
More from Black Hat 2012
For all the news, analysis, commentary and video interviews from Las Vegas, visit SearchSecurity.com's 2012 Black Hat special coverage page.
Far too few organizations are willing to take a database offline for security patching for fear of impacting availability or data corruption. According to a Sentrigo survey from several years ago, two-thirds of Oracle DBAs said they never apply security patches. A more recent survey by the Independent Oracle Users Group (IOUG) similarly found organizations' interest in applying database security patches to be lukewarm at best.
Litchfield said organizations should be up to date with patching, and pointed to his exploit demo on the unpatched vulnerability as an example of how simple it could be for an attacker with access to create an index, run what he called a second order SQL injection attack and gain system privileges that would enable the attacker to set his role as DBA.
“It’s trivial,” Litchfield said in describing what it would take for someone knowledgeable to execute such an attack.
Litchfield has long been poking into database security, focusing initially on stack buffer-overflow vulnerabilities. He discovered the flaw that was eventually exploited by the SQL Slammer worm; Litchfield presented information on the vulnerability at Black Hat 2002, including shell code that demonstrated the seriousness of the flaw. Less than six months later, Slammer emerged and Litchfield said the attacker used his code as a template for Slammer.
“It caused me to call into question what I was doing,” Litchfield said. “Then Larry Ellison said his products were unbreakable. I laughed and laughed. My brother (Mark) and I had found 36 flaws within 24 hours of the announcement. It was really silly stuff too, like using a long username to cause a stack overflow.”