Critical flaw exposes Oracle database passwords 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 …
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.
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.
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."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
