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:

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------------------------------SYSMANDBSNMPSYSTEMSYSMGMT_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:

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.

I refer to the 35 Apex bugs fixed in the October 2006 where most of them did not require authentication. Oracle have clearly made great strides with security in 11g but I was disapointed to see that the number of schemas installed for a default installation has gone up and that Apex is a default. I think the default should be that as little as possible is installed and that the customer should choose what is needed to support their own applications. This unfortunately is not the reality as I see a lot of default databases running in production and this increases the attack surface. Apex is a great product but the reality is that not all database customers will use it so to have it installed by default for those customers who don't use it simply increases the attack surface.

About

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.