 So, we will begin the presentation with a quick recap of what you will do in ease and then the rest of the session is organized as follows. We will look at some of the fundamentals of multipart and then look into the technical details that are related to the operation of multipart. Specifically, we will kind of see what are the technical details involved in the operation of a multipart and why multipart can evade the present day defenses. Then we will move on to two specific threat scenarios that are caused by multipart and finally we will have a demonstration of multipart threat. So, let us have a quick recap of Evil Twin. So, in case of Evil Twin, basically an attacker sets up an AP that looks similar to a legitimate AP and tries to lure an authorized client to connect to such an AP. So, once the connection happens, the attacker can perform man-in-the-middle attacks and retrieve sensitive information from the client. And as many of us may know, there are various tools that are commonly available on the internet to perform such an attack and example tools include karma, delegate, de-hotspotter and so on. So, this threat is more rampant in hotspots and it can also be present in enterprise and academic environments. So, looking at the picture, what we have is a legitimate AP with XYZ as SSID and we have another AP which is represented in the red color and this is Evil Twin of that AP with the same SSID. Now, the Wi-Fi client which is supposed to connect with a legitimate AP is actually connecting to the Evil Twin AP and through this, the attacker can basically launch man-in-the-middle attacks on this particular client. So, having seen what an Evil Twin is, let us look at what are some of the prevalent countermeasures against Evil Twin. So, level one defense. So, what we are looking at here is see if we can avoid a client to actually connect to the Evil Twin. So, this is a wonderful idea because it eliminates the problem completely. However, let us see to what extent this can be practical. So, we give three examples of how this can potentially be achieved and see what are the limitations of those. The first one is what is known as a watchful user, in which case the user is so knowledgeable and observant that they will never connect with Evil Twin AP. As most of us know here, there is no such thing as a watchful user and obviously this does not work. So, another potential approach is to use some kind of mutual authentication between the client and the AP to make sure that the client is actually connecting to a Genine AP. However, the problem here is this will work only in certain scenarios such as enterprise networks or academic networks where it is known a priori what are the list of APs that are authorized. If you consider the hotspot scenario implementing such a policy, such a mutual authentication may be impractical or close to impossible. Similarly, the third option which is to have a pre-programmed list of legitimate APs, MAC addresses will also not work in hotspot environments because it is hard to know what is the universal set of MAC addresses that correspond to a hotspot vendor, for example, T-Mobile. Hence, this approach, though a very good idea, is not foolproof and not always practical. One more interesting thing to note in this approach is that it requires some kind of a client-side software to basically ensure that the client is not connecting to Evil Twin APs. As we all can expect, the users can manually turn off that software and go ahead and connect with Evil Twin. So, this necessitates a level 2 defense and the level 2 defense we are looking at is what is known as a wireless intrusion prevention system and a wireless intrusion prevention system consists of a set of sensors which scan the wireless medium or air and determine whether certain communication is authorized or not. So, once it determines that certain communication is unauthorized, it can take some preventive measures to make sure that such a communication does not happen. One of the popular techniques used to prevent such unauthorized communication is what is known as over-the-air session containment. So, in this case, the sensors transmit certain packets on the wireless medium to disrupt unauthorized communication and a popular technique used for this is known as deauthentication technique wherein the sensor launches a deauthentication attack to break the communication between the unauthorized client and the AP. So, for example, in this case, once the sensor detects that a client is connecting to Evil Twin AP, it will launch deauthentication attack to disrupt the communication and the good news is that such a communication can be easily disrupted using this technique. So, having seen what is Evil Twin and what is a good countermeasure against it, let us look at Multipot. Multipot is simply multiple APs acting as Evil Twin. So, one can notice that this is a simple extension of Evil Twin. However, as we all know, simple things can also be dangerous. And that is what Multipot is. And in case of Multipots, we have multiple APs with identical SSID and they feed data into a common endpoint. An example of such a common endpoint may be an attacker's laptop and the attacker can use such an AP, such a Multipot to launch man-in-the-mill attacks against authorized clients. So, one of the key things to note in case of Multipot is that the previously discussed deauthentication technique does not work against this. The reason being, once the session containment starts on one of the APs to which the client is associated, the client simply hops to another AP and still continues its communication. So, that is the reason why Multipot is a serious threat. So, looking at the picture, we have an authorized Wi-Fi client that is supposed to connect to a legitimate AP, but it is actually connecting to a Multipot which are indicated by two APs represented by red color and the client is still able to communicate even in presence of session containment of wireless intrusion prevention system. So, this slide is a graphic representation or illustration of what happens in presence of a Multipot and authorized client connecting into it. So, as we see, there is authorized client which is connecting to a Multipot which consists of three APs. So, it is currently connected to one of the APs in the Multipot. However, let us see what happens when a wireless intrusion prevention system launches deauthentication-based session containment on this particular session. As we are seeing, the connection between the client and the first AP in the Multipot got disrupted. However, the client immediately hops to the second AP and is still able to communicate with the attacker. So, this process continues and the end effect is that the client communicates without any major disruption even in presence of session containment of a wireless intrusion prevention system. So, having looked at the fundamentals of Multipot, let us do a threat analysis of Multipot and see some of the technical details behind this. So, one of the things to note is that a WIP sensor has certain finite delay associated in detecting a new association and launching the deauthentication attack. So, there are couple of reasons for this. One is that the sensor needs to operate on several channels to detect any unauthorized communication. As we all know, there are 14 channels, a maximum of 14 channels in the .11G band and similarly there are about 25 channels in the .11A band. Further, to complicate the matters, there are certain proprietary modes such as the atheros turbo mode on which the sensors need to scan to comprehensively determine any unauthorized communication in the environment. So, as a result, the sensor has to spend its time on several channels and the reason for that being most of the sensors that are out there today are built using commodity hardware and such hardware is not capable of transmitting and receiving on several channels simultaneously. As a result, the sensor needs to dwell on each channel for some time and then scan the various channels in some order. For example, it can do that in a round robin order. So, there is always a finite delay associated in determining a new association and taking some counter measures against that and our observations indicate that the delay can be of the order of a second and even up to 10 seconds in some systems. So, having looked at the sensor behavior, let us look at the behavior of a client. So, let us have a quick one-on-one of what happens when a .11 client receives a deauthentication packet. So, after receiving a .11 deauthentication packet, a client basically enters what is known as the Mach level reconnection state. So, in this state, it performs a probe, it enters a probe phase, an authentication phase and an association phase before it can actually transmit the data. So, looking at the picture which explains this in a slightly more detailed way, after receiving a deauthentication packet, the sensor, the client enters a probe phase wherein it visits various channels and tries to compile a list of APs that are available and it uses some logic to determine which AP it needs to connect to and once it does determine the AP, it will actually enter the authentication phase wherein it will go ahead and authenticate with the AP and finally, it binds with that AP through the association phase and then it is ready for further activities such as the data transfer or a higher level authentication which is the case in scenarios such as .11, IR, RSN, security networks. So, the important point to note here is that the Mach connection handshake logic or scheme is not specified in the .11 standard. So, as a result, various vendors implement this logic in their own ways and what we have seen is there is a certain heterogeneity in the way they implement this. What I mean is that some of the clients are really aggressive in reconnecting to a AP whereas some of the clients are not and the next slide is basically presenting some experimental results on what is known as the reassociation latency of a client. So, we define the reassociation latency as the time required for a client to complete its association after it receives a deauthentication packet. So, what we are looking at in this particular picture is that we have plotted the reassociation latencies of four cards. Three of them are different models of the popular Centrino client and one of them is the Cisco 350 client card and we have used a D-Link AP for these measurements and what we have done is written our packet injection tool to launch deauthentication packets and come up with some homegrown scripts to basically do a trace analysis on the timing of reassociation. So, looking at the graph one which represents Centrino 2200 model, we can clearly see that the client reassociates with an AP in less than 100 milliseconds. Although we see some numbers which indicate that it is taking up to 400 milliseconds sometimes but more often than not it is reassociating within 100 milliseconds and the same observation holds true for Centrino 2915 and the more recent 3945 model as well. Similarly, a Cisco 350 series card also reassociates with an AP in the order of 300 to 500 milliseconds. So, what this means is that the clients such as Centrino and Cisco 350 are really aggressive in connecting to an AP and we have frequently observed that Centrino client can reconnect to an AP within 30 milliseconds and that is real quick. So, summarizing the threat analysis we have done so far, the WIP sensor has certain finite delay associated with it in determining a new connection and that is of the order of seconds. However, certain fast clients such as Centrino and Cisco 350 reconnect with an AP and this is of the order of milliseconds. So, obviously what we are looking at in the case of multipart is a scenario wherein the WIP sensor gets trapped into a cat and mouse game with the client and given the about timing disparities it is always the client which is going to win this cat and mouse game. As a result in case of multipart the client's wireless application continues to work with minimal disruption even in presence of a deauthentication based session containment. So, having looked at the reason for the behavior of multipart let us see how prevalent countermeasures perform against it and why they do so. So, as noted earlier deauthentication based session containment is not effective for multiparts due to the fact that the client hops to multiple APs and similarly as we have noted in case of Evil Twin client side software is also not enough because user can simply turn it off and then circumvent the solution. Another popular approach which is used for containing unauthorized wireless communication is what is known as wild side port blocking in which case the intrusion prevention system identifies the port associated with unauthorized wireless communication and then simply turns it off from the wild side. However, it should be noted that this also will not work against a multipart the reason being multipart will not have a controllable switch port associated with that. This is because multipart involves an authorized client connecting to an external AP and we will not have any controllable switch port related to that external AP. Continuing on our countermeasure analysis one might argue that starting session containment on multiple channels concurrently may be a good solution for this. However, our answer is no. The reason being a VIP sensor will have to send the authentication packets at a certain frequency for reliably blocking the communication of multipart. However, as we have just now seen, certain clients reconnect with the APs very quickly and that is of the order of 30 milliseconds in many cases and the sensor will not be able to block the communication on more than two channels concurrently. So, this is also not a good solution and similarly using multiple sensors say n sensors for blocking multipart is also not a good idea. For one, it is not scalable and the second reason being it is relatively easy for an attacker to set up n plus one AP in the multipart and beat the countermeasure. So, what we are presenting now are some packet traces based on our experiments which validate our understanding of a multipart. So, this particular packet trace was collected with a multipart with two APs. One AP on channel 6 and another AP on channel 11 and the client used was a Centrino client and we collected the packet trace using Wireshark utility which is freely available over the internet. Looking at the red arrow at the top right corner, what we can see is that on the channel 6 the sensor is launching the authentication packets and this has prompted the client to move to the AP on channel 11 and it continues its communication on that channel. Although, that is not shown in this particular trace by observing the pink packets of the client we are able to verify that the client indeed is continuing to communicate. After a certain point of time which is about slightly more than two seconds the WIP sensor detects that the client has actually changed the association and moves on to channel 11 to launch the deauthentication attack. That prompts the client to actually come on channel 6 and at this point we are clearly seeing that the pink traffic of the client is continuing. The same procedure can be observed in the red arrow, bottom red arrow indicated in the slide and here we are seeing that the deauthentication packets are again seen on channel 6 which means that the sensor has started launching the deauthentication attack on this channel which has again prompted the client to move to the channel 11 and continue its traffic. So, this slide shows similar data but with HTTP traffic. So, what we are seeing here is that the client is able to continue on its web transfer even in presence of a session containment. So, this particular trace confirms our understanding that on launching a deauthentication attack the client in a multiport scenario hops to multiple APIs. Basically what we are showing here is that a ethereal or a wire shark trace with the appropriate filters applied to show only the association response packets and we can clearly see that the client is continually associating with the APIs in the multiport one after another. So, having seen the reason for multiport behavior let us look at two major threat scenarios in which multiport can cause a security issue. So, the scenario one is what is known as the naturally occurring habitat wherein which can potentially occur in an enterprise or academic institutions. In this case what we are referring to is the presence of multiple APIs with identical SSIDs around the enterprise or an academic institution. So, one important thing to note is that most of the organizations have some policies against their authorized Wi-Fi clients communicating to external APIs or it may be a metro or municipal AP for that matter. The reason is obvious nobody will want their users to communicate with their neighboring APs. So, what we are saying here is that in the presence of multiport such policies may not be implemented by the present day VIPs. So, as a result there can be non-policy compliant communication in such enterprises in presence of multiport. The second threat scenario which we have already referred to is what is known as the handcrafted or a malicious variant of multiport in which case the attacker can deliberately set up a multiport close to a hotspot AP and lure the clients into connecting to such a multiport. And consequently the attacker may be able to launch manning the middle attacks on the client and retrieve any sensitive information such as passwords or credit cards from such an AP. And again as we have discussed earlier the present day inclusion prevention systems will not be able to basically stop this attack. So, let us look at the related work of some of the researchers in this area. So, in the past there have been some conjectures that the wireless inclusion prevention of say VIPs can be evaded in future. Like one specific work in this direction is from George Wright who basically created a paper stating that wireless inclusion prevention techniques in a VIPs are good but they can have two problems. One is that they can be fingerprinted and the second is that there can be some evasive techniques against that. However, he has not mentioned any specific evasive techniques and we believe that this is a first evasive technique which we are presenting currently. And similarly there is some work from DARPA and Department of Homeland Security and the project is called MAP which is an acronym for measure, analyse and protect and this is also aimed at creating defences against future attacks. And even in this case they are not referred to any specific new attacks against VIPs and we believe that this is one of the new attacks. So, having understood some of the details of multiport, what we want to do is we want to show a live demonstration of the multiport. I have my colleague Sohail here and I would like to acknowledge his help and one more colleague Amit's help in this demo. And what we are going to show is that the multiport, author, a client can communicate even in presence of a VIP sensor while it is connecting to a multiport. So, let me give you a brief explanation on the setup of the demo. So, as you can see on the picture, we have an authorized Wi-Fi client. We are using Centrino for this purpose and we have two APs constituting a multiport. So, one of the APs is on channel 3 and another AP is on channel 10 and they have some SSID and the client will be communicating with this multiport APs and what we will notice is that the deauthentication attack launched by a laptop which is acting as a sensor in this case will not be able to stop such communication. So, what we will be seeing in the demo is that the Centrino client will swiftly hop between APs in the multiport in response to the deauthentication session containment. And as a result, the pink traffic which we are using as an illustration will continue to happen even in presence of the session containment. Sorry? It's both ways basically. That is what is leading the client to hop. So, what we are saying is if you have one AP, this is going to work. If you have one AP, this is going to work. But if you have multiple APs, it will go and jump and hop onto the other channel and the communication continues there. See, the problem is as I mentioned earlier, say if the WIP sensor sends deauthentication or dissociate frames on one of the channels, it will hop onto the other channel. So, now if I understand you right, you are suggesting that you send it on all the channels. Right. So, what if you notice, one of the things I also mentioned is that when you send dissociate frames even after it has hop, there is a limit on the number of channels on which you can do it concurrently. As I explained earlier, a sensor will typically not be able to contain a client on more than two channels. So, suppose I mean the approach you are saying will work with two channels, but if you have a third channel, the sensor will not be able to contain that. That is why what we are saying is the deauthentication-based approach has a fundamental limitation in handling such multi-ports. The time difference is right. But what I am saying is basically there is a limit to which you can do it that way because of the fact that deauthentication packets will let the client hop. That is where the problem is. So, you cannot solve it in a generic way. There can be a patch solution to that, but our argument is that there is a fundamental problem in the fact that deauthentication leads a client to hop, and that is not a good thing. So, now let us look at the demo. So, what we can see in the demo is that we are having a Centino client which is pinging one of the APs, which is pinging a laptop which is connected at the back end of both the APs in the multi-port. So, what we are seeing is that the ping communication is actually continuing even in presence of a deauthentication attack. And what we can see in the background is a software called Wi-Fi Hopper which basically gives us, which represents what AP is a client connected to. So, if you can notice the LO bar is the AP, the LO bar is the AP to which the client is currently connected. And as we can clearly see that is blinking, which means that the client is actually getting disconnected temporarily and then it is again reconnecting to the next AP in the multi-port. And what we can also see is that the ping communication is happening with very minimal disruption. So, this ping we have used as just a representative traffic. However, the important point to note is that in presence of multi-port, any communication continues and this is definitely a serious threat for today's Wi-Fi enterprises. So, to conclude the talk, what we have showed is that the multi-port threat will basically create more complications to the already prevalent evil twin threat and the present day countermeasures are completely ineffective against that. Especially the deauthentication based session containment used in most of the WIPs today, they are not sufficient to prevent this threat and hence there needs to be some effort and investigation in this direction to prevent this threat from creating more security issues. So, and this concludes my talk and if you have any questions, I will be happy to answer it now or I can, I will be available in the Q&A room and I will be available till tomorrow. So, thanks a lot for your time and if you have any questions, I can take that up. Yeah, the SSID is Vegas. The SSID is Vegas and there are two APs with, there are two Cisco APs and they have different PSSIDs. So, I am sorry, we could not enlarge it further. Yes, the fact that the LO bar is blinking shows that the client is hopping between two APs and the pain communication still continues. Bye, thanks a lot.