Full Disclosure mailing list archives
Re: DCOM RPC exploit (dcom.c)
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Sun, 27 Jul 2003 18:25:25 +1200
Paul Schmehl <pauls () utdallas edu> replied to Ron DuFresne wrote: <<snip "corporate networks should have no exposure>>
Are you really serious? Recall Slammer? There were networks that were locked down pretty tight. Slammer couldn't get in, right? Then one developer who got his unpatched copy of SQL inside the network, by logging in through VPN with his infected laptop, took the entire network down.
Or the remote office which was "too small to be worth getting a firewall for", or the contractor or consultant whose laptops are not required to meet the same standards as in-house machines brought it in from home/another site/etc, and so on and so forth...
You can't get in to our network on those ports either - unless you're already in. But I can guarantee you that we'll be chasing infected boxes down for days after the worm hits. And we've already patched everything that we could patch. ...
Yep...
... I scan for Slammer every week, because every week someone new decides to install SQL unpatched or some stupid app that has an unpatched copy of MSDE. Now I'll be chasing the RPC worm around too.
It's kinda sad that "Trustworthy Computing" turned out to mean "keep pouring the same bug-ridden shite, pre-any-service-pack-or-hotfix-or- any-other-nod-to-security-awareness "redistributables" into everything that needs them and caveat emptor...
You can't firewall 135 inside your network or you'd have no network.
8-) But that's not _quite_ the issue here. The issue is that DCOM RPC is silently enabled by default, a very small proportion of Windows users use DCOM, about one in a million of _them_ actually "need" it to be available "remotely", an even smaller proportion of those with it enabled know it even firking exists and could be a vector for someone to crap in their shoes, and yet Windows Server 2003 _still_ shipped with it installing _enabled and bound to all TCP/IP interfaces by default_. Let me reiterate, in case anyone missed it already -- no-one at Microsoft with any clout and any balls understands security.
The only reason I read lists like this is because I need to know before it hits what the next stupid exploit is that I have to deal with. And every one is a royal PITA. ...
If you want to save yourself much possible pain from this and/or any other future MS RPC-related nonsense, please read the excellent "how not to write a trustworthy OS vis network services likely to be massively unnecessarily exposed to the public sewer known as the Internet" paper: http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html.en Actually, it goes by the much more prosaic title "Minimizing Windows network services" and has been updated in recent months to include some useful, advanced, highly esoteric, TCP/IP service binding information. Why MS makes it so hard to disable, or even better, to selectively configure, the binding of services to TCP/IP (in particular) network interfaces is beyond me, especially for services that no-one in their right mind would knowingly expose to the Internet (oh, of course, I forgot -- MS employs the best programmers so they could _never_ make a mistake and thereby expose your machine to any unwanted "external" harm so we should all enable everything and not worry...) As this has turned into a rant, I may as well throw this in too... Is it just me, or is there something sinister, or at least seriously disingenuous, in MS arguing on one hand that software developers _need_ liability exception under the law "because it is impossible to produce error-free software", yet on the other hand never having shown a hint of concern that its product's were developed with exceedingly little recognition of the fact its own developers may make hugely embarrassing errors? (Of course, the latter is understandable in light of the fact that all major legislative bodies have more or less followed the US governments cowering to the "but we cannot do it well enough" argument and provided the software development industry with its begged for liability exclusions...) OK -- so that was not entirely fair... Most of the other large software developers who also lobby for the "we're too lame to make good software so you'd better legally protect our shoddy products" are probably similarly disingenuous.
... I put virus and worm writers right there in the same pile with spammers. They're all the scum of the earth. Clear examples of the worst of human nature.
Once upon a time I'd have agreed with you, but of late I feel my attitudes to these two groups (malware writers and spammers) changing -- I think you should stop being so nice about the spammers... Regards, Nick FitzGerald _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: DCOM RPC exploit (dcom.c), (continued)
- Re: DCOM RPC exploit (dcom.c) christopher neitzert (Jul 26)
- RE: DCOM RPC exploit (dcom.c) CompSecGeek (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Chris Paget (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Len Rose (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Chris Paget (Jul 26)
- Re: DCOM RPC exploit (dcom.c) morning_wood (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Shanphen Dawa (Jul 26)
- Re: DCOM RPC exploit (dcom.c) morning_wood (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Len Rose (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 26)
- Re: DCOM RPC exploit (dcom.c) Ron DuFresne (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Paul Schmehl (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Nathan Seven (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 27)
- Re: DCOM RPC exploit (dcom.c) KF (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Valdis . Kletnieks (Jul 26)
- Re: DCOM RPC exploit (dcom.c) manohar singh (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Etaoin Shrdlu (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Nick FitzGerald (Jul 27)
- Re: DCOM RPC exploit (dcom.c) Jean-Baptiste Marchand (Jul 29)