|
|
|
|
| |
| A security vulnerability has been found in Windows 2000 running Terminal Services, the Group Policies (GPO) will not be applied to users if the current number of connections to the GPO hosting server exceeds the number of installed user licenses. |
| |
Credit:
The information has been provided by Tom Unger and Thor.
|
| |
The mentioned vulnerability can be easily exploited on a Terminal Services enabled server that we will describe "in detail" in this advisory.
General Description:
Group Policies are used to deploy desktop/system settings to a defined group of users or computers and are a powerful instrument to secure a system. With the aid of Group Policies it is for example, possible to lock down user desktops/systems by denying the ability to run certain programs like regedit.exe or cmd.exe and so on. This is very useful for servers like Terminal Servers running in a hostile environment (e.g. terminal-servers connected to the internet) because a cracked user-password granting access to a weakly restricted user profile is more dangerous than in an trusted network inside a company.
Settings defined in Group Policies are applied to the user profile during logon if the user has the right to access the Group Policy Object. The access is controlled by the ACL (access control list) of the Group Policy Object. The user must have the right to read and apply a GPO in order to successfully apply the Group Policy to its profile. Microsoft claims that a successfully applied Group Policy is saved in the user profile when logging off (in reality this seems not to be true in any case).
The Group Policy Object are stored inside some directories on the share "sysvol" hosted by a logon-server. As any other (SMB)-share, "sysvol" can suffer from connection limits to it, introduced by limited user licenses or manual settings. For example a windows 2000 server with 5 users (out of the box) and default licensing set to "per server" is limited to 5 concurrent connections to sysvol or any other share provided by this server. This legal feature helps the admin to keep track of the actual needed license count and even more than that: it can deny access to a GPO if the number of allowed concurrent connections is exceeded with a dangerous result.
Later in this advisory, we will describe an exploit in which a user can avoid been locked down by a secure GPO.
First, we will describe in which system environment and scenario we found an exploit is possible.
Scenario:
A Win2k-Server(ADC) provides Terminal Services to only one remote user. The server is connected to the internet. Due to security considerations, the administrator of this server develops a tight Group Policy so that the Terminal Server user can only run one program "mywork.exe" he needs for his daily work. Everything else is locked to the remote user.
Here are the details of the server setup:
* Take a win2k-server English/German (both tested) and install it on machine connected to a network.
* Install Win2k-servicepack 2 and the security-rollup-package for Win2k.
* Promote the server to an active-directory-controller * install terminal-server in application mode with 90-day trial (no TS-licensing server).
* The license-manager-program shows five Users "per server" which enough in this scenario with one remote user.
* Create a user TS-User in the AD.
* The user TS-User is member of the security-group "Domain-User".
* The user has the right to log on locally and has the right to log on via Terminal Server in order to use the Terminal Server.
* The administrator creates another Group Policy called TS-GPO beside the default policy.
* The administrator sets up the TS-GPO tight so that the Terminal Server user can run only mywork.exe nothing else. (For quick testing what we are telling you to simply set the GPO to not show "Run" in the Start Menu)
* The admin sets the ACL of TS-GPO so that the user TS-User can read and apply it.
The result is: The user TS-User logs on via Terminal Server client (TSC) to the server. The GPO is applied and the user TS-User can do nothing more than starting "mywork.exe" and logging off. This works fine. The user logs on, logs off, logs on always seeing a locked down desktop. Till the he finds a way to avoid the tight GPO being applied to his profile.
Exploit:
Here is a systematic (step-by-step) description how to provoke the failure of the GPO by simply exceeding the number of user licenses (The user TS-User logged on and off several times before. We say this here to show that the GPO could have been saved to the profile of the user as stated by Microsoft).
1. The user TS-User connects to the Terminal Server via Terminal Server client once. (The administrator recognizes: net session shows one connection. perhaps it shows a second connection by a user called server$ or so)
2. The user TS-User opens a second connection to the Terminal Server via Terminal Server client ("net session" now shows one more session).
3. The user TS-User opens some more connections to the Terminal Server via Terminal Server client until "net session" shows 5 connections.
4. The user TS-User opens another connection to the Terminal Server via Terminal Server client. This time the sixth session exceeds the user limit. The system grants the user TS-User to log on. The system denies access to the GPO hosted somewhere on the share "sysvol". The GPO is NOT applied. The result is the user TS-User sees an open desktop. He can do only things according to his user rights due to membership of domain-user. However, he can do more than intended by the administrator.
If you try out what we are describing here, you will notice that even if the user logs off once the GPO are applied successfully, the GPO is not saved in the user profile. If the GPO would have been saved to the profile as claimed by Microsoft, the desktop would have been locked down even if the system denies access to the GPO.
Workaround:
* Disabling the service "license logging". This keeps the system from controlling connection limits.
* Change licensing from "per server" to "per seat" if this is possible with licensing.
* It is important to have TS based security in place with tools like APPSEC.EXE that allow you to bring additional controls into play specifically for terminal services environments. Group Policy is a wonderful thing, but in the case of terminal services, it should something added on top of a already carefully secured Terminal Server.
|
|
|
|
|
