Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> A few security questions
        
(Message started by: Pete Finnigan on Sep 28^th, 2005, 7:00pm)

Title: A few security questions
Post by Pete Finnigan on Sep 28^th, 2005, 7:00pm

I have a few security related questions and would like to hear from you if these are really an issue in the real world. If yes what their ???risks are. Any comments are appreciated.

1. In the init.ora file, is it mandatory that we need to have the entries REMOTE_OS_AUTHENT and OS_AUTHENT_PREFIX. If yes, what values
should be set? True or False?

2. Using grep -i dba/etc/group and I have the following result: dbadev::511: and dba::510:secadm. Would these be appropriate? If not, what would be the risk?

3. In the dba_profiles table, the SESSIONS_PER_USAER is set to
unlimited.

4. In the dba_profiles table, the password settings are all set to DEFAULT. How to set up to force a password when an account is created?

5. In the system tablespace, we have a lot of objects that are owned by non SYS account.

6. Have a few entries in the sys.link$ whose passwords are not null.

7. What would be the best practices to manage the system accounts? Would it be an idea to keep track of each system account when it is created? The tracking includes creation date, associated applications, and so forth.

Does Oracle have any offical recommendations on these items? Thanks.

Title: Re: A few security questions
Post by Pete Finnigan on Sep 29^th, 2005, 8:26am

Miloann,

Ad 1) REMOTE_OS_AUTHENT should be set to FALSE. For an explanation see http://www.petefinnigan.com/weblog/archives/00000071.htm
I don't think the setting of OS_AUTHENT_PREFIX is very important. The default is OPS$ (not true or false!).

Ad 2) Can't answer that without knowing what use dbadev has. The same for user secadm.

Ad 3) Set sessions_per_user to an appropriate value. Unlimited could cause problems. Not necessarily as a consequence of an hacker but application problems. One time we had a MS access applications selecting from a Oracle table and creating a new session for each record returned. It was a bug in the odbc driver combined with some programming errors. I don't remember the details.
But always test first before changing anything!!

Ad 4) You could define a password policy. Take a look to
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql for an example.
When you create an account you have to give it a password. You could also force a password change by the user with a : ALTER USER <user> PASSWORD EXPIRE.

Ad 5) owned by which users? Depending your Oracle versions there are some users like outln and system that have table in the system tablespace.
No one else should have objects in the system tablespace.

Ad 6) You are using database links with connect to current_user or connected user db-links. This is no a security threat.

ad 7) The system account is created when you create a database. I don't understand your question. Maybe you want to audit (see Oracle audit command) system?

And don't forget to test before changing!

regards,

Ivan

Title: Re: A few security questions
Post by Pete Finnigan on Sep 30^th, 2005, 12:04am

Thanks for the information. I have one more question:

I noticed that the PUBLIC execute privilege is not revoked on the following files:
utl_file, utl_tcp, utl_http, utl_smtp.

Would this be a security threat? My DBA told me these files have to be there to let one of the applicaitons run. Would this make sense?

Thanks.

Thanks.

Title: Re: A few security questions
Post by Pete Finnigan on Sep 30^th, 2005, 8:34am

Miloann,

Public execute privilege could be a security threat and if possible revoke execute priv from public. See
http://www.oracle.com/technology/deploy/security/oracle9i/pdf/9ir2_checklist.pdf
for more information and look at
sql_injection_forms_us.pdf
for an example of how utl_http could be used in combination with a forms sql-injection problem.
Your DBA is probably right but maybe he can grant execute to the users that run the application?

regards,

Ivan

Title: Re: A few security questions
Post by Pete Finnigan on Sep 30^th, 2005, 6:10pm

hi,

