 |
|
Searching for Attacker
Artifacts
Oracle Forensics tips by Paul Wright
|
The analyst has already made a copy of the drive in question using
dcfldd
http://dcfldd.sourceforge.net/
Now the analyst is going to search the disk for likely attacker
artifacts. This can be done for deleted objects as well as those
that remain. Oracle is similar to OS file systems in that a deletion
marks the header as deleted but does not actually delete the data
itself so using BBED we can find it and recover the deletion even
when flashback is not operative.
So there is a suspected hacked Oracle database server and the
forensic analyst is called in to confirm this is the case and find
out how they got in. The forensic analyst has a good knowledge of
how attackers escalate privilege in an Oracle DB. She checks for the
low hanging fruit such as ctxsys.driload and other PLSQL injections
but they have been dropped by the DBA in the hardening process so
let's move to high hanging fruit. She moves onto triggers and
notices that the
SYS.CDC_DROP_CTABLE_BEFORE trigger is vulnerable to SQL injection
which has publicly available exploit code (OHH).
The trigger fires where a table is dropped and executes the
sys.dbms_cdc_ipublish.change_table_trigger procedure which runs the
ChangeTableTrigger Java method which contains the actual injection
vulnerability. The name of the table being dropped is ran in the SQL
of the trigger so if a table name is actually a malicious function
it will run with SYS privileges. Of interest to the analyst is the
fact that the table name will consist of “||” symbols. Of course the
table will be deleted by the attacker possibly with the purge
keyword so no flashback. However the analyst can use BBED to find
the deleted table.
Since the investigator is working on the hunch that a low privileged
user may have escalated privilege by using a trigger the likely
place for the malicious table name to be created is in the low priv
user table space.
This was the
attackers actions not known to the analyst yet:
SQL> CREATE TABLE
"0'||SCOTT.GP||'0"(X NUMBER);
Table created.
SQL>
select table_name from user_tables;
TABLE_NAME
------------------------------
DEPT
EMP
BONUS
O'||SCOTT.GP||'0
TESTBBED
SALGRADE
6
rows selected.
They then created a function that would be injected into the trigger
to select the passwords from the user$ table (see OHH). When the
table was deleted the trigger ran and the function elevating the
attacker to DBA also ran as SYS.
So the investigator gains a good idea of the rowid/blocknumber/file
by creating a new table as the suspected low privileged user used
for the escalation. The test table is called TESTBBED.
This gets the rowid
SQL> SELECT
dbms_rowid.rowid_object(ROWID) FROM OBJ$ WHERE NAME LIKE '%TESTBBED%';
DBMS_ROWID.ROWID_OBJECT(ROWID)
------------------------------
18
This gets the blocknumber
SQL> SELECT
DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) FROM OBJ$ WHERE NAME= 'TESTBBED';
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------
50283
SQL> SET SERVEROUTPUT ON
This gets the file
number:
SQL> DECLARE
2 file_number INTEGER;
3 rowid_val ROWID;
4 BEGIN
5 SELECT ROWID INTO rowid_val
6 FROM obj$
7 WHERE NAME LIKE '%TESTBBED%';
8 DBMS_OUTPUT.PUT_LINE(rowid_val);
9 file_number :=dbms_rowid.rowid_relative_fno(rowid_val, 'SMALLFILE');
10 DBMS_OUTPUT.PUT_LINE(file_number);
11 END;
12 /
AAAAASAABAAAMRrAA8
1
PL/SQL procedure successfully completed.
This is the information required to run BBED.
rowid 18
file 1
block 50283.
Point BBED at the data to be changed i.e datafile 1 and
datablock 50283
BBED> SET DBA 1, 50283
BBED> find /c ||
File: /u01/app/oracle/oradata/orcl/system01.dbf (1)
Block: 50283 Offsets: 1404 to 3449
Dba:0x0040c46b
------------------------------------------------------------------------
7c7c5343 4f54542e 47507c7c 273002c1 02ff02c1 0307786b 0204082b
3407786b
0204082b 3407786b 0204082b 3402c102 ffff0180 ff02c107 02c1022c
001104c3
….
dump /v dba 1, 50283 offset 1
count 4092
(best to use a wide count for big dataset)
Even though the table has been deleted and that change committed the
Oracle datafile still has the table name which can be searched for.
This is because Oracle like many OS file systems does not actually
delete the data it simply marks them as deleted in the header. The
next screen shot shows the deleted malicious table name used for the
exploit as found by the forensic incident handler using the BBED
tool to directly query the datafiles so bypassing the Oracle RDBMS.
Figure 6.4 Using BBED
to find table deleted by the attacker
This is an excerpt from the book "Oracle
Forensics: Oracle Security Best Practices", by Paul M. Wright,
the father of Oracle Forensics.
