Privileges Your Services Do Not Need

Privileges Your Services Do Not Need

Many services are configured with privileges that they really do not need. Public enemy number one in this area is probably backup tools. Just about anyone who has installed a backup tool that has a client component for remote backups can testify to the fact that the client allegedly must run as an administrator. Therefore, the recommendation is invariably to configure the client component to run as a domain administrator. Enterprise management systems (EMSs) often suffer from the same problem.

WARNING: A process running on clients as a domain administrator are hazardous to your network health! It degrades the security of the entire domain to that of the least-secure machine in the domain.

Domain administrative accounts are for administering domain controllers. Period. Far too often, services such as backup and EMS require them because the developers would not take the time to figure out how to perform the same task with minimum privileges. If they just make them run as a domain admin, they can connect to the backup server and vice versa and everything will work. This is an extremely dangerous practice because it degrades the security of the entire domain to that of the least-secure machine in the domain. In Chapter 8, we showed that the probability of every system in a network being secure on any given day is virtually nil. You would do well to ensure that all systems in the environment are resilient to failure of other systems.

Some backup vendors configure their solutions to use the Backup Operators group. That is also undesirable. The Backup Operators group basically has two privileges: SeBackupPrivilege and SeRestorePrivilege. SeBackupPrivilege allows the user to bypass file system access control lists (ACL) and read all files on the hard drive. That privilege is required to back up files, but you need to make sure that the people that have it are actually allowed to read all files on the system. It takes only about four lines of code to bypass any ACL you want if you have this privilege.

SeRestorePrivilege is more interesting. It allows the user to bypass ACLs and write files to the file system. When you have that, you can overwrite operating system files and alter how the system functions. This creates a trivial path to take over the systemjust overwrite a service binary that launches as LocalSystem and reboot. Given that restoring files is a rare operation (hopefully), the users with SeRestorePrivilege should be very limited.

There are other privileges that are just as bad. For instance, many services and some applications require the user who runs them to have SeDebugPrivilege. SeDebugPrivilege enables a user to debug a process that he does not own. More technically, it allows you to open a handle to the process which allows you to read and write into the processes address space and inject code into the process. SeDebugPrivilege is actually all that is required to run the pwdump and lsadump tools demonstrated in Chapter 2. Any user with that privilege can dump out password hashes and service account credentials.

NOTE: Sometimes the applications that require SeDebugPrivilege can take you by surprise. For instance, after removing that privilege from Administrators in the Windows Server 2003 Security Guide, we realized that we could no longer install security updates. A new version of the update.exe tool that installs Windows security updates by patching running binaries required SeDebugPrivilege.

SeTcbPrivilege, or the right to act as the operating system, is another extremely dangerous privilege. It allows a user to call certain APIs such as LogonUser. Using this privilege, a user can add arbitrary groups to its existing security token and essentially become a member of another group, thus obtaining additional permissions on-the-fly .

SeAssignPrimaryToken is a privilege that in-and-of-itself is pretty difficult to use for evil purposes. It allows a user to modify the process token on a process; however, it does not allow the user to create such a token. Thus, to misuse this privilege, some other mechanism for obtaining a privileged primary token must be used, and ordinary users do not have the ability to do that. However, in combination with SeTcbPrivilege or SeCreateToken, SeAssignPrimaryToken is deadly . The former allows the user to steal or create a primary token, and the latter allows him to stamp the token onto an existing process, thus elevating that process to run as any user on-the-fly. The net result looks something like this:

 C:\warez>tlist    0 System Process    8 System  152 SMSS.EXE  200 CSRSS.EXE  224 WINLOGON.EXE  252 SERVICES.EXE  264 LSASS.EXE  372 termsrv.exe  516 svchost.exe  540 spoolsv.exe  588 msdtc.exe 720 svchost.exe  744 LLSSRV.EXE  820 sqlservr.exe  856 regsvc.exe 956 WinMgmt.exe 1004 svchost.exe 1024 dfssvc.exe 1052 mssearch.exe 1368 svchost.exe 1452 svchost.exe 1308 CMD.EXE 1472 tlist.exe C:\warez>lsadump2 Failed to open lsass: 5.  Exiting. C:\warez>whoami PYN-SQL\_sql C:\warez>ElevateProcess.exe 1308 C:\warez>whoami NT AUTHORITY\SYSTEM C:\warez>lsadump2 $MACHINE.ACC  28 00 43 00 52 00 67 00 53 00 62 00 56 00 77 00  (.C.R.g.S.b.V.w.  56 00 3E 00 4B 00 24 00 23 00 31 00 75 00 2B 00  V.>.K.$.#.1.u.+.  73 00 43 00 4F 00 54 00 52 00 64 00 46 00 71 00  s.C.O.T.R.d.F.q. ... 

This exploit works because Microsoft SQL Server 2000 gives these privileges to its service account automatically. According to the best practices (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sp3sec00.mspx) for SQL Server, the process should run as an ordinary user, not as LocalSystem. That part is great; it is what comes next that causes problems. The document recommends that you use Enterprise Manager to assign the account, as shown in Figure 14-1.

Figure 14-1. Using SQL Enterprise Manager to change the SQL Server service account.

When you use SQL Enterprise Manager, the service account gets the following permissions and privileges:

• SeTcbPrivilege

• SeAssignPrimaryToken

• Full control over everything under

  • %ProgramFiles%\Microsoft SQL Server\<InstanceName> (or MSSQL for the default instance)

  • HKLM\SOFTWARE\Clients\Mail

  • HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\80

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\<instancename>

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\Providers

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\Replication

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\Setup

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent

  • HKLM\SOFTWARE\Microsoft\MSSQLServer\Tracking

  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib

A few other things happen as well, but these are the main ones of interest. With this set of permissions, just about anything you would ever want to do with SQL Server would work. Unfortunately, that includes taking over the entire system through a faulty application with an SQL injection vulnerability that accesses the SQL Server using a privileged account. After we have exploited the front-end application to give us a command shell on the SQL Server, we run an attack tool called ElevateProcess.exe and elevate an arbitrary process to run as LocalSystem. (The number 1308 after the ElevateProcess call is the process ID of the target process; in this case, our existing local command shell.)

In the next section, we show you how to stop this kind of attack. Doing so requires going above and beyond what the SQL Server Security Best Practices document shows you to do. This means that you have to be familiar with that document and have followed its recommendations already.