Pete Finnigan's Oracle Security Weblog

OK, I left the last post on 11g 4 days ago with a promise for "more tomorrow.." - well as they say tomorrow never comes. Well its been busy the last few days, becoming the boss of my own company has meant I needed to spend time writing proposals, dealing with leads, emails and so on so blogging and 11g research took a bit of a back seat for a few days.

OK, Oracle 11g Security; The easiest way to hack an Oracle database is to have a password for a user account (either legally or not) - the risk if you have someone with bad intent who legally has an account and password falls out of the scope of this particular discussion as he has acess to the database and his goal maybe to increase his privileges via an exploit, either exploiting a bug or a configuration. OK, back to the story, the case we are after is a hacker (lets just call anyone not legally entering the database; suceeding or not, a hacker) who doesnt have a valid database account or password for that account. How does he get in? - well he first can guess an account name and then attempt to guess a password. The obvious accounts to guess are default accounts and Oracle is famous for including a lot of them, far more than any other major software. Again the simplest attack is to just try and log in, so fancy tools or exploit code, just try and login, you can use SQL*Plus, TOAD or many more tools or even simple choices such as Excel or Word. OK, if he cannot guess a default account password easilly then he can try and brute force the password or use a dictionary attack. You can use simple Perl scripts (There are examples on my Oracle security tools page) or even a C program using OCI API's. This is a limited attack but can be successful, reasonable rates of password tries can be made. A better attack is if you can get hold of the password hashes for all the database users, then a brute force or dictionary attack can be done using password crackers written in C. There are a few free password crackers available now.

