Top STIG – Part 5 (Default Passwords)

One of the most common attack vectors for any hacker is checking to see if you have reset default passwords on service and administrator accounts. Almost every piece of hardware or software comes with some default way to login the first time, and a lot of people are really bad at changing those credentials to be more secure. Oracle databases and DBAs are no exception to that, which is why this week’s CAT I STIG control is all about customization.

V-61541: DBMS default accounts must be assigned custom passwords.

Password maximum lifetime is the maximum period of time, (typically in days) a user’s password may be in effect before the user is forced to change it.

Passwords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.

One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.

DBMS default passwords provide a commonly known and exploited means for unauthorized access to database installations.

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

Depending on the options you have installed, Oracle could have several service accounts that are used to hold schemas and code for various internal functions. These accounts often have “SYS” in their name, though some like “ANONYMOUS” may not. In almost all cases these accounts should not only have their default passwords changed to something new, but they should also be disabled for login completely, per STIG control V-61849, which recommends locking any accounts when not in use.

Fortunately, Oracle provides a view that makes these accounts easy to identify: DBA_USERS_WITH_DEFPWD.

SQL> select username from dba_users_with_defpwd;


Password Hash Strength

So now we know which users need their passwords reset, but we need to confirm something else before we proceed. Oracle has used several different hashing algorithms to protect passwords over the years. The most recent versions are 10g, 11g, and 12c (which supports 12cR1 and newer). The 10g passwords were hashed with a standard DES algorithm, and were not case-sensitive. The 11g passwords were hashed with SHA-1 and added case-sensitivity, and the 12c passwords are hashed with SHA-512. It is possible for an account password to have all three hashes applied to it, and essentially be able to support clients and authentication protocols for all three versions. See this excellent write up for more details.

The PASSWORD_VERSIONS column of the DBA_USERS view will let you know which hashing versions have been applied originally and/or most recently for a given user.

SQL> select username, password_versions from dba_users where password_versions is not null order by username;

--------------------------------------- -----------------
APEX_190100				11G 12C
APP_USER1				11G 12C
APP_USER2				11G 12C
AV					11G 12C
BI					11G 12C
CTXSYS					11G 12C
DBJSON					11G 12C
HR					11G 12C
HRREST					11G 12C
IX					11G 12C
MYDBA					11G 12C HTTP
OBE					11G 12C
OE					11G 12C
PM					11G 12C
SCOTT					11G 12C HTTP
SH					11G 12C
SYS					11G 12C
SYSTEM					11G 12C
TEST					12C
XDBPM					11G 12C
XS$NULL 				11G

32 rows selected.

New users will always have their passwords hashed to the highest level available to the system. Users with older hashing formats will have those hashes recalculated in addition to the newer ones. In order to eliminate the older (and less secure) password hashes, follow these steps from Oracle’s documentation.

Authentication Protocol Support

The sqlnet.allowed_logon_version_server and the sqlnet.allowed_logon_version_client parameters in the sqlnet.ora file set the minimum acceptable authentication protocol supported for logins.

The “client” parameter controls what protocols are supported when connecting as a client. The “server” parameter controls what protocols are supported when receiving connections as a server. In both cases, the versioning will impact which hashing versions will be usable when authenticating. 10 or lower will support any of the 3 password hashing algorithms. 11 will only support 11g and 12c hashes. Setting the parameter to 12 can a bit misleading because it will force 12c clients but still allow 11g hashes. To enforce the use of the 12c hashing, the parameter must be set to 12a.

As previously noted, beginning with 12cR1, the database parameter sec_case_sensitive_logon was deprecated in favor of using the SQLNET.ORA parameters to control which hashing algorithms to support.

How Oracle Stores Passwords – Sean D. Stuber

In order to ensure that only the most secure authentication protocols and password hashes are allowed to be used, set the parameters to their highest available level.


Password Complexity

It is important that passwords themselves, and not just the hashes stored in the database, are also as secure as possible. Several additional STIG guidelines mandate the number and types of various characters that must be in a password, as well as minimum length, expiration dates, and the like.

  • V-61719: The DBMS must support organizational requirements to enforce minimum password length.
  • V-61721: The DBMS must support organizational requirements to prohibit password reuse for the organization-defined number of generations.
  • V-61723: The DBMS must support organizational requirements to enforce password complexity by the number of upper-case characters used.
  • V-61725: The DBMS must support organizational requirements to enforce password complexity by the number of lower-case characters used.
  • V-61727: The DBMS must support organizational requirements to enforce password complexity by the number of numeric characters used.
  • V-61729: The DBMS must support organizational requirements to enforce password complexity by the number of special characters used.
  • V-61731: The DBMS must support organizational requirements to enforce the number of characters that get changed when passwords are changed.

In an earlier post I detailed a method for creating a password verification function that included not only these individual checks, but also a dictionary word check.

Creating a Script

With all of the appropriate authentication protocol, hashing complexity, and password complexity rules in place, it is time to script out a password change for any default users identified with default passwords. In an earlier post, I described a method to generate random complex passwords using a PL/SQL function. Using this function, we can script out random password changes for all default users:

SQL> select 'alter user ' || username
       ||' identified by '|| utl_password.generate_random(20)
       ||' account lock;' update_password_script
  from dba_users_with_defpwd;

alter user TEST identified by M5xUN_YYP_Dpzl8Gq_pa account lock;

Copy and paste the output and run it as a script, securing any pre-defined accounts that still have their default password.

One thought on “Top STIG – Part 5 (Default Passwords)

Leave a Reply

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

You are commenting using your 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.