Back in Black!

For those of you looking at my work status and saying, "What's up with that?" Let me enlighten you. 

In the past 6 months since I have left, radical change occurred at Aerohive. Two people whom I truly admire and respect, took over management of the "Product" that Aerohive produces:The worlds most advanced WLAN architecture. Alan Amrod and Abby Strong. Under this leadership, with the assistance of an incredible team and with many other changes in both personnel and strategy, they have encouraged an amazingly invigorated engineering team to squash more bugs, improve performance, add new features and  improve the overall usability of all aspects of Aerohive HiveManager and HiveOS. 

These improvements, so many in such a short time, visible to me on my very own Hivemanager, illustrated to me what an amazing team Aerohive has and what a terrific product they manage. Then Abby asked me to join and oversee  authentication and 3rd party developer support including APIs as the product owner. With so much positive energy and real progress in place, how could I say no?

Many who know me, understand that these are long held passions of mine and now I have the opportunity to finish the work I began under Bill Hoppin, several years ago. Accompanying me will be another former member of the Aerohive BD team who shares the same passions for APIs and easier to use and access authentication (I will let him explain in his own words if he is so inclined).

So you see, this move is logical and super positive. To those who may roll their eyes at this, just you wait and see what we can do! To my colleagues at Cloud4wi, I am still a hard core believer and supporter. To my Aerohive friends, Guess who is Back in Black?!!

A Look at PCI 2.0 and the New Wireless Guidelines

THE PAST
I have been predicting that the PCI Standards Council would be moving towards more stringent requirements for WLANs, specifically requirements for full time monitoring, scanning and protection. I also was waiting to see suggestions that “all-in-one” solutions that provides both connectivity and security fall short of the mark. I am happy to see these predictions coming true, especially in light of the PCI-DSS v2.0.

Near the end of last year the PCI Standards Councilpublished, Ten Common Myths of PCI DSS. The very first myth addressed is that, “One vendor and product will make us compliant”. The text reads, “Many vendors offer an array of software and services for PCI DSS compliance. No single vendor or product, however, fully addresses all 12 requirements of PCI DSS. When marketing focuses on one product’s capabilities to the exclusion of other PCI DSS requirements, the resulting perception of a “silver bullet” might lead some to believe that a point product provides “compliance,” when it really only addresses just one or a few elements of the standard.” It goes on to say, “The PCI Security Standards Council urges merchants, service providers and processors to avoid focusing on point products for data security and PCI DSS compliance. Instead of relying on a single product or vendor, you should implement a holistic security strategy that focuses on the “big picture” related to the intent of PCI DSS requirements. This approach includes people and processes, not just technology.”

A large number of merchants today are buying into the idea that a single vendor (Cisco, Aruba, Juniper etc.) can cover all your needs with regard to PCI compliance. This is a very alluring message to the CIO who is making budgetary decisions and would prefer to limit the cost and variables in implementing a compliance solution. However, aside from endangering an organization’s PCI compliance, if you ask any Information Security Engineer they will say the same mantra they have been saying for years, “Limit your exposure and risk through a best of breed - layered security model.” Or, in other words, use layers of products from different vendors and processes developed in house to best protect your organization

THE PRESENT
At the end of the summer this year, the PCI Standards Council released a new set of guidelines meant to clarify their positions in version 2.0 of PCI-DSS on the security of wireless networks, specifically 802.11 (Wi-Fi) networks and Bluetooth.

In section 1.1 of the guidelines it state the purpose that the of the document is to provide, “guidance and recommendations for deploying wireless networks including 802.11 Wi-Fi and 802.15 Bluetooth technologies, in accordance with the Payment Card Industry Data Security Standard (PCI DSS). The goal is to help organizations understand and interpret how PCI DSS applies to wireless environments, how to limit the PCI DSS scope as it pertains to wireless, and to provide practical methods and concepts for deployment of secure wireless in payment card transaction environments.”

