I had a conversation with Rob Lempke today and I tried to repro his findings. I couldn't do it on my test machines with NT 4.0 and SP5. I got him to run a couple of tests on his machines and he had some interesting findings. At first many people suspected that Rob had simply misconfigured his permissions, or that his account had more permissions than he believed it to have. He did have his machine configured loosely, but even after altering those permissions back to what is supposed to be the default, he was still able to repro (on some machines). Anyway, the "default" configuration of DCOM, as displayed by DCOMCNFG, has no accounts specified in "Access" permissions, and Interactive, Machine\Administrators, and System in "Launch". According to preliminary information from Microsoft, there are actually implied permissions for "Access" when nothing is specified, they are supposedly the same as "Launch". "Access" permissions shouldn't, if my interpretation is correct, have anything to do with what Rob is doing (since he's able to launch applications). It doesn't explain why Rob, and others, have been able to repro it. Rob's own tests left him baffled as to what was going on. On some machines he could launch, others he couldn't, there didn't appear to be a common denominator. I had him get a normal "Domain User" account created and use it for his tests (to eliminate the possibility of increased privs on his normal account), but the results were equally inconclusive (one some machines he could launch, others he couldn't). There hasn't, so far, appeared to be an explanation as to how the DCOM permissions have been altered to permit what should, by default, not be permitted. Microsoft are busy trying to nail down all things which might alter the default way DCOM handles permissions. It could be, although doesn't seem to be, that some application is altering the default permissions without making the information aware to DCOMCNFG. Since DCOMCNFG stores the ACLs in a registry setting (uh huh!), its more than plausible that something else has entered into the way DCOM reacts to incoming launch requests and not updated the ACLs...but then this represents a flaw in DCOM itself rather than simply a flaw in its default config. Cheers, Russ - NTBugtraq Editor -----Original Message----- From: Hargett, Matt [mailto:Matt_Hargettat_private] Sent: Friday, August 20, 1999 7:32 PM To: BUGTRAQat_private Subject: Re: FW: DCOM attack against NT using VB6 Just so you know, the original mail was just a forward from the NTBUGTRAQ list. I forwarded it because I hadn't seen any mention on BUGTRAQ itself. I haven't tested this exploit myself, nor do I have any other exploit code tucked away somewhere. Moving on-- Depending on the access/launch/configure ACLs on a given DCOM object, authentication may or may not matter. Using the DCOMCNFG utility (included with NT4/5 and Win95/98), you can view the Access/Launch/Configure permissions for the DCOM objects present on your system (that are accessible via the network). Depending on how farmiliar the person who wrote the DCOM app is with CoInitializeSecurity (the COM API call for setting ACLs for Access/Launch/Configure), there are programmatic methods for launching, configuring, or deleting COM objects on a remote machine (as shown in the VB6 program below). This is similar to the problem of many win32 coders not setting ACLs on named pipes and other objects their applicatitons create. In these instances, it's not Microsoft's lack of a comptetent security model--it's the people writing to the API not taking the time to actually understand it. For those interested in learning how to write (more) secure COM apps, the book "Effective COM" (ISBN 0-201-37968) has an excellent chapter on COM Security. -----Original Message----- From: Max Vision [mailto:visionat_private] Sent: Thursday, August 19, 1999 5:39 PM To: Hargett, Matt; BUGTRAQat_private Subject: Re: FW: DCOM attack against NT using VB6 Hi, Did you have credentials to authenticate to your coworker's machines? I was able to create arbitrary files remotely on other NT machines in my network using DCOM/Word/Create, but soon discovered that this was because I had domain admin credentials that were valid for each host. IE, DCOM attacks aren't effective if you don't have authentication credentials. If you have contrary information please let us know :) I could be mistaken, since ISS does a test for non-admin access to DCOM.. What are the chances ISS/NAI want to give full disclosure on their DCOM compromise technique? Required reading: Understanding the DCOM Wire Protocol by Analyzing Network Data Packets http://www.guyeddon.com/MSJ3-98.htm Using Distributed COM with Firewalls http://www.iapetus.com/dcom/dcomfw.htm Max Vision http://maxvision.net/ On Wed, 18 Aug 1999, Hargett, Matt wrote: > -----Original Message----- > From: Rob Lempke [mailto:rlempkeat_private] > Sent: Wednesday, August 11, 1999 1:27 PM > To: NTBUGTRAQat_private > Subject: DCOM attack against NT using VB6 > > > Using the code below I was able to create 20 instances of Excel on my > co-workers machines without modifying their machines at all. The target > must be Windows NT Workstation/Server running sp3 or sp4. sp5 seems to > prevent the attack. > > Private Sub Command1_Click() > Dim xlObj As Object > Dim xlCollection As New Collection > Dim i As Long > For i = 1 To 20 > Set xlObj = CreateObject("Excel.Application", "\\NTBox") > xlCollection.Add xlObj > Next i > > i = 1 > 'clean up > While xlCollection.Count > 0 > xlCollection.Remove (xlCollection.Count) > Wend > Set xlCollection = Nothing > End Sub > > -Robert E. Lempke > -------------------------------------------- > Steven Wright one Liners: > "Black holes are where God divided by zero." > "Quantum Mechanics: The dreams stuff is made of." > "Early bird gets the worm, but the second mouse gets the cheese." > "If everything seems to be going well, you have obviously overlooked > something." > "Join the Army, meet interesting people, kill them." > "Success always occurs in private, and failure in full view." > "Ambition is a poor excuse for not having enough sense to be lazy." > "Hard work pays off in the future. Laziness pays off now." > "Everyone has a photographic memory. Some don't have film." > "Drink until she's cute, but stop before the wedding." > -------------------------------------------- >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:58:34 PDT