English Version | Version en Español
Home | Research | Resume | Projects | Pictures | archive | TCG

Implementation of DoS and Hijacking attacks and 802.11 networks

I am implementing the attacks against 802.11 networks discussed in the papers Your 802.11 network has no clothes and An Initial Security Analysis of the 802.1x....

What I am using

The hardware I am using is a laptop with two PCMCIA slots running a 2.4.17 Linux kernel, a Cisco systems 340 client card, a ZooM Air Prim2 based wireless card and a CISCO Aironet 350 AP.
The CISCO card is used as the sniffer, The ZooM Air as the Rogue AP and the CISCO 350 AP as the target AP.

The software I used is the CISCO drivers for the 340 client (BEWARE: The latest version of Redhat is shipped with a CISCO driver which do not support monitor mode, and hence is not usable to sniff) . I am also using Kismet as the sniffer with ethereal to inspect the packets. And finally, the hostap driver (BEWARE: I am using the snapshot from the CVS. The stable version WILL NOT work, at least the latest at day of today, Mon Jul 06.)

Brief description of the attack

Management frames are not authenticated, but for the ESSID and the BSSID (hardware address of the AP) of the AP and the MAC address od the client. The first think we could do is to use the same MAC address of the client and authenticate to the same AP as him. That should kick the target client out, in theory. But current AP usually will not complain, and will leave both clients associated (creating a mess, that is for sure).

The second technique is to impersonate the AP, and begin sending deassociation frames to the client. The client will Reset the connection and try to reassociate and authenticate again.

There are two ways of impersonating the AP. Your new "impersonating AP" will have the ESSID or/and the BSSID of the AP to impersonate. In this attack I change both. Why?
All right. Say you have an AP with ESSID "tsunami" and your rogue AP changes its ESSID to "tsunami". The client will think both AP are from the same network and will choose ONE of them. It will either be Associated to your rogue AP or to the real AP, depending on who has a better/stronger signal.
In this case if you use a sniffer you will automatically spot the rogue AP, if that rogue AP is in range. So it is not very stealth. Also, you need equipment that provides a better signal strenght that a commercial AP, or a directional Antenna, directed to the client. If all the requirements are met, the client will "roam" to your access point, dissacociating first from the other AP and associating into yours.

If you change both the ESSID and the BSSID, the picture changes radically. You are not another AP with the same ESSID. Basically you are the same AP, in terms of what the client (or any sniffer) sees.
In this case you don't need fancy equipment, even if your signal is less strong than the one from the AP to impersionate. The client will still think that you are that AP. You can then DOS the client, inject packets, etc...

The attack is performed using the ZooM AIR card as the impersonating AP. In the latest CVS snapshot of the hostAP drivers is possible to change our MAC address (BSSID), so taking the same address and ESSID of the AP where the client is connected (which we can know easily with a wireless sniffer utility like Kismet) will confuse the client, and force him to REASSOCIATE

ifconfig wlan0 hw ether { BSSID of targetAP }
ifconfig wlan0 ESSID { ESSID od targetAP }

After that, using the command

iwpriv wlan0 Kickmac { MAC address of the target client }

Will automatically send an deauthentication Management frame to that client. In fact, after changing our hardware address we will force to reassociate to all the station in range of the hostAP associated with the AP. We can do this as many time as we want, just by doing a soft reset of the rogue AP (or by hacking a little the drivers and using another private command)

This attack will likely work with 802.1x machines, as the Management frames are not authenticated even using this protocol

More to come, including: How to redirect the traffic from an AP, how to automate the attack using Kismet


Last changed by Jesus Molina, 2002/11/22 11:35:20