Call: +44 (0)7759 277220 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

Does Oracle's Database Need More Security?

Does Oracle's Database Need More Security? by Sean Michael Kerner

"Four times a year Oracle releases its Critical Patch Update (CPU), which often reveals database flaws numbering in the double digits. But for users who want to take additional steps to secure their Oracle databases, rather than wait for the quarterly CPU, there are other options.

This week, database security vendor Sentrigo will release an update to Hedgehog, a security solution that defends against unauthenticated attacks launched against Oracle databases."

Memory resident backdoors in Oracle

David emailed me last night to let me know about his paper for DeepSec in Vienna at the end of November. I for one am jealous to not be going over there, not just to hear David speak but also because I worked in Vienna for 18 months in the 1990's and enjoyed the city, people and work very much. We went over there last year around christmass for a holiday so got to re-aquaint with some people and also the city. It is a really nice place.

David has made a post on his blog about his talk titled "Memory-resident backdoors in Oracle / Deepsec conference", whilst there is not much detail in the actual post (we need to wait for the slides) its quite an interesting idea that i have mentioned a few times in the past. Modifying data in memory is a a good idea to avoid detection but there are still issues around the actual deployment of the backdoor in terms of a completely hidden backdoor / rootkit.

I have also added David's blog feed to my Oracle Blogs Aggregator so its now possible to pick up his posts there as well.

Simple Oracle 11g Password check PL/SQL script

I included a simple PL/SQL password checker written in PL/SQL in a recent post around the Oracle password algorithm for Oracle 11g. I included the code in line but a number of people have emailed me to ask that i include it as a seperate script so have taken a fwe minutes to do so, because I want to refer to it in a presentation I have written a couple of weeks ago. The script is called sha1.sql

Oracle Database Buffer overflow vulnerability in function MDSYS.SDO_CS.TRANSFORM

Today Application Security Inc have released details of a buffer overflow bug in the package MDSYS.SDO_CS.TRANSFORM:

Team SHATTER Security Alert

Oracle Database Buffer overflow vulnerability in function

October 29, 2007

Risk Level:

Affected versions:
Oracle Database Server versions 8iR3, 9iR1, 9iR2 ( and previous
patchsets) and 10gR1 ( and previous patchsets)

Remote exploitable:
Yes (Authentication to Database Server is needed)

This vulnerability was discovered and researched by Esteban Martínez
Fayó of Application Security Inc.

Oracle Database Server provides the MDSYS.SDO_CS package that contains
subprograms for working with coordinate systems. This package contains
the function TRANSFORM which is vulnerable to buffer overflow attacks.

By default MDSYS.SDO_CS has EXECUTE permission to PUBLIC so any Oracle
database user can exploit this vulnerability. Exploitation of this
vulnerability allows an attacker to execute arbitrary code. It can also
be exploited to cause DoS (Denial of service) killing the Oracle server

Vendor Status:
Vendor was informed about this vulnerability on 2/22/2005 and a patch
was released on 10/16/2007.

Restrict access to the MDSYS.SDO_CS package.

Apply Oracle Critical Patch Update October 2007 available at Oracle


Oracle Database Buffer overflow vulnerability in procedure DBMS_AQADM_SYS.DBLINK_INFO

Today Application Security Inc have released the following advisory for a buffer overflow ion DBMD_AQADM_SYS.DBLINK_INFO:

Oracle Database Buffer overflow vulnerability in procedure

October 29, 2007

Risk Level:

Affected versions:
Oracle Database Server versions 9iR1, 9iR2 ( and previous
patchsets) and 10gR1

Remote exploitable:
Yes (Authentication to Database Server is needed)

This vulnerability was discovered and researched by Esteban Martínez
Fayó of Application Security Inc.

Oracle Database Server provides the SYS.DBMS_AQADM_SYS package that is
used internally by the SYS.DBMS_AQADM package to provide procedures to
manage Oracle Streams Advanced Queuing (AQ) configuration and
administration information. This package contains the procedure
DBLINK_INFO which is vulnerable to buffer overflow attacks.

