COMMAND

    MS SQL Server

SYSTEMS AFFECTED

    Win NT with MS SQL Server 6.5

PROBLEM

    Kevin Hegg found following.   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.

    You  may  think  how  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.  However,  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.

SOLUTION

    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.

    This  simplest  solution  to  this,  assuming  it  works  in  your
    environment, is to set  SQL Server's security mode  to Integrated,
    and then  only use  trusted connections  from Enterprise  Manager.
    There are a couple of gotchas here - in both directions:

    1) If you enable basic authentication, it will pass  user:password
       pairs in clear text across your network.

    2) If you use the integrated security, then you'll have difficulty
       when accessing the  SQL server from  a IIS server.   Basically,
       the NT login to the IIS server isn't transitive - it has no way
       to re-authenticate you to  another server, so you  can't access
       the SQL server on a different machine which uses the integrated
       security.  If you  use the basic auth  on both IIS and  the SQL
       server, it can re-authenticate -  but you'd better be sure  the
       network connection isn't sniffable.