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; USERNAME ------------------------------------------------------------ TEST
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; USERNAME PASSWORD_VERSIONS --------------------------------------- ----------------- ANONYMOUS 11G 12C APEX_190100 11G 12C APEX_LISTENER 11G 12C APEX_PUBLIC_USER 11G 12C APEX_REST_PUBLIC_USER 11G 12C APP_USER1 11G 12C APP_USER2 11G 12C AV 11G 12C BI 11G 12C CTXSYS 11G 12C DBJSON 11G 12C FLOWS_FILES 11G 12C HR 11G 12C HRREST 11G 12C IX 11G 12C MYDBA 11G 12C HTTP OBE 11G 12C OE 11G 12C ORDS_METADATA 11G 12C ORDS_PUBLIC_USER 11G 12C PDBADMIN 11G 12C PM 11G 12C SCOTT 11G 12C HTTP SH 11G 12C SYS 11G 12C SYSTEM 11G 12C TEST 12C TESTUSER 12C XDBEXT 11G 12C HTTP XDBPM 11G 12C XFILES 11G 12C HTTP 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
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.
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; update_password_script ----------------------------------------------------------- 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.