full-disclosure - DCOM RPC exploit (dcom.c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3F251834.8661.1232307A@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: DCOM RPC exploit  (dcom.c)

Paul Schmehl <pauls@...allas.edu> wrote:

<<snip>>
> It takes a lot more work than that.  What do you do about the machines
> that *do* need DCOM?  Ever notice there are students learning
> programming at a university?  It's not like a corporation where you can
> shove changes down people's throats without planning carefully first.

Well, I don't know why anybody ever let most of that MS networking 
stuff run over TCP/IP in the first place.  True, preventing NT-based 
OSes from binding RPC and other less-desirable stuff to every available 
interface is not easy, but it is getting more do-able.  In case you 
haven't looked yet:

   Minimizing Windows network services

   Jean-Baptiste Marchand

   http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html.en

Now, so long as you didn't scrimp on network infrastructure and build 
important parts around cheap, TCP/IP-only routers, take that 
information and start thinking "what if we put Windows RPC services on 
IPX/SPX?".  Still doesn't help you prevent the morons who are allowed 
to install/config their own boxes from "getting it wrong" but gives 
that part of the network that does accept your guidance a fair degree 
of "free" protection while leaving DCOM RPC avalable to those that 
really do "need" it.

> You have consistently stated that all that needs to be done is "the
> work".  The implication is that there's nothing to it.  It can be easily
> done if folks would just get to work.  That implication is false and
> trivializes the amount of work that has to be done.  That is what I'm
> objecting to.

I'd also object most strongly that MS still sees fit to decide a priori 
that a _very little used_ service "should be" installed and enabled and 
bound to every firking network interface on every box its OS is 
installed upon.  We kept hearing that "least privilege" and "service 
minimization" were the key drivers behind the Windows Server 2003 
security review -- we now know that the drivers were DWI...

But it gets worse.  Instead of being off by default and requiring a 
degree of nouse be applied in the very rare cases where those services 
really are needed, we have something that requires intimate familiarity 
with your hardware and arcane registry tweaking procedures to remove to 
make your machine "well-enough secured".  (And what's the bet that the  
interface-by-interface binding of RPC services described in Marchand's 
paper can (silently) "break" if you add, remove or reconfigure network 
adaptors in the machine??)

Regards,

Nick FitzGerald