A majority of the guidelines are normal common sense approaches to securing WLANs (such as ensuring the physical security of any wireless devices, changing default passwords and settings and securely configuring wireless devices, use strong authentication and encryption, use strong cryptography and security protocols etc.) however some new ideas were put forth which shows the increasingly urgent need for full time monitoring and the prevention of wireless intrusions.

Intrusion Detection and Prevention
Section 4.3 addresses WLAN monitoring systems, specifically WIDS and WIPS systems. It states in reference to section 11. 4 of the PCI-DSS 2.0, “Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises.” This is a very important addition. It means companies who were previously attempting to get by with quarterly scans are now being asked to implement full time wireless Intrusion detection and/or prevention solutions.

The next sentence gets even more specific, “Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date.” A quick check of the market today reveals that almost all infrastructure vendors have a very small list of signatures and vulnerabilities to look for and furthermore, they only release new security signatures/alarms when it coincides with a new major release of the entire WLAN system. Typically, this occurs about once every 12-24 months and requires the customer to upgrade all WLAN controllers, APs and all management platforms.  This, coupled with the fact that the newer code may contain bugs or anomalies tends to make IT managers cautious about implementing new code system wide.

WLAN WIDS/WIPS vendors tend to be a bit more agile releasing new vulnerability alarms and attack signatures every 6-12 months although in some cases you may get a patch release on the heels of a widespread and well publicized WLAN vulnerability with a few weeks, but again, the admin must upgrade the entire system (server, clients, sensors etc.) to get the benefit of these new alarms. AirMagnet however has implemented its Dynamic Threat Update (DTU) feature for its AirMagnet Enterprise solution in the first part of 2011, ensuring that all of its customers comply with section 4.3 of the new guidelines.

As an example of what a difference to an organization this makes, we can just look to the last highly publicized WLAN hack, the Cross Site Scripting vulnerability in ArubaOS and AirWave Administration Web Interfaces. This vulnerability which allows, “an attacker to plant an AP with maliciously crafted SSID in the general vicinity of the wireless LAN which would be able to trigger a XSS vulnerability in the reporting sections of the ArubaOS and AirWave Administration WebUIs” was posted on Wed, 6 Jul 2011. Within a few days AirMagnet had code written and was testing this attack in house with the ability to prevent access to the malicious AP. By the 25th of July 2011 every AirMagnet Enterprise 9.0 customer was protected from it.

Alerting to Misconfigurations
Lastly, Section 4.3.2 of the guideline, entitled, “Detection of unsafe activity or configurations” states that, “A wireless IDS/IPS can detect misconfigurations and unsafe activity by monitoring and analyzing wireless communications. Most can identify APs and clients that are not using the proper security controls. This includes detecting misconfigurations and the use of weak WLAN protocols, and is accomplished by identifying deviations from organization-specific policies for settings such as encryption, authentication, data rates, SSID names, and channels.” No single vendor solution monitors its own configuration. They are the configuration system, they believe you should just trust them when they say they are implementing you policy of using strong authentication. And in many cases where bugs appear how could they know that they are misconfigured in the first place? WLAN management systems (Controller, APs etc.) get bugs, all systems get bugs and at other times, people make mistakes. Only a WLAN Intrusion Detection/Prevention system, Like AirMagnet Enterprise, can do that. Just another reason for implementing a separate WIPS solution, one that looks specifically for items such as:

• AP Configuration Changed (Security)
• AP Using Default Configuration
• AP Configuration Changed (SSID)
• Device Unprotected by IEEE 802.11i/AES
• Device Unprotected by 802.1x
• Device Unprotected by EAP-* (the * stands in for PEAP, TLS, TTLS etc.)

THE FUTURE

While today, these rules are really just very strongly worded suggestions, I am willing to go out on a limb now and predict that, unless something dramatic changes the landscape in the next 6-12 months, the PCI Standards Council will insist on full time and independent monitoring and protection of the airspace around your facilities in the next version of the PCI-DSS. Fully integrated solutions will not work as they do a very poor job of responding to new threats and they are similarly poor at ensuring that they themselves are meeting policy and all independent wireless intrusion prevention systems will have to have dynamic threat systems, to ensure the timely delivery of new alarms for recent threats, vulnerabilities and hacks.

