There is a serious vulnerability in the authentication protocol used by some Oracle databases, a flaw that could enable a remote attacker to brute-force a token provided by the server prior to authentication and determine a user’s password. The attacker could then log on as an authenticated user and take unauthorized actions on the database. The researcher who discovered the bug has a tool that can crack some simple passwords in about five hours on a normal PC.
The vulnerability exists in Oracle Database 11g Releases 1 and 2 and is caused by a problem with the way the authentication protocol protects session keys when users try to log in. The first step in the authentication process when a client contacts the database server is for the server to send a session key back to the client, along with a salt. The vulnerability enables an attacker to link a specific session key with a specific password hash.
“This Session Key is a random value that the server generates and sends as the initial step in the authentication process, before the authentication has been completed. This is the reason why this attack can be done remotely without the need of authentication and also, as the attacker can close the connection once the Session Key has been sent, there is no failed login attempt recorded in the server because the authentication is never completed,” said Esteban Martinez Fayo, a researcher at AppSec Inc., who discovered the flaw and will discuss it at the Ekoparty conference Thursday.
“Once the attacker has a Session Key and a Salt (which is also sent by the server along with the session key), 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. This is very similar to a SHA-1 password hash cracking. Rainbow tables can’ t be used because there is a Salt used for password hash generation, but advanced hardware can be used, like GPUs combined with advanced techniques like Dictionary hybrid attacks, which can make the cracking process much more efficient.”
Fayo found the bug after noticing that there was an inconsistency in the way that clients and database servers handled failed log-in attempts. He found that log-in attempts with incorrect passwords were handled differently by the client than by the server and started looking more closely at why that was.
“Basically, I discovered that not all failed login attempts were recorded by the database. Looking closer at the issue, I located the problem in the way that one of the components of the logon protocol, the Session Key, was protected. I noticed that, in a certain way, the Session Key was leaking information about the password hash,” he said.
Fayo said that Oracle has released a new version of the authentication protocol, version 12, which fixes this problem. However, he said that Oracle is not planning to fix the bug in version 11.1 of the protocol, and that even after applying the patch that includes the updated protocol, database servers are still vulnerable by default. Administrators need to change the configuration of the server in order to only allow the new version of the protocol.
Because the vulnerability is in a widely deployed product and is easy to exploit, Fayo said he considers it to be quite dangerous.
“The Oracle stealth password cracking vulnerability is a critical one. There are many components to affirm this: It is easy to exploit, it doesn’t leave any trace in the database server and it resides in an essential component of the logon protocol,” he said.
“It is very simple to exploit. The attacker just needs to send a few network packets or use a standard Oracle client to get a Session Key and Salt for a particular user. Then, an attack similar to that of cracking SHA-1 password hash can be performed. I developed a proof-of-concept tool that shows that it is possible to crack an 8 characters long lower case alphabetic password in approximately 5 hours using standard CPUs.”
In addition to–or in lieu of–the patch, Fayo said database administrators also could mitigate the effects of the vulnerability by requiring external authentication or disabling the Oracle logon protocol version 11 on the server.
