Critical flaw exposes Oracle database passwords
Vuln leaves barn door open to brute-force attacks
Agentless Backup is Not a Myth
A security researcher says some versions of the Oracle database contain a vulnerability so serious that anyone with access to the server over a network can crack database passwords using a basic brute-force attack, given nothing more than the name of the database and a valid username.
"This is a critical issue because it's very easy to exploit, and it doesn't require any privileges," AppSec's Esteban Martinez Fayó said in an interview with Dark Reading.
According to a report issued on Thursday by Kaspersky Labs' Threatpost, the vulnerability stems from a fundamental flaw in the logon authentication protocol used by Oracle Database 11g Releases 1 and 2.
Normally, Oracle databases maintain connections with clients by issuing each a unique value known as a Session Key. But affected versions of Oracle 11g send the Session Key before the user is fully authenticated. As a result, an attacker can send a username, receive a Session Key, then hang up the connection and use the Session Key to guess the user's password.
"The attacker can perform a brute force attack on the Session Key by trying millions of passwords per second until the correct one is found," Fayó said, adding, "This is very similar to a SHA-1 password hash cracking."
According to Fayó, he and his team first alerted Oracle to the bug in May 2010. It was fixed in mid-2011, he says, but the patch was not included in a Critical Patch Update, and it only solved the problem by issuing a new, incompatible version of the authentication protocol, version 12.
Even when the patch is applied to a database, it will still use version 11.1 of the protocol by default. To get up and running with version 12, database servers and clients must both be patched, which means a large number of organizations are still using version 11.1 – and are therefore still vulnerable.
According to Fayó, Oracle currently has no plans to patch version 11.1 of the protocol to fix the flaw, and they aren't doing much to help customers migrate to version 12, either.
"The only comment from them was a paragraph about a new protocol fixing some security issues," he said. "They haven't said anything that made people aware to update the database and all of the database clients."
Mind you, brute-force attacks are not the easiest way to crack a password, since they essentially involve exhausting every possible combination of characters until the right combination is found. And Fayó says advanced cracking techniques, such as rainbow tables, can't be used to exploit this vulnerability, because of the way Oracle's cryptography is designed.
Still, he says, GPU acceleration and hybrid dictionary attacks can speed up the process of guessing passwords considerably, and Fayó has developed a proof-of-concept attack that can crack eight-character Oracle passwords in around five hours using standard CPUs.
In lieu of a fix from Oracle, Fayó recommends several work-arounds. One is to wrap database connections in some additional form of authentication, such as SSL or directory services. Another is to disable version 11.1 of the authentication protocol altogether and use an earlier version, such as 10g, which isn't vulnerable. ®
COMMENTS
Re: Except...
Password lockouts are not relvant anyway. The problem is worse than that! "potential attackers only require the name of a user and that of a database file; they can then abort communication with the server and launch a brute-force attack on the password offline. This method does not cause any failed log-in attempts to be recorded in the log files."
Re: They what?
The description isn't entirely clear, but it looks like when someone sends them a user name they send back the password salt and something from which the password hash can be deduced.
How could anyone think that was a good idea? It's mind-bogglingly stupid.
Like many broken cryptographic protocols, it's probably too-clever-by-half rather than anything that's obviously stupid to someone who isn't trained in security.
My guess (I haven't looked at the exploit in depth, just glanced over the interviews) is that the protocol includes sending the salt from the server to the client so that the client can generate a proof (that the client knows the password) that doesn't include the password itself, and that the server can verify. That's a mistake, but it's the sort of mistake that people who aren't security experts make when they're faced with the question "how do we avoid sending the password from the client to the server?".
That first mistake is then compounded by giving the client something it can use to verify the password+salt, in the session information. But leaking the salt was already bad. (An attacker with a list of valid usernames could probe the server for salt values in use, then compile an offline dictionary of likely passwords hashed with just those salts. It expands the dictionary but only by a factor of N, where N is the number of users.)
Oracle should have used a safe verification method that didn't require exchanging the salt. Zero-knowledge proof protocols like SRP and PAK-RY are one possibility. I think you could also build something with a one-way accumulator and a nonce (server holds V=OWA(P,S); server sends client random nonce N; client sends server evidence E=OWA(P,N); server compares OWA(V,N) and OWA(E,S)), but I don't know of any research into such a protocol. Most people seem to simply fall back on encrypting the session between client and server and letting the client send the password, so they can put the responsibility for protecting authentication on the "secure" channel between the two; there are all sorts of problems with that but it's one way to make it Someone Else's Problem.
Re: Except...
The details in the links say that there aren't any failed logins.
They send the user name, get back the information needed to hack the password, then drop the connection. So there's no login attempt at all, and apparently nothing gets recorded.
They break the password offline, then do a successful login.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
