Relevant Data File Oracle Forensics tips by Paul Wright

The attacker has also deleted the relevant audit entry and the redo logs are not archived plus the current redo logs have overwritten themselves. This makes life more difficult for the analyst. The technician in this scenario will approach the incident from the data files. The fact that a .dbf file does not remove ?deleted? ASCII data was originally discussed publicly by the Author of this book at: http://www.oracleforensics.com/wordpress/index.php/2007/03/21/dbf-records-previous-state-of-each-row/

Subsequent analysis of this fact was published by David Litchfield at this URL. http://www.databasesecurity.com/dbsec/Locating-Dropped-Objects.pdf These observations were made independently of one another as is often the case. One caveat is that the above analysis was carried out on Windows. It would be interesting and useful to demonstrate the non-removal of deleted data on *NIX especially as this platform is the most likely to occur in the field for Oracle, and is the platform for this scenario.

The key files in this case are the .dbf files which will be copied off the machine.

SQL> show user
USER is "SYS"

Information about the datafile header can be gained through this view.

SQL> desc v$datafile_header;

 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------
 FILE#                                              NUMBER
 STATUS                                             VARCHAR2(7)
 ERROR                                              VARCHAR2(18)
 FORMAT                                             NUMBER
 RECOVER                                            VARCHAR2(3)
 FUZZY                                              VARCHAR2(3)
 CREATION_CHANGE#                                   NUMBER
 CREATION_TIME                                      DATE
 TABLESPACE_NAME                                    VARCHAR2(30)
 TS#                                                NUMBER
 RFILE#                                             NUMBER
 RESETLOGS_CHANGE#                                  NUMBER
 RESETLOGS_TIME                                     DATE
 CHECKPOINT_CHANGE#                                 NUMBER
 CHECKPOINT_TIME                                    DATE
 CHECKPOINT_COUNT                                   NUMBER
 BYTES                                              NUMBER
 BLOCKS                                             NUMBER
 NAME                                               VARCHAR2(513)
 SPACE_HEADER                                       VARCHAR2(40)
 LAST_DEALLOC_SCN                                   VARCHAR2(16)

The forensic analyst most trusted information is from the source file so he will go in direct to the dbf. How does the analyst know what dbfs are being used?

SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/u01/app/oracle/oradata/orcl/example01.dbf

At the OS the technician is easily able to find the data files by looking in the oradata directory within the Oracle home and locating the files with .dbf suffixes.

/u01/app/oracle/oradata/orcl/users01.dbf

The analyst makes three copies of the relevant data file and compares the checksums and file sizes of each of these copies. The original drive cannot be taken as it is in production but an untouched copy is burnt to read only media (DVD) and sealed in an evidence bag within a lightproof hard case. This will be a documented item in the chain of evidence. The checksum process can be done using the MD5 algorithm.  For high security purposes it is preferable to check integrity using both MD5 and SHA1 due to the fact that collisions in MD5 allow for two files with differing content to have the same checksum. 

Also by using a tool called stripwire it is possible for an attacker to control the content of a malicious collision. Using both MD5 and SHA1 checksums, dual collisions become all but impossible.

[oracle@localhost orcl]$ sha1sum users01.dbf
9bf496199d3c8d3bcb00795fc45191613389aa13  users01.dbf
[oracle@localhost orcl]$ md5sum users01.dbf
949942ef1ffd76f8d8b3e7ed166aab98  users01.dbf

For Windows, FCIV will create both checksums by using the ?both flag.  http://support.microsoft.com/kb/841290 

C:\evidence>dir

17/03/2007  17:48       <DIR>          .
17/03/2007  17:48       <DIR>          ..
17/03/2007  17:48            5,251,072 USERS01.DBF
               1 File(s)      5,251,072 bytes
               2 Dir(s)   6,233,526,272 bytes free

C:\evidence>fciv -both users01.dbf

// File Checksum Integrity Verifier version 2.05.

                MD5                             SHA-1
---------------------------------------------------------------

8db69198f8b69d4a2bae93431538763d 28cb496d2c588cad674dde918a1f5095cb50744b users01.dbf

Using  hexedit for Linux at http://www.chez.com/prigaux/hexedit.html

http://rigaux.org/hexedit-1.2.12.src.tgz.  In order to search for an ASCII string use the tab key to swap to search the right hand column. Then enter a ?/? and the search string.

Quick commands for hexedit:

/ to search and tab to change to ASCII

<, > :  go to start/end of the file

Right:  next character

Left:   previous character

Down:   next line

Up:     previous line

Home:   beginning of line

End:    end of line

PUp:    page forward

PDown:  page backward

F2:     save

F3:     load file

F1:     help

Ctrl-L: redraw

Ctrl-Z: suspend

Ctrl-X: save and exit

Ctrl-C: exit without saving

Tab:    toggle hex/ascii

Return: go to

Backspace: undo previous character

Ctrl-U: undo all

Ctrl-S: search forward

Ctrl-R: search backward

 

This is an excerpt from the book "Oracle Forensics: Oracle Security Best Practices", by Paul M. Wright, the father of Oracle Forensics.