Isolation of services in Windows
As you know, Windows services are one of the most favorite places to attack the operating system. In the worst case (for us, of course), the attacker gets the opportunity to act on the attacked computer in the context of the account on whose behalf the hacked service is running. And if this account has administrative rights, then in fact the attacker gets full control over the computer. From version to version, new mechanisms appear in Windows that provide additional isolation of services and, as a result, enhance the security of the system as a whole. I would like to briefly review what has fundamentally changed in this direction over the past few years.
The first significant changes in the mechanisms for protecting services appeared in Windows XP Service Pack 2. Now it’s hard to imagine it, but before the release of SP2 all services of the operating system itself were launched in the context of the built-in Local System account, which has the most complete administrative rights on the computer. SP2 added two more entries: Local Service and Network Service. The principal differences between the three listed records can be found in Table. one.
Table 1
Accordingly, starting with Windows XP SP2, the administrator could customize the launch of the service in the context of one of the built-in accounts, local or domain account. However, most of the services of Windows itself still run in the context of the Local System. But even if one abstracts from this, a situation where several services are launched in the context of the same account results in a successful hacking of one service, even without administrative privileges, potentially opening to the attacker any other resources that it has access to. account hacked service.
')
In Windows Vista, there are several mechanisms that increase the isolation of services. I will focus on two.
The first mechanism is the service's unique security identifier (Service SID). This SID is generated for each service by hashing the service name using the SHA-1 algorithm. The prefix S-1-5-80- is added to the result. You can view the service SIDs using the sc showsid command, specifying the service name as a parameter (see Figure 1).
Fig. one
You can experiment, for example, with the W32Time service. For any folder on NTFS in the permissions settings (permissions) you only need to enter the user name in the format NT SERVICE \ <service name>, in our case NT SERVICE \ w32time (see Figure 2).
Fig. 2
Click Check Names, then OK and see the user (see Figure 3), which can be assigned rights.
Fig. 3
Once again, w32time is not a user object. This is a SID, but if so, it can be used in ACLs, both in the GUI and on the command line and programmatically. Moreover, the service SIDs can be used in the Windows Firewall settings, applying certain rules to a specific service, or rather to a specific Service SID.
The second change, which appeared in Vista, is a new type of security identifiers - Write Restricted SID. If a service is marked with the Write Restricted SID type, then its SID is added to its special access token in the special list - the Restricted SID list. When such a service attempts to write something to a file, the algorithm for checking access rights changes somewhat. Namely, the service will be able to write to the file only if Write permission is explicitly given to the SID of this service, or to the Everyone group.
For example, the ServiceAccount1 account of some Service1 service is a member of Group1. Group1 group and only it has Write permission on the Folder1 folder. What happens if the service tries to change something in the Folder1 folder? In a typical situation, ServiceAccount1 will be able to write to a folder through Group1 membership. But if the Service1 service is marked with the Write Restricted SID type, its access token is processed differently and it will not be able to write anything to the folder, since it has not explicitly given permission to Write, nor has this right been granted to Everyone.
You can view the type of security identifier using the sc qsidtype command (see Figure 4).
Fig. four
In particular, in fig. 4, you can see that the Windows Firewall service refers to the type just mentioned. Naturally, this type was introduced in order to further limit the capabilities of the service (the ability to erase or rewrite something) in the event of its successful hacking. It should also be added that this mechanism is intended primarily not for system administrators, but for service developers. If only to enjoy.
In Windows 7 and Windows Server 2008 R2, work on isolating services has continued. There are virtual accounts and managed service accounts. What exactly is the problem? We need to isolate the services - let's create the necessary number of local (or domain) user accounts. For each critical service your account. Yes, this is a solution. But for local services that do not need network access to resources, you must manually set passwords, long and complex. And also manually update them periodically. Well, since we are for safety. For services that need to access resources in the context of domain accounts over the network, plus this still has to register a Service Principal Name (SPN), its own for each service. It is not comfortable. But inconvenience becomes a real problem when the service cannot start due to an expired password. And the admin just forgot to change the password for her.
So for local services you can use virtual accounts. A virtual account is used only to start a specific service, more precisely, to create a security context for a specific service. You will not find this entry among users in Computer Management. And, nevertheless, this is an account, with its unique SID, with its user profile. And therefore, you can assign permissions to it and, thereby, differentiate access rights and clearly control them. But as in the case of Local System, Local Service and Network Service, the operating system assumes the task of managing passwords for virtual accounts. We isolate the necessary services, and we don’t have a headache about passwords.
To create a virtual account, you need to specify in the service settings as the account: NT SERVICE \ <service name> (see Figure 5)
Fig. five
After starting the virtual account service, it will appear in the Services console (Figure 6), and in the Users folder you will notice the appearance of a new user profile.
Fig. 6
The format is very similar to the service SID. But I emphasize that this is not just an additional unique SID for a service as in Vista, it is a separate account and, accordingly, another level of isolation. By default, virtual accounts are used, for example, for application pools (application pool) in IIS 7.5 in Windows Server 2008 R2. It should be borne in mind that virtual accounts are intended for local use. If a service running in the context of a virtual account is accessed over the network, then this call occurs on behalf of the computer account on which the service is running. If it is necessary that a service, for example, SQL Server, work over the network on behalf of a domain account, then managed service accounts will help. However, more subtleties are associated with them, and their consideration is beyond the scope of this post. More details on MSA can be found here .
The mechanisms of isolation of services I have listed do not end there. You can also mention the isolation of the zero session, integrity levels, the mechanism of DEP. I focused on those that I think are less well known, but at the same time have quite practical sense for the administrator. And of course, work on enhancing the security of services in future versions of Windows will continue.
The first significant changes in the mechanisms for protecting services appeared in Windows XP Service Pack 2. Now it’s hard to imagine it, but before the release of SP2 all services of the operating system itself were launched in the context of the built-in Local System account, which has the most complete administrative rights on the computer. SP2 added two more entries: Local Service and Network Service. The principal differences between the three listed records can be found in Table. one.
| Account | Local resources | Network resources |
|---|---|---|
| Local system | Full access to all computer resources | Connect to network resources in the context of a computer account that is running |
| Local service | Standard user rights + a small set of additional privileges | Anonymous connection to network resources |
| Network service | Standard user rights + a small set of additional privileges | Connect to network resources in the context of a computer account that is running. The access token also contains the SID of the Everyone and Authenticated Users groups |
Table 1
Accordingly, starting with Windows XP SP2, the administrator could customize the launch of the service in the context of one of the built-in accounts, local or domain account. However, most of the services of Windows itself still run in the context of the Local System. But even if one abstracts from this, a situation where several services are launched in the context of the same account results in a successful hacking of one service, even without administrative privileges, potentially opening to the attacker any other resources that it has access to. account hacked service.
')
In Windows Vista, there are several mechanisms that increase the isolation of services. I will focus on two.
The first mechanism is the service's unique security identifier (Service SID). This SID is generated for each service by hashing the service name using the SHA-1 algorithm. The prefix S-1-5-80- is added to the result. You can view the service SIDs using the sc showsid command, specifying the service name as a parameter (see Figure 1).
Fig. one
You can experiment, for example, with the W32Time service. For any folder on NTFS in the permissions settings (permissions) you only need to enter the user name in the format NT SERVICE \ <service name>, in our case NT SERVICE \ w32time (see Figure 2).
Fig. 2
Click Check Names, then OK and see the user (see Figure 3), which can be assigned rights.
Fig. 3
Once again, w32time is not a user object. This is a SID, but if so, it can be used in ACLs, both in the GUI and on the command line and programmatically. Moreover, the service SIDs can be used in the Windows Firewall settings, applying certain rules to a specific service, or rather to a specific Service SID.
The second change, which appeared in Vista, is a new type of security identifiers - Write Restricted SID. If a service is marked with the Write Restricted SID type, then its SID is added to its special access token in the special list - the Restricted SID list. When such a service attempts to write something to a file, the algorithm for checking access rights changes somewhat. Namely, the service will be able to write to the file only if Write permission is explicitly given to the SID of this service, or to the Everyone group.
For example, the ServiceAccount1 account of some Service1 service is a member of Group1. Group1 group and only it has Write permission on the Folder1 folder. What happens if the service tries to change something in the Folder1 folder? In a typical situation, ServiceAccount1 will be able to write to a folder through Group1 membership. But if the Service1 service is marked with the Write Restricted SID type, its access token is processed differently and it will not be able to write anything to the folder, since it has not explicitly given permission to Write, nor has this right been granted to Everyone.
You can view the type of security identifier using the sc qsidtype command (see Figure 4).
Fig. four
In particular, in fig. 4, you can see that the Windows Firewall service refers to the type just mentioned. Naturally, this type was introduced in order to further limit the capabilities of the service (the ability to erase or rewrite something) in the event of its successful hacking. It should also be added that this mechanism is intended primarily not for system administrators, but for service developers. If only to enjoy.
In Windows 7 and Windows Server 2008 R2, work on isolating services has continued. There are virtual accounts and managed service accounts. What exactly is the problem? We need to isolate the services - let's create the necessary number of local (or domain) user accounts. For each critical service your account. Yes, this is a solution. But for local services that do not need network access to resources, you must manually set passwords, long and complex. And also manually update them periodically. Well, since we are for safety. For services that need to access resources in the context of domain accounts over the network, plus this still has to register a Service Principal Name (SPN), its own for each service. It is not comfortable. But inconvenience becomes a real problem when the service cannot start due to an expired password. And the admin just forgot to change the password for her.
So for local services you can use virtual accounts. A virtual account is used only to start a specific service, more precisely, to create a security context for a specific service. You will not find this entry among users in Computer Management. And, nevertheless, this is an account, with its unique SID, with its user profile. And therefore, you can assign permissions to it and, thereby, differentiate access rights and clearly control them. But as in the case of Local System, Local Service and Network Service, the operating system assumes the task of managing passwords for virtual accounts. We isolate the necessary services, and we don’t have a headache about passwords.
To create a virtual account, you need to specify in the service settings as the account: NT SERVICE \ <service name> (see Figure 5)
Fig. five
After starting the virtual account service, it will appear in the Services console (Figure 6), and in the Users folder you will notice the appearance of a new user profile.
Fig. 6
The format is very similar to the service SID. But I emphasize that this is not just an additional unique SID for a service as in Vista, it is a separate account and, accordingly, another level of isolation. By default, virtual accounts are used, for example, for application pools (application pool) in IIS 7.5 in Windows Server 2008 R2. It should be borne in mind that virtual accounts are intended for local use. If a service running in the context of a virtual account is accessed over the network, then this call occurs on behalf of the computer account on which the service is running. If it is necessary that a service, for example, SQL Server, work over the network on behalf of a domain account, then managed service accounts will help. However, more subtleties are associated with them, and their consideration is beyond the scope of this post. More details on MSA can be found here .
The mechanisms of isolation of services I have listed do not end there. You can also mention the isolation of the zero session, integrity levels, the mechanism of DEP. I focused on those that I think are less well known, but at the same time have quite practical sense for the administrator. And of course, work on enhancing the security of services in future versions of Windows will continue.
Source: https://habr.com/ru/post/113815/
All Articles