wlan client isolation bypass in WPA/WPA2 network against Windows 7

Wlan Client Isolation Bypass in WPA/WPA2 Network against Windows 7

or Windows 7 TCP broadcast feature

THIS IS NOT HOLE 196, IN THE END I WILL TALK ABOUT THE DIFFERENCES.

Before I can talk about my bypass you have to know some facts. First of all, after you connect to a WPA/WPA2 network two keys are created:

• A unique key for your unicast traffic
• A shared key for broadcast traffic. This key is the same for every pc connected to this wlan station (its called GTK)

So if you send unicast traffic, nobody can sniff it. To make it possible to connect directly to other wlan clients, the wlan gateway decrypts your packet and encrypts it with the unique key of the other client.

But when you send broadcast traffic you don't need the gateway to translate the packet, because the broadcast key (GTK) is for every connected client the same.

Client Isolation

To keep it simple, the client isolation feature just stops the transmitting of unicast traffic of connected wlan client to another wlan client. Basically we are not able to send any unicast traffic to them anymore.

The idea

We have to get the system to use the group key to reach other clients, so broadcast (for being correct, the broadcast mac ff:ff:ff:ff:ff:ff) is needed.

Lets take this scenario:

My ip: 10.0.0.1

victim: 10.0.0.2

Gateway:10.0.0.254

To begin with we have to force the OS to use the broadcast key. This is done by making a static arp entry which maps the victims ip 10.0.0.2 with the mac ff:ff:ff:ff:ff:ff:

arp -s 10.0.0.2 ff-ff-ff-ff-ff-ff-ff

When you now type ping 10.0.0.2 the os will use ff:ff:ff:ff:ff:ff as the destination mac and will use the broadcast key. First way done

The way back

Now the victim won't be able to send a packet back, because he will send unicast packets, encrypted with his unique key. This is where arp spoofing helps out, but arp spoofing per response won't work. As you maybe know, a arp response wouldn't be possible because it's a unicast traffic, so lets spoof via arp request which uses the broadcast mac as the destination mac.

Now the arp cache of the victim maps my ip 10.0.0.1 to the mac ff-ff-ff-ff-ff-ff

This will force the victim os to use the broadcast key and we will receive a answer... or do we?

The problem:

To start with: Linux and Windows XP (Vista not tested) make a certain check when receiving a packet. If the destination mac is ff:ff:ff:ff:ff:ff and the layer 4 protocol has no broadcast, they will drop the packet.

Basically we can reach Linux and Windows XP with protocols like udp and icmp (so you will be able to ping them) but they drop tcp packets, which makes sense. In udp and icmp its possible that the destination mac is ff:ff:ff:ff:ff:ff but not in TCP, no way. But I wanted to use TCP, tcp is the best :D

Now a new feature (bug) in windows 7 helps us. Windows 7 doesn't make the same check as linux or xp, as long as the destination ip matches one of the interfaces on the windows 7, it will ignore the fact that the destination mac is ff:ff:ff:ff:ff:ff. This is really nice Micrsoft =)

Putting alltogether:

Now you are able to reach the victim Windows 7 machine via tcp. The nice thing is you can even use standard tools, like nmap but there are some limitation, but first the 3 small steps:

1. make a static arp entry to map the victims ip to the broadcast mac
2. spoof the victim via arp request (I created a tool to send the arp request, didn't find one for windows)
3. type: nmap -sT <victim ip>

Things to consider:

1. You can use linux to attack a windows 7 machine, but standard tools won't work, because you have to sniff the response. The linux kernel will just drop the packet.
2. You can use standard tools like nmap as long they don't use raw sockets. As an example nmap -sS won't work (-sS needs raw sockets), because it won't look up the destination mac in the arp table instead it will use a arp request (and there won't be a response because of the client isolation). Maybe I find a way around that. I had no time to test the behaviour of metasploit

Difference to Hole 196

If you don't know what hole 196 is, in google you will find it easy.

I will talk about the difference to my attack in the aim of bypassing the client isolation feature:

First of all I have to admit, with hole 196 you are able to attack all machines, not just windows7 machines. To use hole 196 you have to modify your wifi driver, so I assume the attacking machine is a linux machine. This forces another modification. Like I already pointed out, the linux kernel will drop the tcp response packets, because the victim still has to use the destination mac ff:ff:ff:ff:ff:ff to bypass the client isolation feature. You will have to modifiy the linux tcp ip stack too. This seemed to much work for me :D

My arp response spoofing tool (source code included)

https://drive.google.com/open?id=1yunqdL73FHQP2gPvuNMhmQF_I-_zMAfz
/* if you know a good file hoster, please tell me */

usage: tool.exe <your mac> <your ip> <victim ip>

You have to install winpcap 4.1.2 (winpcap team you're awesome)

and don't forget the static arp entry via arp -s <victim ip> ff:ff:ff:ff:ff:ff