Date: Пт, 17 сен 1999 21:49:28
От: Russ <Russ.Cooper@RC.ON.CA>
Кому: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Тема: Alert: Exploit of RASMAN service key escalates privileges
--------------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Regarding Alberto Rodrнguez Aragonйs of The Quimeras Company message
outlining an exploit that would permit a non-privileged user to
replace the pointer to the binary executable for the RASMAN (Remote
Access Connection Manager) service on a remote computer with a binary
of their choosing.
The replacement binary must reside on the exploited server. In his
example, he 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;
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.
In our tests we were unsuccessful in getting his supplied service (a
service wrapped around NetCat) to work properly without generating an
error message. We were, 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. We assume this is simply a problem
with his service coding and not indicative of being able to
successfully exploit using this method.
There is a second key related to RASMan;
HKLM/Software/Microsoft/RASMan/CurrentVersion
which has slacker permissions, but this key remains unaffected by his
program.
Microsoft have been informed about the issue.
In the meantime, you may want to set auditing on the key in order to
be alerted to any change to it. We have not tried modifying the
permissions on it to see if there's a combination which still allow it
to function properly while preventing this exploit from working.
There appears to be a requirement that authenticated access be in
place prior to the exploit working.
I'll take this opportunity to introduce you to Kevin Pedersen
(mailto:Kevin@rc.on.ca) who has joined R.C. Consulting, Inc. as a
Researcher. Kevin was instrumental in the analysis of this exploit.
