The short answer is that this attack is not realistically repeatable on an Aruba network and you do not need to worry about it. Read on for details.
The purpose of this paper, as pointed out in the abstract, was to investigate new attack vector, wireless APs, and how that attack would propagate through an environment. The Chameleon attack replaces the firmware on an existing AP and masquerades as the AP while infecting neighbors and stealing client data. If I were naming the attack, I would have called it the body snatcher attack, because that is what is really happening. The physical AP is being taken over by new firmware. It is worth noting that this attack only works on open, or easily compromised WEP networks. A properly secured WPA2 network would not be vulnerable to this attack in anyway. The encryption and certificates would prevent client devices from associating or allowing non-authorized devices into the network.
Performing the attack can be quite difficult. Remember that all of these steps need to be performed wirelessly by the attacking AP. Step 2 is bypass any encryption security on the AP, the authors admit they can only bypass open and WEP encrypted networks. A secure network isn’t vulnerable. The step 3 is to bypass the administrative interface on the AP which is quite difficult for an Aruba AP considering it does not have an administrative interface on the AP. There is no way for their attack to get past this step. Step 4 requires identifying and storing all of the AP system settings so that they can successfully mimic the AP which is very difficult in enterprise hardware. They would need to hack the controller and the virtual controller. Step 5 is to replace the AP firmware with virus loaded firmware. This is incredibly difficult. This would completely break all communication between the AP and the controller or virtual controller which would result in instant detection. Additionally, properly configured WPA2 clients would never associate with the AP since they would not receive the correct server certificate. If the AP being down didn’t alert IT to a problem, the flood of helpdesk tickets from clients unable to access the network would.
If the attack were able to somehow complete, the paper suggests that it would be impossible to detect. During the introduction of the paper, it is mentioned ‘if the legitimate AP is not turned on or not broadcasting, then there is no normal traffic to compare’ for rogue detection. This may be true for some home or small office networks, but it is not true for any Aruba network. The first issue, is that the controller or virtual controller knows about all of the APs that are supposed to be up and serving clients. If they are not up, it will be noticed and reported by the controller or AirWave. If the radios are not up, it will be notice and can be reported by the controller and AirWave. This is only an issue if you are using an overlay WIDS or laptop based WIDS solution like Kismet which was used by the authors. The overlay is not a part of the network and doesn’t have visibility into what is happening. It just knows about the MAC addresses/BSSIDs of the valid APs and their signal strengths. In that case, the overlay can have a very difficult time proving the authenticity of the AP.
The article did do some interesting research in the idea of APs wirelessly spreading a virus. Wireless has become ubiquitous. In cities it is difficult to find a location without a wifi signal. If you could somehow get around all the issues involved with remotely infecting APs, then it would be a very effective way at creating an airborne virus. But the chameleon virus has no way to infect an Aruba network which would break the propagation model built in the article.