All documents referenced in this article may be found here at the PCI alliances website.

Sadder Still

My Hero

Sad

Turn down that NOISE!!!

Here is a fun experiment if you have a 2 laptops (or 1 laptop and some other WiFi enabled device), a WLAN analyzer like AirMagnet WiFi Analyzer (or something similar such as wireshark) and a microwave oven.

We all know that microwave ovens function in the 2.4Ghz range but how much "noise" is it generating.

Go to your kitchen. Get the device without an analyzer on it and start a really long file transfer via WiFi. Make sure your AP is already on either channel 11. Now Fire up your analyzer and measure the signal, noise and the signal to noise ratio (SnR is signal minus noise) on channel 11. Get an average reading and write it down. Do it several times so you are sure you have a good sample set. Now, restart your file transfer, put a pyrex (or other microwave safe) measuring cup full of water in your microwave and set it for a few minutes on high. Re-measure your signal, noise and SnR. What did you get? Try a few different WiFi adapters with the analyzer. any difference?

Here is what I saw when I did it with the AirMagnet WiFi Analyzer. First is the image of the channel screen on channel 11 with no microwave turned on. Notice the stats.

Signal:      -51dBm
Throughput:  ~34Mb/s
Utilization: 68%
Noise:       -88dBm
SnR:         37 (-51) - (-88) = 37


Here is the important part. Notice that the noise level is completely flat at -88dBm.

Now lets turn the microwave on and do it again, here is what I saw.

Signal:      -47dBm
Throughput:  ~16Mb/s
Utilization: 39%
Noise:       -88dBm
SnR:         41 (-47) - (-88) = 41

Notice anything? Well first off throughput went down and I checked the capture later and packet loss went up. Seems appropriate with a 1200watt device slamming my connection from 2 feet away. Secondly, the signal strength and the SnR INCREASED? Why is that? Well after looking deeper into the frames and looking at the AP configuration, it looks like 802.11N beamforming in action! The AP senses packet loss and pushes harder (no-tech speak for adjusts the phase shift of the signal to focus the waves on top of the client so it gets the benefit of wave addition). Next thing you notice is the increase in SnR from 37 to 41. This is due to two issues. The first we just mentioned. Increased signal strength. The second is the trouble spot. The noise level stayed the same.

What?!!

You heard right, the noise level did not change. I can hear you yelling at me through the intertubes from here. But I thought microwave oven caused noise? Well. they do and they do not. Here I am about to get pretty picky.

You see we at AirMagnet call noise one thing and interference another and WiFi interference a third. Confusing but true. And with good reason. You see, noise readings are fiction. They are falsehood, fabrication, fib. It is a lie. There. I said it. Noise readings (except from a very small number of cards - namely only one kind that I know of) are made up on the spot by each WiFi adapter. They cannot give you a noise reading, they can only give you bits (e.i. 1s and 0s) about things they see and WiFi adpaters only see WiFi modulation. Period. Almost all wifi adapters throw away all other non-WiFi signal long before it ever gets to the the driver. Non-wifi modulation, such as the modulation you get from cordless phone, wireless headsets, video camers etc are thrown away by the radio long before they can be converted to bits. The radios are only tuned for the type of modulation and coding they understand. So a normal 802.11a adapter will only ever pass OFDM modulation. Never QPSK, or FHSS or any other signal that is not OFDM. Thus how can the driver tell us about a microwave oven, or a cordless phone, wireless camera etc? They can't. So we call interference from other modulation types in the same frequency band by a different name, we call it non-802.11 interference.

Then there is WLAN interference, which Tom's Hardware calls "congestion", but could also be thought of as WLAN contention and is sometimes referred to as co-channel interference or even adjacent channel interference. Tom's has a very good article on it here. It is where too many WLAN devices are all trying to use the same medium simutaneously. In 802.11 terms, only one device can talk in an area at one time. Too many devices means collisions and contention in a collision avoidance network that wishes to remain contention free.

