Remote stealth pass brute force
Last updated
Was this helpful?
Last updated
Was this helpful?
The versions 11.1.0.6, 11.1.0.7, 11.2.0.1, 11.2.0.2, and 11.2.0.3 are vulnerable to this technique. In order to understand the idea behind this vulnerability, you need to consider how the authentication protocol works with the database. I will show it for version 11. The interaction with the server proceeds as follows:
The client connects to the server and sends the user name.
The server generates a session identifier (‘AUTH_SESSKEY’) and encrypts it by using AES-192. As its key, the system uses SHA-1 hash generated from user password and salt (‘AUTH_VFR_DATA’).
The server sends an encrypted session ID and salt to the client.
The client generates the key by hashing its password and received salt. The client uses this key to decrypt the session data received from the server.
Based on decrypted server session ID, the client generates a new public key for future use.
Now, here’s the most interesting part: The session ID ‘AUTH_SESSKEY’ sent by the server to the client has a length of 48 bytes. Of these, 40 bytes are random, and the last 8 are the duplicates of ‘0x08’. The initialization vector is 0x00 (Null). Knowing that the last 8 bytes of the public identifier always consist of ‘0x08’, we can bruteforce this password and, moreover, do it in offline mode, which means a tremendous speed, especially if you use GPU. To mount an attack, you need to know SID, valid login (for example, ‘SYS’ account is very interesting) and, of course, have the ability to connect to the database. In this case, there will be no records, such as ‘Invalid Login Attempt’, created in the Oracle audit logs!
Summing it all up:
Use Wireshark to intercept the initial traffic during authorization. This will be helped by ‘tns’ filter.
Extract HEX values for AUTH_SESSKEY, AUTH_VFR_DATA.
Insert them into **[PoC script**](), which will perform a dictionary (brute force) attack.