COMMAND
(R)RAS
SYSTEMS AFFECTED
WinNT 4.0 (Wks, Server, Enterprise Edition, Terminal Server Edition)
PROBLEM
Alberto Rodríguez Aragonés found following. Any domain user can
enumerate services in any domain machine:
SC_HANDLE hSCM = OpenSCManager(machinename, NULL, SC_MANAGER_ENUMERATE_SERVICE);
So you can open a handle to the Service Control Manager, the bug
is that with this handle you can obtain full access to the RasMan
service:
SC_HANDLE hService =3D OpenService(hSCM, _TEXT("RasMan"), SERVICE_ALL_ACCESS);
Now you can change RasMan configuration, for example the binary
path name, and run a malicious service with System privileges.
For a demonstration exploit visit:
http://www.teleline.es/personal/quimeras/ntsu
The replacement binary must reside on the exploited server. In
example, Alberto uses the fact that a domain user would normally
have a home directory on the server as the method of placing the
binary on the server itself. His web page description of the
exploit:
http://www.teleline.es/personal/quimeras/ntsu/rasmanbug/rasmanbug.htm
talks about the directory "x:\users\user". While the unprivileged
user might have this pathname, the server is unlikely to be able
to see a binary referenced by it. Therefore, in order to properly
exploit using the methods provided, the exploiting user would have
to know the actual physical path to the binary on the server
itself. This path is then input into the BERTZHOLE.EXE program
provided, which in turn connects and updates the services entry
at:
HKLM/SYSTEM/CCS/Services/RASMan
ImagePath=
which would normally have a value of
%systemroot%\system32\rasman.exe
and replaces it with the value entered into BERTZHOLE.EXE. The
permissions on this key are:
Administrators=Full Control
System=Full Control
Everyone=Special Access...
Query Value
Create Subkey
Enumerate Subkey
Notify
Read Control
so clearly, he should not be permitted to change its value.
However, the Dacl on the registry key has nothing (directly) to
do with the Dacl on the service. The Dacl on the service is
contained in the Security value under the Security subkey. This
is a self-relative SD which the Service Control Manager reads
from the registry and enforces at the RPC level. The SCM
(running as SYSTEM) should be the entity changing the actual
registry values. For the RasMan service, the Dacl contained in
Security\Security gives Everyone=Full Control.
In additional tests by Russ Cooper he was unsuccessful in getting
his supplied service (a service wrapped around NetCat) to work
properly without generating an error message. He was, however,
successful in using his BERTZHOLE.EXE program to point the RASMan
binary path to a Carbon Copy 32 service binary and successfully
launch it. Assumption is that this is simply a problem with
Alberto's service coding and not indicative of being able to
successfully exploit using this method.
Services in Windows NT are securable objects, just like files and
directories are for example. Thus they are equipped with DACL's
which control access to them, and with SACL's which control
auditing on them. They also have owners. All services seem to
have pretty tight permissions set on them by default, except the
rasman service to which Everyone have all permissions. One of
those permissions is "Change Configuration" (a service specific
permission), which allows to connect to the Service Control
Manager and change the configuration of the service. One thing
which can be changed is the path to the service binary. This is
what has been shown in practice by Alberto Rodriguez Aragones,
with his exploit program BertzHole.
SOLUTION
Patch available at:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/Hotfixes-PostSP6/Security/Rasman-fix/
Notice that its in a "Hotfixes-PostSP6" directory. The fix was
developed after SP6 itself was locked down for release. Although
SP6 is not yet released (will be in a couple of days btw), this
hotfix comes after SP6, hence the directory naming. However, the
hotfix can be applied to SP5 boxes, and will not be over-written
when SP6 is applied to a box with it installed. Its important to
remember, however, that the fix **will not** be included in SP6,
hence its "PostSP6" status.