RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)

From: Schmehl, Paul L (pauls_at_utdallas.edu)
Date: 07/29/03

  • Next message: Schmehl, Paul L: "RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)" 
    To: <nick@virus-l.demon.co.uk>, <full-disclosure@lists.netsys.com>
Date: Tue, 29 Jul 2003 10:07:38 -0500

    > -----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

  • Next message: Schmehl, Paul L: "RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)"

    Relevant Pages

    • RE: Active Directory New Site
      ... The internal uplink to the router would be on your 192.168.16.0/24 network ... Would it be as simple as putting the router between the existing switch, ... The piece of equipment you are missing is a router to get you from one ...
      (microsoft.public.windows.server.active_directory)
    • Re: Moon City?
      ... for many, many different kinds of specialized equipment, and the many, ... a colony. ... Many computers start crashing because a manufacturing flaw left ... distance network on January 15, ...
      (sci.space.tech)
    • RE: [Full-Disclosure] DCOM RPC exploit (dcom.c)
      ... I am a Techie Admin who is in management. ... the product, source it, install it, fix it, Admin it, everything except ... Then they had to retrofit the network. ... best work on our network and the purchased the right equipment, ...
      (Full-Disclosure)
    • Re: f Re: Different Private IPs on the Same Subnet
      ... and must also be able to access our corporate network. ... The problem is that the equipment software wants ... I suspect that the problem is an incorrect subnet mask for NIC2. ...
      (microsoft.public.windowsxp.network_web)
    • 2 Completely separate companies using same server room
      ... accomodate the other company into our network. ... What additional equipment should I get? ... We have our own switches and they have their own switch. ... logical separation between the two company's networks? ...
      (microsoft.public.windows.server.networking)
    • Quantcast