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:visionat_private] >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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:58:07 PDT