I would concur with Ivan,these four packages have been documented as a security risk if they are left with public execute privileges. See my [url http://www.petefinnigan.com/orasec.htm]oracle security white papers page[/url] in the checklists section, the CIS benchmark and the SANS SCORE documents both list them. The reasons that they are a risk is that potentially they allow any authenticated user even via a remote connection such as a web page to use the functions. These functions allow the writing and reading of files or networks. Data can be extracted, sent externally or files created that can be used to gain privileges. The most obvious method is SQL Injection.

Definately remove the PUBLIC execute privileges and grant it back to those specific users that do need access to these packages.

hth

cheers

Pete

Title: Re: A few security questions
Post by Pete Finnigan on Oct 3^rd, 2005, 10:51pm

Thanks for the info.

Would like to talk about the system account management I mentioned earlier.

What would be the general practice to manage the system/application accounts? Can these accounts be used by a regular user to access the Oracle system?

The reason I ask again is we have a good number of system/application accounts and I am not very comfortable if each one is used for its intended purposes. Is there a way to control these accounts?

Thanks again.

Title: Re: A few security questions
Post by Pete Finnigan on Oct 4^th, 2005, 9:17am

Miloann,

I don't know if there are general pratices for managing system and application accounts. Maybe this can be taken into account when designing an Open Oracle Security Standard.
My best practice for system account: it is only for the dba and no one else. Give it a good password and keep it to yourself.
You also could audit it for succesful and unsuccesful logins. I think that the system account can be locked. I'm not sure about that.
When you talk about application user do you mean schema owner? if so then only the dba should be able to login as the schema owner. Give any one else a developers database where they can login a the schema owner if they want so they can create, drop, etc objects. In these developers databases change sensitive data if needed. Developers should give the dba ddl's, dml's that the dba can implement in the test database so that end-users and developers together can test the applications. When tests are ready then the dba can apply the changes to the production system but only after a formal approval by the project management.

regards,

Ivan
Noone needs to have access to the application (= schema owner?)

Title: Re: A few security questions
Post by Pete Finnigan on Oct 5^th, 2005, 10:28pm

Hi,

I would lock the SYS and SYSTEM accounts and store the passwords in a safe. Each DBA should have their own account. I would audit all SYS connections as well - see initialisation parameter audit_sys_operations. Also audit all connections successful and not to the database and review the audit trail. Also write off the audit trail to write once media. Use password management features to protect all accounts especially the DBA accounts. For application schema accounts lock them and set the failed_login_attempts to 1 and also set sessions_per_user to 1. It should not be possible to connect to a schema owner account unless a release is being done. Also ensure you audit connections to all schema accounts.

Also audit for use of any system privileges especially object creation or alter privileges.

Basically control access to database accounts and lock those that should not be used regularly and also audit all connections/disconnections and use of system privileges.

hth

cheers

Pete

Title: Re: A few security questions
Post by Pete Finnigan on Oct 14^th, 2005, 4:48am

Thanks for the info. It all works. Now, I ran into another questions:

I compared the employement records with the user account and found there are totally 250 user accounts owned by employees who are terminated. I showed the list to our Info Sec and here is the interesting part that they responded:

"We have very effective procedures to revoke Windows and Unix accounts when employees departure. As long as we have a very tight process on that part, we are not worried about the Oracle accounts."

We all know disgruntled employees may use these accounts to access. But with restrictions on the OS level, are we safe?

Also, they indicated that those terminated user accounts cannot be removed but set an expiry date because some Oracle applications may still need to reference these accounts. Is this correct?

Thanks again.

Title: Re: A few security questions
Post by Pete Finnigan on Oct 14^th, 2005, 9:28am

Miloann,

I don't think that a restriction on the OS level is enough. Maybe those ex-employees can use someone else OS account to log in Oracle with their old account? If possible you could lock the oracle accounts and also change their passwords (in case someone unlocks the account).
Your question regarding applications referencing Oracle accounts : it's possible. I've seen it before in applications so I wouldn't be surprised. I don't think it is correct but sometimes the cost to redesign an application is just to high.

regards,

Ivan

Title: Re: A few security questions
Post by Pete Finnigan on Oct 14^th, 2005, 6:58pm

Hi,

I think your issue would be if application auditing references the username or some other database logging does then you could have broken links between tables. this would apply if they are also talking about removing users at an application level. I would guess that maybe there are links between oracle usernames and audit in the applications?

I would do a few things:

o - lock the accounts
o - change the passwords to impossible passwords using the values clause of alter user
o - revoke create session from the users and if possible revoke all privileges
o - use audit for login and alter user system privilege - at least

cheers

Pete

Title: Re: A few security questions
Post by Pete Finnigan on Oct 17^th, 2005, 2:00am

Something else to think about.

If your userids follow some sort of naming standard, what happens if a new employee joins with the same (or similar) name to a terminated employee ? Will they definately get a 'brand-new' userid, or might they get the same userid as the old employee.

You need a mechanism to avoid the new employee picking up the privileges of the old. Ideally you wouldn't reuse a userid and if you keep and lock the old account, it should highlight any attempted re-use (ie you'll get an error on CREATE USER). Then you can decide whether you can get a new userid, or whether you have to get your fingers dirty in the application to make sure any 'old' privileges are removed.