Re: RFP9903: AeDebug vulnerability

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 12:25 AM 10/2/99 -0500, .rain.forest.puppy. wrote:

> October is Octoberfest Advisory month: one rfp.labs release planned each week
> for the whole month of October!  (Now, let's see if I can pull it off....)

IMHO, this one doesn't count.

> the following
> registry key holds the program to execute as a debugger:

> \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
>       \AeDebug\Debugger

True, but you have to get something to crash that is running as a
higher-level user than you are.  I understand that this may be possible,
but it is a precondition.

>       Now, the problem is very simple.  First, also by default, the winreg
> AllowedPaths includes \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
> NT\CurrentVersion\.

Yes, I pointed out the same thing in June, 1998.  See
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind9806&L=NTBUGTRAQ&P=R
2725 and the rest of that thread for more details (almost certainly
wrapped).  However, one detail you're missing is that this registry area is
only on the allowed paths for a _server_.  It is NOT the case for a
workstation.  BTW, there are several other issues we discussed in the same
area.

> This means any keys under it, including AeDebug, are
> accessible remotely, providing the right ACLs on the keys allow so.  Well,
> just so happens that Everyone has Special Access to Debugger and Auto
> under AeDebug.  Included in this Special Access is the permission to Set
> Value.

Nope.  This is NOT default.  There is some strange condition involving
upgrades from specific versions of NT.  My own workstation had allowed
users to write to  this key, and it freaked me out and I thought it was a
big problem.  Several other people checked their machines and found that it
wasn't, including some clean installs.  I don't know exactly what the ins
and outs are in terms of what machines will show up with this, and which
ones won't, but you won't find it on all of them.

I suspect that it might be possible to remove the CurrentVersion tree from
the allowed paths without breaking anything, and it certainly is a good
idea to check the permissions on this key to see if your machine is one of
the oddballs that allows everyone write permissions.  That's why I put a
check for this in the 5.6 version of the ISS Scanner that shipped about a
year ago.  I scanned lots of NT machines checking for this, and didn't find
many.

>       This means these keys are remotely accessible and allow anyone to
> change their values.  By changing their values, an attacker can set a
> command (or string of shell delimited commands) to execute upon a
> application crash/fault automatically.

A further precondition for pulling this off is that you need to be able to
place a binary on the system.  Else changing the registry key gets you
nowhere.

> Now, I have not confirmed this, so
> I will disclaim THIS IS JUST MY THEORY, but I would think the debugger would
> execute with a few more priveleges than the normal user

Nope.  Not unless the process that is getting debugged is running with a
higher privilege level than a normal user.  You might want to test some of
these theories before sticking them in advisories...  Consider that the
owner of a process has full access rights to a process, and this includes
the right to attach to it for debugging purposes.  There is an app called
pview.exe buried in the Resource Kit which will show you the DACL on a
process - pretty interesting.

> , so these commands
> may be run with elevated priveleges.  Of course, the actual attack
> wouldn't commence until an application crash occured.  Only if we had a
> way to make something crash remotely.....  >:)

So, you've got to:

1) Find a machine with 139 listening
2) Get a user account (anonymous won't do)
3) See if that particular machine allows rights to AeDebug (most don't)
4) Put a binary on the system
5) Make something crash that has higher access rights than you do

> ----[ 2. Solution

>       There has been previous discussion on this type of vulnerability--all
> the way back to 1997 (found on NTBugtraq).  The solution consists of two
> parts.  First, remove

Actually, June 1998, but whatever.

> \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\
>
> from the winreg AllowedPaths key, found at:

> \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers
>       \winreg\AllowedPaths

This _may_ break things.  I think it may not, but people need to test this
carefully to be sure.  I would be especially interested in hearing about
anyone's experiences with removing this entry, either good or bad.

> This will prevent remote modification of these keys.  Next, remove the Set
> Value and Create Subkey permission from Everyone's Special Access.  This will
> prevent local users from modifying the keys.

Yes, there's even a document entitled "Securing Windows NT Installation" on
Microsoft's site, and it has been there for quite some time.  It recommends
checking the security on this particular key, as well as several others.
Steve Sutton's NSA paper mentions it as well.  So does the ISS Scanner
documentation.
I strongly recommend reading the above resources for several other issues
that occur in the same area, as well as the entire thread that originally
went out to NTBUGTRAQ - Dominque Brezenski, Paul Leach and I had a er,
spirited discussion, and there were several other people who contributed a
lot of good info.

Something which is a LOT more common to find, and much worse is that if
autoadminlogon is enabled, you'll find the username and password in clear
text in the same area.  One reason I do NOT recommend using autoadminlogon,
unless registry security in this area has been closely examined.  BTW, that
one's been known since 1996, so no advisory is needed.

>       - You may have noticed no humor, sarcasm, or snide remarks in this
> advisory.  Yeah, so?

Gee - I thought making an advisory out of something over a year old _was_
humor!
<just joking>

David LeBlanc
dleblanc () mindspring com