Re: Funny sort of question re sys password

Hi Nuno,

some comments in line..:-)

<snipped>
>
>I'd class most of those under the umbrella of "social engineering":
>indirect aquisition of knowledge through exploitation of other weaknesses
>in security. But yes, it is possible that way.
>

You are right for those ideas that involve finding passwords through various means could be social engineering But what i was really thinking of was running various commands as a non DBA user and changing the SYS password and then having access as SYS - those methods are not social engineering but hacking. I am trying to be vague as its not a good idea to show people in a public forum how to hack.

>> If you look at my site http://www.petefinnigan.com/orasec.htm there are
>
>Ta, I'll definitely look this up.
>
>
>> Your Sun guy is easy though, he is just connecting as root and logging
>> on as "/ as sysdba" - i guess.
>
>This doesn't count: it assumes root password knowledge which would break
>ALL security in the system, not just Oracle's.

exactly but that is what i assume he meant as his method - or do you know he has another way not involving root, oracle or dba group? If so probably he has exploit code for a vulnerability that is not patched. If he is the sysadmin and he has an exploit and its not patched then someone should be considering his loyalty to your company.

>Also, logging in as the
>install user would achieve the same. Or any user authorised to dba
>group, I suppose.

taken as read.

>But all that assumes a breakdown in other than Oracle's
>security to start with. That is not an Oracle inherent security
problem.
>
>I was more concerned with obvious security breaches such as unencrypted
>passwords ending up in log files or file headers, or unencrypted comms
>eaves-dropping. Guess those are not that easy with 9i, they used to be
>the order of the day with earlier versions.
>

Unfortunately it is easy still, not for connections but for changing passwords at least. For instance I did:

SQL> alter user scott identified by tiger;

User altered.

and the SQL*Net trace shows:

[10-MAR-2004 12:52:40:567] nsprecv: 74 65 72 20 75 73 65 72  |ter.user|
[10-MAR-2004 12:52:40:567] nsprecv: 20 73 63 6F 74 74 20 69  |.scott.i|
[10-MAR-2004 12:52:40:567] nsprecv: 64 65 6E 74 69 66 69 65  |dentifie|
[10-MAR-2004 12:52:40:567] nsprecv: 64 20 62 79 20 74 69 67  |d.by.tig|
[10-MAR-2004 12:52:40:567] nsprecv: 65 72 01 00 00 00 01 00  |er......|

but if i use the password function in SQL*Plus

SQL> password dbsnmp
Changing password for dbsnmp
New password: ******
Retype new password: ******
Password changed
SQL>
in the trace i get

[10-MAR-2004 12:53:33:132] nsprecv: 64 62 73 6E 6D 70 10 00  |dbsnmp..|
[10-MAR-2004 12:53:33:132] nsprecv: 00 00 10 41 55 54 48 5F  |...AUTH_|
[10-MAR-2004 12:53:33:132] nsprecv: 4E 45 57 50 41 53 53 57  |NEWPASSW|
[10-MAR-2004 12:53:33:132] nsprecv: 4F 52 44 20 00 00 00 20  |ORD.....|
[10-MAR-2004 12:53:33:132] nsprecv: 38 39 44 46 45 31 46 36  |89DFE1F6|
[10-MAR-2004 12:53:33:132] nsprecv: 37 34 43 38 34 36 45 30  |74C846E0|
[10-MAR-2004 12:53:33:132] nsprecv: 45 39 34 39 43 36 36 30  |E949C660|
[10-MAR-2004 12:53:33:132] nsprecv: 33 32 33 31 39 32 31 35  |32319215|

The hash shown is not the password.

So SQL*Net still transmits clear text passwords. ASO would fix that.

kind regards

Pete

-- 
Pete Finnigan
email:pete_at_petefinnigan.com
Web site: http://www.petefinnigan.com - Oracle security audit specialists
Book:Oracle security step-by-step Guide - see http://store.sans.org for details.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------