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.
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!
Parts two and three are here.
My first paper of the conference was given in Hall 1 on Tuesday 4th December 2007. The paper is titled Oracle Security Tools and seemed to go down well. There is also a smaller pdf file version with 6 slides per page called Oracle Security Tools 6Slides for those who want to watch bandwidth.
A couple of quick links; Tanel had a great post recently titled Oracle Security, Part 2: Your read only accounts aren’t that read only that discusses the issue of read only tables.
Alex posted last week two presentations; the first is "Best of Oracle Security 2007", which is in German and the second is "Retrieving Sensitive Information from Oracle Databases" which is in English.