RRM and OTAP frames - Vunerability or not?

[kfarrington]

Please refer to the this thread but thought it may be an idea to start a new one.

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&type=Subscriptions&loc=.2cc04897/6&forum=Wireless%20-%20Mobility&topic=General

So, now I have my security police hat on.

RRM neighbor messages and OTAP messages contain (says the doc) the IP address of the controller.

http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a008093d74a.shtml

Is this desireable as we go to great lengths to secure and protect the identity of the wired network? As any network RF sniffer can pick these up I assume?

Thoughts on this please?

Many thx,

Ken

[dennischolmes]

Yes this does have to do with this post. What basically happens is you use your own controller to capture someone elses APs. Then put them into reap mode. This allows you to remain connected and since you on the wireless vlan, you have visibility into the network from a physically connected standpoint. If you set up primary, secondary, and tertiary controllers along with disabling 12222 and 12223 port traffic to one way only then you have effectively stopped this hack. The problem is you must have multiple controllers and a firewall. A lot of smaller customers haven't invested in that amount of infrastructure. It is now a must.

[kfarrington]

Many thx indeed,

Ken

[George Stefanick]

Im more surprised that when disabled it still sends the controller and mac information. You think, "hey i dont want to share this information, lets disable it ..." and it still send the info.

After much reading i dont think this is a realistic threat as noted. Dennis you always do a great job on the forums.

It just gets under my skin Cisco would allow a leak like this .... Whoever was working the OTAP code from revisions shold have been like.... hey i think we may want to change this or make it a bit more obscure ...

[kfarrington]

And they publish it also, I find that a little strange?

http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a008093d74a.shtml

[dennischolmes]

What you have to understand is that OTAP is a key function of the RRM process and is needed at some level to allow for auto rf to work properly. RX Neighbor information is crucial for the auto rf to work. The controller address is how the APs know which controller and by further examination, which mobility group the APs are in.

[Leo Laohoo]

We've got a chance to ask Cisco's view on this. Starting 14 September 2009 the topic Wireless Security will be "hosted" by Sangita Patel.

[kfarrington]

This will be cool. Thanks for letting us all know :)

[Leo Laohoo]

Hi Ken,

No worries, mate.

[George Stefanick]

See below (note)-- They will look to remove OTAP and encrypt the RRM packet in a patch release 6.x sometime soon.... I am dissapointed it will only be in the 6.x code. So many healthcare orgs are on 4.2

http://tools.cisco.com/security/center/viewAlert.x?alertId=18919

Cisco Lightweight Access Points contain a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition.

The vulnerability is due to insufficient security protections during wireless access point association sequences. An unauthenticated, remote attacker could exploit this vulnerability by injecting malicious packets into the wireless network where newly added access points are seeking controllers. This action could allow the attacker to cause the device to associate to a rogue controller, preventing the device from servicing network clients. An exploit could result in a DoS condition.

Cisco has confirmed this vulnerability; however, software updates are not yet available.

Note: Cisco aims to follow-up with a timely patch for 6.0.x, which removes the Over-the-Air Provisioning (OTAP) discovery method and encrypts the information in the Radio Resource Management (RRM) Neighbor Discovery Packet.

[Leo Laohoo]

Ok guys (and gals), I've just posted my comment regarding this issue. I hope to get some form of comment from Cisco about this.

I'm not at all happy about the result of George's analysis that the information is still being advertised in the open when OTAP is disabled. I've told the Paranoid Dep't (aka IT Security) that we're not affected because we're running the 6.X code and OTAP is disabled. Now I've got to take it all back.

[George Stefanick]

I am in the same boat. Sure.. OTAP when disabled other APs cant learn and get access to the controller. BUT, the controller info is still released in the open. This should be encrypted.

I just hope they pull the patch back to 4.2. I know for a fact some of the larger hospitals here in the US are on 4.2 code...

Our security team was all over this. They werent happy to learn the controller address is wide open by design or not and neither am I.

[Leo Laohoo]

OTAP when disabled other APs cant learn and get access to the controller. BUT, the controller info is still released in the open. This should be encrypted.

If OTAP is disabled, then NO WLC INFO should be advertised. It's akin to building a flyscreen that couldn't even stop a fly the size of a hub cap.

[Leo Laohoo]

Hmmm ... Some from Cisco must've forgotten to tell Sangita Patel that she's hosting the topic regarding Wireless Security.

Some of the questions in the topic doesn't even come close to security.

:P