Re: A question for the list...

From: Steven (steve_at_twcny.rr.com)
Date: 05/18/03

  • Next message: Dave Sharp: "RE: A question for the list..." 
    Date: 18 May 2003 17:29:33 -0000
To: incidents@securityfocus.com
    ('binary' encoding is not supported, stored as-is) In-Reply-To: <3EC6C60E.1070706@pclocals.com>

    A fun thread, indeed.

    Some elements to consider -

    a) Current inter-network is based on the assumption of competence.
    If you offer a service on an external NIC, it must be assumed that you
    intended to offer it, and you intended the rest of the network should be
    able to utilize that service in some way.

    Concept example, the one you must resolve to say this model is untrue -
    You telenet to some.com. No tricks, no hacks, no nada. Username: Guest.
    Password: [blank]. You get a shell.

    Should you be there? Be careful how you answer - there's a LOT of
    heritage associated with "Guest". Also note that this example is moot if
    competence is assumed; it only becomes a trainwreck if competence is
    not... a trainwreck that spans every box on this network, and every
    service on those boxes.

    b) (Yep, this one's bounds check, but...) Admin of a machine had ample
    time and opportunity to mitigate an exploit vector, but didn't. His box
    gets exploited. The competence element implies that he intended that an
    exploit using that vector should occur, since he did nothing to prevent
    it. Since he clearly considers any usage of that vector (and anything
    resulting from it) to be acceptable, then our usage of that vector (with
    any result we desire) is acceptable. Since he went out of his way to make
    such an action possible, competence demands that he intended we would use
    it. Consider the perfect honeypot - a user exploiting a "weakness" in it
    is, by definition, doing exactly what the admin intended... regardless
    that the attacker may think he's violating the admin's intent, in fact he
    isn't. [On the silly side, expect to see an "I thought it was a honeypot"
    defense in a future script-kiddie trial, some day. Hmmm... I think I just
    thought up a new T-shirt! Like I said, it's a bounds check.]

    c) (Another bounds check) Admin of a machine attempted to be dilligent,
    but got exploited anyway. The behavior of the resulting compromised box is
    clearly outside the admin's intent. Regardless, we do a hack-back and
    blue-screen it, or patch it, whatever.

    As soon as the admin claims our hack-back was "unwanted", then he's
    asserting curtilage & authority over the original exploited behavior.
    Think about it - he's claiming that our stopping the behavior was against
    his intent.

    On the other hand, if the admin claims no responsibility for the exploited
    behavior, then he has implicitly denied having any authority over it. He
    may have authority over the physical hardware, but cannot have any over
    the exploited software state. As soon as he asserts terms of usage on that
    state, its existence must suddenly fall inside his intent.

    It's a subtle example, but my porch-light is "wired to the internet".
    Every time any packet hits a certain port, my porch light toggles. Can I
    claim intent over a specific state of the porch light? Or at what point
    have I disavowed it.

    Sticky. Very, very sticky.

    On the good side, if a hack-back is done, we can see that it's scope must
    probably fall only within the exploited chunk of software-state - since
    that's the only part that would probably be outside of the admin's intent.
    Collateral interruptions of other intact services as a result of our hack-
    back would probably be a bad thing, no matter now transient those
    interruptions are.

    ----------------------------------------------------------------------------
    *** Wireless LAN Policies for Security & Management - NEW White Paper ***
    Just like wired networks, wireless LANs require network security policies
    that are enforced to protect WLANs from known vulnerabilities and threats.
    Learn to design, implement and enforce WLAN security policies to lockdown enterprise WLANs.

    To get your FREE white paper visit us at:
    http://www.securityfocus.com/AirDefense-incidents
    ----------------------------------------------------------------------------

  • Next message: Dave Sharp: "RE: A question for the list..."