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.

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!

WLAN IDS and the bizarre world of security exploits

If you make security software (or any software, for that matter) sooner or later you will create what I technically refer to as a booboo. A security vulnerability in your software that raises the ire of your customers and make you feel foolish and sad. Not to worry, mateys, this happens to all software manufacturers. The important thing to remember here is how you handle it. Are you going to be a Pro or a shmuck? Recently, AirDefense (why no dot com?), a WLAN IDS manufacturer had just such and incident. Is this uncommon? Relatively so. Is it dire? Not really. Are you just sniping at your competitor? Kind of, but in the interest of disclosure, we had an incident a long time ago as well so, dear friends, I feel their pain.

Let's talk about what happened first. The vulnerability as explained here happens when you send a specially crafted HTTPS request, which will cause the HTTPS service on the system to crash. It appears from my quick glance as if you need to authenticate first and also be on the segment from which you can administer the system. So what is this? Granted it can bring down the sensor but actually it appears to be a "tempest in a teacup". You need to be the admin or snarf the admin login in order to cause a denial of service to one of probably many tens or hundereds of sensors. Unlikely at best.

So how was this handled? Professionally, in my humble opinion. AirDefense contacted the people who reported the exploit and directed them to a patch for it as reported here, "Solution: Update to the latest firmware version"

AirMagnet had a similar experience Last October. And we handled it the same way. Here is our official response to the problem from back then:


Re: Airmagnet management interfaces multiple vulnerabilities
AirMagnet vendor response below -