Any Oracle database user with EXECUTE privilege on the package
SYS.DBMS_AQADM_SYS can exploit this vulnerability. By default only
SYSDBA users have the required privilege. Exploitation of this
vulnerability allows an attacker to execute arbitrary code. It can also
be exploited to cause DoS (Denial of service) killing the Oracle server
Vendor Status:
Vendor was informed about this vulnerability on 2/22/2005 and a patch
was released on 10/16/2007.

Restrict access to the SYS.DBMS_AQADM_SYS package.

Apply Oracle Critical Patch Update October 2007 available at Oracle


New presentation on Database Vault faults

Joxean Koret has today released a presentation titled Oracle Database Vault: Design Failures that explores some of the issues with database vault. Joxean points out that there are many ways to bypass database vault via the OS, trojanned libraries / DLL's and binaries and also he talks about the lack of segregation at the OS level, particularly that the database software and also the database vault software all run as the same operating system user. Some interesting thoughts on this product!

A new SQL Injection protection PL/SQL package

I saw a post on my Oracle security forum by Gary titled Steven F's SQLguard - sql injection prevention pkg that announces that Steven Feuerstein has created a PL/SQL package called sql_guard that he is calling SQL Guard that aims at developers to help them prevent SQL Injection attacks from being successful on the said developers deployed code.

This sounds very interesting and I for one have dropped Steven an email to ask for a copy for testing to see how well it works and whether its going to be of value to developers. Without seeing it its hard to comment more now, but I will comment more here if Steven does let me have a copy to test.

David Litchfield has started a new blog

I got an email from David today to let me know that he has started a new blog (Its good to see that he using GreyMatter Weblog software, software that I am also helping to develop) on a domain called that looks to be set up as Davids personal site. David has an first interesting blog entry titled "SQL Injection and Data Security Breaches" that discusses some real SQL Injection attacks and also the reality of what can happen in such easy attacks, i.e. very large quantities of identities revealed or stolen and the breach of credit card details. The thing that stuck out for me was that reseachers found most of these and that in most cases they were very simple bugs. The worrying thing for these guys should be did anyone else find these bugs before who were less inclined to let them know about it?? - this is the worry for SQL Injection or any bug that discloses critical data, its found and fixed but did anyone find it before that and exploit it?

CheckPwd version 2 A12 is released

Today a new version of the Oracle password cracker checkpwd has been released at version 2.0 A12. The new cracker has a lot of features not present in the other popular Oracle password crackers such as orabf or woraauthbf. These include:

  • Support for 11g Passwords
  • APEX password cracking
  • collection of passwords from the database
  • ability to crack password hashes in the history
  • Cracking role passwords

I downloaded the latest version to test it but was unable to get it to work on my system. Its unclear whether this is an issue with checkpwd or my system. A test shows that I can connect to my local 10gR2 database with SQL*Plus on the command line but when checkpwd tries to connect to the same database from the same directory it fails with an ORA-12154 error. If i then try to connect to a remote Oracle database (9iR2) then it fails with a ORA-12705 error instead. So i finally tried a non-database connection to try and crack SCOTT's password off line. This also fails. Interestingly a sqlnet.log file is created for the non-database connection mode and the sqlnet.log file shows that the password cracker is trying to connect to a database called ORCL.

Finally a second error seems to occur after the database connect error, an error "SymSetSymWithAddr64 could not be loacted in link lib DBGHELP.dll" is sent to an error dialog box.

This is a pity as I would like to have shown some tests here and tested the new features and be able to compare to woraauthbf and orabf. The feature list of checkpwd is good. Lets hope Alex gets it sorted out, I think the A12 is alpha so we can forgive some glitches.

The one thing I want to note is the license difference between checkpwd and the other two main tools. Checkpwd if used commercially should recognise RDS and the tool and a link to RDS in any customer reports, the other two tools have no such restrictions, woraauthbf is GPL2 and the source is available and although orabf does not include source there are no restrictions for commercial use.

Oracle 11g for Windows is available

The Oracle database release 11gR1 - version is available for download from from OTN and I have started a download:

Oracle 11gR1 for Windows download

Oracle Issues Pile of 51 Security Patches

