Fwd: Yet another "get yourself admin rights exploit":

Duane Schaub ( dschaub@terraworld.net )
Fri, 26 Jun 1998 08:28:36 -0500

For those who missed this, there was an important security oversight posted
on Bugtraq recently. Although it has been known for several years, the
recent posting may encourage renewed attacks of this type. Although my
testing is far from complete, I have removed the WRITE permissions from the
key listed below and have not seen any adverse effects.


>Date: Mon, 22 Jun 1998 18:21:37 +0100
>Reply-To: "mnemonix@globalnet.co.uk" <mnemonix@globalnet.co.uk>
>Sender: Windows NT BugTraq Mailing List
>From: nemo <mnemonix@GLOBALNET.CO.UK>
>Subject: Yet another "get yourself admin rights exploit":
>Comments: To: "ntsecurity@iss.net" <ntsecurity@iss.net>
>Dear All,
>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
>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 |dschaub@terraworld.net