response to cisco light-ap weakness

A Afshin Mansoorieh 3 years 7 months ago
1 0 0

greetings,after the recent news about a flaw that was discovered in cisco light-ap, one our customers who uses our infrastructure and is planning to evaluate cisco solutions, asked if me we could give them a position statement on this flaw and why it does not affect the Motorola gear.With great help from our EWLAN-BU, I crafted and sent the following written response which I would like to share with the team in case anyone else gets the same query and the opportunity to explore this issue, so here it goes: We have discussed your question with our team and here is our understanding of the issue and how it compares with Motorola infrastructure. Please feel free to let me know if you would like to discuss in more details. Vulnerability Details:

Cisco LWAPP 1100 and 1200 APs are affected by this.

At startup, LWAPP APs without a configuration use over-the-air provisioning (OTAP) to associate with a Cisco WLAN Controller. Devices without preconfigured controller lists or certificates have no method of distinguishing valid controllers from malicious ones.

An unauthenticated remote attacker could exploit this vulnerability by injecting remote radio management (RRM) packets with fake Controller information onto the wireless network while an un-configured AP starts up. The injection of malicious RRM packets could manipulate the OTAP process to cause the device to associate to the attacker's controller.

If an exploit is successful, the AP may associate with the attacker's WLAN Controller. Because the rogue Controller cannot access the underlying RADIUS infrastructure (if it can, then there are much more serious wired security issues at stake), the rogue AP and Controller cannot authenticate incoming wireless users. As a result, clients may not be able to access legitimate network resources, leading to a DoS condition.

Only wireless APs that are deployed without a setup configuration are vulnerable. Devices using Locally Significant Certificates (LSCs) or devices with preferred Controller lists configured are not vulnerable.

Motorola Infrastructure:

We do not publish the IP address of the wireless switch/controller in the beacon

We recommend the APs to be provisioned first through a trusted wired connection before plugging it on to other networks

The AAPs (Adaptive APs) are capable of supporting a secure VPN tunnel between the switch the AP which can be configured.

We support and recommend using AES encryption for Point-to-Point Mesh Links.

Motorola's Position:

The new vulnerability highlights a systemic issue with WLAN products that are left to self-audit and self-protect.

Good WLAN security is to not only use authentication + encryption but also have in place, 24x7 Monitoring. Using WLAN monitoring and intrusion prevention solutions such as Motorola AirDefense Enterprise would provide a gap-free security.

As Cisco WLAN vulnerabilities go, this is not as severe issue as some are making it to be (in our opinion). It can be avoided by proper configuration and using authenticated controllers, but here are some past security vulnerability announcements from CISCO:

· Cisco Security Advisory: Multiple Vulnerabilities in Cisco Wireless LAN Controllers · Cisco Security Advisory: Cisco Wireless Control System Tomcat mod_jk.so Vulnerability · Cisco Security Advisory: Cisco Wireless Control System Conversion Utility Adds Default Password · Cisco Security Advisory: Wireless ARP Storm Vulnerability · Cisco Security Advisory: Multiple Vulnerabilities in Wireless Control System · Cisco Security Advisory: Default Password in Wireless Location Appliance · Cisco Security Advisory: Cisco Airespace Wireless LAN Controllers Allow Unencrypted Network Access

CONTACT
Can’t find what you’re looking for?