Skyjacking: What went wrong?

facebooktwittergoogle_pluslinkedinmailfacebooktwittergoogle_pluslinkedinmail

Security is hard to get right and shortcuts — be it coding shortcuts or design shortcuts – come back and haunt the product designers when the rubber hits the road.

The recently discovered “skyjacking” vulnerability of the Cisco LAPs seems to be a classic example.  The “Over The Air Provisioning” (OTAP) feature allows an out-of-the-box Cisco LAP to automatically discover available WLC controllers to connect to by listening to wireless OTAP packets broadcast by neighboring Cisco LAPs.  This feature obviously has attractive plug-and-play benefits for the end user but has also resulted in some critical security holes in the Cisco wireless infrastructure as reported recently.  Malicious OTAP packets transmitted by an intruder can make a LAP connect to a “rogue” WLC controller on the Internet.  This controller can modify the wireless settings of the AP in devious ways resulting in an AP that is in your airspace, connected to your wired network but completely controlled by an attacker.

Many security vulnerabilities are due to coding bugs (for example, inadequate input checking or the infamous buffer overflows).  In contrast, the skyjacking vulnerability has its root, in my opinion, in two questionable design decisions that were probably made as early as the requirements definition stage.

  1. Trusting unauthenticated over the air packets for critical configuration information, in the interest of plug-and-play flexibility.
  2. Continuing to trust over the air packets even after the AP has discovered the configuration and connected to a legitimate controller.

Let me clarify why I think these decisions were flawed.

Who do you trust?

Any protocol requires an entity to communicate with other entities in order to obtain some information.  The question is how such an entity can be assured that the responding entity is trustworthy.  This assurance can be either achieved using cryptographic mechanisms or by making certain security assumptions.

An out-of-the-box Cisco LAP can discover controller information through multiple means:

  1. OTAP packets received via wireless.
  2. Responses to locally broadcast discovery packets.
  3. DHCP (option 43).
  4. DNS resolution of a pre-defined controller name.

In theory, all of these methods are vulnerable to attack.  However, the latter three can be subverted only by an insider with physical access to a (presumably secure) wired network.  One can make (and state) a reasonable security assumption that the wired network and services such as DHCP and DNS are secure and not vulnerable to insider attacks.

This is certainly not a reasonable assumption in the case of over the air packets.  It is trivial for someone sitting in a parking lot to transmit wireless packets that will be seen by devices inside the building.  In other words, it is not reasonable to assume that over the air packets that are not cryptographically validated can be trusted.  Therein lies the nub of the problem.

So could the OTAP packets be cryptographically secured?  Not really.  And the reason is that cryptographic message authentication requires a pre-existing trust relationship between the two entities.  This trust relationship could be either:

  • a direct relationship (for example, both entities know a secret key), or
  • an indirect trust relationship via an intermediary (for example, using the public key infrastructure).

The problem is that an out-of-the-box device has no trust relationship with any other entity.  It is conceivable to create such a trust relationship by pre-programming a secret key in each LAP.  This key could possibly be used to validate the OTAP messages.  But the cryptographic validation that such a method would afford would simply be the assurance that the message has been sent by a Cisco LAP (and not by a trusted Cisco LAP) and would still be vulnerable to attacks.

The only way out of this dilemma in my opinion would be to not implement OTAP at all!

What is your window of vulnerability?

The skyjacking vulnerability would be far less damaging had the window of opportunity available to an attacker were limited to the (short) period of time that an out-of-the-box LAP took to discover a controller address for the very first time.  However, from what I hear, in some scenarios a Cisco LAP appears to accept OTAP messages even after it has been fully (manually or automatically) configured.  This was apparently done in order to support controller fault tolerance and load balancing.  This means that a Cisco LAP is vulnerable not only during its initial deployment but subsequently every time that it boots up.

In my view, other means that do not rely on trusting over-the-air packets could have been used to achieve the objectives of fault tolerance and load balancing.  Once a LAP is connected to a legitimate controller addresses, the controller can push the list of other legitimate controllers to it.  A LAP can try contacting all controllers that it knows about in order to achieve fault tolerance.  The discovery responses from these controllers can contain the load information so the LAP can choose a lightly loaded controller to connect to.  All this communication can happen over the (assumed secure) wired network, where is the need to resort to trusting over-the-air-packets?

My take on this issue is: even if the designers accepted the small window of vulnerability during initial configuration in the interest of end-user flexibility, once an out-of-the-box LAP first connected to a controller, it could subsequently ignore OTAP packets for ever (till reset to factory defaults).  The Cisco WLC does contain a switch to disable OTAP but turning on this switch merely prevents the WLC from accepting connections from LAPs that discovered it using OTAP.  It does not instruct the LAPs to stop transmitting or stop accepting OTAP packets.  Transmitting OTAP information is not quite as damaging (even though it does reveal controller IP addresses etc) than accepting OTAP information.

Conclusions

Ease of use often conflicts with security goals.  OTAP is an example of this classical dilemma.  It seems to me that it is not really possible to achieve the flexibility achieved by OTAP without compromising on security.  But admittedly there might be some smart ways to achieve to have your cake and eat it too in this specific instance.  If you have such an idea, I would love to hear about it.

From the perspective of a security administrator, it is wise to be aware that no software system is (or will be) bug free or free from security vulnerabilities.  From a defense point of view, using multiple independent security layers with non-overlapping holes is probably the only viable means of protecting one’s critical data from such vulnerabilities.  While most enterprises already deploy multiple layers of defense on the wired side (firewalls, IDS, anti-virus, etc), it is curious that most wireless administrators still seem to rely only on the security afforded by the wireless infrastructure itself!

I would love to hear about how you manage the security of your wireless network.

Deepak Gupta

Deepak Gupta is the Director of Product Architecture at AirTight Networks. He brings a unique blend of academic research and product engineering experience. Prior to joining AirTight, Deepak was an Associate Professor in the Computer Science Department at IIT Kanpur. He holds BTech and PhD degrees in Computer Science, both from IIT Kanpur.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>