The time has come. Today, one of NCI's own will head to San Jose to attend the Wi-Fi Mobility Symposium and then be a delegate at Wireless Field Day 2!

This promises to be an amazing event and we are thrilled to have one of our own attending. Just look at the schedule:

Wednesday, January 25 - Wi-Fi Mobility Symposium

This event will cover important topics such as: Mobile Devices & BYOD, Gigabit Wi-Fi, and Hotspot 2.0.

Thursday, January 26 to Friday, January 27 - Wireless Field Day 2

Two days of in-depth, technical presentations and discussions with many of the wireless industries most exciting vendors (in order of presentations): Aerohive, MetaGeek, Ekahua, Meraki, Aruba Networks, HP, and Ruckus Wireless.

This even will also be streamed live (see display below):

NCI looks forward to sharing all that we learn from this event with our current and future clients. Wireless networking is set to really explode in 2012 and we are proud to be right in the middle of it!

The NCI Blogging Robot

On January 1^st we posted a little bit of information regarding the Wi-Fi Protected Setup (WPS) brute force vulnerability. As a follow-up, I have performed a bit more research and analysis on the vulnerability and the attack tools. Here is a list of resources you might want to check out for more information: 

No Strings Attached Podcast 

I was privileged enough to participate in the @NSAShow’s episode 2 podcast: Wi-Fi Protected Setup, Battered or Broken? I highly recommend giving the podcast a listen as it contains a lot of good information. I’d also like to thank the host @revolutionwifi and the other guest @matthewsgast for a fun and insightful 45 minutes. 

Simply Wi-Fi 

We’ve already shared my video demonstration of how a WPS brute force attack works. Since then, I’ve created another video, seen below, demonstrating the use of a tool that identifies vulnerable wireless routers. I’ve also taken some frame captures of an attack and provided an explanation of the frames at different stages of the attack. Sample frames have also been made available for anyone who wants to take a closer look in Wireshark.

United States Computer Response Team (US-Cert) 

Here is the original vulnerability note created on December 27, 2011. It details the basic purpose of WPS and describes the vulnerability. 

Dan C.

If you are aware of any additional resources, please share them in the comments section below.

Recently, a white paper was written by Stefan Viehböck which documented a few implentation weaknesses in the Wi-Fi Alliance's Wi-Fi Protected Setup (WPS). Immediately following the release of the whitepaper, a new tool (called Reaver) was released publicly that could be used to brute force the WPS PIN, and therefore, gain access to the WPA/WPA2 pre-shard key (PSK). The attack takes 4-10 hours on average and has an extremely high success rate.

What does this mean for you?

If you are a home user with a relatively new wireless router, you are probably susceptible to this attack. Basically, if your wireless router is WPS-capable you should assume you are vulnerable.

How do you defend against this attack?

The solution is quite simple: disable WPS on your wireless router. This renders the attack useless and it becomes a non-issue for you.

Hey, wait a minute. How come you only mentioned home users?

WPS is a system designed specifically for non-technical people. It is widely implemented in SOHO wireless routers but is generally not an enterprise wireless feature. If you happen to be running SOHO gear in the enterprise, then you will need to see if you are vulnerable as well.

Just how easy is it to perform the attack?

Easy. Here is a quick video demonstration showing how the attack works, and how to protect against it. This video was created using freely, and readily available how-to documentation on the reaver code page.

The Bottom Line

If you are running enterprise gear, you probably have nothing to worry about. If you are running SOHO gear, then you need to look into this a bit further. Increasing the length and complexity of your PSK does not protect against this attack. You need to disable WPS until the protocol can be strengthened.

Oh yeah, and Happy New Year!

The NCI Blogging Robot

Questions? Concerns? Comments? Get it in touch with us below.

I was originally going to post this in January, but I just couldn’t wait any longer. From January 25^th to 27^th, I will be a delegate at Wireless Field Day 2 (WFD2) in San Jose, CA.

My day job focuses primarily on Aruba Networks and Meraki, but I have always made an effort to keep up-to-speed with what everyone else is doing in the wireless industry. WFD2 will be a tremendous opportunity to do so. Sponsoring vendors include:

