Security Incidents: Re: A question for the list...

[Steven <steve () twcny rr com>]

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