Oracle Issues Pile of 51 Security Patches - By Lisa Vaas

"Oracle releases a long list of patches and scores them in a manner that some say downplays the true risks.

Oracle on Oct. 16 released 51 security fixes, including 27 patches for the beating heart of so many enterprises: the Oracle database."

Interesting article by Lisa that confirms my suspicions here last night that the scores seem low for most of the reported fixes and particularly for the remotely exploitable bugs that do not require authentication.

October 2007 Critical Patch Update (CPU) is out

The latest in the sequence of Oracle critical patch updates - the "Oracle Critical Patch Update - October 2007" is out this evening. The advisory states that there are 51 new security fixes across all products. This is the first CPU that uses the CVSS version 2.0 scoring mechanism / algorithm. The credits go out to the usual bunch of people, including Esteban, David, Alex and Joxean. A new name is Johannes Griel of SEC.

There are 27 fixes for the database itself and of those 5 can be exploited remotely over a network connection without a username and password. These issues alone should be enough for anyone to consider patching as soon as possible. The application server includes 11 fixes of which 7 again can be remotely exploited across a network connection without a username and password. There are 8 new fixes for E-Business Suite and one of those is again remotely exploitable without authentication. OEM has 2 fixes. Peoplesoft and JD Edwards 2 fixes.

What is interesting are the CVSS scores, why would remotely exploitable bugs without authentication get lower scores that those that require a valid connection to the database? presumably because more people have access to authenticated sessions or opprtunity to create those sessions that non-authenticated ones. i.e. thousands of users may have an application account that accesses the database and it may be posisble to exploit via the application interface or a web interface but a much smaller number of people can get direct TNS access to the database?

The number of fixes is not the maximum seen over the period that we have had quarterly patches but its not massively low, 51 fixes is still a lot of security fixes for a company to issue. Is the trend going down or not?

Nice paper on time based blind SQL

Yesterday I got an email from Chema Alonso who told me about his recent paper titled "Time-Based Blind SQL Injection with Heavy Queries" which explores the techniques of blind SQL Injection using time based delays to infer values in the database that cannot be read directly. This technique uses heavy queries (using anti-tuning technques) that deliberatley take a long time to run when a value in the where clause turns out to be TRUE or FALSE. The technique can also use packages such as xp_cmdshell in SQL Server or DBMS_LOCK in Oracle to cause a specific delay. In this way the hacker doesn't need to see any data coming back but simply needs to see the response time of the query. The paper looks at a technique of creating badly performing queries that execute por not based on a value (any value) in the database. This way a "newton raphson" like technique can be used to home in on the value sought based on whether the query takes a long time or runs quickly.

This is a nice paper summarising the technqiues.

Creating a SYSDBA backdoor

Today Paul has released a new paper on his web site titled "Oracle SYSDBA backdoor" showing how a hacker might create a SYSDBA connection in the database and hide it. This is an interesting paper and it highlights the issue known for a long time that there is a disjoint between the password file and the database. I have seen this on a number of professional audits where the contents of the password file are out of step with the database. This is often caused by application vendors installing canned versions of their application and also snapshots of databases that include password files.

Paul shows how to create a hacker user in the database and then grant it SYSDBA rights; no commit needed when you create a user Paul :-) and then goes on to show how the fixed view gv$pwdfile_users can be modified in the binary to hide the hacker user. This technique was first shown in a great paper "Undocumented Oracle - What They Didn't Teach You At Oracle" that shows how to modify a v$ view - its referenced on my undocumented Oracle page.

The hack calls for the copying of the password file at the OS level, whilst this can be done from within the database as a SYSDBA user is creates a much bigger footprint of evidence when its done; Paul's example shows it done at the OS level which is simpler.

Also the database has to be restarted for the modified binary to come into play although as Paul suggests this may be possible to avoid. Stopping and starting the database will obviously also create a big footprint in the evidence world. The stop and start will create entries in the alert log, the sysdba connection will be recorded in the SYSDBA action trace files (cannot be turned off) and more.

