Call: +44 (0)1904 557620 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: "SQL Firewall in 23c - UKOUG and Scripts"] [Next entry: "Oracle Forensics - Missing User IDs"]

Secure Password Store - Wallets



One of the key security issues I come across when performing security audits is the proliferation of passwords located on SQL files and OS shell scripts and more. If you get access to the server you can learn a lot of the database passwords and if you were an attacker use them. We see the same issues in binaries also where the password is hard coded into C code for instance.

Even if you pass in the password on the command line then often in a Unix/Linux environment the password is visible in process lists or is captured in OS history files.

There have been many solutions over the years including adding spaces to the process list to shove the passwords off to the right or clearing history files or adding passwords to hidden files or to environment variables.

The better solution if a password must be used in a program or script is to use a wallet and Oracles secure password store where credentials are stored in a wallet. This is simple to use and then the username and password is no longer visible when used as this is replaced by "/" - slash. On connecting to the database the OCI libraries (The original OCI not the Cloud) know that the method is OCI_CRED_EXT on OCISessionBegin() and know that the sqlnet.ora SQLNET.WALLET_OVERRIDE=TRUE means do and look for the credentials in the wallet referenced also in the sqlnet.ora. So, in this case the password is not seen in clear text and is retrieved from the wallet and passed to the OCI connection sequence of C functions.

So, to use this is simple. If you use a full client the tools are available but if you use an instant client then you can create the wallet on the server and copy to the PC or client Linux/Unix box.

First create the wallet on the server:

[root@localhost ~]# su - oracle
[oracle@localhost ~]$ pwd
/home/oracle
[oracle@localhost ~]$ mkdir client
[oracle@localhost ~]$ cd client
[oracle@localhost client]$ orapki wallet create -wallet . -auto_login
Oracle PKI Tool Release 23.2.0.0.0 - Production
Version 23.2.0.0.0
Copyright (c) 2004, 2023, Oracle and/or its affiliates. All rights reserved.
Enter password:
Enter password again:
Operation is successfully completed.
[oracle@localhost client]$


The wallet password is used only to manage the wallet not to open it. In this case we set -auto_login as we want the wallet to auto open on the PC BUT we cannot set it to -auto_login_local on the server as the wallet will then not auto open on the PC. This is a security issue itself as we want the wallet to auto-open BUT it means an attacker can copy the wallet to their own PC and then connect to the database without knowledge of the password. We have two options here; the first is to get the wallet tools on the client and use auto_login_local; the second is to not use auto_login at all BUT the user would need to pass the wallet password on database login to open it and then just passes the original problem to the next step; i.e. a password is needed. So, if you have to use instant clients and wallets then this is a security risk. You can also use other database features such as Database Vault or logon triggers to limit any connection from a wallet to known clients.

OK, so now as a database credential to the wallet

[oracle@localhost client]$ mkstore -wrl . -createCredential freepdb1 scanner scanner
Oracle Secret Store Tool Release 23.2.0.0.0 - Production
Version 23.2.0.0.0
Copyright (c) 2004, 2023, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:
[oracle@localhost client]$

As you can see the database credentials (username/password) are linked to the TNS entry so if you would like to connect to multiple database users then you can add multiple TNS entry linked credentials to the wallet. i.e. one per user and then add these to the TNS names and use each TNS for each user added.

Now we an ftp the server created wallet (secure password store) from the database server to the client PC. Then create the sqlnet.ora on the client and include:

WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=(DIRECTORY=C:\_aa\PB\bin)))
SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION=FALSE
SSL_VERSION = 0

In my file i point to my wallet location and also set SQLNET.WALLET_OVERRIDE=TRUE to say use the wallet for the password. The tnsnames.ora is just a standard entry as follows:

FREEPDB1=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.18)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=freepdb1)))

Remember if we want to connect to multiple credentials (users/password) in a wallet we need multiple TNS entries and multiple credentials in the wallet. So, now lets connect to the database using the wallet (secure password store)

C:\_aa\PD>sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Wed Nov 29 15:28:51 2023

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

SQL> connect /@freepdb1
Connected.
SQL>

As you can see I can connect to the database now without using a password directly on command line or in a script should I want to connect to the database in a script.

In Oracle 23c Oracle have deprecated the mkstore command. Oracle state that they will be enhancing the orapki tool after 23c to add the functionality in mkstore to it.

#oracleace #sym_42 #23c #wallet #oracle #secure #password #store #credentials