Call: +44 (0)1904 557620 Call

Pete Finnigan's Oracle Security Weblog

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.

[Previous entry: "emkey and the importance of it in Grid Control security"] [Next entry: "List of Security papers"]

In memory backdoors in Oracle

David has a new presentation available from his site titled in-memry backdoors in Oracle. This is a paper about rootkits that David presented at DeepSec recently. This is an interesting area of research. The paper showed in the first part that the original concepts for rootkits are flawed in that they can be discovered easily. David showed that a hacker user can be hidden in the database by altering base data, by setting a users tablespace to an invalid tablespace. This concept is quite powerful but can also be discovered easily. The record still exists in sys.user$ but not in dba_users for instance. The concept is powerful as there are potentially many columns used in dictionary views that could have data altered to avoid showing up in views, checking for a hacker user in this case would be easy as simply counting users in sys.user$ and comparing with dba_users can still be done.

Alex pointed out to me yesterday that changing the user type would avoid this but I agree with David that its still possible to detect. Some ideas would be to digitally sign the data in core dictionary tables that do not change such as user$ and check the signature. This would need to be updated and stored every time a change is made. For all columns this would be difficult as the password management for instance can change this. Another possible check would be for key tables to check values in columns to see if they are pointing at valid values or have valid values that do not point at other tables. For a key table such as user$ this could be possible but its not a solution across the whole database dictionary. Interestingly I discussed the same ideas quite a long time ago with Alex but didn't publish them, kudos to David.

The second step shown by David to simply delete the row from sys.user$ as the row is cached in the dictionary cache. This is a good idea but very transient. Also David suggests that its still there until the database is restarted but an alter system flush shared_pool will also remove it. I guess there are other ways it can be removed if I think more.

SQL> connect haxor/haxor
SQL> connect sys/change_on_install as sysdba
SQL> alter system flush shared_pool;

System altered.

SQL> connect haxor/haxor
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

The second part of David's paper shows an exploit to change the password of SYSTEM in memory by walking the dictionary cache and locating the hash in the cached block and updating it. This is also good idea and also one I thought about years ago, in terms of editing the hash in memory. My thoughts had been around using some of the techniques described by Kyle in his direct SGA programs. I also thought it was possible from within the database. Again Kudos to David for showing how to actually do it. I cannot see which package he has used to deploy the shell code that does the change but I could guess (I am probably wrong, but hey its Christmas)

Of course David will know that although these technqiues can be used to create a hacker user in the database his recent work on forensics will of course show that there would still be evidence. The use of the shell code for instance could be detected if you were lucky enough to have already audited execution of the exploited package or also from various sources such as the SQL area or AWR, statspack etc. Creating the hacker user and hiding it is getting closer to a reality (for most systems as most people would not check anyway and probably not quick enough) - a less is to have audit enabled. The use of the hacker user would also leave a trail of evidence and that would be harder to hide as the use could be limitless in terms of what could be done. Is it possible to create a user, use it for something and not leave any trail? - yes one way, delete the whole database and logs after its been used, without this, unlikely, there would be some evidence and most likely it could be ade quite transient.

Good paper David!

There has been 2 Comments posted on this article

December 30th, 2007 at 08:46 pm

Pete Finnigan says:

Hi Pete ,
Indeed there are tens of ways to fly under radar in oracle and tens+1 ways to revel these tricks. But in reality, how many DBAs you know who are paranoid enough to take care of all of these , in daily or at least weekly basis ?
Honestly , I`ve seen such deep level of investigation only the time it`s too late ,when attacker has already grabbed valuable info , and left his tracks somewhere ELSE , which later was linked to DB systems by hired investigators .
to be short , I think there are MANY DBAs out there unfamiliar with these tricks, happily passing their busy days without noticing anything!

January 4th, 2008 at 12:58 pm

Pete Finnigan says:

Imo, in a lot of cases there would be no need to create a hacker user, with all the added effort of trying to hide it. If you want to "play around", yes, but mostly, I guess an attacker would want to be able to read, possibly write, data he is not privileged to.
The exploit shown changes the in-memory password of SYSTEM, but ofcourse it can change the password for any "normal" user as well. A more advanced version might be able to extract the original hash value first, change it to a known value, and change it back to the original a few moments later. In the mean time, the attacker could log in to the application as that other user (presumably one with a higher level of data access than the attacker has), and be almost indistinguishable from the "real", legitimate person.