Just another site

Archive for July 2010

Sniffing on a Mac (updated)

with 3 comments

One of my first posts for this blog was a discussion of how Mac OS X users might perform WiFi sniffing. Enterprise-class sniffers only run on Windows, so my earlier post is about using a combination of KisMAC and Wireshark. This brief post is about using WildPackets OmniPeek.

Keith Parsons, the WiFi expert who runs, informed me after my post that I should try running professional grade analyzers using a virtual machine like Parallels or VMWare Fusion. Well, here we are a mere 6 months later and I’ve finally taken the time to do it. And it works. And it is superb.

My basic setup includes the following:

  • MacBook Pro running Mac OS X 10.6.4 (Snow Leopard) with a 2.4 GHz processor and 4 GB of RAM
  • Windows XP Service Pack 3
  • Parallels Desktop 5
  • WildPackets OmniPeek Enterprise 6
  • Linksys WUSB600N 802.11n dual-band USB adapter
OmniPeek starts up and runs fine under this setup, though I did wonder if running in a virtual machine would compromise performance. I have yet to get a good answer for that. On the one hand I am seeing almost 20% CRC errors, which would indicate poor sniffer performance. On the other hand the wireless router in this office is inside a closet that has a large metal door (don’t ask), which would explain poor sniffer performance.¬†
I’ll do more work in the near future with OmniPeek (and, God willing, AirMagnet WiFi Analyzer) using Parallels Desktop. In the meantime, it’s just good to know that I no longer have to boot back and forth whenever I run a professional grade WiFi sniffer.

Written by sniffwifi

July 26, 2010 at 11:28 pm

Posted in Uncategorized

Debunking A Vulnerability Myth (Not That One…)

with 8 comments

The Wi-Fi world was set aflutter today by a wireless IDS/IPS vendor sending out a press release advertising a flaw in WPA2 security that will be detailed during a pair of security conferences at the end of the month. (They’re also holding a Webinar early next month that will detail the same flaw.) Much of the commentary on this WPA2 vulnerability has been focused on discrediting its real-world impact, but I am going to abstain from my initial temptation to join those critics. Instead, I’ll take this time to discredit a supposed flaw in TKIP that was touted a couple of years ago, but for some reason never analyzed thoroughly.

The TKIP flaw has been nicknamed Beck/Tews after the researchers that discovered it. Their whitepaper and an excellent analysis of the technical theory behind the flaw by Glenn Fleishman of the superb blog are both available online.

A quick summary of the flaw goes something like this:

TKIP relies on a sequence counter called the TSC (TKIP sequence counter) to prevent packet re-injection. If packets are received with a TSC value at or below the TSC value of the previous packet, then they are dropped. This sequence counter prevents ChopChop-style attacks from being successful at recovering TKIP keys in a similar way to how ChopChop recovers WEP keys. (WEP does not have a sequence counter.)

Beck and Tews noticed that when 802.11e QoS (also known as WMM, or Wi-Fi Multimedia) is used, packets can theoretically be re-injected because APs may allow up to 16 separate sequence counters, one for each Traffic ID. The idea is that if a savvy attacker kept changing Traffic IDs, he could circumvent the TSC by never re-injecting a packet using a Traffic ID that is at a lower sequence counter value than the previous packet. Beck and Tews detailed a “practical” (ironic use of that word, to be sure) analysis of this theoretical attack online, though they accidentally stated that there are 8 separate Traffic IDs rather than 16 (a fact that is irrelevant to whether the attack works).

The problem with Beck and Tews is that it appears that these gentlemen have never actually looked at a packet capture. If they would have, they’d know that APs never actually use 16 sequence counters. Or 8. Or even 4. In fact, APs never use more than one TSC. I know this because I have actually done practical WiFi sniffing.

Take a look at this Beacon frame* that I captured using (gasp) Wireshark with KisMAC and a DWL-G122 USB adapter while running Mac OS X 10.6.4:

Take a look right above the line I highlighted. That line shows the PTKSA (pariwise transient key) Replay Counters field of the RSN (robust security network) information element in a Beacon frame from an AP using WPA2 and QoS. Check out the value there: 0. And check out table 7-35 on page 128 of the IEEE 802.11-2007 standard:

When the PTKSA Replay Counters value is 0 — which it always is in every Beacon from every AP I’ve ever seen — there is only one TSC value. One TSC value means that there is only one sequence of numbers in packets. One sequence of numbers means that any packet re-injection will result in re-injected packets being dropped. Re-injected packets being dropped means that the Beck/Tews vulnerability in TKIP simply does not exist.

Look, I realize that I have not seen Beacons from every AP that has ever existed. And I realize that security researchers sometimes make mistakes. But can we at least have some scrutiny of something that could be this big? TKIP is used on countless WiFi networks. Is nobody out there sniffing WiFi packets to make sure that theoretical vulnerabilities are practical vulnerabilities?

There have been an awful lot of papers and articles written that have taken the flawed Beck/Tews research as gospel. That’s what happens when someone uncovers a new attack that is theoretically sound. My hope is that when this WPA2 flaw is revealed later this month, people will consider whether the theoretical insightfulness is matched with practical applicability.

*I couldn’t fit the QoS-based information element from the Beacon into my screenshot, but that AP is using QoS. It also is using AES encryption rather than TKIP, but the choice of encryption type has no bearing on the PTKSA Replay Counters value.

Written by sniffwifi

July 23, 2010 at 1:03 am

Posted in Uncategorized

Channelyzer Pro… This Could Be Big

with one comment

Metageek has announced that WiSpy USB spectrum analyzers can now be used with Channelyzer Pro. This could make things interesting…

Readers of this blog may know me as an anti-open source kind of guy, but I try to be fair. I’ve talked about popular products like AirPcap NX, Wireshark, WiSpy and Channelyzer and I’ve always tried to give a fair appraisal of their usefulness for enterprise-class wireless environments. The problem is that I usually just don’t find them to be that useful.

Of these products the one that has always been closest to enterprise-class is WiSpy DBx. It competes with the hardware for Fluke Networks’ AirMagnet Spectrum XT and the Cisco Spectrum Expert at a much lower cost ($600), and in many ways it measures up. It can be used in the both the 2.4 GHz and 5 GHz frequency bands, it uses the USB form factor (which beats the PC card form factor for Cisco Spectrum Expert) and it comes with free software in Channelyzer. The big problem was that using the WiSpy/Channelyzer pair meant that you’d have to forgo device classification. Device classification is great because it tells the user exactly what device is causing interference. It makes resolving the problem by finding the device or changing a setting much easier.

Channelyzer Pro is a new product from Metageek (the company that created  both WiSpy and Channelyzer) that was just announced today. It does cost $499 (thus bringing the comparable cost vs. AirMagnet and Cisco to about $1,100), but it adds device classification. Now, I know that a lot of WiSpy users really value the fact that the accompanying software costs nothing, but to me this sounds like superb value. Professional-grade spectrum analysis may be possible for just over a grand. That really is amazing.

Now, I don’t want to get too excited because I have yet to test the product. I’ve emailed my guy from Metageek and I should get a copy soon, so check back next week and by then I’ll have a review up.

Written by sniffwifi

July 21, 2010 at 4:56 pm

Posted in Uncategorized