Wireless (In)Security: 5 WiFi Client (Mis)Uses

Wireless (In)Security: 5 WiFi Client (Mis)Uses

By CWNP On 08/05/2009 - 9 Comments

My previous post (WiFi Rogue AP: 5 Ways to “Use” it) talked about the (mis)uses of a Rogue AP. This post looks at the other challenge – security issues with WiFi clients. WiFi clients come from different vendors and are available in several flavors. They are embedded in today’s notebooks which often carry sensitive enterprise and personal data. By their very nature, such clients are highly dynamic. I am sure that network administrators managing even moderate sized enterprises can relate to the following two issues.

First, the hassle of maintaining an accurate list of enterprise WiFi clients and second, controlling the WiFi profile of a client (WiFi profile of a client determines its mode of operation (BSS/IBSS), wireless networks (SSIDs) it will try to connect to, and its security settings (open/encrypted, secret)). Although wireless LAN (WLAN) infrastructure that provides centralized control (e.g., via a controller or a wireless NMS) can mitigate the first issue, it may not be of much help in controlling the second. This is because of the fact that users often use their official notebooks to connect to their home WiFi and other public WiFi services such as hotspots. Hence, it is possible that enterprise laptops have multiple profiles (some insecure). Such “mis-configured” WiFi clients can be exploited by an attacker in the following 5 ways.

1. Passive Sniffing Since WiFi clients probe the medium at regular intervals, an attacker can just turn on his or her favorite sniffer to (at least partially) reconstruct the WiFi profile of enterprise clients. The key information that can be obtained from this exercise is the list of clients that are potentially vulnerable (and hence, are candidates for the rest of the attacks mentioned in this blog). For example, clients that are probing for hotspot SSIDs, clients that are advertising ad hoc connections. Such leakages cannot be prevented even if your enterprise WLAN uses the best available cryptographic security (WPA2, 802.1x, CCMP) for 802.11 data packets. Now, let us consider a scenario where your enterprise WLAN does not encrypt layer 2 broadcast traffic. In this case, an enterprise client that is connected to your WLAN can potentially “seep” out additional information that can be valuable to an attacker - network and higher layer information about your own enterprise network (e.g., DNS server, IP subnet, active services on a client).    

2. (Wi)Phishing If an enterprise client is probing for networks that are vulnerable, a “honey pot” can be set up to lure the client. The exact nature of the honey pot will depend on the WiFi profile of the client. If a client is probing for a hotspot SSID or a metro WiFi SSID, setting up an AP with that specific SSID may be effective. Alternately, setting up an “Evil twin” of an authorized AP can sometimes succeed in luring clients. Once an attacker is able to get a connection to the client, he can launch man-in-the-middle (MITM) attacks and virtually do anything (e.g., get passwords, access files, propagate worms and trojans). Several public domain tools are available to launch this attack – e.g., Karma, DeleGate, Hotspotter, AirJack. An advanced form of this attack is a “Multipot”, where multiple APs are used as honey pots. They can easily evade some of the popular intrusion prevention techniques used in wireless intrusion detection and prevention systems (WIPS) such as the “deauthentication flood” technique. This is due to the fact that an enterprise client “hops” across individual honeypot APs when a WIPS sensor tries to break one of the associations. If the client hops faster than the latency of the WIPS system to detect this change, prevention can be rendered completely ineffective (More on this in another post).

3. Ad hoc connections WiFi Ad hoc networks (802.11 IBSS connections) are very convenient in sharing data amongst WiFi clients. WiFi users are often very fond of using ad hoc networks. It can be driven by the fact they are not able to share their favorite video with a colleague via the enterprise WLAN (yes, I am talking of Cisco PSPF). Or, they want to access a network printer that supports only ad hoc connections. Or, simply because there is an enterprise policy that forbids the use of ad hoc networks! Whatever the reason, ad hoc networks are inherently insecure and can provide a very easy entry point into your enterprise network. Apart from compromising the particular machine, an attacker can use the connection as a launch pad for accessing the rest of the enterprise network.

4. Fuzzing Based on the WiFi profile of a client, certain random packets can be crafted and injected to the client. This activity (called Fuzzing) will help to discover any potential security holes in the client implementations. Fuzzing can be tried with packets that are not conformant to the 802.11 standard or with packets that exploit common implementation issues (say, buffer overflows).  An attacker can potentially crash a client machine by injecting such packets. If the attacker happens to be blessed (read as, if the client implementation sucks), he may even end up getting a root or admin access on the client.

5. WiFi client Bridging and Internet Connection Sharing (ICS) Have you heard about the Windows Bridge feature? This allows any 2 interfaces of a Windows machine to be bridged so that data can be relayed across them. An employee may (advertently or inadvertently) bridge your enterprise wired network to an insecure wireless network. The other end of the bridge can be as “good” as you can guess: your neighbor’s AP, Google-WiFi, an accomplice’s AP, or even an ad hoc connection. This bridge can be used to transfer data into and out of your enterprise network (without giving any clue whatsoever to your perimeter firewall). Comparable access can be achieved via ICS, which is a NAT-like functionality provided by Windows. Note that all of this can be done without sneaking in a physical Rogue AP into your network!

I would love to hear about your experiences in tackling WiFi client (in)security in your enterprise. 

 

*** Thanks, Gopi (Follow me on twitter: @gopinathkn)

Tagged with: gopi

Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.