COMMAND
getadmin
SYSTEMS AFFECTED
Win NT 4.0
PROBLEM
Mnemonix posted yet another "get yourself admin rights exploit".
This exploit requires nothing more than the default permissions.
By default, the group "Everyone" has special access to the
following registry key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
As part of the special access, "Everyone" is allowed to Set the
values of the entries. The default for the debugger is :
"drwtsn32 -p %ld -e %ld -g". Anyone can change this to whatever
they want but for this exploit to work it needs to be changed to
simply "usrmgr.exe" on an NT server or "musrmgr.exe" on an NT
Workstation.
You now need to get a service to crash. When we say service we
mean any process started by the system. It needs to be a system
process because a child process will inherit the permissions of
the process that spawned it. When and if you can get a service to
crash User Manager will be started with system privs. Below is an
account of the testing of this.
When Mnemonix ran getadmin.exe on NT 4 Workstation (SP1) a memory
error occured in winlogon.exe. He then upgraded the PC to SP3.
When he ran getadmin the same access violation occured in
winlogon.exe. He logged on as a plain old user, changed the
debugger to musrmgr.exe and then ran getadmin.exe... what was
strange was the fact that he had to run getadmin on a non-existent
account first then run it against the account he was logged on
with before it would load User Manager. If you didn't do this
then the system would tell you of a memory problem as opposed to
the debugger being loaded. As to why getadmin was failing after
SP3 was installed we can't be quite sure. Anyway, it seems this
exploit will work on NT Server and workstation SP1 (and on 1 NT
Wkst SP3 - the same getadmin program works fine on all other SP3
machines.) No hotfixes have been applied.
This could obviously be refined....spoolss.exe and winlogon.exe
being the likely candidates to be targeted for causing memory
problems...all that you need is either a way to get a service to
crash or to write a util that will do it for you.
SOLUTION
The fix is to ACL the registry key as described in the white paper
on securing Windows NT at http://www.microsoft.com/security/.
The white paper is dated October, 1997, but this fix was described
in versions from 2 years ago. Note however - that will break some
things. SP4 comes with SCE and might include fix for this.