My organization uses Cisco Wireless LAN Controller products, and we would like to be prepared to get out in front of any future wireless denial-of-service (DoS) vulnerabilities. What steps can we take to secure known vulnerable wireless LAN controllers before an official patch is released?
Ask the Expert!
Have questions about enterprise network security? Send them via email today! (All questions are anonymous.)
Cisco's networking devices are among the most widely used IT products in enterprises today. While largely reliable, like any product, occasionally flaws are discovered. This was the case earlier this year when a series of vulnerabilities were discovered in Cisco's WLAN Controller product line. According to the Cisco security advisory, the issues discovered in that particular incident included a denial-of-service flaw involving Session Initiation Protocol (SIP), a DoS vulnerability in its Wireless Intrusion Prevention System (WIPS), an HTTP profiling remote code-execution vulnerability, and an SNMP unauthorized access vulnerability.
Cisco, to its credit, promptly patched the affected firmware about a week after these flaws were discovered, but let's talk about how to handle unpatched incidents affecting the above-mentioned Cisco products and their network services.
With regard to a WIPS vulnerability, before the above-mentioned patch was released, there was no workaround short of disabling the WIPS feature altogether. So, depending on where your controller is positioned within your network topology, I would position it behind your landline firewall infrastructure and manage your IPS needs with a separate device. This may not be ideal, since the Cisco WLAN Controller handles policy and packet analysis that are specific to Cisco 802.11 technology -- not to mention that your organization likely spent money on Cisco's Unified Wireless Network products so it didn't have to use separate devices. However, by positioning the controller behind another IPS device, it's possible to temporarily mitigate this sort of vulnerability with layered security: The controller continues to do its thing, and the IPS is configured to protect the controller.
The SIP vulnerability is a tricky scenario. As you're probably aware, SIP is a VoIP protocol. In reference to the above-mentioned flaw, there was no workaround. Unless you have a pressing need for VoIP services over your wireless infrastructure, should this type of issue present itself again, I would disable this feature altogether and restrict VoIP service to landlines only until the vulnerability has been mitigated.
With regard to the HTTP vulnerability, Cisco stated that it was limited to software version 18.104.22.168, and only if HTTP profiling is enabled. In this sort of situation, the solution is easy: Either upgrade to a new software version or revert back to a previous version (ideally temporarily). Also, consider another troubleshooting method besides HTTP profiling for packet analysis. Compared to the other vulnerabilities, this sort of issue should be fairly easy to work around.
Finally, SNMP vulnerabilities, in my opinion, tend to carry the largest risk since they reveal network device management data. In regard to the vulnerability mentioned above, Cisco said that its controller was still vulnerable even when the "management over wireless" feature is turned off. The suggested workaround was as follows: "CPU-based Access Control Lists (ACLs) can be configured to restrict SNMP access to the affected [wireless LAN controller]WLC. After ACLs are defined, they can be applied to the management interface, the access point manager (AP-manager) interface, or any of the dynamic interfaces for client data traffic or to the Network Processing Unit (NPU) interface for traffic to the controller CPU." It may be a lot of work, especially for such an expensive product, but being prepared to implement this workaround can help quickly limit the threat such an issue may pose.
While Cisco deserves some credit for being forthright and detailed in providing workarounds when flaws are discovered in its products, this sort of situation does cause one to reconsider the value of a one-size-fits-all networking product. When considering the single-point-of-failure aspect that a significant vulnerability can present, you can see why I prefer more a more distributed networking infrastructure.
This was first published in July 2013