full-disclosure - RE: DCOM RPC exploit

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] [day] [month] [year] [list]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: RE: DCOM RPC exploit

"Steve W. Manzuik" <steve@...renchtech.com> wrote:

<<snip>>
> I understand that admins are busy people -- I used to be one.  But in
> reality are there that many boxes still out there with the ports required
> for exploitation open?  Again, I should probably put my beer down (but its
> almost Vegas week) and do some actual research.  I am fully aware that you
> can exploit this over IIS if it is enabled.

Nothing to do with IIS (which will almost certainly be ignored as an 
attack vector should this DCOM RPC thing ever be used in a worm).  
Think "XP Home", think Win2K or XP Pro in SOHO settings (1-5 ?? 
machines on a LAN with Internet sharing over a DSL or cable 
connection).

Now imagine Paul's perspective -- he faces much that scenario 
"internally".  That is, he can (I think, more or less) block anything 
coming or going at the border that looks like it might be exploiting 
the RPC bug but neither he nor his department have any "authority" over 
several thousands (?) of student-owned and run machines inside "his" 
LAN or several dozen to several hundred (?) staff machines where the 
"owning" department or even just the user has elected to manage the 
machine themselves (which usually means exactly the opposite -- that 
they have chosen to not allow the machine to be sensibly managed at 
all).  In a corporate environment, such a setup is all but 
unimaginable, but in the "we invented the Interent and were using it 
for years before you lot came along" arena of (especially US) academia, 
this is pretty much the expected (I hesitate to say "desired") 
configuration.  Many large universities have only recently been able to 
implement _any_ kind of packet filtering, monitoring or firewalling 
because of its perceived threat to free spech and academic freedom (and 
there may still be several very large university sites where the IT 
staff have not been able to get over, around, under or through that 
hurdle, yet have a mass of un-managed machines connected to their 
largely wide-open "LAN").

Regards,

Nick FitzGerald