 A very good afternoon to all of you. My name is Sohail and I work for Airtight Networks. I'm a WIFI security researcher. And today, I'm going to talk about a security problem in WPA2 protocol. You may have heard about whole 196. In fact, in the last one and a half week, a lot has been said and discussed about whole 196 or GTK vulnerability. And in fact, a lot of speculations have been seen around this problem. So today, we are going to present the real picture and we'll help you understand or see the implication of the problem. So let me answer the most frequently asked questions that people have asked to me. Where did we find this whole 196? And for your information, it's already there in this standard. For the last six years, it was buried in the standard on page number 196. And that's the reason why we are calling it a whole 196. If you see the last line of the page 196, the designers of dot 11 have warned about the weakness of WPA2, one key that is used in WPA2. And on the last line, there is something mentioned about that key. GTKs do not have this property. So designers are talking about some property of encryption key, which is not there, which is lacking. But this problem was never discussed. And in fact, there is a problem, but it was never brought to the attention of WPA2 users. So in this presentation, we'll talk about that. So this talk is not about unauthorized user taking or gaining access to your corporate or your trusted network. No, it's not about that. It's not about key cracking, OK? It's not about cracking private key of a user. This talk is about an insider attack that can be carried by a malicious user who is already part of your network, who is already inside the network. But I have seen people saying that, OK, when a malicious user is already inside the network, then he can do pretty much anything or everything in that network. OK, so what's a big deal? Fine. So let me ask this question to them. If, let's assume that if you are an analysis insider, can you really sniff private data of other Wi-Fi users? If you try to capture packet in the air, you will see encrypted packet. And since you don't have key, you will not be able to decrypt it. So can you really sniff or see private traffic of other Wi-Fi users, even if you are inside the network? And the trick to do that is basically one can try launching man-in-the-middle attack. And the most popular trick is basically in Wi-Fi network is setting up a honeypot, OK? Using this, one can actually do man-in-the-middle and try to capture all the traffic of a user. But in a WPA2 networks, client devices are actually configured to connect to WPA2, OK? So those clients are not going to authenticate honeypot access point or they will not connect. So this trick is also not going to work. So what are the other options available? So probably we can think of launching man-in-the-middle attack in a very conventional style, old style, with the help of ARP spoofing attack. But today's network are basically much more secure than what it used to be. There are security systems which can actually detect ARP spoofing attack, wired IDS, IPS, or even switches have capability to detect it, OK? So if you are going to launch ARP spoofing attack, the chances of getting detected is very, very high, OK? So now let me ask again this question that without getting detected, can you really sniff private traffic or data of other Wi-Fi users? Even if you are inside that network, is it really possible? The answer is yes. In this presentation, I'm going to show you that it is possible. And this will not involve any key cracking or brute force. How? Let's walk through the presentation and we'll see. So I'd like to briefly talk about WPA2 protocol. I'm sure many of you must have a good technical understanding of that. But just to recall, in WPA2 protocol, there are two types of keys which are used for traffic encryption, packet encryption. One is called PTK, pairwise transient key. And the other one is GTK group temporal key. And the purpose of PTK is to protect unicast traffic, OK? While the purpose of GTK is to protect broadcast or multicast traffic. So there are two types of keys. If you see PTK is a unique key. It is unique for each user. And it is derived per session. So for example, if two clients are connected to a WPA2 enabled access point, both of these clients will be using two different keys. So client one will not know the private key of client two and client two will not know the private key of client one. So their traffic is basically secure. But GTK is a shared key. It is shared among all associated client devices. And it is actually managed by access point. So whenever a client connects to access point, it receives a copy of GTK from access point. So at any point in time, all associated clients are going to have same copy of GTK. Now I said GTK is used to protect broadcast traffic or multicast traffic. So in a Wi-Fi network, if you have noticed, all broadcast traffic is basically sent by access point. Because access point can talk to each and every client. And this traffic is never sent by a client device. Because client can, whenever a client has to talk to other Wi-Fi client device, it first send packets to access point. So for a client, destination is always fixed. Which means client always send unicast packet. And that gets, so does that mean client never generate broadcast packet? It generates. But in dot 11, that broadcast frame gets mapped to unicast frame. We'll not talk about that. But just to, so which means by design, GTK is going to be used as a one way key. Access point is going to use it for traffic encryption, broadcast traffic encryption. And all client devices are going to use it as a decryption key. And that's how the software in access point and clients are programmed. And here I'm showing you a log of Wi-Fi client device. There is a software called WPS supplicant, which runs on client devices. And it shows that client has a copy of GTK available, right? So the group key is always available to client device. It is always known to client device. Why it is available? Why client keeps a copy of GTK? Because it has to decrypt packet coming from access point. Now let me ask, what is stopping that client not using that GTK for its own packet encryption? So protocol says something which is a normal behavior. Client should not use this key for packet encryption. It should always use this key for packet decryption. But analysis user can always exploit this key. Analysis user present in that network can always use this key to create its own packet, generate its own packet, which means for analysis user, one broadcast frame is available, which that analysis insider can generate, is created, and send that packet to all other Wi-Fi client devices. But Wi-Fi client devices are programmed to receive packets from access point, not from other Wi-Fi client device, right? So in order to successfully deliver that packet, this insider is going to spoof the MAC address of access point. So once the attacker keeps the MAC address of access point as a sender of that packet, all clients present in that network and associated with the same access point is going to receive that packet and going to decrypt it successfully, right? Which means analysis insider has access to a broadcast frame, which it can create and generate and send. And there is no way for other Wi-Fi client devices to differentiate whether this packet is coming from other analysis user or it is coming from access point. Absolutely there is nothing present in that packet which can help a client to, you know. So now it's clear that attacker can send broadcast packet. So he can do a lot of attack. It depends what kind of attack payload he's going to encapsulate inside that broadcast frame, right? So in this presentation, I'm going to show you three exploits of GTK and the first exploit is basically using the ARP payload to encapsulate and create broadcast frame. So in this example, attacker is generating its own broadcast frame and sending that frame to other Wi-Fi users present in that network. And basically the attacker is advertising that he's a gateway of that network. All other clients are going to receive that packet and update its ARP cache thinking that the gateway, this new machine has become the gateway of that. And that's how our protocol works. If you send, if you advertise that you are a gateway, all recipients of that packet is going to update its ARP cache, okay? So attacker becomes the gateway of the network for that client who receives that packet. And after that, all traffic generated from that victim is going to be destined to this new gateway who is the attacker. So victim sends all its packet to access point, encrypting its packet with its own private key which is known to this user or access point. So access point will be able to decrypt those packets. And at this point, access point finds that this packet is actually destined for other Wi-Fi user who is also part of the same network. So access point forwards that packet to other Wi-Fi user. And that other Wi-Fi user happened to be a malicious attacker, right? So finally, the packet reaches to that insider. So just by injecting one spoofed or gratitude USR or ARP request frame, the attacker is able to redirect all the private traffic of a legitimate user in that network to its own machine. At this point, attacker can actually drop all the packets and do a denial of service attack in the network. But he wants to steal information, right? So for that, he has to provide a seamless service to the user, a transparent service to the user. User should not feel that there is something wrong going on in that network. For example, if I'm accessing Yahoo, and I'm not able to access that, it means there is something wrong in that network. So what happens at that? Attacker is going to forward all that packet to actual server or gateway, and he becomes man in the middle, right? So just by exploiting the GTK shared key and forging its own broadcast packet, attacker is able to redirect private traffic of other victim to its machine and able to provide services. Since attacker is sending a broadcast frames, it means all other Wi-Fi client devices which are also present in that network are going to receive that packet and update its ARC. So attacker is not just victimizing one Wi-Fi user, he's victimizing almost all Wi-Fi user who are in the range of that attacker. Now one can ask what is the difference between this and the old style, conventional style of ARP spoofing attack? Okay, one can, I mean no matter what, I mean no matter if you are using a WPA2 network, I can always use ARP spoofing attack. I can always launch ARP attack to do man in the middle. So in this old style ARP spoofing attack, your packet first goes to access point and after that access point decides and forwards those packets to wired segment of the LAN or wireless segment of the LAN, which means the security systems present on that network wired IDS or IPS or switches are going to see that packet, which means the footprint of the attack is available on the wire and in any wired security systems which are capable of detecting ARP spoofing attack are going to capture that packet and detect this attack. But then when attacker is using this Stealth mode attack, packets are directly sent by one malicious user to other Wi-Fi users in that network. Packets are never going to access point and it is never reaching to wired segment of the LAN. Which means the footprint of attack is limited to the air, which means most of the wired IDS, IPS systems are going will not detect this because packet is not hitting the wired segment of the LAN. So without getting detected, attacker can do man in the middle attack and steal private information of other Wi-Fi users in a WPA2 network. Okay? So this is one example of GTK exploit or whole 196 exploit. I'm going to present here the second exploit and it's all about changing the payload, what kind of payload you are encapsulating in that broadcast frame. So this time attacker is going to use unicast IP payload inside that packet to basically launch IP level targeted attack. So for example, if frame is, at layer to frame is broadcast, but I can always use IP layer, layer three unicast frame inside that. And one example could be port scanning. If I'm going to use a payload, which is used for port scanning, then my packets will actually reach to the victim and victim will respond to that packet. Which means I can do port scanning and I can find out whether that Wi-Fi user is vulnerable or not. Which can further be exploited. So just think what else is possible. I mean if I know that this payload is going to do cause some buffer overflow, then I can inject that packet, right? I can probably, I can also inject malware. So a frame is available in which attacker can inject, in which attacker can encapsulate payload of his choice and cause serious damage to other Wi-Fi users. This is second example of GTK exploit. The third example of GTK exploit is some, is related to the replay detection in WPA2. There is something called replay detection in WPA2. So all encrypted data frames have this, there is a field called packet number, which is a 48 byte number. And this number is going to be present in all encrypted data frames. And this number is used to detect whether a frame is replayed or not. And how that replay detection works. When client connects to access point, access point informs that client that this is the last consumed packet number. So you should use this number for replay detection. So for example last consumed packet number was 700. Client is going to cache that number, save that number. And after that client is expecting data frame having packet number greater than 700. So for example, if I'm replaying packet, which I have captured at the time when packet number was 600. And if I'm replaying that packet, that packet will not be accepted because client will find that the packet number is less than the last successfully received packet, which was 700. When access point sends packet, it will send with 701 because that is part of its traffic stream. It has already sent 700, so next packet will be 701, 702, and so on. So when access point sends packet with 701, client is going to accept that packet. And once the packet is successfully decrypted, client is going to update its locally cached packet number. So now the packet number becomes 701. And that 700 number, one will be used to detect replayed frames. So attacker is going to exploit this replay detection logic. Here what attacker is doing, he's injecting a very large packet number, arbitrarily generated number, because it is a 48 bit number. So let's take this example in which client, the last successfully received packet number was 780. At this point, attacker is injecting a packet because attacker knows the GTK, he can create its broadcast frame, he can put any number of his choice. So he's going to put a number, let's say 9,999, 949s, okay? Client is going to accept that packet because at the time of replay detection check, it finds that packet number is greater than the last successfully received packet number, which was 780. So the client is going to update its locally saved packet number. And the local packet number becomes 9,999. Access point has no idea about this, this change which has happened on the client device. So access point will send broadcast packet as per its own traffic stream. So the last packet which sent by access point was 780. So next time it will send 781, 782, 783 and so on. But let's see what is happening at the client device. Client device finds that the numbers are too less to the locally saved packet number. The last saved packet number was 9,000 and I'm getting 781, which means somebody's replaying packet. So client device is going to drop all the broadcast packet whose packet number is less than its locally cast packet number. Now imagine the implication of this. All Wi-Fi client devices who have successfully received attacker injected high packet number will start dropping all the broadcast packet coming from access point, which means the protocol which works on broadcast packet will not work, right? Two clients will not be able to communicate with each other because they will not be able to resolve ARP. So attacker by exploiting this replay detection logic, he's causing denial of service attack in downlink direction. And which can break few protocols. So this was the third example of exploit of whole 196 or GTK vulnerability. Now I will talk about the POC code that was written to exploit GTK. And I have used two open source software. One is WPA supplicant software and I've used it. There was no modification done, so it was used as it is. And then I have used open source driver, mad Wi-Fi. And the main modification was done in the driver part of the mad Wi-Fi. So before we actually see what kind of modification was done, let me quickly present the .11 frame here. When a client sends a packet to access point, it is called 2DS frame, okay? From client to access point, uplink packet. And when access point sends a packet to client, it is called fromDS packet or it is a kind of downlink packet and there is a field present in the frame which indicates about the direction of frame, whether it's going from client to access point or it is coming from access point to client, okay? But if you notice, there is not much difference between 2DS frame and fromDS frame. If you do a cyclic shift, 2DS frame will become fromDS frame. You move address three to address one, address one to address two and address two to address three it will become fromDS frame, right? And this requires three line of code to do that. And one line of code to change 2DS flag to fromDS flag. So in four line of code, you can actually convert 2DS packet into 4DS packet, fromDS packet. And then you need to select a right key to encrypt that packet because client always use unicast data traffic, so it always use unicast key. So six lines of code were added to choose right key. So it's just about selection in which data structure what kind of keys stored, right? So in just 10 lines of code, it was possible to exploit the GTK vulnerability. So now I will do a demo of man in the middle attack in which GTK vulnerability will be exploited. And after that I will talk about the counter measures. So in this example, the demo that I'm going to do now, I'll be using two Wi-Fi client devices. One client device is going to be the same laptop which I'm using for presentation. And then I have one more laptop here, which is running backtrack. And I'm going to use one of the tools available for launching man in the middle attack. There are a lot of tools available using which one can launch MITM. So for example, these are the tools, very popular tools which are used to launch man in the middle attack. So I'm going to use one of the tools. So the only modification, the only soft code changes that was done was in mad Wi-Fi driver. Everything is available open source. I have set up one access point here and you can see the SSI of that access point is corporate Wi-Fi. And if you go, you will see that this is a WPA2 configured, this is a WPA2 access point. So I'm going to access my attacker machine with the help of BNC software so that you can also see what's going on on the attacker machine. Okay, so my machine is accessible, so we can access this. So this is the backtrack running machine which I'm going to use to launch attack. Okay, perfect. So is this visible to people at the back? Or should I increase the font size? All my stuff is here. And I have two Wi-Fi interfaces running on this laptop. One is running on top of unmodified version of drivers. I will be using it to demonstrate something. And then I have at zero interface which is running on top of a modified version of driver. So let's, so I'm going to use SSL strip software to launch man in the middle attack. Okay, okay. So I'm able to successfully run SSL strip soft tool. Now, the next step is to basically poison the ARP cache of the client, right? And for that, I'll be using the modified version of driver. So, and let's quickly check the, what is the default gateway present on this subnet. So default gateway is running on 172.16.8.1. And if you check the ARP cache entry, you can see the default gateway is running on 8.1 and the MAC address is basically the last two bytes is FE72, okay? And we are going to replace the MAC address, the IP and this MAC binding with the attackers MAC. So, and the Wi-Fi users, the IP address of users to which I'm going to victimize is using IP address 172.16.8.218. So I have used his IP address and this is the MAC address of my machine and this is the IP address of gateway on behalf of which I'm sending this spoofed ARP request packet. Now let's go back and see what is the ARP entry. So if you remember the last ARP entry for gateway was, the MAC address was FE72. Now let's quickly check. And you can see the MAC address of the default gateway has changed. It has become 0AD3, okay? So far everything is working fine. Let's hope SSL history works as per the expectation. So I'm going to open some site. Let's open, let's say, Gmail, oops. Let's try running, sorry, okay. So it looks like I've not be able to successfully run this SSL strip, but I was able to poison the ARP cache entry of a victim. And just to demonstrate that my packets which I'm injecting is not actually flowing on the wire, I'm going to take a packet capture. Here you can see right now I'm sniffing on a wireless interface of my client. And you can see ARP request and responses, frames are being exchanged between my client and the attacker. The attacker was sending request frames and my machine is responding to those requests. Now let me quickly connect a wire. And we will sniff what kind of traffic is flowing on the wire. And here you can see there is no broadcast ARP request packet coming on the wire. The packet which I was injecting, those packets are directly going on the, these are the response which is basically sent by my client devices. So the footprint of attack is available only in the air, it's not available on the wire, okay. But if I, instead of using a modified interface which was running on top of a modified version of driver software, if I run unmodified version, what will happen? So let me quickly, so in fact I have demonstrated that my packets are not actually running, going on the wire. Let me quickly present all basically countermeasure techniques. The real fix is basically fixing this problem in the protocol and for that one can think of duplicating the use of GTK and group address data frame. The other solution is basically using the endpoint security software like SNOT or ARP watch which detects ARP cache, change in the ARP entry, but there is a limitation of this software. It is not available for all kind of Wi-Fi devices. Then one can actually think of using PSPF for client isolation feature. But then this can also break the legitimate communication between legitimate users. For example, if a user wants to share some pictures from laptop to smartphone, that kind of thing will not be possible. And we can probably not use this feature in a voice over Wi-Fi deployment scenario because then two Wi-Fi client devices will not be able to communicate which means this will create a problem. So can we really think of using wireless monitoring system? Since the footprint of attack is available in the air, it is possible to detect that in the air. So Vips can also serve as an additional layer of security to in detecting and protecting from such attacks. So the final conclusion is that all WPA2 networks are exposed to whole 196 and the inter-user privacy that was guaranteed is now broken in WPA2. The real fix is to fix this problem in the protocol. In the meantime, enterprises can think of using PSPF kind of feature, but for endpoint security they can use a SNOT or IPsec, but then you say it is not foolproof in some certain scenario it will not work. So multi-layer of security is required and probably over the air security can be used to detect attacks like whole 196 or any zero day vulnerability. So the final words, be aware, be secure. That's it.