• Aerohive - @Aerohive
• Aruba Networks - @ArubaNetworks
• Ekahau - @Ekahau
• Meraki - @Meraki
• Metageek - @MetaGeek
• Ruckus - @RuckusWireless
• HP - @HP_Networking

If the opportunity to get all these vendors in the same room and have a pointed, no-BS discussion about wireless technology wasn’t enough, there’s more! Along with the vendors, there will also be a list of delegates that is nothing short amazing! So far, delegates include:

• Marcus Burton, CWNP, @MarcusBurton
• Sam Clements, SC-WiFi,  @Samuel_Clements
• Rocky Gregory, Intensified,  @BionicRocky
• Tom Hollingsworth, The Networking Nerd,  @NetworkingNerd
• Jennifer Huber, Wireless CCIE, here I come!,  @JenniferLucille
• Blake Krone, Digital Lifestyle,  @BlakeKrone
• Chris Lyttle, Wifi Kiwi’s Blog,  @WifiKiwi
• Andrew vonNagy, Revolution Wi-Fi,  @RevolutionWiFi
• Daniel Cybulskie, SimplyWifi - NCI, @SimplyWiFi

That’s a lot of wireless knowledge to cram into a single room. Seriously, my Wi-Q will increase just by hanging out with these people for a few days – awesome!

I’ll be tweeting and blogging during the entire event to help make sure that everyone gets to benefit from this amazing event. If you’re interested, you can also check out the official WFD2 channels.

Dan C.

Be sure to check back for more news on WFD2 as we get closer to the event date.

Every day, innocent wireless controllers are framed for crimes they didn’t commit. This is the story of how one WLAN controller was falsely accused of connection murder…

The Crime Scene - WLAN Connection Murder

Testimony: A user is having difficulty connecting his brand new laptop to the lab WLAN using WPA2-PSK. He has been able to connect to the corporate WLAN but all attempts at the connecting to the lab have failed. Also, the user has been able to connect to other WPA2-PSK protected networks in the past. 

Prime Suspect: Bystanders report seeing a WLAN Controller fleeing the scene.

Investigation performed by Detective @SimplyWifi

Are other clients having a similar issue? - No.

Are there comments in the controller’s release notes regarding this issue? – No.

Had client submit to a connectivity test and sent logs to the lab for analysis. Lab results below:

Deauth from sta: 24:77:03:xx:yy:zz: AP xxx.yyy.yyy.zzz-00:24:6c:aa:bb:cc-NameChanged-AP Reason Unspecified Failure

 Offender Profile

Based on the resulting debug lab results, it was determined that the wireless client was successfully connecting. However, it would immediately disconnect itself due to an: ‘Unspecified Failure’. The important take-away was, the controller was not initiating the disconnect; it was the client deciding to disconnect. This information allowed the detective to provide the following offender profile:

Age: Less than 1 month old.

Height: ~1 ft.

Build: Standard corporate image.

Behavioural Patterns: The offender is highly mobile but tends to spend a lot of time resting on a docking station on a desk. When connected to the docking station, the offender will likely be physically connected to the wired network via an Ethernet cable.

The Takedown

The offender was located and, as predicted, it was found connected to a docking station. Upon removal from the docking station, the client was able to successfully connect to all corporate and lab WLANs. Detective @SimplyWifi told reporters: “This is another tragic case of the victim turning out to be our perp. Once we started looking at the evidence, it was clear that the WLAN controller was being falsely accused. After that, it was a simple matter of following the evidence back to the victim.”

Final Comments:

In this case, it turned out that an application on the client was blocking the ability to connect to both a wired and wireless network at the same time. As is usually the case, the issue was a client-side issue and required no controller changes to resolve the issue. It serves as a great reminder of the importance of performing detailed victimology in any wireless investigation.

Dan C.

Do you have a story about spending time troubleshooting the WLAN controller only to eventually determine that the issue was with the client? If so, we’d love to hear it in the comments section. Also, if you are having troubles resolving issues on your own WLAN, please contact us and we’d be happy to assist.