Pete Finnigan's Oracle Security Weblog

I found a good website that includes a list of 200 security papers. This site is Security and Hacking Documentation. Some of the papers are old but still relevant. The papers are categorised into various sections and themes in hacking techniques. Its a good starting point for anyone who wants to read more about security.

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!

I had an email from Paul Vallee to let me know of a good post on the pythian blog written by Grégory Guillou titled http://www.pythian.com/blogs/736/oracle-grid-control-the-importance-of-deleting-the-emkey - (broken link) Oracle Grid Control: The Importance of Deleting the emkey. The title doesnt shout out Oracle security but its clearly about this subject, my favourite subject. I was aware of this issue and have included the decrypt code in previous presentations but this is a really good article that covers the subject very well. Oracle also provides some documentation on http://download-uk.oracle.com/docs/cd/B14099_19/manage.1012/b16242/security2.htm - (broken link) enterprise manager security which is not bad and covers the commands used in more detail.

Whilst looking into writing some of my presentations for the UKOUG conference recently in Birmingham I came across a very good three part paper by Arup Nanda titled "Mining Information from the Listener Log - Part 1" that is worth reading. Whilst it is not specifically about security, it does cover security. The paper is great as it uses a simple concept to gather information from the listener that can then be cross referenced easily with other data in the database. This is of course using an external table. Be aware that if you use these techniques to secure the RBAC to the file itself. Access to key logging data from within the database can be a security issue itself as an attacker may use this detail to assess how they may be tracked.

Parts two and three are here.

My two hour Oracle Security Masterclass (4MB) from the UKOUG conference in Birmingham is available. The talk was well attended and went well I felt. The paper looks briefly first at what the issues are and then the bulk of the paper explores the issues of doing an audit of an Oracle security database and goes through the process including some examples. The paper concludes with a brief look at what to do next. There is also a version of the Oracle security masterclass with 6 slides per page which is smaller at 1.2MB for those with bandwidth issues.

My presentation on Oracle Forensics that I gave last week at the UKOUG conference in Birmingham on Wednesday the 5th of December. This paper looks at the subject of Oracle Forensics and covers where to find information, what data to look for and also looks at some examples of data mining. The presentation is also available as Oracle Forensics 6 slides a pdf with 6slides per page for those with bandwidth issues.

I have finally found a few spare minutes to start and post up my papers from the UKOUG conference last week. This was a great conference and I spent a lot of time meeting a lot of people, chatting and attending some great presentations.

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.

OK, a few quick bits. Its Monday evening, the UKOUG started today in Birmingham but i wasn't there yet, client work today instead. I am heading down there in the morning, some client meetings first and then into the conference. I am speaking about http://conference.ukoug.org/default.asp?p=685&dlgact=shwprs&prs_prsid=1406&day_dayid=12 - (broken link) Oracle Security Tools just after lunch and then its the
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.