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 :)