cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1901
Views
30
Helpful
27
Replies

RRM and OTAP frames - Vunerability or not?

kfarrington
Level 3
Level 3

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

27 Replies 27

ericgarnel
Level 7
Level 7

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:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00806c9e51.shtml

"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

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

It says:-

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

Radio ID

Group ID

Management IP Address (of the Controller)

Channel Count

Antenna Pattern (Omni, Left, Diversity, Right)

Measurement Interval

Key

Channels

Power

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?

Many thx,

Ken

Hi all,

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,

Ken

The Radios send the info to the controller.

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080901caa.shtml

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

http://www.airespace.com/products/lwapp.txt

Also,

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."

Hi folks.

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: geemayil@gmail.com

Cheers,

Justin

Hi guys,

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

Thx

Ken

dennischolmes
Level 7
Level 7

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.

http://www.theregister.co.uk/2009/08/25/wireless_skyjacking_vuln/

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?

Strange?

Thx

Ken

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 ....

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

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!

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

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 ...

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

Hi Guys,

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

Ken

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: