Archive for the ‘security’ Category

h1

Hacking into an Oracle database

September 23, 2008

At a site I was working at they employed a security company to perform penetration testing on a new application (Oracle/Peoplesoft/Unix/Windows/NT). The test was from within the network  and they failed to breach Oracle database security directly. However …

Password guessing against a NT server resulted in the discovery of a domain admin account (db2admin), which resulted in full compromise of this host and also the remaining servers that are members of this domain.

When you build a Windows server you are asked for an initial password (which you are expected to change later on). This password is stored in a build file and as it had not been changed after the installation  it was then used to logon to the domain (any of  the servers as local administrator)This allowed searching of files on the NT server which produced a file containing the oracle account and password to the people account (peoplesoft admin user)

Once onto the database a reasonably privileged account with a weak password was discovered. From there the encrypted values of the users were captured from dba_users and were compared against a known list of passwords and permutations based on the current password i.e. a zero used instead of an ‘o’. This compromised an account with create procedure and from there they were into the OS.

 

These issues have all been resolved and we are much more secure than we were but it just shows how a lapse in security somewhere on the network can allow what appears to be innocuous access which eventually provides full ingress into what is supposed to be a secure system.

h1

More problems with orapwd file and shipping redo logs

May 12, 2008

OEL Linux 11.1.0.6

I had a orapwd file set up on both databases and have restarted the databases since I re-created the orapw file. I could connect using ’sqlplus sys/password@tnsnames_alias as sysdba’ between both nodes and the sys password is the same on both nodes.  However archived redo logs files were not shipping across to the standby node and I was pulling my hair out struggling to get it to work.

Error messages were :-

*** 2008-05-09 09:44:43.898
Redo shipping client performing standby login
OCISessionBegin failed. Error -1
.. Detailed OCI error val is 1031 and errmsg is ‘ORA-01031: insufficient privileges

An attempt to establish secure session using password verifier based approach will be attempted..
OCISessionBegin failed. Error -1
.. Detailed OCI error val is 1031 and errmsg is ‘ORA-01031: insufficient privileges

An attempt to establish secure session using password verifier based approach will be attempted..
OCISessionBegin failed -1
.. Detailed OCI error val is 1017 and errmsg is ‘ORA-01017: invalid username/password; logon denied

*** 2008-05-09 09:44:44.127 1095 krsh.c
Error 1017 received logging on to the standby
————————————————————
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
————————————————————


The passwords were lowercase on both nodes. In fact I was using  a cut’n'paste to create both password files, only replacing  the node name.
Eventually I fixed the problem by re-creating the password files on both nodes (for the 3rd or 4th time) and restarting the databases. I added the parameter ignorecase=y and everything sprung to life.

This gets me to think that the password was being translated to uppercase when it came across to the remote node

There is a bug on Metalink (6804839) ORA-01017 (16191) LOGGING ONTO STANDBY WHEN SEC_CASE_SENSITIVE_LOGON=FALSE

The bug detail itself is not public but the title seems to confirm that it that bug is likely to be related to my problem although in my case sec_case_sensitive is set to true on both nodes already.

How annoying metalink can be, searching all sources for ORA-01017 or 16191 (both in the title of that bug) does not bring it up.

Another suggestion was to copy the orapwd file from one server to the other and ensure that permissions are correct

So the short answer is that if you are stuck with a similar problem try recreating the orapwd file with ignorecase=y set