You may have heard that researchers at AirMagnet’s Intrusion Research Team have uncovered the vulnerability in Cisco’s proprietary OTAP protocol that allows an attacker to take control of an authorized light weight APs (LAPs).
Interestingly, the advisories that have come from both AirMagnet and Cisco have different severity level assigned to the reported problem. Also, the safeguards proposed in these advisories are either too involved or time consuming. For a network and security administrators, what matters is a first line of defense that can buy them some time to implement a real safeguard. But what is a real safeguard and how they can be implemented are also unclear to many.
In order to find an answer, I decided to do a self investigation of the OTAP vulnerability. I read a few docs which were relevant to Cisco’s OTAP protocol implementation:
Doc 1: Understanding Over−the−Air Provisioning (OTAP), Document ID: 100516
Doc 2: Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC), Document ID: 70333
Here are key findings of OTAP protocol implementation:
1. LAP uses Over−the−Air Provisioning (OTAP) feature to discover WLCs. LAPs support OTAP only when they have a full LWAPP Cisco IOS image.
a. Out−of−the−box LAPs are shipped from the factory with a stripped−down version of lightweight Cisco IOS® Software that is called the LWAPP Recovery Cisco IOS image and does not support OTAP.
b. Out−of−the−box 1510s and 1520 APs have a full image installed in flash. (See Doc 1)
2. OTAP process utilizes Radio Resource Management (RRM) neighbor packets. The RRM neighbor packets are transmitted without any encryption (See Doc 1)
3. The OTAP feature is enabled on a WLC by default. (See Doc 2). OTAP enabled on the controller indicates to the controller whether or not to respond to discovery requests with the OTAP bit set. It does not prevent the LAPs already joined to the controller from the transmission of the management IP address of the controller in the clear in RRM neighbor packets.
With this information available on OTAP protocol, I hope; now it would be much easier to make a judgment on AirMagnet’s and Cisco’s advisories or for that matter anybody’s advisory on this topic. Some of the frequently discussed queries are answered below:
I. Skyjacked LAP provides a direct access to a corporate WLAN
II. OTAP vulnerability will simply cause Denial-of-Service (DoS) problem
False. A Skyjacked LAP can act like a rogue device physically connected to
a corporate LAN. Once skyjacked an attacker gets full control of a LAP and he
can open a backdoor entry to your corporate LAN.
III. Disabling OTAP feature can solve this problem
IV. Only out-of-the-box LAPs are vulnerable
False. All LAPs (primarily 1100 and 1200 series) running full Cisco IOS®
Software are vulnerable.
V. My LAPs are Up and connected. Are they vulnerable?
Yes. The attack works whenever a LAP reboots. If your LAPs are up and running they are safe but reboot of a LAP can be observed in the network e.g. whenever you change mode of a LAP say from “local” to “monitor” (used in location based service, LBS) it reboots.
A First Line of Defense
Network administrators can stop vulnerable LAPs from getting hijacked by blocking LWAPP communication ports (UDP port no 12222 and 12223) in a network firewall.
• A WLAN customer with a locally deployed WLC system can block LWAPP Data and Control ports.
• A WLAN customer with a WLC present on WAN link (including REAP/H-REAP mode deployment) can apply firewall rule to allow communication on LWAPP Data and Control ports only with authorized controllers (WLCs) IP address.
Wi-Fi networks are known to have security flaws. Zero-day problem like “OTAP vulnerability” will keep on surfacing. If you are lucky you will find a first line of defense but what, if you fail to find one? Network compromise and huge Data loss Right! But the answer also depends on whether or not your WLAN deployment is equipped to protect against potential exploits of zero-day vulnerability. Use of an independent overlay Wireless Intrusion Prevention System (WIPS) adds that extra layer of security which prevents WLANs against any potential misuse.
Isn’t it a right time to think of an independent shell of security for WLANs? Choice is yours!