(1) The vulnerabilities are tested against an over-a-year old AirMagnet Enterprise product,
(2) Some of these vulnerabilities have been patched and fixed in AirMagnet Enterprise version 7.0.x,
(3) All vulnerabilities are now completely fixed by AirMagnet Enterprise version 7.5 build 6307 and later.
(4) AirMagnet customers can download patches from MyAirMagnet support web site (http://www.airmagnet.com/my_airmagnet/index.php)

So to summarize, there are a lot of security professionals out there who are trying to make a name for themselves and do it in an industry, like the WLAN industry, that is going places. They spend all their time looking for these exploits and I, for one, am glad they do. They keep us honest and ensure that we are doing our very best to protect our customers. Are their motives pure? Debatable but mostly. Do they sit down afterwards and talk amongst themselves about what l@m3rz those software guys are? You bet! Should I take it personally? Nah.

The Myth of the Self-Monitoring WLAN

Recently, as you all probably know by now, Duke University had a WLAN meltdown. The CIO, Tracy Futhey (Comment here) and the assistant IT director, Kevin Miller (Comment here) have put to rest the notion that the Apple iPhone caused it. Cisco has issued an advisory to the effect and Apple assisted in the effort.

I am not going to go into the details of what happened or why. Suffice it to say that mobile handhelds of all types, not just iPhones, send a lot of ARP traffic and the Cisco infrastructure was not ready for it. The quote at Network World explains that, "The advisory finally makes it clear that the iPhone simply triggered the ARP storms that were made possible by the controller vulnerabilities. Any other wireless client device, moving from one subnet to another apparently could have done the same thing."

What I will point out, however, is the problem we in the Wi-Fi community have today with the following simple delusion, "Your WLAN infrastructure as a cohesive, integrated, single-vendor solution is all anybody needs. It is self monitoring and self healing." I talk to a lot of people about which WLAN solution they are going to purchase and implement and I am always surprised by how many believe that the AP and controller vendor has all the answers. Don't get me wrong, I am a huge fan of this type of solution. Central management is critical for even medium sized organizations of 50 or more APs, much less larger ones that may a few hundred or even thousands. Manually changing the configuration of each AP is not a viable solution in these cases. The Admin needs assistance. And the story sounds so great, "Implement our solution and it will fix itself when it breaks and protect itself when security policies are breached." Who wouldn't want that?

But the truth is a little more complicated. As we have seen from previous posts, sometimes the solution doesn't behave the way your business practices need. Similarly, sometimes there are security problems within the infrastructure itself. So what to do?

This will sound like an advertisement for the company I work for and I apologize ahead of time but there is a very good reason I continue to work there. Mainly, I believe in the message.

When the Duke network went down and the Assistant IT director looked at his WLAN infrastructure dashboard, what did he see? I have not spoken with him directly but my guess would be it said, "hey man, it ain't me. Everything looks good from my end" So what did he do? he pulled out a sniffer and got to work. With packet traces in hand and assistance from Cisco and Apple he solved the problem. Did the infrastructure fix itself? Did it correctly identify the problem and solution? No. A patch is now needed to keep this from happening again.

One should not blame the infrastructure for not getting this right at the outset nor should one blame Mr. Miller. He was correctly reading what the controllers were telling him. But it shows how important it is to have a separate, 3rd party solution also available to get down to the bits and bytes or even spectrum analysis (if the problem should be something other than 802.11 protocol madness.)

There are a few great WLAN security vendors out there and they make 3rd party, best of breed solutions for monitoring the security of your WLAN (one of which recently got snatched up pennies on the dollar and will probably be rolled into another integrated, self-healing, self-monitoring role; against my better judgment.) There are an even smaller number who both monitor your security and your connectivity and performance and give you great troubleshooting tools built-in (insert shameless plug here). These should be your trusted advisor's when things go wrong. I am in no way suggesting that they would have identified the problem and cause and given a solution at Duke either (although I think they at least would have shown alerts for denial of service and strange traffic behavior.) What I am suggesting is that with them in place you now have a set of tools to assist in solving the problem. Remote packet and/or spectrum analysis. Alarm thresholds that can be set by the admin and will continue surveillance. Reports. System-to-system notifications. Graphs of speed and traffic type. Lists of who is connected to what and how. All the things you would need to get to the bottom of any problem in that invisible Luminiferous Ether.

Meraki AirMagnet Stats

Some folks have requested more technical details on the Meraki nodes so I am uploading some AirMagnet Laptop Analyzer images for your perusal. Let me know what you think.

(Click an image to enlarge it)

Here, for example is the AirMagnet Start screen showing the 3 nodes I have up

And here we have the Infrastructure page showing how they are viewed.

But the details that most folks have been asking for is here on the Channel Page (notice the bytes and frames. Very good data speeds for the most part. Since the beacon interval is set to 500ms I have the channel scan time set to 750ms)...

...and here on the main portion of the Infrastructure page. I also had the Spectrum Analyzer integration enabled. For this image I selected the main "root" node to analyze.

I was in the papers a few times also...

So maybe I am in a, "toot your own horn" kinda mood. (I must not get enough love at work) but I thought I would catalog some props from my past.

I have been printed in a variety of articles in the mainstream press, most of which I am very proud of. For example, I just happened to be a a h@x0r convention in Washington DC called ShmooCon on behalf of AirMagnet when Simple Nomad relased a [kinda] zero day for wifi. I was just hangin out afterwards when a reporter from the Washington Post grabbed a seat at my lonely table to discuss it. Brian Krebs is very well respected and I was happy to talk to him so we chatted about how lame it was that Microsoft kept having stuff blow up on them and this one was such a silly thing. It really blew us away. He asked for a real interview to learn how this had been effecting some of my customers - which it had - and then we went a had a few beers.

You see I was getting calls from a bunch of my customers saying that they were seeing bizarre SSIDs showing up on the Dashboard of our IDS, AirMagnet Enterprise. And to top it all off, they were all in Ad-Hoc, or peer-to-peer mode. SSIDs with names like, linksys, tmobile, hpsetup and wayport-access. My customers were blaming our software, saying we were, "sending false positives". Well, it turns out it was Microsoft's fault the whole time. Go Figure.

Brian is a great guy so I will probably grab a few beers with him this year when I go out in March, but it just goes to show you that 80% of success is just showing up (thanks Woody Allen).

Here are some other links to press on me:

Here is the Washington Post piece. And almost exactly a year later, here is Microsoft's resolution to the vulnerability.

I conducted a walk around with the New York Times (didn't get a mention but my neighborhood did).

And here are a bunch from DefCon 13 where I found a bunch of radio interference:


Wireless Week


The IEEE


EE Times


Information Week

There is also some stuff from waaaaayyyyy back with computer world and a ton of ISSA, ISACA and other speaking engagements. too old to worry about.

Hey, I was on TV!

So a long time ago, I was asked by my V.P. of Marketing at the time, Rich Mironov (One of the best Marketing guys I know, BTW), to assist our PR firm with a show they were putting together. Tactical to Practical on the History Channel. It is a show where in the first half hour they show the military doing something really cool and then, for the second half hour they show you how you, The average American, can do something similar with stuff you can pick up from Frys.


It was a fun shoot. I brought along a friend of mine, Jon Erikson, who wrote a fabulous book called the Art of Exploitation. One of the most well received books on security exploits I know of. He and I were to conduct an actual hack over wireless at a hotspot in downtown San Jose for the cameras.


Jon had a few prepared 'splots he wanted to run. One was a MitM attack with stream injection. I would search for, oh, lets say, "shrimp" at Google and he would substitute, say, "giant" for "shrimp" so all the returns from Google were about really big things. Kinda funny but a hard concept to convey in 15 minutes to a TV audience.


The other idea was pretty simple (read:LAME), I would log into my mail account and he would snarf my password and go read my mail. It came off OK and they kept it as the final for the show. It was fun to do and we got a ton of inquiries. I actually get about 15 minutes of airtime. So there is my Andy Warhol quote for the day. Here is the link: Bruce_on_TV