Call: +44 (0)7759 277220 Call
Blog

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.

[Previous entry: "Weakness in Oracles new 11g authentication protocol"] [Next entry: "Extreme SQL Injection"]

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.name||':'||u.password||':'||substr(u.spare4,3,63)||':'||d.name||':'||sys_context('USER
2 from sys.user$ u, sys.V_$DATABASE d where u.type#=1
3 and u.name='SCOTT'
4 /

U.NAME||':'||U.PASSWORD||':'||SUBSTR(U.SPARE4,3,63)||':'||D.NAME||':'||SYS_CONTE
--------------------------------------------------------------------------------
SCOTT:F894844C34402B67:CC92BE1125BD6136A74370F64B3957C9016402C0214E307BFCD34EF02
806shockedRA11G:vostok:


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

U.NAME||':'||U.PASSWORD||':'||SUBSTR(U.SPARE4,3,63)||':'||D.NAME||':'||SYS_CONTE
--------------------------------------------------------------------------------
SCOTT:9B5981663723A979:71C46D7FD2AB8A607A93489E899C08FFDA75B147030761978E640EF57
C35shockedRA11G:vostok:


SQL>


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.

There has been 4 Comments posted on this article


October 9th, 2007 at 11:22 am

Pete Finnigan says:

While its brute force speed is impressive, saying that it is the fastest oracle password cracker is misleading. Password cracking is not just about pwd/s, it is also about how you choose these passwords.

Based on my observations on real passwords, John the Ripper (incremental mode) has the same discovery rate than a "stupid" brute forcer when the brute forcer runs 35 times faster, even when it orders letters by order of appearance instead of alphabetic order. (Based on a large pwdump output, about 7000 *french* accounts. This is not so scientific, and might only apply to french passwords ...)

And of course Markov filtering is lots better smile



October 10th, 2007 at 09:16 am

Pete Finnigan says:

Thanks for your comment. I said its the fastest "Oracle" password cracker not "THE" fastest cracker around. The fact you reference pwdump suggests that you are talking about Windows password crackers. I am talking here about Oracle database password crackers.

You are of course also right that the choice of password guesses and order is very important as are character order choice algorithms as well as techniques such as distributed cracking.

cheers

Pete



October 10th, 2007 at 09:50 am

Pete Finnigan says:

Good point, this result is not directly applicable to oracle passwords, because they are not chosen by "standard" users, but by DBAs.

On the other hand, my experience showed that most oracle passwords are identical to the login!

I'm a nitpicker, and it should be noted that with "strong" passwords the most important parameter is pwd/s, and this tool is the most suited for that task.



October 10th, 2007 at 10:21 am

Pete Finnigan says:

big grin , yes my experience is the same, a lot of databases tend to have passwords set to the default values or to the username!!

Thanks for your furthre comment

cheers

Pete