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:

 

Hash Type Speed (H/s)
HTTP Digest - MD5 200.300.000.000
DES: (Oracle: 7+) 7.208.400.000
SHA1: Type: (Oracle: 11+) 68.697.900.000
PBKDF2: (Oracle: 12+) 818.000

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.

4 comments

Skip to comment form

    • Michael Seberg on February 23, 2018 at 14:02
    • Reply

    Good information. Have a 12.1.0.2 database and users with issue:

    EXEC dbms_xdb_http_digest.disable_http_digest('GSMUSER');

    ERROR at line 1:
    ORA-28007: the password cannot be reused
    ORA-06512: at "SYS.DBMS_XDB_HTTP_DIGEST", line 130
    ORA-06512: at line 1

    So I create a new profile and switch the user to it thinking it will solve the issue. Same error. Nothing on Oracle support that I see thoughts?

      • Michael Seberg on February 23, 2018 at 14:28
      • Reply

      OK, I did something stupid. I changed the profile on GSMUSER but ran disable_http_digest('GSMCATUSER').

      The switch profile works fine!

    • Coway on August 30, 2021 at 12:10
    • Reply

    Better not to use the hack that Oracle doesn't support. Instead, use the correct ways to disable HTTP digest:

    Use cases:

    Creating a new user XXX without digest authentication:

    Create user as before, user will not have MD5 hash.

    Creating a new user XXX with digest authentication:

    Create user XXX as before

    EXEC dbms_xdb_http_digest.enable_http_digest('XXX');

    ALTER USER XXX identified by actual_password;

    Permitting digest authentication for an existing user XXX:

    No action; user already has permission.

    Denying digest authentication for an existing user XXX:

    EXEC dbms_xdb_http_digest.disable_http_digest('XXX');

    If the db version supports: (I think the version is 12.2 and onward, I could be wrong)
    ALTER USER user PASSWORD EXPIRE HTTP DIGEST DISABLE;

      • Phni on February 21, 2023 at 19:01
      • Reply

      Thanks Coway, your steps helped and it is surprising that Oracle doesn't have clear documentation for HTTP verifiers

Leave a Reply

Your email address will not be published.