Default Passwords

De OWASP
Saltar a: navegación, buscar

Contenido

Remove Default Passwords

Background

During Oracle software installation and database creation, it is common for accounts to be created and then forgotten. These accounts, which often carry default passwords (such as "tiger" for SCOTT), are favored entry points for intruders. You would be shocked to hear how many production database installations I have audited that use "change_on_install" or "oracle" as the password for SYS. Your first line of action should be to immediately identify and remove these default passwords.

Strategy

How do you identify the accounts with default passwords? One option is to try to login to the account using the default password—but this is definitely a cumbersome approach, not to mention a time-consuming one.

Fortunately, there is a more elegant option. Take a look at the password column in the view DBA_USERS:

SQL> select username, password

 2  from dba_users
 3  where username = 'SCOTT';

USERNAME PASSWORD


------------------

SCOTT F894844C34402B67

The password is hashed and thus undecipherable, but we know that SCOTT's password is "tiger." Therefore, the hash value for "tiger" when userid is "scott" is F894844C34402B67. Now, if SCOTT's password changes, this hash value also changes. You can then confirm in the view DBA_USERS to see if SCOTT's password matches this hash value, which will verify the password as "tiger." Note however that the hash value is not a hash value of the password itself; if another user has the password "tiger", that hash value will be different.

SQL> create user scott2 identified by tiger;

User created.

SQL> select username, password

 2  from dba_users
 3  where username = 'SCOTT2';

USERNAME PASSWORD


--------------------

SCOTT2 C44C11D4C34DB67D

Note the different hash value ( C44C11D4C34DB67D), even though the password is identical.

So how can you use this information? It's simple. If you create the default users with default passwords, you will come to know the hash values of those passwords. Then you can build a table of such accounts and the hashed values of the default passwords and compare them against the password hashes stored in the data dictionary.

In January 2006, Oracle made a downloadable utility available for identifying default passwords and their users. This utility is available on MetaLink as described in the document ID 340009.1. As of this writing, the utility checks a handful of default accounts in a manner similar to that described above; by the time you read this, however, its functionality may well have expanded.

Furthermore, security expert Pete Finnigan has done an excellent job collecting all such default accounts created during various Oracle and third-party installations, which he has exposed for public use in his Web site. (Standard disclaimer: Oracle does not validate the content of third-party web sites.) Rather than reinventing the wheel, we will use Pete's work and thank him profusely. I have changed his approach a little bit, however.

First, create the table to store the default accounts and default password.

CREATE TABLE osp_accounts (

  product          VARCHAR2(30),
  security_level   NUMBER(1),
  username         VARCHAR2(30),
  password         VARCHAR2(30),
  hash_value       VARCHAR2(30),
  commentary       VARCHAR2(200)

)

Then you can load the table using data collected by Pete. (Download the script here.) After the table is loaded, you are ready to search for default passwords. I use a very simple SQL statement to find out the users:

col password format a20 col account_status format a20 col username format a15 select o.username, o.password, d.account_status from dba_users d, osp_accounts o where o.hash_value = d.password / USERNAME PASSWORD ACCOUNT_STATUS


-------------------- --------------------

CTXSYS CHANGE_ON_INSTALL OPEN OLAPSYS MANAGER OPEN DIP DIP EXPIRED & LOCKED DMSYS DMSYS OPEN EXFSYS EXFSYS EXPIRED & LOCKED SYSTEM ORACLE OPEN WMSYS WMSYS EXPIRED & LOCKED XDB CHANGE_ON_INSTALL EXPIRED & LOCKED OUTLN OUTLN OPEN SCOTT TIGER OPEN SYS ORACLE OPEN

Here you can see some of the most vulnerable of situations, especially the last line, which says SYS and the password is "ORACLE" (as is that of SYSTEM)! It may not be "change_on_install", but it's just as predictable.

The vulnerability varies across versions. In Oracle Database 10g and later, the database installation has a prompt that asks what the password should be, instead of assuming it to be "change_on_install" or something else. Because the user is forced to make a decision, it is likely that the password will be a non-default one. However, if the user chooses something as predictable as "oracle", then the point is moot. (Perhaps "oracle" was chosen when the database was being built prior to production as a convenience to the DBAs. After it went to production, the password stuck around.)

In versions prior to Oracle Database 10g, the password is not prompted to be entered, and hence it is likely that the default password—e.g. "change_on_install" for SYS and "manager" for SYSTEM—is active. This tool will help you identify such cases.

Also note that the userid SCOTT—the demo account for learning SQL techniques—may be fine for a development database, but not a production one. It is a potential back-door entry for intruders and you should immediately drop it.

Accounts like CTXSYS, DMSYS, and OLAPSYS, are required for Oracle tools. The best strategy is to drop these users if you are not using these options. If you are not sure you are using them, or just want to reserve the opportunity, you can keep these accounts but lock them from connections. To lock an account and expire the password, you would issue:

alter user dmsys account lock expire password; which will set the account status to EXPIRED & LOCKED. When the user tries to login, the following error will be raised:

ERROR: ORA-28000: the account is locked Warning: You are no longer connected to ORACLE.

Change the password for all accounts you cannot lock. One such account is DBNSMP, but we'll discuss that later.

Implications

The locking of unused accounts shouldn't cause any problems. Action Plan Identify the unused accounts. Lock them and expire their passwords.