Oracle 18c hash_dump, JTR format not supported

[7043mcgeep]

18c not supported yet

Oracle 18c (successor of 12c) hashing is not supported by oracle_hashdump. The root cause is the different hashing of 18c (a new format, but reusing 160-bit T part).

Currently, hash formats up to Oracle 12c is supported by lib/msf/core/auxiliary/jtr.rb (module jtr_oracle_fast makes use of its hash_to_jtr function)

Explanation of 12c hashing:

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/changes-in-oracle-database-12c-password-hashes/

12c hashes look like this (full S, H, and T parts):
S:BF6D4E3791075A348BA76EF533E38F7211513CCE2A3513EE3E3D4A5A4DE0;H:3814C74599475EB73043A1211742EE59;T:0911BAC55EEF63F0C1769E816355BE29492C9D01980DC36C95A86C9CE47F93790631DE3D9A60C90451CFF152E25D9E94F612A1493EC82AF8E3C4D0432B06BA4C2C693B932332BC14D2D66CEF098A4699

To my understanding (I've tested a similar query that oracle_hashdump runs on my own 18c database) 18c hashes look like this (only S and T part -- no H part whatsoever, in all user pw hashes):
S:C9E559319D4098C71B572773853B0B4A66621AF43FDA792306BE3E3C84B4;T:8C989A3B100233F409A2BAE89C58D444B39AFFD9636354B64C5BE82ACB58B0A9507B5B3BBA8D58D824DE95CD6C1A39E

Confusing results when querying

As mentioned above, I ran a similar query, not the same one as oracle_hashdump, because the same one doesn't work, even though the 18c hashes are still stored in the same spare4 column.

On my 18c DB, trying the same query of SELECT name, spare4 FROM sys.user$ where password is not null and name <> 'ANONYMOUS'; results in:

NAME
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
GLOBAL_AQ_USER_ROLE

Weird, I thought. So I ran this:
SELECT name, spare4, password FROM sys.user$ where name <> 'ANONYMOUS' and password is null; and got over 120 entries. Some empty, some with full S and T parts, and some with a bunch of zeroes in their S and T parts. To sum it up, here's what a few of them look like:

...
OLAP_DBA

NAME
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
PASSWORD
--------------------------------------------------------------------------------

OLAP_USER

MDDATA

NAME
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
PASSWORD
--------------------------------------------------------------------------------
S:68DE992170BC783B350B89B7379921B2F7CEFE7A5CDC228D88737BEFDCAD;T:AD94C6723F5E8F4
B12398BEF07DD46FD1C908CA2C9EB2606169597491AAB9C9BE5D5A15F881F726FE600DCEF550706F
C2B79FE7D7FC964F92A15ED6D64807910F5B8026BAF96A18E07FA8DD860049CDA

RDFCTX_ADMIN

NAME
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
PASSWORD
--------------------------------------------------------------------------------

LBACSYS
S:00000000000000000000000000000000000000001FAA02E5810517F3AA3E;T:000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000C4C4946E3EEB5784CE68F907193B98CC
...

With these results (after querying for a null password and getting many entries with full hashes), I'm a bit confused as to what password actually means in the original query that works for 12c. Nonetheless, it seems that the H part is gone with 18c, and the meaning of password possibly also changed. I'm also confused because these changes were not documented anywhere that I can find.

(ping @h00die any ideas?)

[h00die]

I was unaware Oracle had a free version of the database. Also, I don't like Oracledb and never looked.

Downloading 18c xe now, will spin up a vm after the 2.4gig download finishes, and start to take a look.

I think the hash_to_jtr most likely needs some re-tooling for oracle. it would be good to add in some logic that if we see S vs T vs H instead of just 'this is here its that' kind of logic.

I see oracle has 11.2 xe, but no v12? any ideas where that is (legally)

[7043mcgeep]

Free for students, I believe (1/1 perk of college debt).

I think the hash_to_jtr most likely needs some re-tooling for oracle. it would be good to add in some logic that if we see S vs T vs H instead of just 'this is here its that' kind of logic.

Totally agree. With each version's changes, it seems like it's getting more difficult to keep hash_to_jtr from fumbling the hashes.

As per https://community.oracle.com/thread/4170956,

There is no Oracle 12c Express Edition (and there will be no 12c XE).

:(

[jmartin-tech]

Oracle is surprisingly friendly on licensing requirements for development. They want money as soon as you move to something used in testing however. See Development Environment:

Subject to the full terms of the OTN License Agreement,
this limited license allows the user to develop applications using the licensed products
as long as such applications have not been used for any data processing, business,
commercial, or production purposes.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.