Re: FW: DCOM attack against NT using VB6

[Russ.Cooper () RC ON CA (Russ)]

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_Hargett () NAI COM]
Sent: Friday, August 20, 1999 7:32 PM
To: BUGTRAQ () SECURITYFOCUS COM
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:vision () whitehats com]
Sent: Thursday, August 19, 1999 5:39 PM
To: Hargett, Matt; BUGTRAQ () SECURITYFOCUS COM
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:rlempke () ADNET2000 COM]
> Sent: Wednesday, August 11, 1999 1:27 PM
> To: NTBUGTRAQ () LISTSERV NTBUGTRAQ COM
> 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."
> --------------------------------------------