Top STIG – Part 2 (Obscuring Credentials)


The next two STIG controls in this series on CAT I vulnerabilities relate to the obscuring of passwords as they are entered into applications, either on the command line or in a user interface. The trick to these controls isn’t so much technical – hiding passwords from casual observers or from system monitoring isn’t that hard – but the idea that as the enforcer of the Database STIG the DBA is responsible for understanding more than just what happens inside the database. You also need to understand your client technology stack, database networking, where their potential vulnerabilities are, and how to mitigate them.

V-61843 & V-61845: Applications must obscure feedback of authentication information; when using command-line tools such as Oracle SQL*Plus, which can accept a plain-text password, users must use an alternative logon method that does not expose the password.

To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.

Obfuscation of user-provided information when typed into the system is a method used in addressing this risk.

For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.

Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.

This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

These controls are somewhat trickier than others, because you can’t just “scan” for the current state and tweak an initialization parameter to fix things if they are off. In order to make sure things are properly protected, you need to maintain an ongoing relationship with application developers and have a voice in the software development and/or acquisition process. Make sure that security is considered from the beginning of any new design or product evaluation.

In particular for these controls, you need to know if any client applications – current or planned – allow passwords to be specified in clear text from the command line, or otherwise fail to obfuscate authentication information during the login process. As you just read, V-61843 prohibits the exposure of authentication data for client applications in general, while V-61845 deals specifically with SQL*Plus. It states:

To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.

Obfuscation of user-provided information when typed into the system is a method used in addressing this risk.

For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.

Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.

SQL*Plus is an essential part of any Oracle installation. SQL*Plus cannot be configured not to accept a plain-text password. Since the typical SQL*Plus user is a database administrator, the consequences of password compromise are particularly serious. Therefore, the use of plain-text passwords must be prohibited, as a matter of practice and procedure.

For Oracle SQL*Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation:

1) Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval.
2) Train all users of the tool in the importance of not using the plain-text password option and in how to keep the password hidden.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

There are a couple of ways to deal with this. First, you can educate all users of SQL*Plus (and other like tools) how to login without exposing the password on the command line. For example, we don’t want users to do something like this, which would expose the username and password to any other user of the system running a “ps” command or monitoring running processes, like a sysadmin:

# sqlplus pete/mypassword@tnsdbname

In the case of SQL*Plus what we do want is for everyone to use the /nolog flag. This starts SQL*Plus without prompting for any connection information. Then we enter a connect command from the SQL prompt to complete the connection, like so:

# sqlplus /nolog
SQL*Plus: Release 12.1.0.2.0 Production on Thu Apr 9 01:17:22 2020

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

SQL> conn pete@pdb1
Enter password:
Connected.

SQL> conn / as sysdba
Connected.

Then the only thing a user will see if running ps, top, or any other monitoring tools is “/nolog” option. This prevents monitors from seeing or recording either the password, the username (or role), or the TNS alias that you are using in your connection. Notice that I didn’t provide the password in the connect command either. I left it out and let the program prompt me for it, automatically masking the feedback, so even someone shoulder-surfing me wouldn’t see what my password was.

Note: Exposing the password on the command line is bad, but the problem doesn’t go away when you exit the program. Most operating systems maintain a history of shell commands that the user can scroll through like a redial feature on a phone. Those commands that you enter – including your passwords – are maintained in that history where anyone with sufficient privileges can find them weeks or months later.

A second method would be to use an Oracle Wallet (aka External Password Store) to hold encrypted credentials that can be used by a client application to authenticate. That method is described here. Most clients – including application servers like Tomcat – can support the use of an Oracle Wallet to hold credentials so that they don’t need to be embedded in configuration files. I would still recommend the use of /nolog with SQL*Plus, even if using a wallet, just to maintain obfuscation of the username and network connection information.

If you choose either of these options, for full STIG compliance you must be able to prove that all of your users have been trained in these methods of connection and demonstrate that they are using them – most likely through a monitoring audit of client systems.

For Oracle SQL*Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation, verify that the system documentation explains the need for the tool, who uses it, and any relevant mitigations; and that AO approval has been obtained. If not, this is a finding.

Request evidence that all users of the tool are trained in the importance of not using the plain-text password option and in how to keep the password hidden; and that they adhere to this practice. If not, this is a finding.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

A third option would be to require all users to use accounts authenticated with PKI certificates, such as those provided in a Common Access Card. If there is no password to expose, then the risk is eliminated. Using a CAC to authenticate users to the database is described here.

It is important to note that other controls, while not themselves CAT I severity, also play a factor in how these two CAT I’s are resolved.

  • V-61703, V-61705, V-61707, and V-61709 require the use of multi-factor authentication, like a CAC card, for virtually all user authentication.
  • V-61737 requires that “DBMS passwords must not be stored in compiled, encoded, or encrypted batch jobs or compiled, encoded, or encrypted application source code.”

These also effectively require the DBA to be familiar with approved client applications and their basic security mechanisms.

Because the Database STIG crosses several boundaries between the database, operating system, network, and applications, ensuring a STIG-compliant environment requires the DBA; system, network and application administrators; developers; and security managers to work together as a team. If nothing else, take away from these controls the idea that a DBA needs to be proactively involved in the design and configuration of the database infrastructure, including the application and client technology stack.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.