Security Incidents mailing list archives
Re: A question for the list...
From: Steven <steve () twcny rr com>
Date: 18 May 2003 17:29:33 -0000
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 ----------------------------------------------------------------------------
Current thread:
- Re: A question for the list..., (continued)
- Re: A question for the list... Jimi Thompson (May 23)
- Re: A question for the list... Jay D. Dyson (May 25)
- Re: A question for the list... De Velopment (May 19)
- RE: A question for the list... Rob Shein (May 19)
- Re: A question for the list... Andy Shelley (May 20)
- RE: A question for the list... John McCracken (May 20)
- Re: A question for the list... Anders Reed Mohn (May 20)
- RE: A question for the list... Dave Sharp (May 20)
- Re: A question for the list... Ray Stirbei (May 21)
- RE: A question for the list... Bojan Zdrnja (May 26)
- Re: A question for the list... Ray Stirbei (May 21)
- Re: A question for the list... Steven (May 20)
- Re: A question for the list... Chip Mefford (May 21)
- RE: A question for the list... Luc Pardon (May 21)
- Re: A question for the list... Keith W. McCammon (May 22)
- Re: A question for the list... Steve Barnet (May 22)
- Re: A question for the list... Gary Flynn (May 23)
- Re: A question for the list... Valdis . Kletnieks (May 25)
- Re: A question for the list... Dave Booth (May 22)
- Re: A question for the list... Brian Finn (May 22)
- Re: A question for the list... Kevin Reardon (May 23)