Good find. We found similar excesses this year at Black Hat 2K in Vegas
regarding the SE_TCB_NAME and SE_ASSIGNPRIMARYTOKEN_NAME user rights
assigned to the SQL Server service account. However, I believe the
appropriate response is to provide a work-around , inform the community, and
inform Microsoft so that they can provide a long-term solution. Statements
like "securing SQL server by means of using least privileged account for the
service is simply ineffective" could be counter-productive if someone reads
that and then simply gives up and goes LocalSystem. Least-privilege should
always be the standard - don't avoid it just because MS made an error in
executing good design. Also keep in mind that the sysadmin-level intruder
can totally tank SQL Server by tweaking other keys and we must conceed that
once someone is a sysadmin, SQL Server (and more importantly all of its
data) is toast - no argument there.
Thanks for the information. It should definitely end up in our hardening
scripts. One potential work-around I have tested is to simply load regedt32
and assign the service account read-only access to the registry key.
Voila - your script fails ('Access is Denied' on xp_regwrite). You can't
change it later unless you go back in and reset the key permissions but this
shouldn't be a problem unless you rotate service accounts frequently.
The next thing we need to do is audit every single ACL, user right, and
other changes that occurs when service accounts are assigned and see what
other problems are lurking...
Thanks again Bronek for an excellent discovery.
Chip Andrews
http://www.sqlsecurity.com
----- Original Message -----
From: "Bronek Kozicki" <brokat_private>
To: <focus-msat_private>; <bugtraqat_private>
Sent: Thursday, April 18, 2002 4:35 AM
Subject: Re: Microsoft Security Bulletin - MS02-020
>
> 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 archive was generated by hypermail 2b30 : Fri Apr 19 2002 - 19:13:33 PDT