Hi,
while setting up and workung with a windows 2000 server running
terminalservices I think I found a
securityhole/exploit:
Windows 2000 grouppolicies (gpo) are not applied to users if the current
count of connections to the gpo hosting
server exceed the number of installed userlicenses
This can be easily exploited on a terminalservices enabled server which I
will decribe "en detail" in this mail.
This behaviour can be reproduced on any standard installation of windows
2000 server. To be sure that
this is not caused by any fancy setting applied by myself, I repeated the
installationprocedure of the system
three times even with different languageversions of the serversoftware only
to find always the same issue.
I thought this is interesting to you and other administrators beeing
responsible for terminalservers.
general description:
=============
Grouppolicies are used to deploy desktop/systemsettings to a defined group
of users or computers and are a powerful instrument
to secure a system.With the aid of grouppolicies it is for example possible
to lock down userdesktops/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 terminalservers running
in a hostile environment (e.g terminal-servers connected to the internet)
because a cracked user-password granting access to a
weakly restricted userprofile is more dangerous than in an trusted network
inside a company.
Settings defined in grouppolicies are applied to the userprofile during
logon if the user has the right to access the grouppolicyobject.
The access is controlled by the acl (access control list) of the
grouppolicyobject. The user must have the right to read and apply
a gpo in order to successfully apply the grouppolicy to its profile.
Microsoft claims that a successfully applied grouppolicy is saved
in the userprofile when logging off (in reality this seems not to be true in
any case).
The grouppolicyobject are stored inside some directories on the share
"sysvol" hosted by a logon-server.
As any other (smb)-share, "sysvol" can suffer from connectionlimits to it,
introduced by limited userlicenses 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 licensecount and even more than that: it can deny
access to a gpo if the number of allowed concurrent
connections are exceeded with a dangerous result.
Later in this mail, I will describe an exploit in which a user can avoid
been locked down by a secure gpo.
First I will describe in which systemenvironment and szenario I found an
exploit is possible.
Szenario:
=======
A Win2k-Server(ADC) provides terminalservices to only one (1!) remoteuser.
The server is connected to the internet.
Due to securityconsiderations the administrator of this server develops a
really tight grouppolicy so that the terminalserver-user
can only run one program "mywork.exe" he needs for his daily work.
Everything else is locked to the remoteuser.
Here are the details of the serversetup:
* 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-direcory-controller
* install terminal-server in application mode with 90-day trial (no
ts-licensing server)
* the license-manager-program shows 5 Users "per server" which is really
enough in this scenario with one remoteuser !
* 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
terminalserver in order to use the terminalserver
* The admin creates another grouppolicy called TS-GPO beside the
defaultpolicy
* The admin sets up the TS-GPO really tight so that the terminalserver-user
can run only mywork.exe nothing else.
(for quick testing what I am telling you simply set the gpo no to show "Run"
in the startmenu)
* 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 beeing applied to his profile.
Exploit:
======
Here is a step by step description how to provoke the failure of the gpo by
simply exceeding the userlicenses
(The user TS-User logged on and off several times before. I 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 terminalserver via terminalserverclient
once.(the admin 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 connenction to the terminalserver via
terminalserverclient ("net session" now shows
one more session )
3. the user TS-User opens some more connections to the terminalserver via
terminalserverclient until "net session" shows 5
connections
4. the user TS-User opens another connections to the terminalserver via
terminalserverclient. This time the sixth session
exceeds the userlimit. 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 N O T applied. The result is the user
TS-User sees an totally open desktop.He can do only
things according to his userrights due to membership of domain-user. But he
can do more than intended by the admin.
If you try out what I am telling here, you will notice that even if the user
logs off once the gpo are applied successfully, the gpo
is not saved in the userprofile. If the gpo would have been saved to the
profile as claimed by Microsoft, the desktop would
have beed locked down even if the system denies access to the gpo.
As you will agree with me, neither the admin nor the TS-User are violating
any licensing issues. There is one user exceeding the 5-user limit.
The problem is the stupidity of the system by simply considering userlimits
more important than granting access to grouppolicies.
This is also no terminal-server issue, because the eventlog shows (if
auditing is enabled correctly) an event which describes
an access-denial to sysvol\... where the gpo resides.
Workarround:
=============
* disabling the service "license logging". This keeps the system from
contolling connectionlimits
* change licensing from "per server" to "per seat" if this is possible with
licensing
Microsoft has been informed by mail on march 23, 2002.