As Paul suggests checksumming is a good idea in the database and on the OS binaries with a tool such as Tripwire. The hack can be seen to work, its not trivial remotely and it would be reasonably "noisy" to do.

A simpler solution to the problem is to set remote_login_passwordfile = NONE as i recommend to clients as this would prevent the remote authentication as SYSDBA. If SYSDBA connections are needed for RMAN or OEM then this is harder to avoid. It would not be too difficult also to limit SYSDBA connections from remote sites using a firewall as the TNS packets identify a SYSDBA connection also valid_node_checking can be used to limit the database connections at the TNS level.

Nice interesting paper though Paul and worth a read.

Extreme SQL Injection

I saw today a link on Tom's blog to a cartoon that shows how SQL injection could transfer to the real world. The cartoon was pointed out to me before that by patrick. The cartoon shows how you could name your children with such a name like "Robert') drop table students--" so that when they were entered into the school computer an attack could occur. Its a joke but a serious message is included, any data that can end up being used in a SQL statement is a potential attack vector for SQL Injection. Patrick also told me that his colleague beat this cartoon by two years with a similar attack talked about in his post "How to break the National Identity Register". Obviously using names in the sense of naming your child like this is carzy to effect a SQL injection attack but the idea is not crazy, what would happen if you filled in a form with a pen that is then later read by some sort of reader into a computer - if you added an injectable payload then it could work.

The fastest Oracle password cracker in the world is released!!!

Yesterday Laszlo Toth let me know that he has finally released his Oracle password cracker to the world under a GPLv2 license and including source code of course. I have known Laszlo's cracker for quite a while and have used it on real assessments and found it to be very fast and reliable. Laszlo has added the 11g password algorithm and uses an approach that cracks the old DES based hash first and then when its found the password (if it finds the password) it then solves the case sensitivity problem with the new hash. This cracker has the following features (taken straight from Laszlo's page):

  • Oracle password hash attack
  • Oracle password hash attack for 11g. It tries to crack the old hash and checks the case sensitivity with the new algorithm.
  • 8i authentication attack without oracle dlls
  • 9i and 10g authentication attack with oracle dlls
  • Dictionary attack
  • Incremental brute force attack
  • Multithreaded
  • Resume mode

The end of the paper includes a speed comparision with Alex's checkpwd (BTW, Alex is working on a version 2 and this new version includes a lot of new features, whilst not giving it the all out speed, it will give it a great array of features) and the excellent orabf. Its getting to the point where anyone performing an assessment may use more than one of the free Oracle crackers available to get all the features.

Laszlo's tool also does an Oracle 8i, 9i and 10g authentication attacks as shown in his paper talked about here yesterday.

I did a couple of quick tests to see how woraauthbf works with an Oracle 11g password. First i used a simple peice of SQL from Laszlo's paper to get the details in 11g for the SCOTT user to crack his password:

