RE: [fw-wiz] Worms, Air Gaps and Responsibility

From: Dana Nowell (DanaNowell_at_cornerstonesoftware.com)
Date: 05/17/04

  • Next message: Roger Barbeau: "RE: [fw-wiz] Authenticated VS Anonymous in a secure Zone"
    To: "Paul D. Robertson" <paul@compuwar.net>, Dana Nowell <DanaNowell@cornerstonesoftware.com>
    Date: Mon, 17 May 2004 11:45:45 -0400
    
    

    At 04:46 PM 5/13/2004 -0400, Paul D. Robertson wrote:
    >On Thu, 13 May 2004, Dana Nowell wrote:
    <snip>
    >Yes, but hundreds of thousands of Cisco routers allow connections from the
    >"inside." Things like the "Poisonbox worm" are old history now- once
    >again, the ubiquity of the target means that success is hideously
    >powerful.

    I was concentrating on external attacks causing worm/virus spread, internal
    attacks are a different threat as I do not believe that deliberate worm
    release within a network by an insider is the typical vector. Under the
    scenerio of external threats the Cisco is less of a target as it exports
    less 'services'[1] (if we limit the discussion to worms/virus, social
    engineering, DDOS, and friends are not attack vectors, 'services' are the
    main attack vector, IMO). While I agree the internal interface of a router
    can typically be better secured, usually the external interface has some
    ACL security at a minimum. So externally, IMO, the Cisco has a lower
    surface than say Windows. It is not that Windows couldn't lower the
    available surface, it could (most things CAN). We have all said for a long
    time that executable attachments, RPC, and many other 'on by default'
    Window's 'services' are a bad thing. Microsoft has repeatably said, 'but
    users want them' or something to that effect. Now that the insecurity bug
    is biting deep, MS is starting to, at least officially, change their tune.

    The difference is that both Cisco AND admins of Cisco routers HAVE lowered
    installed Cisco surface (from an external viewpoint). Windows has
    historically had an increased 'default surface' with each release AND
    windows' admins[2] have not done as good a job (IMO) of reducing that surface.

    As to the issue of the internal router interface being less than tight,
    well that kind of implies either you think the worm was released internally
    OR that some other vector was initially successful and THEN the Cisco was
    attacked. One COULD argue that if you hadn't been compromised via the
    Windows/Linux/Solaris/Acme box FIRST the router was not too viable a
    target. (No I'm not really arguing that defense in depth is unnecessary,
    so save the blow torch :-).

    >
    >> Now in the case of a web server, yup, that external traffic sure does make
    >> a stop, at least on port 80. So comparing a Cisco router's external public
    >> interface with a web server's public interface is not necessarily fair.
    >> The router is probably not exporting any services on the external interface
    >> and the web server has to export at least one. So you are comparing the
    >> packet routing code in the router to all the code up through the web server
    >> on the NT box.
    >
    >No, I accounted for vulnerability surface in at least one of my messages
    >in this thread. I'm just saying that ubiquity doesn't equal targeting.

    I think we agree that 'ubiquity doesn't equal targeting'. I just think
    your message/example was not clear :-). The 'ubiquity doesn't equal
    targeting' statement gets a visceral reaction and makes people want to say,
    'then why windows, why not Macs, PDA, ...'. Your choice of example, a
    router vs. Windows in a typically external attack scenerio when people KNOW
    (that visceral thing again) that routers are externally secured and Windows
    has executable everything, wasn't clear/helping, IMO.

    >
    >> The router high level 'data entry' OS functions (add/change ACLs, change
    >> router params, ...) are all frequently/usually ACL protected. In THEORY
    >> the low level routing functions have minimal code involved (need to be
    >> fast) so the code base is MUCH smaller and MUCH more specialized and
    >> 'simpler' (no real input buffers to overflow as max TCP packet size is
    >> fixed by spec, etc.).
    >
    >Which hasn't stopped all the exploits in services the router must expose
    >when certain configuration options are on.

    Isn't that a DOH, more 'services' implies more surface? Now marry that to
    less frequently used functions get less real world testing and less real
    world testing frequently implies more 'breakability' and I think we agree.

    >
    >> So while I agree that there are alot of Cicso boxes on the net, I think the
    >> exposed code base is small, special, and reasonably free of UI/entry things
    >> like buffer overflows and such due to function. It is also unlikely that
    >
    >They come with HTTP servers now...

    Internally only, unless the admin is a moron ;-).

    >
    >> large amounts of the packet switch code get rewritten with each release.
    >> Given the small code base and the amount of 'unit hours' in the field, the
    >> current level of packet switch code SHOULD be pretty good.
    >>
    >> Comparisons to code related to web servers where the UI stuff is always
    >> changing and has more 'latest whizbang' toys in each release seems unfair.
    >> If Cisco routers had publically available web interfaces they too might get
    >> targeted more AND be broken more (for kudos).
    >
    >Network available = public in the hands of a reasonably competent
    >attacker...

    Internal network availability != external network availability to a worm
    unless you are already compromised, in which case I think we agree that you
    are pretty much already screwed. The original food that attracted the worm
    in the first place is probably VERY plentiful inside the perimeter, the
    router just ain't THAT tasty in comparison. I think both of us would
    choose internal compartmentalization of windows boxes to reduce the spread
    over "lock down the internal router interface" if we had to choose where to
    place the resources today.

    >
    >> I think that ubiquity DOES increase 'targetability' (for lack of a better
    >> term) but I agree that ubiquitousness alone is insufficient. One of the
    >> reasons to target Windows boxes over Cisco routers is SPAM. I hack a
    >> windows box (or linux, unix, or other desktop/server) I can eaisly use it
    >> to send SPAM, a Cisco router is a bit less useful (not impossible, just
    >> more complex) and lower usefulness lowers the 'targetability coefficient'.
    >
    >Adding a SOCKS v4 proxy wouldn't take all that much code...

    OK, but adding a SOCKS proxy on a router running IOS is probably a bit
    beyond the average script kiddie while installing a proxy via a canned
    windows hack script isn't. So what do you think the ratio of attackers in
    those two classes are? Which is probably a bigger short term threat to Joe
    Sixpack or Mr. Average Small Business? Yeah, I know long term is a better
    way think. However that implies that thinking occurs and that short term
    needs do not overwhelm long term thought (how many guys in a foxhole under
    fire think about what's for dinner or what they're going to do in two years
    when they get out?, yeah bad analogy but best I could do on a Monday.).

    So I agree that long term thought is better, I agree that this list is a
    good place for it, I agree that the 'professionals' are the ones to do it.
    But any long term thought that does not account for short term needs has an
    obvious uselessness. Which leads to: any examples that even tangentially
    imply that external router interfaces are in the same class as windows
    boxes better be REALLY clear as to WHY or WHY NOT because the average guys
    ducking the bullets aren't going to take time to figure it out and change
    will not occur.

    >
    >> I'd argue that boxes with equal 'ubiquity' start with an equal
    >> 'targetability coefficient' which is then adjusted based on end use (kudos,
    >> spam, intel, ...) and 'breakability'. Since Windows scores high in all
    >> three categories, it becomes the 'industry leader'. Cisco scores high in
    >> the first category but low in the remaining categories. IMO, Linux scores
    >> a medium, medium-high, and a medium. As Linux becomes more prevalent and
    >> is run more often by 'Joe Sixpack', its targetability will increase.
    >
    >Solaris is less popular then Linux as a platform, and yet it's been used
    >for automatic malcode about as much (I'm discounting manual intrusions
    >because they rely more on the skillset or toolset of the attacker to
    >achieve targetability.)

    So Linux is medium, medium-high, medium and Solaris is medium-low,
    medium-high, medium-high, sounds like a close race. I think that's my
    point, ubiquity + usefulness + breakablity = targetability coefficient.
    I'm still unclear on any weighting factors that should be applied. Things
    like reputation also factor in to some degree, Windows has a 'bad rep' and
    Linux has a 'good rep' in security (visceral relativity, so to speak). I
    honestly think that if Windows became more secure than Linux tomorrow, it
    would still be the target of choice for awhile. I'm sure there is a
    lead/lag function to the 'rep' process. I guess we could replace
    'breakability' with 'perceived breakability' but that's going to get
    nastily subjective (not that this topic isn't already subjective to a big
    extent).

    <snip>
    >So, I'll argue that ubiquity doesn't necessarily increase the level of
    >targeting (re: Cisco,) nor the success of targeting (re: No
    >click-to-execute mail clients.) Sure, it does have some impact on the
    >level, but it's not a given that "lots of things" means "lots of shot
    >things," and it certainly doesn't mean "the same number of dead things."
    >I do think it means "more shot things."

    Yeah, we agree. I honestly thought we did when this started, I just
    disliked your example. It appeared unclear (at least to me) and needed
    discussion to make the point clearer . I was happy to help :-).

    [1]: I place 'services' in quotes because I lump in packet routing and all
    endpoint connectivity (mail routing, mail viewing, disk shares, web
    surfing, ..), many of which are not found in /etc/services.

    [2] Especially when including the home user with a broadband pipe in the
    calculation.

    -- 
    Dana Nowell     Cornerstone Software Inc.
    Voice: 603-595-7480 Fax: 603-882-7313
    email: DanaNowell_at_CornerstoneSoftware.com
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    

  • Next message: Roger Barbeau: "RE: [fw-wiz] Authenticated VS Anonymous in a secure Zone"

    Relevant Pages

    • RE: [fw-wiz] Worms, Air Gaps and Responsibility
      ... >> Even Cisco is not immune to the exploits. ... >given that ubiquity equates to common and automatic malcode exploitation. ... not let any traffic arriving at the external router adapter 'talk to' the ... more complex) and lower usefulness lowers the 'targetability coefficient'. ...
      (Firewall-Wizards)
    • T1 Site-to-Site VPN
      ... Cisco 1841 ... crypto isakmp policy 1 ... set security-association level per-host ... Cisco Router and Security Device Manager is installed on this device. ...
      (comp.dcom.sys.cisco)
    • RE: Router with security features
      ... Subject: Router with security features ... Unlike other companies Cisco tells their customers about bugs and security ... Using this information you can proactively secure your network. ... turn on a router configure it and then never look at it again. ...
      (Security-Basics)
    • Re: Connecting Cisco 831 Router behind the D-Link Router
      ... My home network uses D-Link Router providing 192.168.1.x addrress ... When I connect Cisco 831 Router so that I can be ... At its most basic level, the dlink is a switch, and just had a dhcp ...
      (comp.dcom.sys.cisco)
    • Re: Connecting Cisco 831 Router behind the D-Link Router
      ... My home network uses D-Link Router providing 192.168.1.x addrress ... When I connect Cisco 831 Router so that I can be ... At its most basic level, the dlink is a switch, and just had a dhcp ...
      (comp.dcom.sys.cisco)