Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 53 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Pete Finnigan's Oracle security weblog


Home » Archives » August 2007 » Oracle 11g Security - part 2 {The beginning}

[Previous entry: "11g and Oracle Security"] [Next entry: "Oracle 11g Security - part 3 {peek and poke}"]

Oracle 11g Security - part 2 {The beginning}

August 26th, 2007 by Pete


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.

There has been 2 Comments posted on this article


August 27th, 2007 at 01:49 pm

Patrick Wolf says:

Hi Pete,

you write "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."

Which large numbers of recently security bugs are you referring too? CPU July'07 shows one for APEX 3.0. Oracle 11g contains 3.0.1.x which already includes the latest patchset.

I would be very interested to get more infos about that, because security issues are always something a developer should have a look at.

Thanks
Patrick



August 27th, 2007 at 10:41 pm

Pete says:

Hi Patrick,

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.

cheers

Pete


August 2007
SMTWTFS
   1234
567891011
12131415161718
19202122232425
262728293031 

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.

Weblog Home
Weblog Archives


Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0


Valid XHTML 1.0!