Penetration Testing mailing list archives

Re: [PEN-TEST] SQL 6.5 & 7.0 passwords in the registry (NT 4.0)


From: Attonbitus Deus <Thor () HAMMEROFGOD COM>
Date: Wed, 17 Jan 2001 21:50:48 -0800

My bad.  I thought that was the issue Pentester was talking about- I should
have read his post a little better.  (That's what I get for being in a
hurry! )

Aaron:

"In SQL Server 6.5, the passwords are stored unencrypted in the registry.
In SQL Server 7.0, the passwords are stored using a simple substitution
encryption method which can easily be deciphered by a skilled attacker."

Database Scanner does not actually attempt to figure out the password, it
simply detects that someone has placed a password there and lets you know.

I know of no one outside of ISS and Microsoft that is aware of the
algorithm, although I'm sure that it's because no one has made an effort.
As stated above, it's a simple substitution algorithm.

I posted a request for data regarding a SQL 7.0 crack a while back, and got
a response from the guy that wrote the original code for the cracker in
dbsecure.  According to him, the product (now DSS as you pointed out-
thanks) did actually crack the passwords, but it was changed to simply
report weak or strong pwd's on the box for some reason- (but you are right-
the dictionary brute I was thinking of came from NTSecurity.nu)  He was
going to try to get me the original code, but I don't think he could put his
hands on it. But that was for 6.5.  Now, this was for the passwords stored
in sysxlogins that linked to the users in sysusers- I think this 'stored in
the clear' business was regarding EnterpriseManager as Todd pointed out in
his reply.

Does anyone have any more info on this?  I have penetrated many SQL boxes
and retrieved the master db, but have never been able to crack the passwords
in sysxlogins to get further down range.  I think that if it really were
simple, there would be crackers out there for it.

Additionally, if the 6.5 system users and pwds really are in the clear, why
would Pentester be asking us for the crypto?


----- Original Message -----
From: "Todd Sabin" <tas () webspan net>
To: "Penetration Testers" <PEN-TEST () SECURITYFOCUS COM>
Cc: "Attonbitus Deus" <Thor () HAMMEROFGOD COM>
Sent: Wednesday, January 17, 2001 8:54 PM
Subject: Re: [PEN-TEST] SQL 6.5 & 7.0 passwords in the registry (NT 4.0)


Attonbitus Deus <Thor () HAMMEROFGOD COM> writes:

Todd Sabin discovered this and reported on it over 3 years ago... For
SQL
6.5, the username is clear, and the password is hashed via PKZip's
crypto
using a fixed key.  This should be in the Bugtraq archives.

7.0 uses a different hash, and though dbsecure allows you to brute it
via
dictionary, I have not found a tool that cracks SQL 7.0 sa password when
mixed mode is used.


Actually, there were two separate issues, one of which was mine.

What I found was that when you install SQL Server 6.5, it creates an
NT account (not a sql one) named SQLExecutiveCmdExec or something like
that, and stores the password in an Everyone:Read part of the
registry, encrypted with PKZip's encryption with a fixed key.  Since
you normally need credentials to read the registry in the first place,
it didn't get you all that much, really.  MS seems to have fixed this
in later versions, but I haven't looked at it too deeply.

At around the same time, someone else (don't remember, sorry) reported
that SQL Enterprise Manager stored (under the SQLEW key) the passwords
to SQL accounts that you used to register servers.  In that case, the
passwords were stored plaintext, although it was in the midst of a
blob of REG_BINARY data, so you had to look for it.  Depending on
configuration, it would put them either under HKCU or HKLM.

Haven't seen the particular thing the original poster was asking
about, though it looks like a similar problem.


Todd


Current thread: