Removing exposed HTTP Digest hash from user$ in Oracle 12.1

Background

Oracle 12.1 has introduced a lot of new cool security features and improvements. We all agree with that.

However, one of the most bizarre and security vulnerability things that Oracle did in this release was introducing HTTP Digest Authentication to allow XDB users to log in. The new EM Express Edition is one of the built-in applications based on XDB.

Before going deeper, let me just to give an overview of the passwords hashes that an user can have:

SQL> alter user c##DBARJ identified by oracle;

User altered.

SQL> select password, spare4 from user$ where name='C##DBARJ';

PASSWORD
----------------
SPARE4
--------------------------------------------------------------------------------
099284AE54251642
S:36A79DEC4FA97F7F2A3AA58CE151F71BB32D78D9DE5839BB9208FAAAFFD8;H:6747F421C1E3C9B
ABE3E7CE6EB6FD08A;T:F561744F19996B34313890FEE14459D903CB1B61552AAA25C45F765DB67A
5B49116955377262F9AB6B3E52FF60BEECFFCB8010A37ABBD19A243B3300A2543610495AC1F86703
AC121AD6FCAA5DD80FB6

SQL>

What is each column and each attribute?

• USER$.PASSWORD - DES password hash used from Oracle 6 until 10g.
• USER$.SPARE4 (attribute S:) - SHA1 password hash introduced on Oracle 11g.
• USER$.SPARE4 (attribute T:) - PBKDF2 password hash introduced  on Oracle 12.1.0.2.
• USER$.SPARE4 (attribute H:) - HTTP Digest password hash introduced on Oracle 12.1.0.1.

The biggest problem is that HTTP Digest is a very old RFC (1999) based on Unsalted MD5 and very fast to crack if we use multi-nodes GPU clusters to break it.

And if we compare the benchmarks of how many hashes we can generate per second using a very strong cracking tool like Brutalis, we have:

So when you create or alter an user password in 12.1, for every very strong PBKDF2 hash you will also have a MD5 hash that can be broken 245.000 times faster.. of course that if your users hashes somehow get exposed, hackers will try to break the HTTP Digest password instead of any other.

How to hide weaker hashes

Hiding the DES and SHA1 hashes can be achieved through SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter:

• Default = 8 -> ALL HASHES are stored.
• = 9, 10 or 11 -> ALL HASHES are still stored.
  
• = 12  -> Remove HASHES in DES (user$.password)
• = 12a -> Remove HASHES in SHA1 (user$.spare4)

The change will only be noticed next time the user has his password updated.

However, there is no explicit documented way to remove the HTTP Digest (in Oracle 12.1).
So, after researching a lot, I've decided to create my own solution: forcefully remove them.

update user$
set spare4 = regexp_replace(spare4,'H:([[:digit:]]|[A-F])*(;)?','')
where instr(spare4, 'H:')>0;

** Please note the this is not an approved nor recommended solution by Oracle.

The update statement above will simply remove all HTTP Digest hashes from spare4 column. We can also automatize this removal for every new/altered user creating the trigger below:

CREATE OR REPLACE TRIGGER Sys_User_Remove_Digest
AFTER CREATE OR ALTER ON DATABASE
WHEN (ora_dict_obj_type = 'USER')
BEGIN
  update user$
  set spare4 = regexp_replace(spare4,'H:([[:digit:]]|[A-F])*(;)?','')
  where instr(spare4, 'H:')>0 and name=ora_dict_obj_name;
END;
/

** AGAIN, please note the this is not an approved nor recommended solution by Oracle.

After all are removed, now you are secured without MD5 unsalted hashes of your users passwords. However, of course that any attempt to authenticate a user via HTTP Digest of XDB will fail as the user hash does not exist anymore.

P.S: I've tested this in multiple databases and so far I didn't have any problem (note I'm not using XDB or EM Express).

You can check for any remaining Digest by either checking for "H:" attribute in spare4 column or by running:

select * from dba_digest_verifiers;

To undo all those changes, you can simply remove the trigger and expire the passwords of affected users.

What about 12.2 ?

In Oracle 12.2, they modified this exposure and now HTTP Digest are not enabled by default.

In 12.2 release, all DB users will have their HTTP Digest
verifiers disabled by default at the time of creation.
A separate [HTTP] DIGEST [ENABLE|DISABLE] clause has been added to
[CREATE|ALTER] USER DDLs to support generation of these verifiers on a
per-user basis.

For users with enabled HTTP Digest, we should see "HTTP" in PASSWORD_VERSIONS column of DBA_USERS.

More details about the syntax is available at the Oracle Official Doc.

+3