So that still leaves us with noise. What is going here? When I open a WLAN analyzer I see a noise reading. You showed me one right there (see images above). Where does that come from?

To understand what the adapter manufacturers are doing requires that we first understand what noise is. Noise can be thought of as the level at which all radio signal become indistinguishable from one another. Wikipedia describes the noise floor as, "the measure of the signal created from the sum of all the noise sources and unwanted signals within a measurement system." You can create an analogy of this as follows: Imagine five people in a room, each yelling in a different language. You could probably figure out what each language was even if you couldn't have a conversation in there, you might even be able to work out what they are talking about. That example would be considered interference to you if you were trying to yell in English. Now imagine a room with 500 people in it all talking at the same time. in that instance you proabaly could not tell what any of the languages were or what anyone was talking about at all. That is noise. Again, the Tom's Hardware article is a great reference for this, especially slide 9.

 Adapter manufacturers were asked many times for a noise reading so the person conducting the WLAN site survey could determine the signal to noise ratio, or SnR. This helps determine if there is enough signal to be heard above the RF noise floor. So under this presure they created algorythims that can fake the noise reading. I have no idea what the algorythims are but I can assume from tests we have done at AirMagnet that they include measurements of retry rates, CRC errors, channel utilization, average throughput and, mostimportantly, number of devices active in range (as determined by RSSI). The reason I can know this is because at AIrMagnet we have an RF isolation chamber - or Faraday Cage. If I take a noise reading in that chamber with one AP and no STAs (WLAN client adapters) I get a zero reading with many adapters. But if I add STAs the noise floor rises. even if the STAs are mostly dormant.

Here is another catch, aside from the fact that different manufactureres create this value differently, some adapters only give noise readings on a channel by channel basis, others frame by frame and still others give no reading at all. Symbol devices fit this last group and when asked about why they gave no noise reading they replied, "that would be lying". Does that mean that you cannot use that value to create the much sought after SnR? No, I would still use it, but I would be wary if tehre were very few STAs nearby. Or many for that matter.

I hope this helps understand what noise is, what interference is and what co-channel interference or WLAN contention is.

BlackHat 2011 and Defcon 19

The scene in Las Vegas last week on the wireless security front was quiet and reserved. There was a veritable dearth of WLAN issues to report on at either BlackHat or Defcon. Sure there was the Wi-Fi hacking UAV and Vivek Ramachandran's normal Wi-Fi security and hacking class, also the wireless water meter 900mhz hack and 1 or 2 new WEP attacks (like WEP needs any more attacks against it, isn't complete penetration in under 5 minutes fast enough?) but nothing really new and interesting. Most of the talks were about making your PSKs long and secure to shield you from, "Sniff now, Crack Later" (using Rainbow Tables found here and here) and talks reminding everyone to monitor their WPA2-EAP implementations against Honeypot Radius WPE (the WPE is not a typo, it stands for, "Wireless Pwnage Edition" and info may be found here and here). This last one is an old vulnerability but many people still have not been keeping an eye on it especially if your organization uses server certificates only in their EAP implementation.

So what does this absence of new WLAN vulnerabilities mean? Are the hackers bored with the ability to enter a company’s WLAN from 125 miles away? Do not bet on it. Has the IEEE, Wi-Fi alliance and FCC finally secured Wi-Fi so that no new vulnerabilities will be forthcoming? I sincerely doubt it. So what is the deal?

