Depending on your configuration your wireless supplicant may connect automatically to these adhoc networks without you really knowing. Other times, the users sees a pop up “Free Public WiFi” and willingly connects to the network in hopes of free internet access. To the untrained eye these are wireless networks promising a free WiFi connection. However, you have no idea who is on the other end. The mobile user suspects it a real access point.

This NPR article stops by saying “it’s a bad thing and you should never connect”. But lets cover the why and the how. Suppose  I configure an adhoc wireless network  broadcasting the SSID “Free Public WiFi” from my laptop in a busy area where mobile users frequent. This could be at the mall, airport and conference center for example. The adhoc configuration is simple, so simple in fact it can be done in under a minute. You may recall a number of months ago the Russian spy’s were using adhoc wireless to communicate amongst themselves.   

After I configure my adhoc wireless network. A non suspecting mobile user connects to me thinking they are getting FREE PUBLIC WiFi. But what they don’t realize they are connecting to my laptop. At which point I now have a layer 2 adjacency with this user. From here I could run a DHCP server on a VM local to my laptop. Whereby bridging layer 3 connectivity between me and the unsuspecting mobile user.

Once this is complete it’s a simple launch of Backtrack, whereby I could act as a man in the middle or deploy a library of attacks. 

http://www.npr.org/templates/story/story.php?storyId=130451369 

Wikipedia - http://en.wikipedia.org/wiki/Wireless_security
Security Tube - http://www.securitytube.net/Attacks-on-WiFi-(ADHOC-Networks)-video.aspx
Hot Spots Attacks - http://www.ethicalhacker.net/content/view/66/24/

I was asked, “The WiSM Config Practice has been out for years, how did you find this ?” The devil is in the details.... 

WiSM Configuration Practice

The initial steps in configuring a Cisco WiSM is what I like to call a “configure-and-forget” step. This is because once the WiSM is configured and married to the backplane of the Sup720 via the “service port” its rare one would need to revisit this procedure again.

There are a number of Cisco WiSM Configuration guides available at cisco.com explaining this process. We will get into these in a bit… 

What is the WiSM “service port”?

First lets understand what the service port interface is and the purpose of the service port. The WiSM service port is one of many ports on a Cisco WiSM. They include the management, ap manager, virtual, service and the operator dynamic interfaces.

•  Management interface (pre-defined and mandatory)
•  AP-Manager interface (pre-defined and mandatory)
•  Virtual interface (pre-defined and mandatory)
•  Service-port interface (pre-defined and mandatory)
•  Operator-defined interface (user-defined)

Cisco’s 4400 and 5500 model controller’s service port is used for out-of-bandwidth management. The service port is a physical port supported on these models, whereby allowing you physical access with a console / null modem cable.

Contrary to the service port on the 4400 and  5500’s models. The WiSM service port is NOT used for out-of-bandwidth management. Rather it is used to synchronize the supervisor engine (720) and the WiSM. 

How does the “service port” on the Cisco WiSM connect to the Sup720?

Once the WiSM is installed, you enter the Sup720 and create a local vlan for the purpose of communications between both the WiSM and the Sup720.  Cisco references vlan 192 in their WiSM config documents, but of course any vlan number can be used. 

Cisco’s WiSM Configuration documentation goes a step further and states to create an SVI interface. An SVI interface is a gateway to bridge traffic. (Here in lies the problem. I will cover in more detail in the next section.)

(See below reference and links to Cisco WiSM configuration Guides, note the SVI interface recommendations and the lack of an ACL) 

The Vulnerability

The Cisco WiSM Configuration Guides detail the creation of an SVI interface for the purpose of the service port interface. For example;

Sup720(config)# interface Vlan 192
Sup720(config-if)# ip address 192.168.10.1 255.255.255.0
Sup720(config-if)# no shutdown
Sup720(config-if)# exit

The Cisco WiSM Guides makes no reference to an ACL which would restrict traffic access to the service port SVI interface. By creating the SVI interface you have a “connected route” from users who terminate to the 6500 to reach the SVI interface. This would include wired and wireless users. Essentially, inside users have access to the WiSM service port. This would also include wireless guest!

Lets follow the packet:

1)     Wireless client pings 192.168.10.1

2)     The packet egresses the wireless client and 802.11 headers are applied

3)     The packet travels via RF

4)     Packet reaches Access Point

5)     Access points encapsulates the packet in a LWAPP/CAPWAP headers

6)     The packet is then sent to the Cisco WiSM / Controller

7)     The WiSM removes the LWAPP/CAPWAP encapsulation and adds 802.3 headers

8)     The WiSM places the packet on the wired

9)     The packet transverses the router to the connected 192.168.10.1 SVI interface

I’m positive this is an oversight by Cisco. Recent conversations with Cisco SE’s, Cisco TAC and other peers agree this is an issue on many levels.

Engineers and Admins who configure the WiSM for the first time or perhaps engineers who have little knowledge would follow the Cisco WiSM Configuration Guide step by step. Not understanding that an ACL needs to be applied to the SVI interface for the WiSM service port. 

Real World Examples:

Lets cover why this is an issue with some real world examples:

Example#1 –

Your inside networks are 10.x.x.x and 172.x.x.x. Your service port on the WiSM is configured for 192.168.10.x network. Users who terminated to the cat / Sup 720 that houses the WiSM has access to the SVI interface 192.168.10.x. Why, because it is a connected route. The traffic will bridge over from 10 / 172  to the 192 network.

Example#2 –

Suppose you don’t have a Cisco WLC to anchor guest traffic. Your wireless guest traffic terminates to the  cat / Sup720 that houses the WiSM. Let suppose you ACL your "GUEST" SVI interface denying your known inside networks. You think you are done and call it a day.

DENY 10.0.0.0 (inside network)

But did you remember to deny 192.168.10.x? If you didn’t your wireless guest now have access to your service port

How to Fix it:

If you configured an SVI interface. Simply ACL the SVI not to allow ANY network access to this SVI interface.  

Conclusion:

I admit this isn’t a five-alarm hole. You don’t have to drop everything you are doing.  But it is one that needs to be addressed if you followed Cisco WiSM Configuration Guides.

Cisco links to WiSM Config

http://www.cisco.com/en/US/docs/wireless/technology/wism/technical/reference/appnote.html

! - Create a vlan in the Supervisor 720, this vlan is local to the chassis and is used for

communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit interface on

the Supervisor and service-port in the Cisco WiSM. 

Sup720(config)# vlan 192 

! -- Assign an appropriate IP address and subnet mask for VLAN 192 

Sup720(config)# interface Vlan 192

Sup720(config-if)# ip address 192.168.10.1 255.255.255.0

Sup720(config-if)# no shutdown

Sup720(config-if)# exit

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_tech_note09186a00808330a9.shtml

Create the WiSM Service Port Gateway and assign the IP address.

Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit Interface on the Supervisor and a service port in the Cisco WiSM.

interface Vlan192 

Description WiSM Service Port Gateway or Management Interface on CAT6K

ip address 192.168.10.1 255.255.255.0 

  

I want to share an event you may not see very often in the wild, TKIP countermeasure. 

The TKIP countermeasure is a configurable variable by SSID and can be disabled. I blogged about this in December of last year. The commands for both the WLC and Autonomous are below:

So what happen?

Geo - “I blogged on my site about the unencrypted RRM packet just a few weeks ago. The RRM packet got little attention, but I seen this as a much bigger issue. I seen this as more than just an IP address in the clear but rather a gold mine of information, but just how could it be exploited. “

In this tutorial I will share with you an attack using the recently identified and less talked about security vulnerability with the Cisco RRM packet in conjunction with SNMP. I would like to emphasize --- this video is to educate network engineers,  system administrators and security professionals of the potential risk of a enterprise wide attack on your Cisco Unified Wireless Network if Cisco best practices are not followed.

The foundation of this attack is to use the less talked about RRM and widely known SNMP vulnerabilities.  There isn’t  anything new that isn’t already known about these vulnerabilities, but what I will share  is the concept of an attack and the real world potential it may have in your enterprise especially if you use default strings or and more importantly if an attacker knows your strings on the WLC. The concept of the attack is simple, sniff the RRM packet, discovery the WLC, and then join the WLC to the rogue WCS server. After which point your wireless network is at the complete mercy of the hacker. The hacker could create a “rogue” ssid for later outside attack over wireless, complete DOS attack of your wireless network enterprise wide, delete admin accounts on the controllers to prevent you from logging into the controllers while an attack is underway.

In the last week you heard about the OTAP issue. OTAP stands for Over The Air Provisioning. It is a means whereby a Cisco access point can find a Cisco controller to initiate a join process.

OTAP when enable, by design , sends the controller mac and ip information in the clear every 60 seconds in the multicast RRM packet. This aids access points to join the network.

Cisco recommends you disable OTAP during normal production. OTAP should only be deployed during the deployment phase of a wireless network.

What isn’t being reported, when disabled the RRM packets still includes the controller mac and ip address!

 Enjoy the video 

If you're an Enterprise user or any user that uses Windows Zero Config with WEP or PSKs. Or if you're a user who forgot or lost your WEP or PSK, this video is for you!

The WZCOOK application can be delivered via a USB stick and launched on a workstation and within seconds revealing your networks WEP or PSK keys.

In the case of an attacker exploiting a system with WZCOOK, specific to WPA or WPA2 networks using a pre-shared key authentication, are also vulnerable since there is no regular key rotation mechanism. WPA or WPA2 networks using IEEE 802.1X authentication and an EAP type are also vulnerable to attacks when the PMK has been revealed, but it is limited to a single workstation and only for the duration of the current authentication session.

Fig 1

My Video Link: (click full screen for better viewing)