>Date: Mon, 22 Jun 1998 18:21:37 +0100
>Reply-To: "firstname.lastname@example.org" <email@example.com>
>Sender: Windows NT BugTraq Mailing List
>From: nemo <mnemonix@GLOBALNET.CO.UK>
>Subject: Yet another "get yourself admin rights exploit":
>Comments: To: "firstname.lastname@example.org" <email@example.com>
>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
>As part of the special access, "Everyone" is allowed to Set the values of
>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
>You now need to get a service to crash. When I say service I 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 I ran getadmin.exe on NT 4 Workstation (SP1) a memory error occured in
>winlogon.exe. I then upgraded the PC to SP3. When I ran getadmin the same
>access violation occured in winlogon.exe. I 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 I had to run getadmin on a non-existent account
>first then run it against the account I 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 I 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.
>The simple solution to this would be the change the default permissions set
>in the registry.
Duane Schaub, President |Terra World, Inc - Connecting The Planet
Terra World, Inc. |Southeast Kansas' Leading Provider
200 Arco Place, Suite 252 |Flat Fee - Never an hourly Charge
Independence, Kansas 67301 |Where Service is Top Priority!
Voice (316) 332-1616 |http://www.terraworld.net
FAX: (316) 332-1451 |firstname.lastname@example.org