SQL> select||':'||u.password||':'||substr(u.spare4,3,63)||':'||||':'||sys_context('USER
2 from sys.user$ u, sys.V_$DATABASE d where u.type#=1
3 and'SCOTT'
4 /


Then i saved this to a file called 11g_test.txt:

Password Hash file for woraauthbf

The text file is called 11g_test.txt and is available from here. OK, now I can run the password cracker. I first run in dictionary mode and I used Alex Kornbrusts excellent password_file.txt included with his checkpwd tool. Here is the output:

Dictionary attack with woraauthbf

That clearly shows that the cracker performed well and found that SCOTT still has its default password of TIGER except that its in lower case, it correctly found that I had set the password to the lower case value but it also worked fast as tiger is still a default password irrespective of the case of the leters used. Next I changed the password for the SCOTT user in SQL*Plus, i first saved the SQL select statement that is used to get the details the cracker needs:

SQL> save pwd.sql
Created file pwd.sql
SQL> alter user scott identified by Cra3k;

User altered.

SQL> @pwd



And then I saved the output to a new file called 11g_test2.txt with the same format as the first file. Then I could run the cracker againin dictionary mode:

Dictionary attack with woraauthbf

This time the password is not found (as its not a dictionary word - well not in this dictionary, if the orabf permute tool was used it would most likely have found it). The tool is very fast though in dictionary mode, it is going at 515,000 hashes per second on my dual core laptop and did the whole file in 3 seconds. Lets now run the cracker in brute force mode and see if it can find the password (I used the same file 11g_test2.txt):

Brute Force attack with woraauthbf

This tool is fast, over one million hashes per second (faster than orabf on the same machine) and faster in terms of elapsed time also and of course it found the case sensitive password.

Weakness in Oracles new 11g authentication protocol

Laszlo Toth has released a paper analysing the new 11g authentication protocol used to authenticate users to the database. The paper is titled "Initial analysis of Oracle native authentication version 11g" and it describes the authentication mechanism. The O5Logon protocol is a changed/Improved? version of the O3Logon protocol used in 10g and earlier. Laszlo also includes some proof of concept code written in C to decrypt the database password if the Server session key, Client session key, new 11g password hash and the AUTH_PASSWORD are known. Laszlo includes an example session using his proof of concept code to show that a password can be retrieved.

This means that the same weakness that existed in earlier versions of the authentication are still in evidence; that if the password hash is known (Oracle have made some efforts to better secure the hash by removing it from DBA_USERS for instance) then the password can be retrieved from session sniffing. Of course as Laszlo points out the simple solution would be to use network encryption to prevent session sniffing and of course the key issue is to not let password hashes fall into a hackers hands. As Laszlo also points out because the password algorithm is known a brute force attack is also possible. I have used this type of attack during Oracle database security audits if i find SQL*Net traces that include the relevant keys and AUTH_PASSWORD.

One key observation that is not included in Laszlo's paper but we have discussed off-line is the fact that the database server also sends the SALT in the AUTH_VFR_DATA field. This in my opinion decreases the value of the SALT. OK, the database now has hashed passwords that are different (Not withstanding the fact that the old hash is also stored in the database!!) for each time you assign the same password to the same user and also different password hashes across different databases for the same user/password combination but if the SALT is available remotely just for the asking then where is its value? - any connection attempt to the database for any particular user results in the SALT being sent to the client. The SALT can then be used in the new 11g password algorithm to dictionary attack or brute force attack the password. This lessens the value of the SALT in my opinion as its readilly available. Quite obviously the same solution of using network encryption will be useful to prevent sniffing of the SALT (and the rest of the values) from the wire BUT this wont prevent anyone with nefarious reasons to connect or used a client to the Oracle database with no knowledge of the password and use SQL*Net trace level 16 (support) to get the SQL*Net packet contents. Of course they need physical access to connect and also if encryption is used the means to use that but nowadays a larger number of incidents and attacks are internal.

This is, as usual a nice paper from Laszlo.

Nice SQL Injection cheat sheet

I saw an entry on Alex's blog refering to a nice SQL Injection cheat sheet for Oracle that includes a good overview of some of the common types of syntax that can be used in SQL Injection attacks. The author admits he is new to Oracle but the list is a good first stab at it.

Also referenced in the same page is a link to a more complete SQL Injection reference for other databases including MySQL, MS SQL Server PostGreSQL and of course Oracle. This paper is titled "SQL Injection Cheat Sheet" and is an excellent reference to the types of SQL injection available.

The first Oracle 11g password cracker

vonjeek from The hackers Choice has updated his Oracle password cracker to include the 11g password hashes and to use the 11g SHA1 password algorithm. The cracker also takes advantage of the fact that 11g keeps the old DES based/derived hash in the same place as the new SHA-1 hash. The THC 11g Password cracker is shown below in action for a sample password:

Oracle 11g Password Cracker

The password cracker exploits the fact that the old DES hash is stored. Therefore the upper case version of a password can be cracked first. If the password guessed generates a hash that matches that stored in the SYS.USER$.PASSWORD column then a further attack can be made on the SHA-1 hash to determine the case sensitive version of the password. This reduces the number of guesses necessary. As you can see the tool is graphically based and does a test based on user=pwd, dictionary attack then a brute force attack using the old DES based hash first. The readme is shown below:

Oracle 11g Password Cracker

explains how the cracker works. Nice tool!!