Pete Finnigan's Oracle security weblog

Hamid.k says:

The rootkit released by Argeniss is based on few tricky modifications of SYS database , which makes oracle NOT to show details as they really are (jobs for example). The way rootkit make oracle to so so is not complex at all, but it`s based on simple tricks like modifying informations which oracle relays on, for showing details to DBA. and all these happens with 3 queries . simple but effective.

Pete Finnigan says:

Hi Hamid,

I have not seen Argeniss root kit but i was involved in the first root kits created for Oracle. Alex Kornbrust and I discussed Oracle rootkits in detail quite a few years ago and before his BlackHat papers on the same subject. I suspect that they have simply shipped some code to modify built in views such as DBA_USERS or DBA_JOBS. The problem with this is its easy to detect a hacker simply by comparing SYS.USER$ with DBA_USERS for instance. Alex's ideas for secodn generation rootkits for Oracle are sound and have been tested limitedly, the issue for me is that key data that could be used to identify a database users is propogated to a huge amount of places in the database and this would need a huge amnount of modified views to be implemented. Also remember that a rootkits is not simply a hiding mechanism, but should include installation, backdoors (I suggested a variation on port knocking to Alex last year and he used it in his BlackHat paper on Oracle 2 rootkits), log and audit cleaning and much more.

I think we are a way from seeing real Oracle rootkits that are slick and really hide a user and what he is doing in the database.

cheers

Hamid.k says:

Hi Pete.
You`re right about your guess. Argeniss have also provided backdoors too, but as you said these are far away from a real-world rootkit and can be used only against DBAs with low level of knowledge. A sharp DBA can reveal these in matter of minutes. I have read Alex notes too, before Argeniss release it's version. I belive current state of database rootkits like user-land days of OS rootkits which never proved to be successful. I'm not a DB expert but I think as long as community is working on top level of DB, results would not be much effective. why not move to deeper level of modifications, like replacing or altering core components of DB? one-byte patch for ms-sql is a good old example but I'm sure there are many targets available to focus. stored procedures would be my choice for this. In Oracle for example, there are many ways to bypass protection mechanism and let attacker manipulate DB from OS level not DB level.