{"id":4897,"date":"2020-12-21T11:26:44","date_gmt":"2020-12-21T14:26:44","guid":{"rendered":"https:\/\/www.dbarj.com.br\/2020\/12\/21c-gradual-database-password-rollover-brings-new-backdoor-opportunities\/"},"modified":"2020-12-21T14:07:28","modified_gmt":"2020-12-21T17:07:28","slug":"21c-gradual-database-password-rollover-brings-new-backdoor-opportunities","status":"publish","type":"post","link":"https:\/\/www.dbarj.com.br\/pt-br\/2020\/12\/21c-gradual-database-password-rollover-brings-new-backdoor-opportunities\/","title":{"rendered":"21c Gradual Database Password Rollover brings new backdoor opportunities"},"content":{"rendered":"

Oracle Database 21c introduced the new feature called “Gradual Database Password Rollover”. This allows the database password of the application user to be altered while allowing the older password to remain valid for the time specified by the\u00a0PASSWORD_ROLLOVER_TIME<\/code> limit (PROFILE parameter).<\/p>\n

With this new feature, a password of an application can be changed without having to schedule a downtime, which is great. However, any new feature also brings new security opportunities for attackers<\/strong>.<\/p>\n

If an attacker wants to place a “second” password to later access the “SYS” or a “DBA” schema (aka backdoor<\/strong>) without raising any alert, this is now easy as 2 passwords can concurrently work for the same account.<\/p>\n

Example 1:<\/strong><\/span><\/p>\n

[oracle@lab21c ~]$ sqlplus \/nolog\r\n\r\nSQL*Plus: Release 21.0.0.0.0 - Production on Mon Dec 21 12:25:13 2020\r\nVersion 21.1.0.0.0\r\n\r\nCopyright (c) 1982, 2020, Oracle.  All rights reserved.\r\n\r\nSQL> conn \/ as sysdba\r\nConnected.\r\nSQL> create user C##DBA identified by \"welcome1\";\r\n\r\nUser created.\r\n\r\nSQL> grant create session to C##DBA;\r\n\r\nGrant succeeded.\r\n\r\nSQL> conn C##DBA\/welcome1\r\nConnected.\r\nSQL> conn C##DBA\/mysecretpass\r\nConnected.\r\nSQL> alter user C##DBA identified by \"welcome2\";\r\n\r\nUser altered.\r\n\r\nSQL> conn C##DBA\/welcome2\r\nConnected.\r\nSQL> conn C##DBA\/mysecretpass\r\nConnected.\r\n<\/pre>\n
Example 2:<\/strong><\/span><\/p>\n
SQL> conn \/ as sysdba\r\nConnected.\r\nSQL> alter user system identified by \"welcome1\";\r\n\r\nUser altered.\r\n\r\nSQL> alter user system expire password rollover period;\r\n\r\nUser altered.\r\n\r\nSQL> alter user system identified by \"welcome1\";\r\n\r\nUser altered.\r\n\r\nSQL> conn system\/mysecretpass\r\nConnected.\r\nSQL>\r\n<\/pre>\n
How someone could do something nasty like this and how we protect against this possible backdoor implementation<\/strong><\/span> is what you are going to see in this post.<\/p>\n
PS: In my previous post<\/a>, I explained how the new hashes we have in SPARE4 column of USER$ works during the rollover period. I recommend reading it before moving forward.<\/p>\n
Getting started<\/h4>\n
So first of all, to allow a second password to work, an attacker would need to create a new password HASH on SPARE4 column on the USER$ table. Oracle did a great improvement and now it’s impossible to run any UPDATE against USER$ table<\/strong><\/span> unless you open the database in migration mode. So this is not an option.<\/p>\n
Another way to add another password HASH\u00a0 would be intercepting the “ALTER USER … IDENTIFIED BY …” or the “CREATE USER … IDENTIFIED BY …”\u00a0 DDL calls.<\/p>\n
First thing that came into my mind was using a “before DDL trigger”. However, Oracle did another great implementation and it’s not possible to get the current used password on those triggers (via ora_sql_txt<\/strong> variable). So if the attacker used this method, the password would not least more than 7 days (max value for PASSWORD_ROLLOVER_TIME<\/strong>) as he can’t keep setting it.<\/p>\n
Going straight to the point, the final idea he could have would be intercepting this calls using profile functions, the only place where we do know the user password. When a CREATE or ALTER user password is called, the profile function would create a job<\/span> to:<\/p>\n
    \n
  1. Change the PASSWORD_ROLLOVER_TIME used by this account profile to 7 days (max allowed), if not already.<\/li>\n
  2. Temporarily disable PASSWORD_REUSE_TIME, PASSWORD_REUSE_MAX (to avoid reuse errors).<\/li>\n
  3. Temporarily disable PASSWORD_VERIFY_FUNCTION (to avoid a loop in the code).<\/li>\n
  4. Set the password to a desired value (backdoor password).<\/li>\n
  5. Expire the password rollover so the backdoor password will be the only one valid.<\/li>\n
  6. Set the password to the user specified value.<\/li>\n
  7. Restore back the disabled profile resources.<\/li>\n<\/ol>\n
    This job will execute every 6 days so the attacker will ensure that the “second” password will always be valid (as the expiration is 7 days).<\/p>\n
    So what is required:<\/p>\n