At 04:31 PM 8/20/99 -0700, Hargett, Matt wrote:
>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.
The most recent Win32 SDK also has an excellent section on DCOM security.
I believe it is also available from the web site (and no, I don't have the
URL handy, so please go search for it yourself). "Inside Distributed COM"
has a whole chapter on it, and this book seems to be clearly written and
thorough. This isn't to say that the above recommended book isn't (I
haven't read it), just that these 2 sources are also good.
>From: Max Vision [mailto:[EMAIL PROTECTED]]
>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?
I wrote those checks, so I know exactly what they are doing. It is no big
secret. I RTFM'd (at least twice), and figured out the security
implications of the following registry sections:
HKLM\Software\Microsoft\OLE
HKLM\Software\Classes\Appid\
HKLM\Software\Classes\ClsId\
All the code in that section of the scanner is just running down those
sections, checking for certain things (such as the presence of a RunAs
value), and then doing a fair bit of work to determine which app it really
belongs to.
It is really just a lot of grunt work. If you care to do the same work
that I did to understand the implications of those keys and the values they
contain, and then the tedious part about mapping things from GUIDs to
applications, you could write a DCOM security checker in perl, VB script,
whatever floats your boat. Writing a help system, GUI, and stuffing all
the results into a database is what really takes a lot of time.
RTFM on all the controls on dcomcnfg and RTFM on the COM security portion
of the SDK is where I learned all this. There are some portions of the NT
checks that are a little arcane, and the methology used could constitute
some sort of trade secret, but this isn't one of them. There is no
'compromise technique' per se - it is just reading the registry.
I put all that in there because I feel like DCOM security is an extremely
important aspect of overall Windows NT security, and one that is frequently
either overlooked or misunderstood.
That said, I strongly suspect that the guy who posted the original report
was admin on the boxes he was hitting. I wrote and asked him to check
that, and never heard back.
David LeBlanc
[EMAIL PROTECTED]
