Newbury is spreading FUD. Here's the Deal.

(Originally posted by Mike Fratto on SecureEnterprise Magazine's Website on 02/01/06)Newbury Networks has been pushing extremely hard the idea that Wi-Fi is broken and can't be trusted unless you deploy their products. They are pushing over the top marketing in webinars and white papers. This white paper is one of the most blatant cases of fear mongering I have seen in a long time. Let's take this apart point by point. Stirring the potMixed in with the F.U.D. are some kernels of truth. One of the first points Newbury makes is that Wi-Fi signals are not restricted to the physical building, and yeah, that's right. The radio transmissions do leak beyond walls. That means an attacker can place an AP in your building, wire it to the network, and gain access while sitting in their van in the company parking lot. Or in a slightly less paranoid situation, a well meaning but uninformed employee brings in an AP from home and leaves it unsecured. Of course, attackers can capture packets and attempt to mess with the wireless infrastructure like DoSing clients, attempting to insert their AP in the middle of the conversation, etc. Now Newbury claims to have products that solve both of these problems (and more) by locating authorized and unauthorized AP's and blocking client access to them. Maybe they do, maybe they don't. This Network Computing review of Wi-Fi IDS systems titled Distributed Wireless Security Monitors by Frank Bulk is informative. Even if you haven't deployed wireless on the corporate network, getting a handle on the airspace may be useful. But you can also limit the efficacy of a rogue AP attack by implementing strong physical security processes. Ya probably weren't born in a barn, so don't leave the front door open.

The rest of the white paper is FUD, pure and simple. They make the claims that 1) IPSec VPN is broken (not true) 2) WPA, WPA2, 802.11i are insecure (not true), 3) man in the middle attacks will always work AND subvert your security (also not true). They further present existing attack strategies like social engineering as if they are particularly effective for breaking into a Wi-Fi network.

Where to begin?Let's start with the claim that IPSec is broken. Newbury apparently doesn't understand the nature of the problem nor how IPSec is typically deployed. The UK National Infrastructure Security Co-ordination Centre issued a vulnerability advisory titled NISCC Vulnerability Advisory IPSEC - 004033 in May 2005, that describes several attacks that can cause data protected by IPSec in tunnel mode to be leaked. This is not an IPSec issue, but an implementation issue which only occurs in specific, non-standard configurations. IPSec provides confidentiality and data integrity for layer three traffic. A typical, default configuration for IPSec VPN gateways is to apply encryption and integrity to the protected data, in that order. The described attack only works when IPSec is used when integrity checking is disabled. The attack works by flipping bits in the encrypted payload in an attempt to manipulate or corrupt the internal IP packet header. An error in the internal IP packet header causes the VPN gateway to send an ICMP error message to the source host often with the protected data in the ICMP payload. Similarly, the bit fiddling causes the VPN gateway to forward the clear text packet to a different host. That vulnerability is a device implementation issue leveraging how network devices work normally. The other IPSec configuration is when just using authenticated header, which is rarely used alone. The solution is to use both encryption and integrity, which is most likely the default configuration anyway. That's a no brainer.

Supposed AP Deployment problemsIn a graphic labeled Diagram 3, they show a typical home office Wi-Fi situation and Newbury pushes the notion that an attacker can whack a home user or remote user at a hotspot, and gain access to the internal network. That is a common attack vector and certainly not specific to Wi-Fi networks. Look, when someone is remotely accessing the corporate network regardless of whether they are at a wireless hotspot, hotel broadband, customer site, or home, they should be using a VPN or some form of encrypted, authenticated access. Treat wireless clients like any remote client. If you already require users to access internal resources over a VPN and you have a centrally managed desktop firewalls deployed for traveling users, then you're doing everything you can do. If you are allowing unencrypted, unauthenticated access to internal resources for remote users, you have far more fundamental problems to deal with than wireless.

Newbury also spends a lot of time talking about rogue APs and how attackers get users to connect to a rogue. That is certainly a problem, but also easily thwarted using existing processes and technologies. Best practices dictate that you change the default SSID on AP's so that they aren't easily guessed, use WPA-2 Enterprise, and use upper level encryption and authentication. In addition, if your wireless clients are configured to only connect to authenticated AP's and not connect in Ad-Hoc mode, then a man in the middle attack is not likely to work. But even if an attacker does successfully get in the middle of a client and a wireless AP, there is still little they can actually do other than deny service to the client.. If you have a properly configured host firewall, then external attacks can't be executed. If your remote user is accessing internal resources over a VPN, then there is little an external attacker can see. And educating users to never send credentials in the clear for any website whether the user is connected via the wire, wireless, dial-up, or any access method is always a good practice.Finally, the cracking problem is important but easily mitigated. First, avoid using pre-shared keys or if you must, make them complex and rotate them often. Dictionary attacks rely on easily guessable passwords and common permutations. Cracking a seemingly complex password like "fR@g1l3" is pretty likely because the substitutions (@ for 'a', 1 for 'i', 3 for 'e') are fairly common It is unlikely that a dictionary attack will crack a pre-shared key like "34ERUrYHJn&^%gReed#2EDtrt6hjM(".

Making it rightHere are the general steps to deploy secure wireless: 1) Use the best layer 2 protection available. That means WPA2-Enterprise. That way the the client and the authentication server can authenticate each other, and encryption keys will be rotated regularly. If you're still using WEP, stop now and upgrade. 2) Don't allow your clients to associate with untrusted APs by pre-configuring the wireless client to connect to only certain SSIDs and turning off the wireless clients ???scan for any AP' behavior. If necessary, use client-based software to enforce those policies and a wireless IDS system at the office.3) Use a host-based firewall, always. 4) Use a VPN (IPSec or SSL) for remote access regardless of wired or wireless access.5) Train users on the proper use of wireless and user oriented security.6) Use a wireless IDS to detect malicious activity such as rogue APs, but only after you have deployed a robust and secure wireless infrastructure.

You can read about Newbury's response here.