New tool cracks most enterprise wireless LANs

New tool cracks most enterprise wireless LANs

Summary: If your company or organization runs an enterprise wireless LAN network, I have some troubling news for you.  Odds are high that your current "enterprise-class" wireless LAN deployment is vulnerable to authentication leakage which not only exposes your internal network but all of your server access controls.

SHARE:

If your company or organization runs an enterprise wireless LAN network, I have some troubling news for you.  Odds are high that your current "enterprise-class" wireless LAN deployment is vulnerable to authentication leakage which not only exposes your internal network but all of your server access controls.

You can use all the strongest authentication protocols such as PEAP, EAP-FAST, or EAP-TTLS and the strongest encryption algorithms like AES, but you're still easily vulnerable because of poor wireless client design.  Mainstream wireless clients from Microsoft, Apple, and Funk software make it impossible for normal people to discern when they're being tricked.  They provide so little pertinent information to the user that they qualify as a fairly serious design flaw in the client TLS implementation.

The problem with the wireless LAN EAP authentication is that there is no natural and intuitive way to match the name on the digital certificate to the SSID name.  More specifically, the "subject" field (AKA CN "Common Name" or DN - "Designated Name") on the server's digital certificate can be anything you want to call it.  Most organizations will at least have some part of their company name in the certificate and if the certificate is purchased from a commercial Certificate Authority, then the domain name must be at the end of the subject field.

HTTPS clients (Web Browsers) by contrast don't have this problem since they automatically match the domain in the URL address to the subject field in the digital certificates.  So when a user goes to SSL/TLS secured https://secure.mybank.com and the certificate subject field contains secure.mybank.com, a nice little lock icon lights up and assures you that some trusted entity like VeriSign or Entrust certifies that you're really at secure.mybank.com.  But for a wireless client that utilizes a TLS-based EAP authentication, it's not so simple.  If you see a Wireless network with an SSID called "MyCompany", the certificate might be ".some.cryptic.corporate.IT.name" which looks nothing like the SSID.

Microsoft's Windows XP SP2 client and Vista when deployed using Group Policy offers the highest level of lockdown possible if the administrator knows how to lock it down.  The standalone configuration of the Microsoft wireless client on the other hand is not only confusing, but it's flawed because of the fact that it hides the certificate name from view.  When the user is presented with a new certificate and all it shows is VeriSign trust network but the name on the certificate "hacker.from.anywhere" is hidden from view, they can easily be fooled in to making the connection.

However, Windows XP SP2 and Vista do allow you to lock things down so that the user will never be prompted by fake RADIUS servers but that depends on proper user configuration which can't always be depended on.  To make it easier on you, see the following screen shot to see what you need to lock down.  You can also look at my guide on enterprise wireless LAN security which teaches you how to manually or automatically deploy these settings and a whole lot more.

The key things to ensure is that

  • Validate server certificate is enabled
  • The "Connect to these servers" field in the wireless supplicant specifies the subject field in the X.509 digital certificate AKA CN or DN.  If that's confusing to you, you're not alone.  Additional server names can be entered separated by a semi-colon.  Note that in my enterprise wireless LAN security guide, I don't specify this field but it's ok to leave out in a very specific situation.  If you use a private certificate authority and lock down the certificate authority and you don't prompt users for new servers or certificate authorities, you don't have to have this field populated.  But if you use a public signing authority, you must have this field locked down.
  • The CA (certificate authority) must be specified whether it's a public CA or your own private CA.
  • The "do-not-prompt user to authorize new servers or trusted certificate authorities" option was a key enhancement to the Windows wireless client.  Funk's Odyssey client also has this security feature but it's missing from other wireless LAN clients like Mac OS X.  Letting users add additional certificate authorities is extremely dangerous.

To drive this point home, security researchers Joshua Wright and Brad Antoniewicz have produced a weapons-grade penetration tool called FreeRADIUS-WPE that exploits these deployment weaknesses.  Why would they release such a thing?  To raise awareness since no one ever cares about these things until they see it with their own eyes or they read it in the news.  Without the tool, the massive problem still exists and can be exploited with less convenient but still effective methods but no one actually does anything about it since it's not on their list of things to audit for.  Now that the tools are public knowledge, security auditors will have to use FreeRADIUS-WPE to perform penetration testing on their own networks before the bad guys get to them first.

Topics: Networking, Security, Servers, Wi-Fi

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

22 comments
Log in or register to join the discussion
  • That's why I don't use these methods for security

    You have to consider wireless networks as inherently insecure, whether you use wep, wpa or any of this complicated key crap. They were asking for wireless acces here at my corp for a long time and I had to finally give in and implement it. Heres how:
    cheapo linksys router covers all the space. SSID = linksys, NO WEP, NO WPA. MAC filtering so you have to ask me for access. router is connected directly to a cable modem, which is good since most times it's some visitor who needs only internet acces. access to the corporate network must go out the cable modem AND back in through the T1, using citrix or VPN.

    SO I have security that I don't need to worry about, while providing the wreless access that is needed.
    If someone breaks into the wireless, it only looks like some linksys router with a cable modem, with NO info about the company which it serves.
    erm@...
    • Not Bad, But...

      Since it is still your company's cable connection, if used for some illegal purposes, you'd probably still be held accountable in some of today's more liberal courts.

      Not saying I agree, just saying from recent court judgments. If you don't secure your connection, you can be held liable.
      rkuhn040172@...
    • Not that secure...

      Well that's secure in only that you can't access your company network from the wireless without the VPN. Spoofing the MAC address is a pretty simple thing though. Just keep generating MAC addresses until you hit one that's allowed.
      Uncle Ebeneezer
      • don't need brute force

        It would take a while to go through the entire range of MAC addresses. All someone would need to do is watch the traffic for valid MAC addresses, then spoof allowed ones once those users are offline...
        Litehouse
    • Here's why you can't use VPN to replace Wi-Fi security

      http://blogs.zdnet.com/Ou/?p=489
      georgeou
      • Blatant errors in your anti-VPN arguments

        I personally use and enforce IPsec on my wireless
        networks instead of using traditional Wi-Fi security
        mechanisms. The blog post you point contains factual
        errors and reaches an incorrect conclusion.

        "More expensive gigabit-capable VPN gateway". Run as
        many IPsec tunnel endpoints as you want on your wired
        LAN -> no bottleneck on a single VPN gateway.

        "Saving nothing on Wi-Fi related infrastructure".
        This is not an argument _for_ traditional Wi-Fi
        security.

        "Getting less performance and more overhead". The
        perf of pretty much any processor on typical
        encryption and HMAC algorithms is much greater than
        the max theoretical throughput of 54 Mbit/s of
        802.11g. A 4-year old K8 @ 1.8 GHz 32-bit openssl
        benchmark shows an RC4 encryption speed of 163
        MBytes/s and a HMAC(MD5) hashing speed of 316
        MBytes/s. So encrypting & hashing 54 Mbit/s of
        traffic would cost only 6% of CPU, ridiculous.
        Moreover ESP & AH headers typically consume 62 bytes,
        you won't notice any perf difference between an MTU
        of 1500 and 1438 on a 54 Mbit/s wireless network.

        "Getting less compatibility to embedded devices".
        Pretty much the only thing you got right.

        "Offering less manageability with no pre-login
        connectivity". IPsec is arguably as flexible as WPA2,
        if not more. And it _does_ offer pre-login
        connectivity.

        "Allowing the hacker to get onto your open Wi-Fi
        network and probe your network and Wi-Fi clients for
        weaknesses". Properly configured IPsec tunnel
        endpoints _drop_ non-IPsec traffic coming from the
        wireless network. As for the client, you should do
        the same. Not securing them because you rely on
        WPA/WPA2/whatever is a bad security practice.
        zpdixon 42
        • Sorry, you're confusing the issues

          "The perf of pretty much any processor on typical encryption and HMAC algorithms is much greater than the max theoretical throughput of 54 Mbit/s of 802.11g."

          What's the aggregate performance of 100 dual-band access points? What about 100 dual-band 802.11n APs? What kind of a VPN gateway do you need to handle the load for that? What kind of latency do you add? What about the 60 to 100 bytes per packet overhead and what does that do to small-packet application like VoIP?


          ""Offering less manageability with no pre-login
          connectivity". IPsec is arguably as flexible as WPA2, if not more. And it _does_ offer pre-login connectivity."

          You're talking about GINA type mechanisms that log in when the user types in the password. That isn't the same thing as machine unattended login and it's nowhere near as seamless.

          "'Allowing the hacker to get onto your open Wi-Fi network and probe your network and Wi-Fi clients for weaknesses"

          Properly configured IPsec tunnel endpoints _drop_ non-IPsec traffic coming from the
          wireless network. As for the client, you should do the same. Not securing them because you rely on WPA/WPA2/whatever is a bad security practice.

          Do not confuse layer 2 security for layer 3 security. You're arguing that layer 3 lockdown is sufficient that you don't need to worry about the layer 2 issues and that's just plain wrong.

          No, you're just confusing the issues.
          georgeou
          • IPsec more mature than WPA2

            A modern dual-core processor probably outperforms by
            10x-20x the crypto chip in an AP. Heck a $90 Athlon
            64 X2 4800+ runs HMAC(MD5) at 2.9 Gbit/s per core, or
            5.8 Gbit/s per socket. An organization with hundreds
            of APs has probably dozens of subnets, servers,
            gateways, etc. Running the IPsec tunnel endpoints on
            a dozen gateways for example would be plenty
            sufficient to handle the load.

            VOIP is not bandwidth intensive, the ~60 byte
            overhead per packet is negligible.

            I wasn't talking about GINA. In standard IPsec
            environments, no matter whether a key-exchange
            protocol is used or pre-shared secrets are defined,
            the SAD entries are created when the OS configures
            the network, way before the user logs in. The network
            is basically always available all the time.

            About layer 2 security: firstly, 802.11 vulns like
            the famous CVE-2006-5710 typically concern all
            wireless networks: those protected by WEP/WPA as well
            as those protected by IPsec. IPsec would only fail to
            prevent attacks using protocols above 802.11 other
            than IP. For virtually all networks, there is only 1
            such protocol: ARP. The one attack achievable via
            this protocol is ARP spoofing, whose effects on an
            IPsec network is only a DoS. The traditional defense
            is to use static ARP entries, but frankly this is
            kind of pointless and nobody does that because it is
            very easy to DoS any wireless network anyway, no
            matter what you use (WEP, WPA, IPsec, etc). Bottom
            line: IPsec provides at least as much security as
            WPA2.

            WPA2 is less mature, has more interoperability issues
            than IPsec, and is *riddled* with implementation
            flaws (can I link to one of your post to prove my
            point ? http://blogs.zdnet.com/security/?p=901).
            zpdixon 42
          • You're using implementation bugs to disparage a whole standard?

            You're using implementation bugs to disparage a whole standard? Why don't you google "IPSEC vulnerability" and see what you come up with.

            You're comparing apple's and oranges.
            georgeou
    • MAC filtering is a waste of time

      http://blogs.zdnet.com/Ou/?p=454
      georgeou
  • RE: New tool cracks most enterprise wireless LANs

    Except that with no WEP / WPA on the link to your wireless client, someone could sniff out passwords, server names, logins, etc. without too much difficulty. The problem isn't just the edge security at your electronic gateway, it's that sensitive information goes all the way down to the client.

    Steve G.
    aureolin
    • So what is the point you are trying to make?

      "The problem isn't just the edge security at your electronic gateway, it's that sensitive information goes all the way down to the client."

      So what is the point you are trying to make?
      georgeou
  • RE: New tool cracks most enterprise wireless LANs

    WHich is why it is named linksys, with only a cable modem, not too interesting. AND you would have to sit outside for MONTHS to sniff the amount of traffic that flows here to get anything useful, since it's rarely used. The macs are taken out when not in use.
    That's alot of work for something that looks to be not interesting.

    The logs don't show any of the above.
    erm@...
  • RE: New tool cracks most enterprise wireless LANs

    FYI,
    George Ou has written on this ad nauseum. He's explained why each of the various security attributes/features either do or do not actually contribute to increased security, and why.

    The six dumbest ways to secure a wireless LAN:
    http://blogs.zdnet.com/Ou/index.php?p=43

    Wireless security myths that won't die:
    http://blogs.zdnet.com/Ou/?p=454
    thinker999
  • RE: New tool cracks most enterprise wireless LANs

    To gadget_jb - It's a good thing for most folk that there are websites such as this one, explaining the pitfalls, and the right way of doing things. Better too much advice than not enough.
    peter_erskine@...
  • RE: New tool cracks most enterprise wireless LANs

    Wireless will never be truly be secure. Most wireless networks have some piece of reoccurring code that crackers key into this is the weakness of wireless. There are more secure wireless methods that prevents reoccurring code but that appears to be too expensive for most enterprise to implement... unless there is a break in. Most enterprises and vendors which need to cater to the enterprise are "Penny wise, pound foolish" so unless there is publicized break-in they will do nothing and the wireless network will remain unsecured.
    phatkat
    • Your statement isn't true

      "Most wireless networks have some piece of reoccurring code that crackers key into this is the weakness of wireless."

      Your statement isn't true. Wireless has been secure for many years when it's implemented and deployed correctly.
      georgeou
    • Cracking WPA requires 4 packets of data...

      http://www.infoworld.com/article/03/11/07/HNwpa_1.html

      A new paper by a leading security expert says that the new Wi-Fi Protected Access (WPA) security standard may be less secure, in certain scenarios, than WEP, the wireless standard it was designed to replace.

      ".. attackers who want to compromise WEP and LEAP need to harvest large quantities of network traffic before they can decipher the passphrase. In contrast, WPA only requires them to capture four specific packets of data, Moskowitz said."

      "Passphrases with fewer than 20 characters long are unlikely to withstand a dictionary attack, and attackers who miss those four packets in transit can easily trick a wireless access point into doing a new "handshake" and sending the packets to the attacker again, he said. "

      -Mike
      SpikeyMike
      • That article is very misleading

        "Passphrases with fewer than 20 characters long are unlikely to withstand a dictionary attack"

        That's under the assumption that a very non-random password is used. If you use just a 10-character alpha-numeric password that is random, it's extremely impractical to hack. WPA-PSK is extremely computationally expensive to run dictionary attacks on by design.
        georgeou
  • Exe's in my Temp Internet Files folder

    Right now I see two places for files that are accumulated during web surfing.The Internet Temp Files folder and in the History folder.If you take the HIDES out in Windows Explorer>Tools>Folder Options>View--you just might see exe's that are uploaded to your computer during your time on the Internet.Google does this a lot.It's like the entire Internet is disassembled and stored on your drive.
    BALTHOR