Pete Finnigan's Oracle Security Weblog

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 Connected. SQL> connect sys/change_on_install as sysdba Connected. SQL> alter system flush shared_pool; System altered. SQL> connect haxor/haxor ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL>

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!