back to article 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 very …

COMMENTS

This topic is closed for new posts.
FAIL

Big shocker that

Guarantee you: 95% of the time the user and password are both "apps" so it's a one-pass brute force attack.

Fail because that best describes the whole "ecosystem" surrounding this boutique sailboat manufacturer posing as a software giant.

0
0
Bronze badge
Mushroom

Re: Big shocker that

A good reason to use SQL server. Only a couple of security vulnerabilities in the last decade versus hundreds for Oracle.....

0
2
Silver badge
WTF?

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.

0
0
Silver badge

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.

1
0

Oracle customers...

Oracle customers have already licensed the product and paid the support fee. There is nothing else to give them without making them pay again.

0
0
Anonymous Coward

Except...

... Oracle by default locks a users account after 3 failed logins.

0
0
Silver badge
Headmaster

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.

1
0
Bronze badge

Re: Except...

But nearly every production database has this turned off, since no DBA wants to wake up at 2 AM to unlock an account on a prod database because of a few failed logons.

0
0
Bronze badge
Mushroom

Re: Except...

Or they ditch the Oracle crap and use AD integration - and then set a sensible account lockout time - like 15 minutes...

0
2
Bronze badge
Mushroom

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."

2
0
This topic is closed for new posts.

Forums