Database Reference
In-Depth Information
I think you get the strategy here, which can be extended to configuration parameters from
v$parameter,
etc. I
will not go into more detail as this manual checking is being automated into 12c Enterprise Manager cloud control, as
we shall see in the next chapter.
However, we do need to check the checksummer, as our checks are dependent on the integrity of the original
dbms_utility
. If an attacker had backdoored
dbms_utility,
then the dependency tree falls down. This following
query produces a checksum for DBMS_UTILITY with a comparison of the actual source code stored in the DB.
SELECT sys.obj$.owner#, sys.obj$.NAME, sys.source$.obj#, To_timestamp(ctime), to_timestamp(mtime),
to_timestamp(stime), AVG(dbms_utility.get_hash_value(source,1000000000,power(2,30)))from sys.source$
inner join sys.obj$
ON sys.source$.obj#=sys.obj$.obj#
where sys.obj$.name = 'DBMS_UTILITY'
AND source like '%e9teUZAUAQzjqqLOq388E8K0SoAW1VEwffOEzWHYi0H4M9od5d9LwNlefOxz/KLCMC//OBVf
cCn3lEtBlCjGUsV58UT/OVtL3/nlXjkEYVtduuLJQQAu1P3Z+BnRltSLiQQe/Z8/mBWFj2N6
AcdCLoAKx08sIn9r5lGzZgcckNyMUnSEWS+5oV+bd8tmjH/Yk0eG/wMsG9Q4lFEf/EVkvQyt
Ngx5zX9PVeQj7UUBnVYgcqqHGQaPnpH50AYjOjgBvFO6c8Fz/JLPgWyYvLWlhvynyXGvusAY
Cj2Brh5PWD/tRe3tvmLORHurtizpWZDaUhGTC6YgCpH+M3Cmgq/D0EMkXtG/2McNbIT0Pwa4
ejwI3BR67hhhzIQr4C17gROk2miWE19lsWNBMh99NQhyMGLVZHDM7NTNFqOgsBFbHGy3Umv1
boqDkkd/R+fZjuTl+twI9Bq4AZ2UqG3Gl0MI35cOV19zMG5JdVXhlgeEXC+3TqANv/lFZPsy
DiEjPWi428BT5EYoelVAA5sriNqrgyWJ6ttTawNQoemV4AobGmDP14u0ycJrPXB9qaPBzSri
Vdj9W+wY7PbjOxGs8cntUaBhuykls2EJ0hygdMsmENApKm+TMh3QpRUI0yCV8U2QdYwtSqQ7%' GROUP BY
sys.obj$.owner#, sys.source$.obj#,ctime, mtime, stime,sys.obj$.NAME;
Of course, the problem with the above is that there is still a dependency within the query on the state of
dbms_utility
,
and also a dependency on the Oracle relational database engine itself.
If
dbms_utility
has been tampered with, or if the
Oracle software has been modified, then the query above could not be trusted. Here we have a chicken and egg problem.
How to forensically verify the integrity of the integrity checker within the DB? The answer is to follow the security hierarchy
and pass this requirement to the next security level up, which is the OS. What we will do next is, from root, read the code for
dbms_utlity
from the SYSTEM tablespace data file and verify that code with a known-good value. There are a number of
considerations with this process, which we will now detail.
Root Verification of Checksummer Integrity
The aim of this next section is to compare the checksum of
dbms_utility
code in the SYSTEM data file, read from the
Unix root account, at the point the privileged session ends, to the known-good checksum from before the break-glass
period was initiated, thus comparing
before
and
after
the privileged session
.
We will run this state check from a cron
job as root, which will check the state of
dbms_utility
in the data file. We need to know the active data file for the
SYSTEM tablespace that contains the dictionary objects. That can be done as follows:
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> select value from v$parameter where name= 'control_files'
VALUE
--------------------------------------------------------------------------------
/home/oracle/app/oracle/oradata/orcl/control01.ctl
, /home/oracle/app/oracle/flas
h_recovery_area/orcl/control02.ctl
