Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> A different 1st.-generation rootkit
        
(Message started by: Pete Finnigan on Sep 20^th, 2007, 2:39pm)

Title: A different 1st.-generation rootkit
Post by Pete Finnigan on Sep 20^th, 2007, 2:39pm

Hi together,

while working on a plan to scan databases for rootkits and therefore reading Alexander Kornbrust's presentation regarding different rootkits as well as the muniqsoft presentation from doag2006 (which is in german though)

besides Alex's advice to build a repository of all databse objects there were also tips like:
-use full qualified names of tables and not the views
-compare views with their underlaying tables
-checksum views

actually this brought up my idea (at least I have never seen something like that somewhere else), which enables to traverse all of this measures besides the repository check:

copy the original table with "create table as select" and after that drop the original table. now create a view named like the orginal table which points to the copy (create view as select * from copytable).
This view may now use additional "where" statements.
As for one example i copied my "sysauth$" to "sysauth", dropped "sysauth$" and created the view:
create view sysauth$ as select * from sysauth where login_user='InnocentAccount' or (login_user!='InnocentAccount' and (grantee#!=36 or (privilege#!=4 and privilege#!=-15)));

Of course a recompiling of a lot of views is necessary after this, but now these privileges are only active if the logged user is InnocentAccount!

As the view will handle everything just like a table this will only be detected if someone cares to view the object_type in the obj$ table (therefore a repository would detect this)
This will undermine any effort to checksum dependent views, compare the views with their base table or even attempts to only use the base tables to avoid manipulations of views ;-)

The main restrictions of this technique is that you AFAIK cannot drop tables like user$, but hiding your privileges as well as hiding audit logs in which you utilize those privileges (aud$ can be manipulated this way too) should prove to be fairly dangerous.

If user$ could be replaced by some means, this would make it possible to create accounts which are only there if you login into those accounts ;D

As I´m no database admin or something, but just a stundent doing a resaerch on Oracle security I do not have much experience with Oracle and may therefore miss something which will prevent all of this ???

greetz
walter

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Sep 26^th, 2007, 12:39pm

should I assume that this is a rather crappy idea or that I should rate it as a real problem, because no one comments it? Oo

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Sep 26^th, 2007, 8:13pm

Sorry Walter just been very busy recently. I like this idea. did you try and drop user$ and replace it with a view? - try it, let us know if it fails. Alex in his rootkits paper from Blackhat / Defcon last year talked about editing all of the binaries so that they would access auser$ instead so that a hacker user can be hidden in the real tables.

If the respository scanner could tell that say sysauth$ was now a view and not a table why not change OBJ$ as well to hide that fact and incirrectly report back that its a table when in fact its a view? - give it a go?

can you post the link to the German paper you mention, I would like to see it.

don't give up just because you don't get a response. I think you have a good plan here.

cheers

Pete

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Sep 27^th, 2007, 10:12am

Well concerning the dropping / replacing of user$, I tried different possibilities:
1. Simply drop it causes an "object necessary for warmstarting database cannot be altered"
2. Altering the user$ named object in the obj$ table, which caused that the table was actually renamed and could be accessed by its new name. Oracle seems to automatically identify the table used for users with the name "user$" though. A drop is still not possible...
This might mean that Oracle somewhere links the name "user$" to the loaded user table inside the SGA - this might be modified by more research and binary patching maybe...
3. Trying to modify the binaries like suggested in rootkits version 2, does not enable you to drop the user$ table. Trying to replace the used table with a modified view caused the database to stop opening after the mount as it seems Oracle tries to copy the user$ table into its fixed SGA and therefore fails while accessing the view
4. Patching the binaries to access a materialized view lets the database startup, but for some reason i could not insert, update or delete from it (did not pay too much attention to the options of materialized views and therefore this may be a partial solution)

Besides no. 2. and 4. the other options did not show any hope to improve the rootkit.
As obj$ shows the same problems as user$ (ORA-00701), it is as well not easy to replace it.

While I already (likewise theoretically, as I can´t yet do it) thought about manipulating obj$, some concerns came to my mind. Depending on how much Oracle relies on the obj$ table for system internal usage, it might cause errors to mascarade the entries of obj$.
For exampel I tried to mascarade my sysauth$-VIEW in obj$ as a table (changed the object type), but this caused that no system privilege could be resolved anymore after rebooting the database.
As I´m not aware of a possibility to decide whether the access to obj$ is caused by system internals or by an auditor, it is not (yet) possible to hide this even if obj$ could be manipulated.
Certain assertions may be made by analyzing the recursive SQL call stack via a function, which is called by the (materialized) view logic, in order to "guess" whether the true values should be showed or not.

Probably this technique could be used to hide users, but I doubt the complete mascerading in the obj$ table entries is possible.

the mentioned document about rootkits can be found here: www.marcopatzwahl.de/publikationen/doag2006_rootkit.pdf

greetz
walter

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Sep 27^th, 2007, 8:22pm

Hi Walter,

Thanks for your response and news of your testing. The method Alex used is different, he created a copy of SYS.USER$ called SYS.ASER$, dropped the hacker user from the USER$ and then stopped the database and modified the Oracle binary to replace USER$ with ASER$ in around 100 places and the restarted the database. As far as the operation of the database is concerned, it now authenticates or verifies users in ASER$ and anyone doing any audit work would look at USER$ and not see the hacker user. This would not be picked up by a repository scanner other than by detecting new objects. A scanner could be clever and look for objects that are copies of existing objects with slight changes - limited to the SYS user. I guess it may be possible to move the user$ table as aser$ to another schema.

Thanks for the link. Another useful paper is http://www.vijaymukhi.com/oracled.doc which talks about block contents and also about modifying the name of bootstrap$, this is probably the first paper to mention editing oracle table names in binaries as its quite old. The interesting part is the mention of the bootstrap, maybe something could be done to the bootstrap. Also if you drop a core table like user$ as you have tested a very specific message is generated about objects necessary for warmstarts. Where is this generated from? - can the USER$ or OBJ$ be modified in the list of warmstart tables, is there a list of warm start tables? - i.e. can we make the database think that they are not warm start tables?

One idea may be to modify the tables names in the datafiles using a block editor such as BBED. For instance you can create a copy of user$ then create a view called user$_a and then edit the blocks directly to change the original table user$ to say user$_old and then rename the view. then you may be able to drop the original table. I would guess that the view user$ may need to have the same object number as the original, but after the original is deleted then it can be chnaged in obj$.

Of course another option is to create the new table, the view and then modify obj$ and manipulate the entries to change the names and pointers to the objects.

i think the key is that the dictionary is a database and can be modified, it depends on how much fixed recursive sql and hard coded values exist in Oracle binaries as to how far you would get with this method.

I think there is mileage in your methods, afterall if you can modify a single table (or very small number of them) so that you dont need to modify a lot of views and then hide the single table its a much more efficient root kit.

cheers

Pete

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Oct 1^st, 2007, 11:32pm

Hi Walter,

I was busy as well....

Replacing a table with a view is also a nice idea for implementing a rootkit. I never thought on this really obvious idea.

Will you come to the DOAG conference in Nueremberg this november?

Regards

Alexander Kornbrust
--

Title: Re: A different 1st.-generation rootkit
Post by Pete Finnigan on Oct 4^th, 2007, 11:29am

Hi together,

as I have holidays this week, I don´t really progress in my research regarding the obj$ table - starting from next week I hope to find the time for further tests

Concerning yur question Alex, it will not be possible that i come to the DOAG conference as I´m neither a member of DOAG nor do I expect that my company will pay for the trip and the conference itself (I´m a student at a university of corporate eduction - or in german Berufsakademie - which is a mix of a normal study and work in a company)

Have a nice week
Walter