Message-ID: <001201c35528$67ddfc80$6701a8c0@VALUEDBGU6KK3Z>
From: admin at governmentsecurity.org (Admin GSecur)
Subject: DCOM RPC exploit  (dcom.c)

I completely agree, unfortunately this is a constant problem in any
enterprise size network.  So many times it only takes a less experienced
network admin to bring a network to it's knees.

Personally I have found an aggressive and continuous network auditing
policy by the corporation can help negate any difference in security
levels among the large number of servers and devices on their network.
But so many times the corporation doesn't want to spend the capital on
the manpower needed. (Even if it is for a single additional body)

Another common problem is the random "orphaned" server that was
installed with out the NOC ever knowing.  So many times this single
neglected machine can cause the downfall of even the tightest network.
So are the woes of an enterprise admin.

Blake Wiedman
Founder GovernmentSecurity.org
"Know thy enemy"

-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Schmehl,
Paul L
Sent: Monday, July 28, 2003 12:12 PM
To: Ron DuFresne
Cc: Robert Wesley McGrew; full-disclosure@...ts.netsys.com
Subject: RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)

> -----Original Message-----
> From: Ron DuFresne [mailto:dufresne@...ternet.com] 
> Sent: Monday, July 28, 2003 10:46 AM
> To: Schmehl, Paul L
> Cc: Robert Wesley McGrew; full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)
> 
> And those sites during slammer that blocked 1434, as was 
> advised when the patch was made available, though it was 
> advised even long before that, were largely unafected.  Sites 
> that are properly blocking 135 and it's protocolcs will most 
> likely be unaffected from any new worm wishing to exploit 
> this repeat problem with DCOM/RPC.
> 
This is simply and plainly false.  I don't know why people can't seem to
grasp this.  I know of several major corporations who not only had
1434/UDP blocked at the firewall but also on a number of internal
routers *and* had aggressive patching programs, and they *still*
suffered from Slammer.   All it takes is *one* infected box *inside* the
network to negate all the hard work you've done trying to keep the worm
out.

When you have 150,000 machines worldwide, having 1% of those unpatched
(which is a 99% *success* rate) means you have 1500! vulnerable
machines.  Most situations that I'm familiar with were in the tens - not
even the hundreds - but it only took 10 or 15 machines to take down the
entire network due to the nature of that worm.  10 or 15 boxes
represents 1/100th of a percent of the total, yet that small number
could completely destablize a network and cause untold hours of work for
the admins and networking staff.

Now anybody who wants to tell me that a 0.01% failure rate in a patching
program proves the admins are incompetent is simply ignorant of the
issues.  I guess it's just impossible for people who don't actually run
a large network to grasp the nature of the issues.

You build your little home network, you put up a FreeBSD box as a
NAT/Router/Firewall, and you think you understand networking in a large
enterprise?  You haven't a clue.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists