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;
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!
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!