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@xxxxxxxxxx
<mailto:dedba@xxxxxxxxxx>> 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@xxxxxxxxxx
<mailto:vxsmimmcp@xxxxxxxxxx>> 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@xxxxxxxxx
<mailto:sethmiller.sm@xxxxxxxxx>]
*Sent:* Thursday, July 10, 2014 3:24 PM
*To:* McPeak, Matt
*Cc:* curtisbl@xxxxxxxxx <mailto:curtisbl@xxxxxxxxx>; oracle@xxxxxxxxxxx
<mailto:oracle@xxxxxxxxxxx>; 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@xxxxxxxxxx
<mailto:vxsmimmcp@xxxxxxxxxx>> 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@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Bobby Curtis
*Sent:* Thursday, July 10, 2014 1:17 PM
*To:* sethmiller.sm@xxxxxxxxx <mailto:sethmiller.sm@xxxxxxxxx>
*Cc:* oracle@xxxxxxxxxxx <mailto:oracle@xxxxxxxxxxx>; 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@xxxxxxxxx
<mailto:sethmiller.sm@xxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:oracle@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:dave.morgan@xxxxxxxxxxx>
403 399 2442
--
//www.freelists.org/webpage/oracle-l
