Oracle Authentification with a long password (>16 characters)

[k4amos]

In an authentication with an Oracle database, the size of AUTH_PASSWORD will change if the password length exceeds 16 characters, as explained here.
@magnumripper had proposed in this issue #2155 (comment) to add a field with the size of Auth_PASSWORD at the end of the hash, but unfortunately this option doesn't seem to be implemented.

Is there a way to break these hashes with john?

[solardiz]

I skimmed those referenced issues now, and I think this should just work. Have you tried? Unfortunately, we don't seem to have a test vector with a long password - it would be good to add one - maybe you'd contribute that?

add a field with the size of Auth_PASSWORD at the end of the hash, but unfortunately this option doesn't seem to be implemented.

As I understand, this was determined to be unnecessary and redundant - the length is determined from the hex encoding length of the existing field.

[k4amos]

Hi solardiz,
I have provided an example of o5logon authentication with a password longer than 16 characters password1234567890 in this pull request: openwall/john-samples#28
Here is the expected format of the hash to crack with john :

$o5logon$ <server's AUTH_SESSKEY> * <AUTH_VFR_DATA> * <AUTH_PASSWORD> * <client's AUTH_SESSKEY>

Here is what we have in the pcap sample :

<server's AUTH_SESSKEY> --> 4D04DBD23D103F05D9B57EB6EC14D83A0A468AB906EAC907D3A8C796573E5F34BC15F0ECBC9EAC0350A38A663A368233
<AUTH_VFR_DATA> --> 442192E518F6F43D7CF7
<AUTH_PASSWORD> --> D3963B6AAED39C231BD5C92A10C0F146CA4784D1503A9B97598B31D33406390B7CA4F8B3EE5406A54C1842E4E63D1220
<client's AUTH_SESSKEY> --> 192AB7C9BA21C883824CF3D5BA073AC1129FD841E0AF6DF522C7EBDC52783CB8B97B792BFB6D9D743C7F4376FF0E7F93

Here is the obtained hash that we should be able to crack with john (but it doesn't work):

$o5logon$4D04DBD23D103F05D9B57EB6EC14D83A0A468AB906EAC907D3A8C796573E5F34BC15F0ECBC9EAC0350A38A663A368233*442192E518F6F43D7CF7*D3963B6AAED39C231BD5C92A10C0F146CA4784D1503A9B97598B31D33406390B7CA4F8B3EE5406A54C1842E4E63D1220*192AB7C9BA21C883824CF3D5BA073AC1129FD841E0AF6DF522C7EBDC52783CB8B97B792BFB6D9D743C7F4376FF0E7F93

This issue only occurs with passwords longer than 16 characters.
Once this issue is resolved, I will probably contribute to add the oracle2john.py file.

[solardiz]

Thank you very much @k4amos!

I see this hash doesn't even get loaded, are you seeing the same?

Once this issue is resolved, I will probably contribute to add the oracle2john.py file.

This would be a welcome contribution. We also seem to lack documentation for how to proceed without such program currently. I only found that john-samples/Oracle_O5LOGON/README.md says Use Ettercap to get JtR compatible hashes from .pcap files. but that's not in this repo and it doesn't say how exactly to use Ettercap. So maybe you could contribute such documentation as well.

[solardiz]

This makes it work, but I have no idea why the check was that way before and so whether the patched check is correct or not:

+++ b/src/o5logon_fmt_plug.c
@@ -131,7 +131,7 @@ static int valid(char *ciphertext, struct fmt_main *self)
        if ((p = strtokm(NULL, "*"))) { /* client's encrypted password */
                int len = hexlenu(p, &extra);
 
-               if (extra || len < 64 || len % 32 || len > 2 * PLAINTEXT_LENGTH + 16)
+               if (extra || len < 64 || len % 32 || len > 3 * PLAINTEXT_LENGTH)
                        goto err;
                if ((p = strtokm(NULL, "*")) == NULL)   /* client's sesskey */
                        goto err;

[k4amos]

Hi solardiz, thank you, that's indeed what fixes the bug. I don't know why it was implemented that way.