RE: DCOM RPC exploit (dcom.c)

["Schmehl, Paul L" <pauls () utdallas edu>]

> -----Original Message-----
> From: Nick FitzGerald [mailto:nick () virus-l demon co uk] 
> Sent: Monday, July 28, 2003 10:12 PM
> To: full-disclosure () lists netsys com
> Subject: RE: [Full-disclosure] DCOM RPC exploit (dcom.c)
>
> ...if s/he is under-resourced.  It need not be the way you 
> describe at  
> all.  It can be done _much_ better with a relatively small initial 
> commitment to "doing it properly".  Of course, most 
> enterprise systems 
> start off with the "is there a cheaper option" attitude.  In a 
> "manufacturing" type operation, such a question tends to have a 
> (relatively) low opportunity cost should it turn out that the cheap 
> route leads to too many failures (you switch to the slightly more 
> expensive but better quality inputs, suck up the cost of recalling or 
> otherwise replacing the already shipped stock and perhaps push up the 
> price a bit).  However, if what you scrimped on was "infrastructure" 
> fixing it nearly always entails pulling out great gobs of now largely 
> useless and valueless plant and replacing it with more expensive but 
> better fit equipment.  Thus taking the cheap route on infrastructure 
> such as networking equipment, operating systems, network security and 
> so on becomes a hugely expensive thing to "fix properly".  
> Thus we tend 
> to see band-aid fixes such as firewalls, IDSes, antivirus 
> software and 
> all manner of other things that should be largely unnecessary 
> were the 
> system they are going into "properly designed" from the start.  (This 
> is not say that those things might not have _some_ value in a 
> properly 
> designed and maintained system, but they certainly should not be the 
> security "front line" in enterprise systems.  Of course, for the SOHO 
> market, such band-aids may be the only viable solutions given 
> there is 
> not (enough) money to hire the best trained and equipped professional 
> sysadmin staff nor can the initial setup overhead of "doing it 
> properly" be justified against the size of the userbase and/or the 
> value of the "operation".)

All of this is true and wonderful and oh so right.  (Not pickin' on you,
Nick.)

Now let me tell you how it works in the real world (one example.)  Our
School of Management is moving in to their new building in the next week
or so.  Obviously, when you put up a new building, one of the things
that has to be done is wire it and build the infrastructure for
networks, right?  (Well, actually, when they built the new Activity
Center a few years back, they sort of forgot that part until the
building was finished.  Then they had to retrofit the network.  Now
**that** was fun!!)  So, they consulted with IT to find out what would
best work on our network and the purchased the right equipment, right?

Well, actually, the Dean happens to have contacts at Alcatel, and
Alcatel, in their gracious wisdom, decided to donate *all* the
networking equipment that the new building would need - switches,
routers, cabling, everything.  How nice of them, right?  Weeeellllll, it
turns out that what they donated is stuff they couldn't get rid of, much
less sell for a profit.  Gives them a nice tax writeoff, and, much to
the Dean's chagrin, limits the functionality of the network.  (You see,
they *did* consult with IT *afterwards*, when things weren't working the
way they expected.  That's when they got the *bad* news.  No H.323 for
you.  No QoS.  Etc., etc.)

Now their stuck with a less than optimal configuration, limited
capability and obsolete equipment.  And IT is stuck with the headache of
trying to support that, dealing with the constant complaints that will
come from the staff and faculty of that school when things don't work
right, etc., etc., etc.

Oh, and was any thought given to security in the design phase?  Well, of
course not.  They didn't even have locks on the wiring closets until we
refused to support them unless they were installed.  (Although some of
us actually argued that we'd be better off to leave the locks off.  That
way the equipment would get stolen, and we could charge SOM for the
replacements, which would be configured the way *we* wanted them with
the capabilities that they need - and paid for by SOM.)

In an ideal world, none of this would happen.  But that is what I
referred to in an earlier post as the "pollyanna" world.  I know all the
techies would just *love* to be making the decisions about stuff like
this (so would we, don't kid yourself), but it's never been that way,
and it never will be that way.  That's reality.  And that's what IT
folks have to deal with every day.

I've actually seen posts where people have said things like, "Well, I
wouldn't work for a place like that."  Indeed.  That's why you're
unemployed.

So, when you(pl) shake your head and think, "They could do so much
better if they just had a clue", keep in mind that the real world
doesn't always give you what you want or need, and you have to learn to
deal with what exists, not with what you'd like to see exist.  And then
you have to listen to all the armchair generals telling you how
incompetent you are.  It's no wonder a lot of admins get very
frustrated.  (Again, I'm not talking about myself.  I really don't give
a rats ass what anyone thinks of me, so it doesn't matter what you say
about me.  Which is why, BTW, I'm perfectly willing to keep pounding
this point home, regardless of how much STFU mail I get.)

Now I'm certain that *someone* in this group of resident geniuses will
respond, "Well, the Dean should be fired if he's that stupid."  Well
Einstein, Deans get paid for bringing money into the school and riding
herd on the faculty.  The Alcatel deal *helps* his credibility with
senior administration.  How's that for a topsy turvy world? 

Paul Schmehl (pauls () utdallas 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