Please refer to the this thread but thought it may be an idea to start a new one.
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.
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?
The traffic MAY be encrypted as the APs have a factory cert installed. It has been a while and I cannot find any info to support the above statement, but I believe it is encrypted.
On the other hand, OTAP should be turned off in an established production environment per:
"You should have OTAP enabled only during AP provisioning intervals. After APs are deployed, disable OTAP as a deployment best practice. Also, Cisco Aironet LAPs (1130 AG, 1200, and 1240 AG series) ship from the factory with a stripped-down version of lightweight Cisco IOSÂ® Software that is called the LWAPP Recovery Cisco IOS image. OTAP is not supported on those APs out-of-the-box that run LWAPP Cisco IOS Software. When you upgrade Cisco Aironet APs from autonomous Cisco IOS Software to lightweight mode, the LWAPP Recovery Cisco IOS image is the software that is loaded. The LWAPP Recovery Cisco IOS image does not support OTAP. In order to support OTAP, Aironet LAPs must first join a WLC in order to download a full LWAPP Cisco IOS image."
The thing is, int the URL
Radio Resource Management (RRM) Neighbor Packets
OTAP utilizes RRM neighbor packets. This section provides a brief background on RRM neighbor packets. LAPs already joined to a controller transmit RRM neighbor packets to the RRM multicast address 01:0b:85:00:00:00. Each LAP must transmit a Neighbor Discovery packet once every 60 seconds on each of the configured Auto-RF channels for 802.11b/g and 802.11a. The RRM neighbor packets are transmitted without any encryption similar to other RF management packets, such as probe requests and probe responses. The RRM neighbor packets contain neighbor control messages. Each neighbor control message consists of (see RRM Neighbor Packet for 802.11a later in this document):
Management IP Address (of the Controller)
Antenna Pattern (Omni, Left, Diversity, Right)
So one would assume that even with OTAP disabled on the controller, this information still goes out to neighboring APs for the RRM feature?
Would that be correct?
I see that cisco controllers support MFP, but this would only be useful with clients with ccx v5 correct?
How are Cisco doing with ccx v5 as on the ccx homepage, it still does not say much about v5, but reference to ccx v5 is in the mobility guide?
Many thx indeed,
The Radios send the info to the controller.
Shows that the rrm uses lwapp, so the traffic will at least be encapsulated, although, I think the latest version of wireshark can sniff lwapp....
and some really dry reading
Right below your snippet from the same url
"The LAPs encapsulate and forward to the controller any RRM neighbor packets they receive. This allows the controller to form RF groups for adjusting the power and channels among LAPs that can see each other. LAPs that are booting can use these RRM neighbor packets to discover the controller that neighbor LAPs are already joined to."
A late response, but this one just recently caught my interest...
Yes, the RRM neighbour messages do contain the IP of the AP's parent WLC and also the MAC address of their RF Group Leader (possibly different from the AP's WLC). The rest of the info doesn't seem like it could be of much use to an attacker, just mundane RF info IMHO.
The WLC IP could be pretty useful in the hands of a less-than-ethical person because it's like giving a burglar a little window next to your front door, through which he can see the inside door lock mechanism or possibly reach the inside door lock through breaking the glass. By this I mean that the WLC IP isn't of much use from the outside, if the wireless LAN is secured from the wireless side (outside). However, sometimes lazy admins forget to secure their networks on the inside. So an evil person could conceivably gather intel about the controllers' inside addresses, find some once-off brief opportunity to get access to the inside network (posing as a visitor for example), see if the WLCs have been left poorly-secured from the inside network and if so he could quickly open up a wireless hole for future unlimited access from the outside world.
Having the controller's IPs could also be a nice aid to deducing the IP structure of the target network... useful for guessing a workable IP for his "visit" and also for figuring out where the juicy parts of the network lie (usually the WLCs are on a network infrastructure or even server IP range).
Other interesting tidbits are that the MIC of the RRM packets is a 16-byte checksum, so it's probably MD5. It also doesn't seem to include any timestamp as a factor (in contrast to what the Cisco docs say) - the MIC field remains constant for all RRM messages for a given AP until any of the RRM values change. Some person who's bored could probably figure out which fields are used as input to the MIC and how it's derived (unless there is actually some data on the controller which is used as input, and which does not appear in the packet data itself).
An insignificant oddity that I also noticed is that for 802.11a the RRM messages are sent out and an interval which is 10% short of what's defined on the controller. For b/g the timing exactly matches what's set.
I've done a feeble analysis of the RRM packet structure and identified most of the fields, but the file upload feature on this form doesn't seem to work too well. I have lots of captures (lab and field) - if anyone else wants to have a look at them just drop me a mail: firstname.lastname@example.org
Just been away for a couple of weeks.
Excellent info here. Will just catch up and get back with some more info I have on this :)
It appears this subject matter of these posts has made its way into the public eye. We need to begin a discussion on how to handle this with clients and customers. I don't really see this as a severe threat as you should have your external side of the WLAN protected by WP2-AES and your inside protected with strong password protection. Cisco will surely develope a plan of attack on encrypting OTAP and RRM packets.
Yeah, Ive seen this.
I find it a little hard to understand as I did over a year ago, why you cannot encrypt this portion of the data in the packet?
I was biting my lip ... but i have to mention ... 5 weeks ago Jerome Henry did a great video on OTAP... He even talks about the security hole ...
2 weeks ago out of left field AirMagnet takes credit for the OTAP find...
I smell fish ....
Yep. I sent the link to this post to some BU guys as soon as Fluke (lets not call them airmagnet, because theyre not)loosed the "discovery" of the hole.
Im about to post a video that will blow the lid off this ... OTAP is still send the controller information in the clear with OTAP DISABLED...!!
check out www.my80211.com in about 1 hour!
We've already established that. That's not the real problem. Go out and watch the skyjack video. It's not really an issue if you put a primary, secondary, and tertiary controller and limit the 12222 and 12223 port traffic at the firewall. Problem is when you dont do this you have issues with hreap APs becoming rouges. Still not a very practical hack. Costs the average hacker much more money than it would be worth.
LOL i just spent 2 hours ... LOL
Where is the video at ? you have a link? i didnt see it posted anywhere about it being disabled and still sending the packet ...
Great posts. Can I just ask, does this all relate to the post last year. the fact that RRM packets contain the IP address of the WLC, or is it, now there is a hack to exploit this?
Sorry, been offline a while :)
Kind regards, and thanks for all the help as always :)
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.
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 ...
And they publish it also, I find that a little strange?
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.
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.
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
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.
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.
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.
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.
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.