RE: Interesting Hack
- From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 17 Jul 2014 09:00:48 -0700
I found it strange that Oracle went to the trouble of removing passwords from
the dba_users table, but gives the troublesome accounts like dbsnmp access to
the sys.user$ table. It's good to know they have fixed this is 12.
It has been longp assed time since passwords have needed to be longer than
eight characters. Length and complexity are both important, however when
passwords become very long and complicated they become extremely difficult to
enter correctly or to remember. This may in users keeping their password's
written on a cheat sheet. The long complicated password may have guarded
against cracking, but provided no protection against surreptitious entry
using the cheat sheet. That is why pass phrases may be better than over
complex passwords. Phrases such as "Hear6Parrotsskwawk." are better than
"X%2+<935()pw0ncD*?V" Seth, you used the term complex. That term needs to
defined. Both the above passwords use lower case letters, upper case letters,
digits, and special characters. Both may use any of those at a particular
position in the password, however , one need not spell out or even purposely
misspell out a phrase. The second style of password has this freedom. It
therefore allows for more permutations than the first. However the first
password is enterable by a human.
Let's say a site has 100 databases to look after, and I want to use
Enterprise manager. Let's also say that passwords need to be changed every six
months.
Changing the dbsnmp password for 100 databases and entering those passwords
into Grid Control is time consuming. However long passwords of the first
style can be used. The dbsnnp password is usuallynot entered each time, so
it is possible to have a 30 byte password composed of any permutation lower
case letters, upper case letters, digits, and special characters allowed by
Oracle. Now it isn't as safe as having 100 different passwords, but is it
safe enough to be reused at all? As you add databases the prospect of
different passwords everywhere becomes difficult in practice. If not at 100
databases than perhaps at 1000 or 10000. In these cases databases may be
assigned to a group, and members of a group would share the password.
However not every database would have a different password.
Ian MacGregor
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Seth Miller
Sent: Wednesday, July 16, 2014 3:15 PM
To: De DBA
Cc: Oracle-L Freelists
Subject: Re: Interesting Hack
Tony,
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@xxxxxxxxxx> 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@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> 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]
Sent: Thursday, July 10, 2014 3:24 PM
To: McPeak, Matt
Cc: curtisbl@xxxxxxxxx;
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> 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] On Behalf Of Bobby Curtis
Sent: Thursday, July 10, 2014 1:17 PM
To: sethmiller.sm@xxxxxxxxx
Cc: 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> 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> 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
403 399 2442
--
//www.freelists.org/webpage/oracle-l
��i��0���zX���+�� n��{�+i�^
Other related posts:
