Re: Funny sort of question re sys password

Hi Nuno,

Thanks for your comments.... some more comments in line In article <200403102122.i2ALMw126614_at_mail009.syd.optusnet.com.au>, dbvision_at_optusnet.com.au writes
>> Pete Finnigan <oracle_list_at_peterfinnigan.demon.co.uk> wrote:
>
>> 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.
>
>Beg to disagree. If hacking techniques (including social engineering)
>are not made public, there is no way in the world we can expect people
>to learn how to "harden" their systems. I've learned a lot about how to
>secure my systems by frequenting hacker exploit sites. It's amazing what
>can be learned this way. Where I got l0phtcrack among so many others.
>

I think the issue is the difference between full disclosure and non full disclosure. This has been debated widely on forums like bugtraq and pentest  as to which is best. Its a matter for your own opinion as to whether you should reveal exploit code or just advise that there is a vulnerability and a patch or workaround to fix it or release the exploit as well. The bugtraq database has many exploits in it although a lot more advisories nowadays come out without exploits.

>The dblinks weakness has been around for a long time and is
>fixed I believe since 8.0. The command line uid/pwd weakness
>is common to any other product where one types passwords
>in the command line. A proper password check must always involve
>a challenge. Volunteering a password is the quick way to a cracked system.
>IMHO, it should be fixed by disallowing uid/pwd to be used in the command line.
>Ie, make SQLPuss and other commands not accept pwd in command line.
>The log files are a real problem. Proper protection on them is mandatory,
>but who bothers? I can count on one hand the number of sites
>I've been to in 15 years that had their log directories protected.
>The SGA dumping was news to me. A roundabout way, but effective.
>The SQL injection has been doing the rounds for a while and is not
>only Oracle's problem. The comms eavesdropping can be countered
>by using an encoded comm protocol. There are a few now that can be
>used with Oracle Net. But once again, I can count on one hand the
>number of sites where I have seen a custom Net setup including
>encryption. Too hard basket.
>
>April said it in one: increased security should be the default, not the option.
>
>Coming back to the initial concern, I still can't see how someone
>can claim to crack the Oracle security in 10 minutes. Other than by
>using external exploits. As far as I know, DES is still 10-minute
>safe?
>

agreed, has to be an exploit, the 10 minutes intrigues me though unless they are waiting for a batch process to run so they can grab the password with ps. Anything else should take seconds.

If your DBA and sysadmin have cracked DES in less than 10 minutes then they should watch out the security agencies will want to employ them!!

kind regards

Pete

>> If
>> he is the sysadmin and he has an exploit and its not patched then
>> someone should be considering his loyalty to your company.
>
>Exactly. That is why I reckon exploits should be discussed openly.
>Otherwise the potential is there for someone to grab hold of one and do
>untold damage before others become aware it is possible.
>
>> SQL> alter user scott identified by tiger;
>>
>> User altered.
>>
>> and the SQL*Net trace shows:
>
>Yup. So if anyone has access to the trace, security is history.
>
>BTW, thanks for the feedback everyone. Much appreciated.

>Cheers
>Nuno
>@work
>----------------------------------------------------------------
>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
>-----------------------------------------------------------------

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