OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: MS SQL Server 6.5 stores password in unprotected area of
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MS SQL Server 6.5 stores password in unprotected area of registry

  • To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
  • Subject: Re: MS SQL Server 6.5 stores password in unprotected area of registry
  • From: Kevin Hegg <kevinheggkshtechnology.com>
  • Date: Tue, 30 Jun 1998 21:34:02 -0400
  • In-Reply-To: <199806301833.OAA22142tetsuo.mspring.net>
  • Reply-To: kevinheggkshtechnology.com
  • Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
I got a few e-mails on this, so I should clarify. This is a problem if you
use standard security. It is not a problem if you use integrated security.
Be careful if you just want to test this out and you are not already using
standard security. There is another bug, that is known by Microsoft, that if
you switch from integrated security back to standard or mixed security, you
can corrupt your registry. In general, security with SQL Server 6.5 is not
implemented very well.

Regarding John Wiltshire's response about only those with the proper
permissions being able to access this part of the registry. I think there
are two important issues here. First, using the logic that if only admins
and the specified user can see the registry entries then it is not a
security hole is flawed. If anyone can gain access to a password, including
an NT admin, that they are not supposed to have access to then you have a
security problem. Second, if the computer that has this registry problem is
breached, for whatever reason, then this information can be used to gain
access to the computer that is running SQL Server and once on that computer
you have will the power to do some serious damage. Many NT admins are sharp
enough to configure the computers that they control correctly. But this
registry problem can be created on any computer and in many cases without
the NT admin's knowledge. There are a lot of DBAs who are pretty clueless
about NT security issues.

--------------------
Kevin Hegg
KSH Technology, Inc.
kevinheggkshtechnology.com

> -----Original Message-----
> From: Windows NT BugTraq Mailing List
> [mailto:NTBUGTRAQLISTSERV.NTBUGTRAQ.COM]On Behalf Of Kevin Hegg
> Sent: Tuesday, June 30, 1998 11:22 AM
> To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
> Subject: MS SQL Server 6.5 stores password in unprotected area of
> registry
>
>
> Actually it is much worse than that. If you register a server under SQL
> Enterprise Manager then whatever login and password you register is stored
> in the registry. Typically a DBA will register using the 'sa'
> login, so that
> also puts the 'sa' password in the registry. To view the login
> and password
> go to HKCU/SOFTWARE/MICROSOFT/MSSQLSERVER/SQLEW/Registered
> Servers/SQL 6.5,
> then select the target server, choose the 'View->Display Binary Data' menu
> item, select the 'Byte Format' radio button, and scroll down through the
> 'Data:' list box and you will see the login and password (no
> programming is
> required). And yes, Microsoft is aware of this.
>
> --------------------
> Kevin Hegg
> KSH Technology, Inc.
> kevinheggkshtechnology.com
>
> > -----Original Message-----
> > From: Windows NT BugTraq Mailing List
> > [mailto:NTBUGTRAQLISTSERV.NTBUGTRAQ.COM]On Behalf Of Todd Sabin
> > Sent: Monday, June 29, 1998 10:01 PM
> > To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
> > Subject: MS SQL Server 6.5 stores password in unprotected area of
> > registry
> >
> >
> > SQL Server creates an account named SQLExecutiveCmdExec during its
> > installaion. This account is created with very limited rights on the
> > machine, and is used by the SQLServer and SQLExecutive services
> to execute
> > commands submitted to xp_cmdshell by users other than sa (if so
> > configured).
> >
> > The problem is that SQL Server stores the password for this
> account in an
> > unprotected section of the registry.  Under the key
> > HKLM\SOFTWARE\Microsoft\MSSqlServer\SQLExecutive, there is a
> value of type
> > REG_BINARY named CmdExecAccount.  The data for this value is
> the password
> > for the SQLExecutiveCmdExec account, encrypted using the PKZip
> encryption
> > algorithm and a fixed key.  It is possible to write a program which
> > decrypts these passwords instantly.
> >
> > The risk here is probably not too great.  The
> SQLExecutiveCmdExec account
> > is, by design, extremely limited in rights.  SQL Server is normally
> > installed on servers; ordinary users won't be able to access
> the registry
> > remotely, nor log in to the server to access it locally.  It's
> > probably the
> > case that it requires more rights to obtain the password than
> the password
> > would give you.  Nevertheless, this is bad practice, and people
> > ought to be
> > aware of it.
> >
> > I notified Microsoft of this issue in October 1997, and asked again in
> > March.  I was told that they 'have some people looking into the
> > issue', but
> > haven't heard anything since.
> >
> >
> > Todd
> >
>