('binary' encoding is not supported, stored as-is) In-Reply-To: <3EC6C60E.1070706at_private> 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 ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Tue May 20 2003 - 12:57:06 PDT