Re: Interesting Hack
Date: Thu, 10 Jul 2014 23:29:09 -0500
Message-ID: <CAEueRAVbO7XTvLTZYXV0P60oH3b77qxQ79ZEs_Ts6TBKE4CDTQ_at_mail.gmail.com>
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-lReceived on Fri Jul 11 2014 - 06:29:09 CEST