Re: Interesting Hack

We can safely give Oracle credit on this. They've done a very good job in making sure the passwords are well encrypted while stored in the database. The table that stores this data is only visible to users that need access to it. In fact, 12c has revoked access to user$ (among other sensitive tables) from the "SELECT ANY DICTIONARY" role to which DBSNMP is still granted.

*"For better security, the SELECT ANY DICTIONARY system privilege no longer permits you to query the SYS schema system tables DEFAULT_PWD$, ENC$, LINK$,USER$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, and XS$VERIFIERS."
<http://docs.oracle.com/cd/E16655_01/network.121/e17607/release_changes.htm#DBSEG672>*

One way hashed passwords will always be brute force crackable given a system that has already been compromised and a weak password. This is precisely why passwords should *NEVER *be reused anywhere, ever, under any circumstances, no matter what, given any situation, under any scenario...ever. And, they should be something <http://arstechnica.com/security/2012/08/passwords-under-assault/> that will never be in a "Rainbow Table". I could post the user$.spare4 of all of my databases and the shadow file of all of my servers on the internet and sleep well knowing they will never be cracked. If any DBA or sysadmin can't do the same, <insert offensive sarcastic statement here>.

Seth Miller

On Fri, Jul 11, 2014 at 12:21 AM, De DBA <dedba_at_tpg.com.au> wrote:

> Ah, I see.. and am flabbergasted. Your original post had me think that
> the entire value in the SPARE4 column was the result of the sha1 hash, but
> it actually is the hash, *plus the unencrypted salt concatenated to it*!
> So your pseudo-code becomes:
>
> *if sha1(sha1(password) || bin(substr(spare4, 43, 20)))**||substr(spare4,
> 43, 20)** == spare4 *
> * then*
> * cracked!*
>
> Amazing. What bright light could have imagined that this constitutes
> security? Even I, simple DBA, can imagine that if you give a cracker the
> actual key, they may get in...
>
> Thanks,
> Tony
>
>
> On 11/07/14 14:29, Seth Miller wrote:
>
> Actually, your second one is really close but you have to change the salt
> to binary before adding it to the hash.
>
> perl -mDigest::SHA -e 'use Digest::SHA qw/sha1 sha1_hex/;
> $a=Digest::SHA->new(1); $a->add( $ARGV[0]); $a->add( pack "H*",
> "3A2BACEE5639367A6F9A" ); print uc( $a->hexdigest ), "\n";' 1TestTestTest
> 7E41F29D8CF37C3753C1BC0FFD4474805C473E8D
>
> You're quite right about this being somewhat moot. If someone has access
> to DBSNMP, your database is probably already compromised. But, if bad guy
> is not looking for data in that database but is looking for passwords
> because bad guy is assuming other servers have tastier treats and dummy DBA
> used the same DBSNMP password on all the databases...
>
> Seth
>
>
> On Thu, Jul 10, 2014 at 9:40 PM, De DBA <dedba_at_tpg.com.au> wrote:
>
>> Not contesting that brute-force cracking tools are plenty available, I
>> think there may be a thought error here.. if the SPARE4 column is the SHA1
>> hash of two concatenated values, then how could the 2nd value be equal to
>> the last 20 characters of that hash?
>>
>> In my 11.2.0.1. instance it doesn't work like that:
>>
>> SQL> create user test identified by "1TestTestTest";
>>
>> User created.
>>
>> SQL> select user#, name, password, spare4, substr(spare4, 43, 20) salt
>> from user$ where name = 'TEST';
>> USER#|NAME |PASSWORD
>> |SPARE4 |SALT
>>
>> ==========|=========================|===================================|======================================================================|=====================
>> 113|TEST |A02061EDD343E9BE
>> |S:7E41F29D8CF37C3753C1BC0FFD4474805C473E8D3A2BACEE5639367A6F9A
>> |3A2BACEE5639367A6F9A
>>
>> 1 row selected.
>>
>> # calculate hash using concatenated sha1 hex strings:
>> $ perl -mDigest::SHA -e 'use Digest::SHA qw/ sha1_hex /; print sha1_hex(
>> sha1_hex($ARGV[0]) . "3A2BACEE5639367A6F9A" ), "\n";' 1TestTestTest
>> 981887b207411feee08b8e152330daabc8439c67
>>
>> # calculate hash using pure sha1 values:
>> $ perl -mDigest::SHA -e 'use Digest::SHA qw/sha1/;
>> $a=Digest::SHA->new(1); $a->add( sha1( $ARGV[0]) ); $a->add(
>> "3A2BACEE5639367A6F9A" ); print $a->hexdigest, "\n";' 1TestTestTest
>> ef443979df05151e034feef43da02fb7b256997d
>>
>> Also, in order to user the spare4 column for cracking passwords, the
>> cracker must first have access to the system tablespace, no? In a normal
>> production system this would constitute a security breach in itself... Also
>> TDE may prevent this kind of cracking, unless the cracker has already
>> access to a DBA account, in which case knowledge of passwords is irrelevant
>> anyway..
>>
>> Cheers,
>> Tony
>>
>>
>> On 11/07/14 08:17, Seth Miller wrote:
>>
>> Yes, they are salted making a reverse lookup ostensibly impossible.
>> However, the spare4 column is simply the sha1 hash of the 40 character sha1
>> hash of the password concatenated with a 20 character salt. How the salt
>> was created doesn't matter. There are dozens of scripts on the internet for
>> brute force cracking Oracle database passwords.
>>
>> if sha1(sha1(password) || substr(spare4, 43, 20)) == spare4
>> then
>> cracked!
>>
>> Seth
>>
>>
>>
>> On Thu, Jul 10, 2014 at 3:33 PM, McPeak, Matt <vxsmimmcp_at_subaru.com>
>> wrote:
>>
>>> How are they already cracked? I thought all hashed passwords were
>>> salted to avoid a simple lookup against pre-built tables.
>>>
>>>
>>>
>>> Or are you saying they’ve cracked every 8 character password for every
>>> possible salt value?
>>>
>>>
>>>
>>>
>>>
>>> *From:* Seth Miller [mailto:sethmiller.sm_at_gmail.com]
>>> *Sent:* Thursday, July 10, 2014 3:24 PM
>>> *To:* McPeak, Matt
>>> *Cc:* curtisbl_at_gmail.com; oracle_at_1001111.com; Oracle-L
>>> *Subject:* Re: Interesting Hack
>>>
>>>
>>>
>>> It depends on the length and complexity of the password used. Any
>>> combination of eight characters or less is sitting in a rainbow table you
>>> can download right now and is already cracked. Longer passwords without
>>> sufficient complexity will be cracked as well.
>>>
>>> If you think you have outwitted a hacker by using l33t to come up with
>>> "70rchw00d", you deserve to be hacked. #BrokenRecord
>>>
>>> Seth
>>>
>>>
>>>
>>> On Thu, Jul 10, 2014 at 2:03 PM, McPeak, Matt <vxsmimmcp_at_subaru.com>
>>> wrote:
>>>
>>> The article casually mentions cracking the password hash to get the
>>> system password. I didn’t know it was that easy!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* oracle-l-bounce_at_freelists.org [mailto:
>>> oracle-l-bounce_at_freelists.org] *On Behalf Of *Bobby Curtis
>>> *Sent:* Thursday, July 10, 2014 1:17 PM
>>> *To:* sethmiller.sm_at_gmail.com
>>> *Cc:* oracle_at_1001111.com; Oracle-L
>>> *Subject:* Re: Interesting Hack
>>>
>>>
>>>
>>> Seth,
>>>
>>>
>>>
>>> Not harsh at all.
>>>
>>>
>>>
>>> I thought it was an interesting hack as well. I think the point of this
>>> hack example was to highlight what not to do; but we are all human and
>>> don’t listen half the time.
>>>
>>>
>>>
>>> Bobby
>>>
>>>
>>>
>>>
>>>
>>> On Jul 10, 2014, at 12:36, Seth Miller <sethmiller.sm_at_gmail.com> wrote:
>>>
>>>
>>>
>>> That is interesting except DBSNMP does not have a default password.
>>>
>>> If your application is not using bind variables (which would prevent
>>> this simple sql injection) and you are dumb enough to set your privileged
>>> DBSNMP account password to DBSNMP, you deserve to be hacked.
>>>
>>> Am I being too harsh?
>>>
>>> Seth
>>>
>>>
>>>
>>> On Wed, Jul 9, 2014 at 7:32 PM, Dave Morgan <oracle_at_1001111.com> wrote:
>>>
>>> Granted the database security was crap to begin with but I did not know
>>> the escape to shell trick.
>>>
>>>
>>> http://www.notsosecure.com/blog/2014/07/08/abusing-oracles-create-database-link-privilege-for-fun-and-profit/
>>>
>>> Dave
>>>
>>> --
>>> Dave Morgan
>>> Senior Consultant, 1001111 Alberta Limited
>>> dave.morgan_at_1001111.com
>>> 403 399 2442
>>> --
>>> http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

--
http://www.freelists.org/webpage/oracle-l