My opinion is that people are sitting on some of the latest vulnerabilities and making use of them. Wikipedia states that, “Zero-day attacks occur during the vulnerability window that exists in the time between when a vulnerability is first exploited and when software developers start to develop a counter to that threat.”  Meaning that a hacker can only execute the exploit before it becomes common knowledge. Once the vendor and security community find out about it, then everyone races to plug the hole. In the past, plugging the hole took several months for most major WIPS and WLAN vendors and then several more months before most customers implemented the new release (this was due to the fact that it required a system-wide upgrade). But the world is much more agile now and the ability to dynamically plug a security hole quickly just got a big boost when we at Fluke Networks released our AirMagnet Enterprise version 9.0. The version 9.0 solution has the ability to dynamically update the WLAN Intrusion Prevention System against threats as they become known. We  also broke out the alarm code and implemented a much easier, non-programmatic method for creating the signature and anomaly alarms that make up the system.  This means that from the time a zero-day is known to the time it is implemented can be as little as a day or two. This is a huge benefit for customers but a real drag for hackers. They will now have even more reason to hang on new vulnerabilities. It is also a clarion call to WLAN security researchers to step up their game and look for more fuzzed approaches to WLAN threats and try more anomaly-based alarms. I know our team is so ready here at Fluke Networks so bring it on!

Happy 802.11 day!

Today is 802.11 day, August 8th 2001 or 8/02/11. As a friend of mine noted in Google+, Hallmark probably does not make a card for that. In honor of this auspicious day I think now is a great time to reflect on this amazing technology that we use every day and almost take for granted.

This all started when, in 1985, the FCC decided to release several radio bands for unlicensed use. This meant that just about anyone could use these frequencies however they felt like provided they adhered to certain rules such as low power, spread spectrum, and ensuring that the devices were not intentionally jamming or eavesdropping. I refer to this in classes I teach as the FCC sandbox. Then, round about 1997 the IEEE decided to standardize the protocols and RF effects into the 802.11 standard and rapidly followed by the creation of the Wi-Fi alliance creating one the quickest adoption cycles in history. Suddenly our computers were free to communicate without wires. When I read about this I was stunned and had to try it myself. I remember demonstrating this amazing effect using a Lucent WaveLAN Silver card and the initial Apple Airport to several of my decidedly non-technical friends in 1999. They didn’t appear to get it. I was loading webpages on my PowerBook G3 and there was nary a wire in sight and these friends of mine were commenting that this was just another geeky gadgety gimmick of mine that had no practical application for people in the real world.

Later on in my career and while working at AirMagnet I recall presenting the benefits of WLAN technology (802.11g at the time) to a high level executive venture capitalist. I was mentioning how health care organizations, amongst other verticals, were adopting the technology a break neck speed. To this he replied that he hoped he would never have to stay at a hospital where this was true, for how could he trust his life to a technology that worked as badly as it did at his home.

This type of thinking is one of the sad realities of a bottom up adoption process. And the embracing of WLAN technology and 802.11 was decidedly that. Most companies started to implement WLAN technology not as a way to cut costs and deliver an amazing amount of increased mobility to their users but as a way to appease executives who were bringing in Linksys routers from home and plugging them in under their desks. Executives were stating, "well if I can set one of these up at home, how hard can it be?"

This disparity between the attitude of "how hard can it be?" and "I can’t trust your network because mine at home in unreliable" is huge. These arguments leave out a great deal. They ignore the value of WLAN professional planners, surveyors, architects, engineers and integrators. They dismiss the years of research and development companies like Cisco, Aruba, Motorola, Meru, Aerohive, Ruckus and others have invested. They discount the impact of hackers and all the other various security needs. Lastly, they oversimplify issues that, to them, appear trivial and unimportant. This oversimplification is a serious issue today as it lowers the value of the technology and the people that research, build and implement it. WLAN vendors are not helping in this area either by suggesting that prospective customers do not need to know anything about wireless. That the WLAN system will heal itself and defend itself without the customer having to worry about a thing. Since when have networks not needed any protocol expertise in the people who properly design and run them? Does your router fix itself when something goes wrong? This is an issue that we, as an industry need to get past before we can expect to see realistic views of WLAN technology and appreciation of our talent by lay people.

Wireless networks today are invaluable. Without them we would be lost. For example, WLANs are the absolute key to the supply chain. They are the enabling technology for just-in-time delivery and short term warehousing. Additionally. they promote collaboration in the Enterprise and reduce costs through the reduction in cable pulls and per port costs on networking equipment. WLANs allow hospitals to reliably move equipment in and out of operating theatres, patient rooms and clinics. They enable Voice over IP anywhere. WLAN technology is in every smart mobile device made today from Smartphones to refrigerators to automobiles. We’ve come a long way baby, but still have a long way to go.

