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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:31 PDT