This is the simplest way in and more worringly from doing security audits of Oracle databases it is a realistic way in as all databases I perform Oracle security audits on always have weak passwords, either a password is set to the username, a default user still has a default password or accounts have passwords that are too short, set to dictionary or easy to guess words. Often I see a worrying trend that often a lot of accounts have the same password (interestingly when you install 11g this is the basic option when creating a database - choose the same password for multiple key acounts!

What does 10gR2 have? - The password algorithm used is old and known, its recognised to be weak (this is relative to how much computing power you have), the password hashes can be read easily from the DBA_USERS view and also SYS.USER$ and also SYS.USER_HISTORY$ (old hashes), password management exists but checks for default users are external. The view DBA_USERS in 10gR2 shows:

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options SQL> SQL> select username,password from dba_users; USERNAME PASSWORD ------------------------------ ------------------------------ MGMT_VIEW F25A184809D6458D SYS B024681DBF11A33E SYSTEM F4D9D0B6DF5B383C DBSNMP B4D333BC1130C687 SYSMAN 47561F76D27DEDC6 TESTUSER B222330EE300D65A OUTLN 4A3BA55E08595C81 MDSYS 72979A94BAD2AF80 ORDSYS 7EFA02EC7EA6B86F EXFSYS 66F4EF5650C20355 DMSYS BFBA5A553FD9E28A USERNAME PASSWORD ------------------------------ ------------------------------ WMSYS 7C9BA362F8314299 CTXSYS 71E687F036AD56E5 ANONYMOUS anonymous XDB 88D8364765FCE6AF ORDPLUGINS 88A2B2C183431F00 SI_INFORMTN_SCHEMA 84B8CBCA4D477FA3 OLAPSYS 3FB8EF9DB538647C SCOTT F894844C34402B67 TSMSYS 3DF26A8B17D0F29F BI FA1D2B85B70213F3 PM 72E382A52E89575A USERNAME PASSWORD ------------------------------ ------------------------------ MDDATA DF02A496267DEE66 IX 2BE6F80744E08FEB SH 9793B3777CD3BD1A DIP CE4A36B8E06CA59C OE 9C30855E7E0CB02D HR 6399F3B38EDF3288 28 rows selected. SQL>

For 11gR1 we get:

Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select username,password 2 from dba_users; USERNAME PASSWORD ------------------------------ ------------------------------ DBSNMP SYSMAN MGMT_VIEW SYS SYSTEM FLOWS_FILES MDSYS ORDSYS EXFSYS SCOTT WMSYS USERNAME PASSWORD ------------------------------ ------------------------------ ORACLE_OCM TSMSYS XS$NULL BI WKSYS PM WK_TEST MDDATA IX CTXSYS ANONYMOUS USERNAME PASSWORD ------------------------------ ------------------------------ SH OUTLN DIP OE APEX_PUBLIC_USER HR XDB SPATIAL_CSW_ADMIN_USR WKPROXY SPATIAL_WFS_ADMIN_USR ORDPLUGINS USERNAME PASSWORD ------------------------------ ------------------------------ FLOWS_030000 OWBSYS SI_INFORMTN_SCHEMA OLAPSYS 37 rows selected. SQL>

The password column is empty, the view now has been changed to prevent passwords from being displayed except if they are EXTERNAL or GLOBAL. The worrying thing though is that there are now 37 accounts installed by default, instead of 27. Also worryingly Apex is installed by default, considering its web facing purpose and also the large numbers of receny remotely exploitable bugs without authentication is also worrying.

SQL> select username from dba_users 2 where account_status='OPEN'; USERNAME ------------------------------ SYSMAN DBSNMP SYSTEM SYS MGMT_VIEW SQL>

5 accounts are open. This is still too many in my opinion.

Checking default passwords in 11g is now easier with the new view DBA_USERS_WITH_DEFPWD - see:

SQL> desc dba_users_with_defpwd Name Null? Type ----------------------------------------- -------- ---------------- USERNAME NOT NULL VARCHAR2(30) SQL> select * from dba_users_with_defpwd; USERNAME ------------------------------ DIP MDSYS WK_TEST CTXSYS OUTLN EXFSYS SCOTT MDDATA ORDPLUGINS ORDSYS XDB USERNAME ------------------------------ SI_INFORMTN_SCHEMA WMSYS 13 rows selected. SQL>

This is also a "slight" worry as a default install has 13 default passwords still set. Its slight because (OK, slight is too strong) of:

SQL> edit Wrote file afiedt.buf 1 select d.username,u.account_status 2 from dba_users_with_defpwd d, dba_users u 3* where u.username=d.username SQL> / USERNAME ACCOUNT_STATUS ------------------------------ ------------------------- EXFSYS EXPIRED & LOCKED MDDATA EXPIRED & LOCKED ORDSYS EXPIRED & LOCKED SCOTT EXPIRED & LOCKED OUTLN EXPIRED & LOCKED WMSYS EXPIRED & LOCKED MDSYS EXPIRED & LOCKED ORDPLUGINS EXPIRED & LOCKED WK_TEST EXPIRED & LOCKED XDB EXPIRED & LOCKED DIP EXPIRED & LOCKED USERNAME ACCOUNT_STATUS ------------------------------ ------------------------- SI_INFORMTN_SCHEMA EXPIRED & LOCKED CTXSYS EXPIRED & LOCKED 13 rows selected. SQL>

If we create a new user:

SQL> create user x identified by x; User created.

Then we can see in SYS.USER$ and DBA_USERS:

SQL> set head off SQL> l 1* select * from sys.user$ where name='X' SQL> / 88 X 1 8E9A9A5413F0B5EE 4 3 26-AUG-07 26-AUG-07 0 1 0 0 DEFAULT_CONSUMER_GROUP 0 S:FF5FB0BFD44E35386C0ADDC28AD63E30DC24BABAA57E60D83185AEDE366C SQL> select * from dba_users where username='X'; X 88 OPEN 22-FEB-08 USERS TEMP 26-AUG-07 DEFAULT DEFAULT_CONSUMER_GROUP 10G 11G N SQL>

The above output shows that the default case in 11g is to create a new user with an old DES based password and also a new SHA-1 based password - i.e. 10g and 11g passwords.

If we create the same user in 10gR2 then we get:

SQL> set head off SQL> / 62 X 1 8E9A9A5413F0B5EE 4 3 26-AUG-07 26-AUG-07 0 1 0 0 DEFAULT_CONSUMER_GROUP 0

This confirms that the same password is created - i.e. the old DES based one.

There are still lots of issues and even more research to be explored in my next posts, Oracle have reduced the exposure to password hashes but they can be got in other ways, I will explore this. The password throttling is a good idea but it wont protect against a known default password (if the account is open and the new view has not been checked) or a simple password that can be guessed in a small number of attempts. I support the changes but they will only work really effectively if password management is used, every account has strong passwords and all other sources of revealing hashes have been locked down.

Oracle have clearly embraced the simplest way to attack an Oracle database and taken useful actions to prevent this attack. They have removed the most obvious source or password hashes, they have added a new password algorithm, they have added a built in default password check (more on this later) and they have introduced a throttling process to prevent repeated password guessing with simple connect attempts. They have really started to take security really seriously. Hurrah for Oracle.