With the recent release of the 802.11n standard we finally have a technology that supplies the range and speeds that enterprises can use and depend on. And this is just the beginning, 802.11ac, 802.11ad and 802.11ah are coming to go beyond the gigabit realm into mutigigabit speeds. But with these advances in speed and range comes complexity. When these technologies break who will be there to fix it? How will they do so? And who will supply them with the tools they need to get the job done? I think you know who I am thinking of…

RTS/CTS and you!

Imagine the following scenario:

It’s 2005 and you are at a convention.

There are hundreds of Wi-Fi devices around you. There are tens of APs. Not your run of the mill Linksys or Dlink APs but real enterprise grade, controller based APs. You fire up you trusty AirMagnet Wi-Fi Analyzer and what do you see? Specifically you see 10 APs and 700 STAs. A little math later and you realize that there are 70 Wireless Mobile devices (STAs) per AP.

“That’s Crazy!” you scream in your head. There isn’t enough capacity on this 802.11b/g network. You are correct. Then you start to imagine what is really happening and how many of the STAs cannot see one another because the network was implemented at MAX power and many STAs talking to the same AP cannot “hear” one another. Collisions go up, retries go up. Throughput crumbles and dies on the floor.

But help is on the way, the WLAN admin enables RTS/CTS in the controller and people start to behave nicely. Each STA sends and RTS and waits for the CTS from the AP before speaking. Collisions diminish. Retries diminish. Throughput gets up off the floor and makes a go at it again and you see some overall improvement. It’s still not pretty but it is better. “Great work WLAN admin!” you say to yourself.

What just happened? AirMagnet WI-Fi Analyzer says, To deal with contention, “the IEEE 802.11 standard includes the RTS/CTS (Request-To-Send/Clear-To-Send) functionality to control the station's access to the RF medium. The wireless device ready for transmission sends a RTS frame in order to acquire the right to the RF medium for a specific time duration. The receiver grants the request by sending a CTS frame of the same time duration. All wireless devices observing the CTS frame should yield the media to the transmitter for transmission without contention.”

This also eliminates a hidden node issue. Again, the AirMagnet Wi-Fi Analyzer says, “A hidden station problem occurs when a wireless node cannot “hear” one or more of the other nodes, and thus the media access protocol (CSMA/CA - Carrier Sense Multiple Access/Collision Avoidance) cannot function properly. When this happens, multiple nodes will attempt to transmit their data over the shared medium simultaneously, causing signal interference with one another. For example, imagine there are two 802.11 end-users (Station A and Station B) and one access point. Station A and Station B can't “hear” each other because of high attenuation (e.g. substantial range), but they can both communicate with the same access point. Because of this situation, Station A may begin sending a frame without noticing that Station B is currently transmitting (or vice versa). This will very likely cause a collision between Station A and Station B to occur at the access point. As a result, both Station A and Station B would need to re-transmit their respective packets, which results in higher overhead and lower throughput.”

Turning on the RTS/CTS then allows the hidden node to function without collisions.

Its 2011 and you are at work

Now fast forward to today. You are sitting in your cubicle and trying to understand what you see on the screen of your AirMagnet tool. It says, “Denial-of-Service Attack: CTS Flood”. Here is the detail text:

Description: In channel 6 2.437GHz, the system has detected 1800 CTS frames in the last minute, which matches the traffic pattern of the form of denial-of-service attack, CTS (Clear-To-Send) attack. A wireless denial-of-service attacker may suspend the wireless media for communication by taking advantage of the privilege of CTS frame to reserve RF medium for transmission. By transmitting back to back CTS frames, an attacker can force other wireless devices sharing the RF medium to hold back its transmission until the attacker stops transmitting the CTS frames.

“Why would someone be Dos’ing us?”, You inquire. “And why this particular attack?”, you wonder. “And why did he tell me all that other stuff about contention first?”, You ask.

