 |
|
Correlating Timestamp with
Checksum
Oracle Forensics tips by Paul Wright
|
The DBA or
attacker is mainly interested in current vulnerability status
whereas an auditor should also be interested in the long term
vulnerability status of the server he or she is auditing.
Visa and
Mastercard security standards require merchants to apply patches
with one month of release.
If the DBA has hurriedly applied patches just
before the Auditor arrived then it would be useful for the Auditor
to know this so they can make an assessment of the long term risk
the DB has been subjected to.
The auditor could use the Time Created and
Modification time of the vulnerable packages fixed by the patch.
This is a way of using the 10g precalculated checksum method to also
include timestamp.
select
last_ddl_time from dba_objects where object_name in (SELECT NAME
FROM DBA_SOURCE WHERE OWNER='SYS' AND NAME='DBMS_AQ_INV' AND TEXT
LIKE '%786e 1907%');
LAST_DDL_TIME
---------------
30-AUG-05
30-AUG-05
Time is considered to be one of the most
important pieces of data that can be gained about a piece of
evidence. There are three time fields ctime, mtime and stime which
are stored in sys.obj$ and can be viewed in dba_objects as created,
timestamp and last_ddl_time. The last_ddl_time is changed when the
object is recompiled through a patch for instance. The created time
should stay the same.
On OS the created
timestamp is not changeable though of course it can be made to be
changed. Oracle timestamps are different from OS timestamps. Oracle
timestamps could be reset by resetting the system time of the
server/db and then recreating the packages from the plbs. This would
cause the timestamp to be created in the past. Could set the system
time to be the same as the previous time and then recreate a package
using malicious code. It is more difficult to set the exact
timestamp of a package recreation this way so worth being exact with
timestamps. Oracle are not at the moment. More simply a privileged
user could simply change the timestamps as the timestamps is just a
value in a table.
SQL>
select ctime from sys.obj$ where obj# =4356;
CTIME
---------
30-AUG-05
SQL> update obj$
2 set mtime = '29-AUG-05'
3 where obj# = 4356;
1 row updated.
SQL> select ctime from sys.obj$ where obj# =4356;
CTIME
---------
29-AUG-05
So we know that the timestamps in Oracle are
even more easily changed than timestamps at the OS level (see the
Touch command). Of course file size could also be used as a way to
identify the state of an object. Problem is that the line number can
be changed again easier than on an OS.
What this all means is that in order to keep an eye on how the
database is changing and has changed, a record of the state of the
DB should be kept away from the server. Need to have a Depository
which we will expand upon later.
An alternative to
timestamp is the SCN Pseudocolumn
SQL>
select ora_rowscn, name from sys.user$;
ORA_ROWSCN NAME
---------- ------------------------------
5072905 SYS
5072905 PUBLIC
5072905 CONNECT
5072905 RESOURCE
5072905 DBA
5072905 SYSTEM
5072905 SELECT_CATALOG_ROLE
5072905 EXECUTE_CATALOG_ROLE
5072905 DELETE_CATALOG_ROLE
5072905 EXP_FULL_DATABASE
5072905 IMP_FULL_DATABASE
SCN is more strongly bound to the internal
workings of the database and the sequence of events is more strongly
deducible using the SCN as a machine timeline BUT SCN can not be
correlated easily with the other logs and witnesses recollections
that will make up an investigation.
http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10795/adfns_fl.htm#1008156
This is an excerpt from the book "Oracle
Forensics: Oracle Security Best Practices", by Paul M. Wright,
the father of Oracle Forensics.