The answer is interesting but requires another scenario. Imagine the following. There is a room with an 802.11b/g AP in it (It doesn’t matter if it is controller based or autonomous). There are 20 STAs attached to the AP and they are all 802.11g devices. That means that all the management traffic (beacons, probe requests, probe responses, etc) are 1Mb/s CCK modulated and all data traffic is faster (6-54Mb/s) OFDM modulated. Are you with me so far? Good. Here is the fun part.

An 802.11b STA walks into the room. He only speaks 1Mb/s-11Mb/s CCK modulated data traffic. So he starts jabbering while the “g” clients are talking and creates a bunch of collisions. Why? Because he cannot “hear” OFDM modulation. He has no idea that the “g” STAs are talking.

“That’s silly”, you say, “The IEEE would never allow that to happen”. Correct you are, Padawan. They re-used a function they already had, specifically to deal with this. And as you have probably already guessed what it is - RTS/CTS. RTS and CTS frames are 1Mb/s CCK modulated so it is as if the “g” STAs all asked for contention slots to send data and the “b” STA heard the CTS and went quiet until it was his/her turn.

But why the alarm? Well, what really happened was that awhile ago various card manufacturers as well as the IEEE noticed a problem and a loophole in the RTS/CTS scheme.

• The problem : most APs are usually not configured to do RTS/CTS. Also, STAs may not decide to use it.
• The loophole: The CTS frame does not have a source MAC.

No one really knows who sent the CTS frame. It could be anyone. Thus, “CTS Flooding” and “CTS-to-self” was born.

CTS Flood

Remember, The AirMagnet Wi-Fi Analyzer describes how hackers use CTS floods as follows, “A wireless denial-of-service attacker may take advantage of the privilege granted to the CTS frame to reserve the RF medium for transmission. By transmitting back-to-back CTS frames, an attacker can force other wireless devices sharing the RF medium to hold back their transmission until the attacker stops transmitting the CTS frames.” Because all STAs obey the CTS rule and also because CTS frames have no source MAC address, hackers love this attack. Please do follow the advice and go look for the hacker just to be sure but maybe something else is going on instead.

CTS-to-self

CTS-to-self is a protection mechanism (a method for protecting your frames from collision). A STA wants to talk so he does away with the RTS/CTS handshake altogether and just sends himself a CTS frame. No one wonders about the source of the frame and everyone allows that STA a time slot to send his/her data. However, in our example, this is completely unnecessary if protection is unneeded. If, for example, there is no one to protect the OFDM modulated traffic from.

Thus until the “b” STA walks in there are no CTS frames. The second he joins the AP everyone goes mad with CTS-to-self. In fact the “b” doesn’t even have to be on the same AP, just in range.

“Wait a gosh darn minute!” you yell, “That isn’t a DoS attack. That is a naturally occurring condition of the network. No hackers are bringing me down”. While this might be true, there may not be a hacker DoS’ing you, you are, never the less, definitely under a DoS attack. Especially if the 1800 CTS Frames/minute threshold is reached. This is because at 1800frames/minute you reach the 30fps value needed to cause a sever reduction in throughput. You are being denied access to the medium because you are waiting for your slot time to speak and it never arrives because everyone wants a slot time. You are being denied service. Now isn’t that the definition of a DoS attack?

How to (really) find a Rogue AP

I want to tackle a problem that most people think of having been solved a long time ago. Rogue Access Points (I can almost hear the groans). Seriously, it deserves another look. Why? Well, to be truthful, I think when trying to track down and physically remove the AP, most people do it wrong.

While almost every infrastructure vendor has a method for the determination and mitigation of an unauthorized access point, what they cannot do is physically remove the device from your premises. No WLAN WIPS robot has yet been created to go out to a facility and track down exactly where a rogue is and then pick it up and deposit it in a dumpster or ask the owner to please take it home or whatever it is your security policy says you should do when one of these is found.

Instead, we rely on both our infrastructure and a variety of laptop or handheld based software tools to assist us in this task and then we send a real flesh and blood person out to do this. This is where the major mistakes are usually made.

Every person I have met that has this task as one their responsibilities have told me the following, “I want to use a wifi adapter with a directional antenna to find the device. Just point it and it will tell me where to go.” This is wrong. Let me say that again, WRONG!

Let me explain why.

Let’s take one of the “flag” antennas that are fairly popular now (fig. 1).

Fig. 1

 Inside the plastic shell of this device is a Yagi-Uda antenna, commonly called a “yagi”. This is a fancy name for the type of antenna that televisions used to use before cable and satellite. Here is an example of what a yagi looks like without a shell (Fig. 2).

 

Fig. 2

Antennas professionals use a pattern diagram to describe the sensitivity pattern for the antenna. The diagram shows a pattern view from above and from the side (Fig. 3).

Fig. 3

The left view is looking down on the antenna from above known as the azimuth view and the right view is from the side and is known as the elevation view. This illustrates the amount of gain this antenna gets in any particular direction.  The problem here is when you start to use a high gain (in this case 8dBi) antenna indoors you get some strange effects due to the lobes described by the diagram above.

Here is an example. You are determined to remove a Rogue AP physically from your building. You stand in the building and aim your antenna. As you sweep left and right you watch the signal strength of your rogue finding tool. In this case we will use the find tool in the AirMagnet Wi-Fi Analyzer (Fig. 4).

Fig. 4

You monitor the signal strength and figure that when you are aiming right at the AP it will be the strongest. The graph will be at a peak and the meter will show the highest signal strength. However the signal is herky-jerky and very difficult to know when you are aiming right at the Rogue. Sometimes it is high when you are way over to the right and sometimes it is just as high when you are pointing to the left. Why is that? Shouldn’t it just be obvious when you have the device in your sights? No. Let me show you why.

As you aim your directional antenna the gain field of the antenna sweeps out ahead of you and you get a high reading as expected when pointing right at it (Fig. 5).

Fig. 5

Then as you sweep away to the right the signal drops when you hit the gap between the primary and secondary lobe (Fig. 6).

Fig. 6

Then the signal jumps up again as you enter the second lobe (Fig. 7).

Fig. 7

Also it may jump again as the signal bounces off of the walls and reflect back towards you (Fig. 8) since when you aim directly at the Rogue AP the signal is attenuated by the internal walls but the signal reflected back to you is clear.

Fig. 8

You see the directional antenna with a very high gain can be fooled. A user may spend 20 minutes trying to track down this device sweeping left and right trying to find the correct direction.

There is a better way. I will show you how to find a Rogue AP in just a minute or two and as a bonus you get some great exercise as well.

The key here, counter-intuitively, is to use an omnidirectional antenna and walk very fast. The technique is quick and accurate. You will find the rogue in less than a minute, whereas with the previous method it may take many minutes or more.

The first step is to stand at the edge of the building and walk perpendicular to the wall. It is very important that you walk fast as the graph you will be watching will be jiggling around and you will need to be able to observe a distinct change to the graph which will be easier the faster you walk. Keep your eye on that graph and when it peaks and starts to decline, stop and back up to the area where it peaked (Fig. 9).

Fig. 9

Now turn 90° to either the right or left and start walking that direction quickly as well. If your signal immediately declines, reverse your course and walk the other direction (Fig. 10).

Fig. 10

Once again, when the signal peaks and starts to decline, turn 90° and walk quickly. In this way, you will box in on your objective and be able to walk right up to it and remove it (Fig. 11).

Fig. 11

I think once you have tried this method you will be extremely pleased with the result. If you have tried to use a directional antenna to find a Rogue AP in the past, you will know that you can spend quite a great deal of time aiming your antenna before you even try to move towards the device. Then when do start to move around the results are hard to determine and you tend to move slowly and carefully. This method that I have described is fast and efficient and enables you to quickly find your problem Rogue AP.

Our AirMagnet class instructor has taught over 5000 students how to use this method and it really is more efficient.  Try it out and let me know what you think.