1 00:00:00,000 --> 00:00:08,920 Thank you very much. So, good afternoon and welcome to the IIDS and IoT Intrusion Detection System Talk. 2 00:00:09,620 --> 00:00:16,980 My name is Vivek Ramachandran. My team members Nishant and Ashish were also responsible for a lot of work. 3 00:00:17,620 --> 00:00:21,400 They aren't here, unfortunately, but just so you know. 4 00:00:21,480 --> 00:00:26,400 A little bit about myself. I started as a programmer in the Layer 2 security team. 5 00:00:26,400 --> 00:00:31,220 Wrote a lot of the 802.1X and port security for Cisco's CAT 6K. 6 00:00:31,560 --> 00:00:36,480 Moved on to do security research. Broke web cloaking in DC-15. 7 00:00:36,740 --> 00:00:41,360 This is actually my 10th year here. And discovered a lot of other wireless attacks. 8 00:00:42,440 --> 00:00:48,460 I speak and train at a lot of conferences. I run the Wi-Fi class at Black Hat for the past five years. 9 00:00:49,280 --> 00:00:53,160 I also run Pentester Academy and SecurityTube.net. 10 00:00:54,180 --> 00:00:55,440 Authored a bunch of books. 11 00:00:56,920 --> 00:00:58,700 And for today's talk. 12 00:00:59,420 --> 00:01:02,300 So, why an IoT IDS? 13 00:01:04,040 --> 00:01:07,940 We all know how secure IoT devices are, right? 14 00:01:09,480 --> 00:01:13,980 And when I actually looked at the problem for the last six months, 15 00:01:14,620 --> 00:01:21,860 what I was trying to do is come up with a solution where we could go ahead and monitor IoT devices on the network 16 00:01:21,860 --> 00:01:25,400 and try to see if we can create an intrusion detection. 17 00:01:26,400 --> 00:01:27,400 And then a prevention system. 18 00:01:28,780 --> 00:01:33,660 So, as a lot of people have predicted, an average home will have 10 or more devices. 19 00:01:34,160 --> 00:01:38,280 Of course, you have industrial IoT and enterprise IoT devices as well. 20 00:01:39,140 --> 00:01:45,900 The key challenge in IoT devices is the fact that there is no built-in protection, right? 21 00:01:45,960 --> 00:01:49,760 There is no built-in firewall, no IDS, no AV. 22 00:01:51,260 --> 00:01:55,820 Unfortunately, most of these devices do not even have good logging capabilities. 23 00:01:56,740 --> 00:02:06,080 So, we cannot rely on the device itself to send us any sensible information in order to do any form of threat hunting or intrusion detection. 24 00:02:08,020 --> 00:02:12,300 So, this is where I went ahead and defined the problem scope. 25 00:02:13,040 --> 00:02:15,060 Now, IoT is vast, right? 26 00:02:15,100 --> 00:02:21,880 You have devices communicating over Wi-Fi, Bluetooth, Bluetooth LE, custom frequencies, and whatnot. 27 00:02:22,660 --> 00:02:24,580 What I did find is, 28 00:02:24,580 --> 00:02:33,720 most IoT devices seem to be converging towards Wi-Fi as the backhaul network with 11 AC and extremely high bandwidth. 29 00:02:34,720 --> 00:02:39,980 Additionally, of course, most IoT devices do not send out a lot of data, right? 30 00:02:40,040 --> 00:02:41,100 It's pretty bursty. 31 00:02:41,220 --> 00:02:46,140 There could be sensors and such devices which might not always be communicating. 32 00:02:47,240 --> 00:02:50,720 Now, when I looked at creating an intrusion detection system, 33 00:02:51,320 --> 00:02:54,560 the only option was to take an overload of data, 34 00:02:54,560 --> 00:02:55,540 which is a fairly network approach. 35 00:02:56,080 --> 00:02:57,800 And what I mean by that is, 36 00:02:57,900 --> 00:03:01,920 because we cannot have code running on the IoT devices, 37 00:03:02,560 --> 00:03:06,420 as well as maybe even on the network the devices connect to, 38 00:03:06,700 --> 00:03:12,380 I'd like to monitor the air with different IoT IDS sensors, 39 00:03:13,140 --> 00:03:16,300 gather information of how these devices are communicating, 40 00:03:16,880 --> 00:03:20,460 and see if we can do any form of threat detection. 41 00:03:22,640 --> 00:03:24,940 So, when you look at the architecture, 42 00:03:25,320 --> 00:03:29,020 of course, you can have a single standalone sensor, right? 43 00:03:29,620 --> 00:03:32,840 So, one sensor plugged in, running your code, 44 00:03:33,020 --> 00:03:35,640 trying to figure out if intrusion detection is happening. 45 00:03:36,260 --> 00:03:41,280 The other possibility is more of a spatially distributed sensor network. 46 00:03:41,760 --> 00:03:43,420 So, we distribute them, 47 00:03:43,580 --> 00:03:49,160 they push whatever metadata, packets, or whatever we decide towards a central collector, 48 00:03:49,160 --> 00:03:52,080 and that is where all the intelligence resides. 49 00:03:53,140 --> 00:03:55,940 So, I'm going to talk about both these architectures today. 50 00:03:58,380 --> 00:04:00,720 Probably, if I were to do each and every demo, 51 00:04:00,820 --> 00:04:02,080 I'd take five to six hours. 52 00:04:02,540 --> 00:04:06,420 So, I'm going to do a couple of them in the initial ones at least live. 53 00:04:06,680 --> 00:04:10,000 I have videos, all the source code is open source. 54 00:04:10,280 --> 00:04:11,340 Feel free to download. 55 00:04:11,980 --> 00:04:13,860 If you'd like to see more live demos, 56 00:04:13,980 --> 00:04:15,400 you can even talk to me after the talk. 57 00:04:16,920 --> 00:04:18,540 And, of course, it's DEF CON. 58 00:04:19,160 --> 00:04:21,220 And I wouldn't want to be running a Wi-Fi sensor. 59 00:04:24,360 --> 00:04:25,660 So, IDS sensors. 60 00:04:26,300 --> 00:04:29,920 Now, when you look at securing IoT devices, 61 00:04:30,420 --> 00:04:33,720 the question, of course, is how do you want to build your sensor? 62 00:04:34,220 --> 00:04:37,980 So, I decided to pick up an IoT platform for it. 63 00:04:38,360 --> 00:04:41,020 So, I've chosen the ESP8266. 64 00:04:41,380 --> 00:04:42,120 Anyone's used it? 65 00:04:43,100 --> 00:04:44,300 Okay, two, three people. 66 00:04:46,400 --> 00:04:48,260 The ESP8266 is an SOC. 67 00:04:48,260 --> 00:04:53,720 It has a full Wi-Fi stack in it, capable of BG and N. 68 00:04:53,900 --> 00:04:57,480 It supports web, WPA, WPA2 networks. 69 00:04:57,940 --> 00:05:01,380 I think the latest update even supports WPA2 enterprise. 70 00:05:02,320 --> 00:05:06,380 It's a 32-bit RISC, can run up to 160 megahertz. 71 00:05:07,180 --> 00:05:10,180 In my demos, we're going to be using the 80 megahertz option. 72 00:05:10,420 --> 00:05:12,720 But you can go ahead and run it at 160. 73 00:05:16,080 --> 00:05:17,360 Now, ESP8266, 74 00:05:17,360 --> 00:05:20,500 has been created by this company called Esprit. 75 00:05:21,160 --> 00:05:25,080 And in the early days, their SDK wasn't well documented. 76 00:05:25,780 --> 00:05:28,740 So, unfortunately, a lot of the work which I had to do, 77 00:05:28,820 --> 00:05:31,540 and early for this was probably a year back, 78 00:05:31,760 --> 00:05:35,220 was really just looking at how they programmed a couple of things 79 00:05:35,220 --> 00:05:36,980 and even reverse engineering some components. 80 00:05:37,620 --> 00:05:39,940 Good news, now they have a much better SDK. 81 00:05:40,540 --> 00:05:43,780 So, should be easy for anyone who'd like to extend my code. 82 00:05:46,300 --> 00:05:47,340 The ESP8266, 83 00:05:47,360 --> 00:05:50,120 comes in different shapes and sizes. 84 00:05:51,020 --> 00:05:55,220 The one I'm actually going to be using is the NodeMCU. 85 00:05:56,120 --> 00:05:59,700 The key difference between the regular chip and this, 86 00:06:00,160 --> 00:06:04,220 is this has the chip and a USB to TTL converter. 87 00:06:04,540 --> 00:06:08,180 So, I can just plug it to the USB on my computer and program it, 88 00:06:08,280 --> 00:06:11,860 rather than having to build a circuit just for this purpose. 89 00:06:13,520 --> 00:06:15,520 So, there it is, NodeMCU. 90 00:06:15,520 --> 00:06:22,140 I think this retails for three dollars on AliExpress. 91 00:06:23,460 --> 00:06:25,620 So, three to three and a half dollars. 92 00:06:25,940 --> 00:06:28,360 If you are willing to go a little back and forth 93 00:06:28,360 --> 00:06:30,420 on the chat with some of the vendors, 94 00:06:30,700 --> 00:06:34,040 they can even give it to you for three, for ten pieces. 95 00:06:36,420 --> 00:06:39,260 So, okay, the programming environment. 96 00:06:40,080 --> 00:06:45,200 Now, the ESP8266 has its own SDK, as I mentioned. 97 00:06:45,520 --> 00:06:48,680 But what people have done is they've wrapped around 98 00:06:48,680 --> 00:06:52,820 a lot of that functionality using the Arduino framework. 99 00:06:53,740 --> 00:06:56,420 So, a lot of code which you'll actually see 100 00:06:56,420 --> 00:06:57,920 looks like regular Arduino, 101 00:06:58,520 --> 00:07:03,080 but I have to go ahead and add a lot of SDK specific functionality 102 00:07:03,080 --> 00:07:06,940 and call those functions as and when we need to do things. 103 00:07:07,680 --> 00:07:10,580 The code which I'm going to give out is very well commented, 104 00:07:10,660 --> 00:07:12,940 so hopefully you shouldn't have trouble using it, 105 00:07:12,980 --> 00:07:14,620 but you can always contact me later. 106 00:07:17,080 --> 00:07:21,020 So, what could be the building blocks 107 00:07:21,020 --> 00:07:23,620 of an intrusion detection system over Wi-Fi? 108 00:07:24,120 --> 00:07:27,920 To begin with, of course, you have to have scanning functionality, right? 109 00:07:28,080 --> 00:07:32,360 You plug in your IoT IDS, scans the air, 110 00:07:32,520 --> 00:07:34,920 starts looking at which access points are around, 111 00:07:35,660 --> 00:07:39,700 eventually can start monitoring certain access points of interest, 112 00:07:39,860 --> 00:07:42,380 which is your home AP or your office AP, 113 00:07:42,580 --> 00:07:44,980 and also starts monitoring 114 00:07:45,520 --> 00:07:45,740 which access points are around your clients. 115 00:07:47,560 --> 00:07:52,840 Now, what this means is you have to have some kind of a raw interface 116 00:07:53,430 --> 00:07:55,140 so you can get the packets directly. 117 00:07:56,160 --> 00:07:59,280 How many of you have programmed with raw sockets? 118 00:08:00,480 --> 00:08:02,340 Okay, three people? Okay. 119 00:08:02,660 --> 00:08:06,060 So, we will be using something similar. 120 00:08:06,620 --> 00:08:10,140 There are SDKs do expose some low-level APIs 121 00:08:10,140 --> 00:08:13,040 which function similar to raw sockets. 122 00:08:15,520 --> 00:08:18,000 After that, once we start the monitoring exercise, 123 00:08:19,120 --> 00:08:21,740 then detecting misassociation. 124 00:08:21,840 --> 00:08:23,220 So, what is misassociation? 125 00:08:24,200 --> 00:08:28,460 Let's say I have an authorized client connected to an access point, right? 126 00:08:28,760 --> 00:08:31,260 Now, an attacker creates a honeypot, 127 00:08:31,920 --> 00:08:34,240 and he starts sending deauth packets. 128 00:08:34,640 --> 00:08:38,640 So, the client may get disconnected with the authorized AP 129 00:08:38,640 --> 00:08:41,000 and connect to the attacker's honeypot. 130 00:08:41,480 --> 00:08:44,520 This is one example of a misassociation attack. 131 00:08:44,520 --> 00:08:48,960 So, a wireless IDS ideally should look at this and say, 132 00:08:49,100 --> 00:08:52,600 hey, this authorized client should only be connected 133 00:08:52,600 --> 00:08:54,880 to this authorized AP or set of APs. 134 00:08:55,800 --> 00:08:58,320 Now, when I say AP or set of APs, 135 00:08:58,340 --> 00:09:02,620 we define them using the access points, MAC address, and SSID. 136 00:09:03,960 --> 00:09:08,200 I will also talk about how to detect MAC address spoofing, right? 137 00:09:08,260 --> 00:09:09,380 That's for the very end. 138 00:09:12,120 --> 00:09:13,240 Detecting honeypots. 139 00:09:13,240 --> 00:09:14,560 So, what are honeypots? 140 00:09:14,980 --> 00:09:18,240 Same SSID as that of the authorized access point. 141 00:09:18,880 --> 00:09:20,540 The attacker brings it up. 142 00:09:20,600 --> 00:09:22,520 Authorized clients may try to connect to it. 143 00:09:24,360 --> 00:09:28,160 After that, we look at distributed sensors, central collector. 144 00:09:28,520 --> 00:09:30,840 We'll talk about advanced attack detection. 145 00:09:31,760 --> 00:09:35,060 I'm going to pick up some examples of how to detect evil twins, 146 00:09:35,760 --> 00:09:37,100 MAC address spoofing, 147 00:09:37,140 --> 00:09:39,160 and at the very end, 148 00:09:39,300 --> 00:09:41,280 even how we can use machine learning 149 00:09:41,280 --> 00:09:43,220 to do device fingerprinting. 150 00:09:43,240 --> 00:09:44,260 So, what is device fingerprinting and automatic learning? 151 00:09:47,660 --> 00:09:49,780 Okay, so the Wi-Fi scanner functionality. 152 00:09:53,080 --> 00:09:54,320 So, that is the attacker. 153 00:09:54,440 --> 00:09:55,760 The graphic is custom made. 154 00:09:58,540 --> 00:10:01,020 So, typically, what you want to do is 155 00:10:01,020 --> 00:10:03,440 have the ability to monitor what is happening, right? 156 00:10:03,500 --> 00:10:06,640 That is the only way you can actually pick up 157 00:10:06,640 --> 00:10:08,260 that there is an attacker in the vicinity. 158 00:10:09,220 --> 00:10:09,700 So... 159 00:10:16,460 --> 00:10:16,860 . 160 00:10:20,220 --> 00:10:22,180 I'm sure the code is visible at the end. 161 00:10:23,040 --> 00:10:23,440 . 162 00:10:24,800 --> 00:10:27,480 So, the whole idea is not to make this a coding exercise. 163 00:10:27,980 --> 00:10:30,000 I'm going to give out all the code for free, 164 00:10:30,100 --> 00:10:32,800 completely open source, use as you want. 165 00:10:33,400 --> 00:10:36,640 What I'm going to do is I'm going to run a couple of these snippets, 166 00:10:36,640 --> 00:10:39,900 and for the more complicated examples with APs and clients, 167 00:10:40,180 --> 00:10:41,180 I have videos, 168 00:10:41,180 --> 00:10:43,120 but you can always catch me after the talk. 169 00:10:44,680 --> 00:10:48,200 So, let me go ahead and run this. 170 00:10:48,580 --> 00:10:51,420 I have my ESP8266 connected. 171 00:10:52,520 --> 00:10:55,140 So, this is a simple scanning program. 172 00:10:55,460 --> 00:10:58,160 All it does is it scans Wi-Fi 173 00:10:58,160 --> 00:11:00,500 and figures out the list of APs, 174 00:11:00,500 --> 00:11:02,080 their MAC addresses, the channel, 175 00:11:02,280 --> 00:11:05,220 the RSSI levels, encryption, and all of that. 176 00:11:05,600 --> 00:11:07,980 So, this is one of the core building blocks, 177 00:11:08,120 --> 00:11:10,080 which is the ability to first find 178 00:11:10,080 --> 00:11:13,160 the access point, SSID, BSSID, 179 00:11:13,800 --> 00:11:16,460 you know, of the network you're interested in protecting. 180 00:11:18,850 --> 00:11:21,940 So, once this runs, let's open up the serial monitor. 181 00:11:27,280 --> 00:11:29,880 And if you notice, it says starting to scan, 182 00:11:30,740 --> 00:11:33,360 and it immediately starts scanning all of that. 183 00:11:34,400 --> 00:11:35,700 Why isn't anyone clapping? 184 00:11:36,060 --> 00:11:36,880 This is $3. 185 00:11:37,120 --> 00:11:37,700 . 186 00:11:39,060 --> 00:11:40,400 It's a $3 device. 187 00:11:42,840 --> 00:11:45,040 So, as you can clearly see, 188 00:11:45,860 --> 00:11:49,260 it has a reasonably robust implementation 189 00:11:49,260 --> 00:11:51,520 of the low-level Wi-Fi scanning stack. 190 00:11:52,080 --> 00:11:54,420 Some of the SDK is open source. 191 00:11:54,700 --> 00:11:57,560 I've been a C programmer for over 16 years. 192 00:11:58,260 --> 00:12:00,260 I think it's pretty high-quality code, 193 00:12:00,320 --> 00:12:01,200 from what I've seen. 194 00:12:02,500 --> 00:12:04,700 So, this is how we go ahead, 195 00:12:04,820 --> 00:12:06,160 implement a simple scanner 196 00:12:06,160 --> 00:12:09,560 on this three, $3.5 chip, 197 00:12:09,820 --> 00:12:11,600 so that you can look at what is around. 198 00:12:17,860 --> 00:12:18,380 Okay. 199 00:12:19,180 --> 00:12:21,000 Monitoring access points and clients. 200 00:12:23,560 --> 00:12:27,080 Now, scanning is actually generally quite easy. 201 00:12:27,140 --> 00:12:27,360 Why? 202 00:12:27,660 --> 00:12:30,340 Every operating system has low-level APIs 203 00:12:30,340 --> 00:12:32,720 with which you can query the card, 204 00:12:32,820 --> 00:12:34,180 talk to the card, have it scan. 205 00:12:34,660 --> 00:12:36,140 But when you talk about scanning, 206 00:12:36,140 --> 00:12:36,640 when you talk about monitoring, 207 00:12:36,900 --> 00:12:39,960 this is really where it kind of becomes 208 00:12:39,960 --> 00:12:42,980 very, very architecture and system-specific. 209 00:12:43,480 --> 00:12:45,980 So, you have to figure out how to sniff packets 210 00:12:45,980 --> 00:12:47,160 using this device. 211 00:12:48,300 --> 00:12:49,780 Now, the good news is 212 00:12:49,780 --> 00:12:52,360 that they did provide some low-level APIs. 213 00:12:57,200 --> 00:12:59,080 All of this code is going to be available. 214 00:12:59,940 --> 00:13:01,620 I wrote part of this code, 215 00:13:01,700 --> 00:13:03,080 which we released at Black Hat, 216 00:13:03,080 --> 00:13:05,240 Singapore, called YD. 217 00:13:05,960 --> 00:13:08,520 But typically, what I'm doing here is 218 00:13:09,080 --> 00:13:11,940 going ahead, getting the packet in promiscuous mode, 219 00:13:12,140 --> 00:13:14,360 and parsing that to look at 220 00:13:14,360 --> 00:13:16,520 if this is a management packet, data control. 221 00:13:17,080 --> 00:13:20,000 Based on that, what I really do is create these flows. 222 00:13:20,780 --> 00:13:23,340 So, a flow could be an access point 223 00:13:23,340 --> 00:13:24,440 and connected clients. 224 00:13:25,260 --> 00:13:26,780 That's an example of a flow. 225 00:13:27,200 --> 00:13:31,260 So, what you ideally want is an authorized API 226 00:13:31,260 --> 00:13:33,060 should only talk to authorized clients. 227 00:13:33,080 --> 00:13:33,720 Right? 228 00:13:35,580 --> 00:13:38,120 Of course, you will have to have the admin 229 00:13:38,120 --> 00:13:39,660 give the list of authorized clients. 230 00:13:40,640 --> 00:13:42,640 We'll talk about some machine learning techniques 231 00:13:42,640 --> 00:13:45,160 with which you can auto-detect some of those as well, 232 00:13:45,640 --> 00:13:47,000 but I'll save it for the end. 233 00:13:49,180 --> 00:13:52,940 So, I'm not going to go ahead and run this code. 234 00:13:53,040 --> 00:13:57,480 Let me just go ahead, show you a quick demo. 235 00:14:07,180 --> 00:14:11,140 So, what this code does is low-level sniffing, 236 00:14:11,200 --> 00:14:13,380 gets the packet, parses it, 237 00:14:13,500 --> 00:14:16,360 and now starts looking at what APs are there 238 00:14:16,360 --> 00:14:17,580 and what clients are connected. 239 00:14:18,040 --> 00:14:20,640 This code is specific to AP enumeration. 240 00:14:24,420 --> 00:14:27,300 All of this code is available after the talk. 241 00:14:28,900 --> 00:14:32,200 So, right now, we are enumerating the access point. 242 00:14:32,200 --> 00:14:35,300 The key difference is this is using 243 00:14:35,300 --> 00:14:38,000 absolute low-level raw sockets, right? 244 00:14:38,140 --> 00:14:40,820 So, people who haven't programmed with raw sockets, 245 00:14:40,980 --> 00:14:44,280 this is like trying to reimplement what TCP dump 246 00:14:44,280 --> 00:14:46,260 or some of those APIs do, right? 247 00:14:46,420 --> 00:14:48,400 LibPCAP, trying to implement that. 248 00:14:51,100 --> 00:14:52,300 That's supposed to be me. 249 00:14:57,000 --> 00:14:59,600 So, we've looked at the monitoring APs. 250 00:14:59,640 --> 00:15:01,280 Let's look at the monitoring clients. 251 00:15:09,220 --> 00:15:13,720 So, what we have here is the leftmost column 252 00:15:13,720 --> 00:15:17,120 is the MAC address of the client. 253 00:15:17,540 --> 00:15:20,200 The column after that is the SSID 254 00:15:20,200 --> 00:15:22,400 that client is connected to. 255 00:15:23,060 --> 00:15:27,240 And then, of course, you have the BSSID in some cases. 256 00:15:27,260 --> 00:15:28,900 Is it probing? Is it connected? 257 00:15:29,120 --> 00:15:30,200 Have you seen data packets? 258 00:15:31,480 --> 00:15:35,680 So, think of basically this as a state machine. 259 00:15:36,440 --> 00:15:38,980 So, if we actually see a client probing, 260 00:15:39,000 --> 00:15:40,780 we say, hey, this is in probing state. 261 00:15:41,420 --> 00:15:44,060 Once we end up seeing it send a couple of data packets, 262 00:15:44,280 --> 00:15:46,320 we know it's in connected state, right? 263 00:15:46,640 --> 00:15:49,120 So, you have different client and APs 264 00:15:49,120 --> 00:15:51,680 moving through these multiple state machines 265 00:15:52,060 --> 00:15:52,920 at the same time. 266 00:15:53,660 --> 00:15:57,000 And what you'd ideally want to do is find anomalies in this. 267 00:15:57,820 --> 00:15:59,400 So, as you can clearly see, 268 00:16:01,060 --> 00:16:03,460 total number of clients detected is three. 269 00:16:03,620 --> 00:16:05,120 These are the MAC addresses. 270 00:16:06,140 --> 00:16:08,560 This is the SSID they are probing for. 271 00:16:08,920 --> 00:16:12,100 And two of them are actually in probing state. 272 00:16:12,260 --> 00:16:14,080 They haven't yet connected. 273 00:16:16,440 --> 00:16:18,840 The video actually looks pretty good on my screen, 274 00:16:19,000 --> 00:16:21,080 but I apologize the way it looks here. 275 00:16:21,260 --> 00:16:23,260 So, you'll have it after the talk. 276 00:16:25,040 --> 00:16:26,940 One of the clients, the third one, 277 00:16:27,020 --> 00:16:28,800 is actually connected to the AP 278 00:16:28,800 --> 00:16:31,360 because we can see the AP's MAC address, right? 279 00:16:31,500 --> 00:16:34,800 So, this shows there have been data packets exchanged. 280 00:16:38,840 --> 00:16:42,960 So, let's step back and summarize what we've done so far. 281 00:16:43,500 --> 00:16:46,080 We have used the ESP8266. 282 00:16:46,590 --> 00:16:48,000 We've put it in monitor mode. 283 00:16:48,180 --> 00:16:49,700 We are sniffing packets. 284 00:16:50,140 --> 00:16:52,880 We are figuring out which access points exist, 285 00:16:53,000 --> 00:16:53,980 which clients exist, 286 00:16:54,360 --> 00:16:57,120 which clients are talking to which APs. 287 00:16:57,120 --> 00:16:58,540 And when I say talking, 288 00:16:58,680 --> 00:16:59,960 that could mean probe requests, 289 00:17:00,240 --> 00:17:02,220 trying to just figure out, you know, 290 00:17:02,240 --> 00:17:03,700 what capabilities the AP has 291 00:17:03,700 --> 00:17:05,880 or actual data packets, 292 00:17:06,080 --> 00:17:07,640 which means both the client and AP 293 00:17:07,640 --> 00:17:08,640 are already connected 294 00:17:08,640 --> 00:17:11,200 and exchanging information, right? 295 00:17:11,560 --> 00:17:14,860 So, that is what we've accomplished so far. 296 00:17:16,180 --> 00:17:18,460 Now, in order to go ahead 297 00:17:18,460 --> 00:17:20,880 and convert this into an IDS, 298 00:17:21,040 --> 00:17:24,600 we will require a little bit of more information. 299 00:17:24,760 --> 00:17:26,280 And that information is, 300 00:17:26,280 --> 00:17:31,080 the list of BSSIDs of APs which are authorized 301 00:17:31,080 --> 00:17:33,400 and the list of MAC addresses 302 00:17:33,400 --> 00:17:35,220 of the clients which are authorized, right? 303 00:17:35,640 --> 00:17:38,340 You could use some interesting learning techniques. 304 00:17:38,380 --> 00:17:40,440 As I said, I'll talk about that at the very end 305 00:17:40,440 --> 00:17:42,720 so that you can try to auto learn, 306 00:17:43,680 --> 00:17:45,900 assuming, of course, you don't have an attack underway. 307 00:17:48,960 --> 00:17:50,700 So, let's actually move forward. 308 00:17:52,440 --> 00:17:55,100 Detecting misassociation attacks and detecting honeypots. 309 00:18:08,220 --> 00:18:10,120 I'm going to increase the font size a bit. 310 00:18:15,260 --> 00:18:16,700 Is this a little bit more visible? 311 00:18:17,000 --> 00:18:17,240 Okay. 312 00:18:17,240 --> 00:18:17,320 Okay. 313 00:18:24,680 --> 00:18:26,480 I'm going to take you... 314 00:18:29,000 --> 00:18:31,040 So, what we've done is 315 00:18:31,880 --> 00:18:34,560 we've gone ahead and commented every part of the code 316 00:18:34,560 --> 00:18:37,080 so later on you can just add whatever MAC address 317 00:18:37,080 --> 00:18:38,640 belongs to your network, right? 318 00:18:40,320 --> 00:18:44,180 You can add a BSSID or a set of BSSIDs 319 00:18:44,180 --> 00:18:47,420 and that's basically the BSSID 320 00:18:47,420 --> 00:18:49,540 of the access point serving our network. 321 00:18:50,480 --> 00:18:51,900 The clients over here, 322 00:18:51,980 --> 00:18:54,200 which is client one, two, and three, 323 00:18:55,640 --> 00:18:58,120 these are supposed to be the authorized clients. 324 00:18:58,360 --> 00:18:59,680 Again, you can fill these up. 325 00:19:00,000 --> 00:19:02,100 You don't need to have only three clients. 326 00:19:02,200 --> 00:19:02,980 You can have a hundred. 327 00:19:03,580 --> 00:19:04,980 Whatever count you have, 328 00:19:05,060 --> 00:19:06,780 just make sure that you're going to change it. 329 00:19:07,880 --> 00:19:11,400 I'm also documenting the code on how to use it. 330 00:19:11,460 --> 00:19:12,960 Hopefully, you should have that next week 331 00:19:12,960 --> 00:19:14,020 so you know where to change what. 332 00:19:15,300 --> 00:19:17,380 So, what we do now 333 00:19:17,380 --> 00:19:20,080 is we use all of that state machine 334 00:19:20,080 --> 00:19:21,080 which we created 335 00:19:21,080 --> 00:19:23,820 by monitoring the APs and the clients 336 00:19:23,820 --> 00:19:26,320 and now we combine that 337 00:19:26,320 --> 00:19:28,460 with this additional knowledge 338 00:19:28,460 --> 00:19:31,920 of first, which AP are we interested in? 339 00:19:32,320 --> 00:19:33,820 Because as you can imagine, 340 00:19:33,880 --> 00:19:35,340 if you're just monitoring the air, 341 00:19:35,460 --> 00:19:38,100 you're probably seeing dozens of access points 342 00:19:38,100 --> 00:19:41,740 and you really don't want to spend a lot of time 343 00:19:41,740 --> 00:19:43,180 monitoring everything. 344 00:19:43,180 --> 00:19:45,700 At the very same time, 345 00:19:45,720 --> 00:19:47,000 this only has one radio. 346 00:19:47,620 --> 00:19:49,960 So, you probably want to go ahead, 347 00:19:50,160 --> 00:19:52,920 scan, figure out the AP of interest, 348 00:19:53,080 --> 00:19:54,360 which is your authorized AP, 349 00:19:54,580 --> 00:19:56,360 change the card's channel, 350 00:19:56,620 --> 00:19:57,980 go to that channel, 351 00:19:58,140 --> 00:20:01,400 and just monitor that access point's MAC address. 352 00:20:01,900 --> 00:20:04,020 This is exactly what the code does. 353 00:20:04,780 --> 00:20:06,240 So, it'll scan 354 00:20:07,680 --> 00:20:11,060 and find MAC addresses of all the APs around. 355 00:20:11,220 --> 00:20:13,160 The moment it sees that MAC address, 356 00:20:13,180 --> 00:20:14,940 and matching with that in the config file, 357 00:20:15,180 --> 00:20:17,320 it'll automatically change its channel, 358 00:20:17,460 --> 00:20:19,320 put itself on that network. 359 00:20:20,380 --> 00:20:22,720 One of the things which I've also added 360 00:20:23,540 --> 00:20:26,400 is let's say the AP automatically changes channel. 361 00:20:27,160 --> 00:20:30,000 So, if this does not find that AP there, 362 00:20:30,260 --> 00:20:32,740 it'll automatically go back into scanning mode. 363 00:20:33,980 --> 00:20:36,720 So, a little bit more intelligence built into it. 364 00:20:37,160 --> 00:20:38,500 This is really important 365 00:20:38,500 --> 00:20:40,360 because you have a lot of access points 366 00:20:40,360 --> 00:20:43,080 which do automatic channels 367 00:20:43,080 --> 00:20:43,340 that are channel hopping 368 00:20:43,340 --> 00:20:45,760 based on the interference in the channels 369 00:20:45,760 --> 00:20:46,860 where they are in, right? 370 00:20:47,780 --> 00:20:49,560 So, once we do that, 371 00:20:49,660 --> 00:20:51,540 we know this is the authorized AP. 372 00:20:52,040 --> 00:20:55,080 We immediately start just monitoring packets 373 00:20:55,080 --> 00:20:56,420 from that access point. 374 00:20:57,020 --> 00:20:59,420 And then we create these flow graphs 375 00:20:59,420 --> 00:21:00,320 which I talked about. 376 00:21:00,620 --> 00:21:02,500 These are just internal data structures. 377 00:21:04,260 --> 00:21:05,520 At that point, 378 00:21:05,660 --> 00:21:07,720 what we really have is 379 00:21:07,720 --> 00:21:09,640 what we see on the network, 380 00:21:09,760 --> 00:21:10,820 which is one whole tree, 381 00:21:10,820 --> 00:21:12,840 versus what is allowed, 382 00:21:13,020 --> 00:21:14,340 or the whitelist, right? 383 00:21:14,400 --> 00:21:15,220 Which is a separate tree. 384 00:21:15,780 --> 00:21:18,660 Any time there is any mismatch, 385 00:21:18,680 --> 00:21:20,120 we automatically go ahead 386 00:21:20,560 --> 00:21:22,500 and send out an alert saying, 387 00:21:22,700 --> 00:21:24,460 hey, this client or this AP 388 00:21:24,460 --> 00:21:27,520 is probably malicious, right? 389 00:21:27,680 --> 00:21:29,520 AP malicious is honeypot, 390 00:21:29,680 --> 00:21:31,960 which is trying to broadcast the same network. 391 00:21:32,400 --> 00:21:34,720 Client malicious really is 392 00:21:34,720 --> 00:21:38,080 an external client not on the authorized list 393 00:21:38,080 --> 00:21:39,940 trying to connect to the authorized AP. 394 00:21:39,940 --> 00:21:42,980 And misassociation is an authorized AP 395 00:21:42,980 --> 00:21:45,240 trying to connect to an external AP, right? 396 00:21:46,620 --> 00:21:47,960 So, let me show you 397 00:21:47,960 --> 00:21:49,560 how this looks like when we run it. 398 00:22:10,920 --> 00:22:11,460 OK. 399 00:22:11,680 --> 00:22:14,180 So, now the code is running. 400 00:22:20,060 --> 00:22:22,100 And what we automatically do, 401 00:22:22,200 --> 00:22:23,600 of course, we want to show attacks. 402 00:22:24,000 --> 00:22:25,920 So, these are different clients 403 00:22:25,920 --> 00:22:28,460 trying to connect to our authorized AP. 404 00:22:29,300 --> 00:22:31,680 So, what IIDS does is 405 00:22:31,680 --> 00:22:33,880 any time a client sends a probe request 406 00:22:33,880 --> 00:22:34,900 or a data packet, 407 00:22:35,160 --> 00:22:36,160 or for that matter, 408 00:22:36,240 --> 00:22:38,020 any management or control packet, 409 00:22:38,180 --> 00:22:39,440 management or data packet, 410 00:22:39,440 --> 00:22:41,600 it automatically figures out 411 00:22:41,600 --> 00:22:43,180 that this MAC address 412 00:22:43,180 --> 00:22:45,840 doesn't belong to the list of authorized MACs 413 00:22:45,840 --> 00:22:47,160 and starts flagging it. 414 00:22:47,580 --> 00:22:50,760 We also have a backend MQTT integration. 415 00:22:51,380 --> 00:22:53,880 So, the radio once in a while 416 00:22:53,880 --> 00:22:55,300 can go into client mode, 417 00:22:55,420 --> 00:22:57,620 connect to a backend access point, 418 00:22:57,840 --> 00:22:59,620 and send you an MQTT message. 419 00:22:59,960 --> 00:23:01,000 Anyone MQTT? 420 00:23:02,540 --> 00:23:03,220 OK. 421 00:23:04,240 --> 00:23:05,340 It's basically short, 422 00:23:05,400 --> 00:23:07,040 bursty messaging for IoT devices. 423 00:23:07,220 --> 00:23:08,120 Extremely popular. 424 00:23:08,120 --> 00:23:10,420 Some people like to call it 425 00:23:10,420 --> 00:23:11,660 Twitter for IoT devices. 426 00:23:12,300 --> 00:23:13,960 And some people hate calling that. 427 00:23:14,100 --> 00:23:15,400 So, either way. 428 00:23:16,280 --> 00:23:17,860 So, it's a very flexible, 429 00:23:17,920 --> 00:23:18,760 simple protocol 430 00:23:18,760 --> 00:23:21,080 where you can just put a message inside 431 00:23:21,080 --> 00:23:22,520 and off it goes. 432 00:23:23,200 --> 00:23:24,400 The good news is 433 00:23:24,400 --> 00:23:26,140 if you have an MQTT server, 434 00:23:26,400 --> 00:23:29,500 you can even have client apps on your phone 435 00:23:29,500 --> 00:23:31,340 and you can automatically get alerts. 436 00:23:32,220 --> 00:23:34,260 So, you don't even have to do 437 00:23:34,260 --> 00:23:35,720 all of that alerting mechanism 438 00:23:35,720 --> 00:23:37,000 and workflow on your own. 439 00:23:37,000 --> 00:23:39,540 It's kind of built into most apps nowadays. 440 00:23:46,040 --> 00:23:49,660 So, in this example, 441 00:23:49,720 --> 00:23:50,920 we have multiple clients. 442 00:23:51,840 --> 00:23:52,720 If you notice, 443 00:23:52,800 --> 00:23:55,140 now we have one that says misassociating 444 00:23:55,140 --> 00:23:57,980 and the others which says intruding, right? 445 00:23:58,340 --> 00:23:59,680 I explained the difference. 446 00:24:00,220 --> 00:24:02,660 Misassociation is an authorized client 447 00:24:02,660 --> 00:24:04,800 trying to connect out to an external AP. 448 00:24:05,000 --> 00:24:06,380 This could be a honeypot. 449 00:24:06,380 --> 00:24:09,100 While intruding 450 00:24:09,100 --> 00:24:11,700 is an external unauthorized client 451 00:24:12,100 --> 00:24:14,220 trying to connect to one of our authorized APs. 452 00:24:24,080 --> 00:24:24,400 Okay. 453 00:24:25,160 --> 00:24:26,320 Another custom graphic. 454 00:24:27,520 --> 00:24:28,160 Right? 455 00:24:28,240 --> 00:24:29,940 Honeypots and misassociation. 456 00:24:32,420 --> 00:24:33,060 Okay. 457 00:24:34,040 --> 00:24:36,200 So, building a distributed sensor 458 00:24:36,380 --> 00:24:36,680 collector. 459 00:24:38,100 --> 00:24:39,660 Now, when you talk about 460 00:24:39,660 --> 00:24:41,860 any form of distributed sensor architecture, 461 00:24:42,320 --> 00:24:44,260 the key question is 462 00:24:44,260 --> 00:24:46,500 how much processing you'd like to do 463 00:24:46,500 --> 00:24:47,220 on the sensor 464 00:24:47,220 --> 00:24:50,300 and how much would you like to ideally offload 465 00:24:50,300 --> 00:24:52,400 onto the central collector, right? 466 00:24:54,660 --> 00:24:56,080 And this is really where 467 00:24:56,080 --> 00:24:57,360 this is a $3 device. 468 00:24:58,200 --> 00:25:00,080 I mean, you cannot expect 469 00:25:00,880 --> 00:25:01,900 this device 470 00:25:01,900 --> 00:25:04,640 to be able to do a lot of heavy duty 471 00:25:04,640 --> 00:25:06,300 number crunching, 472 00:25:06,300 --> 00:25:07,760 metadata and statistics collection. 473 00:25:08,220 --> 00:25:10,920 So, what I actually did was 474 00:25:10,920 --> 00:25:13,200 the device scans the air, 475 00:25:13,380 --> 00:25:15,500 figures out a lot of this metadata, 476 00:25:15,880 --> 00:25:18,480 immediately flips over to client mode, 477 00:25:19,060 --> 00:25:21,080 connects back to our backhaul network, 478 00:25:21,460 --> 00:25:23,620 and actually sends all of that metadata 479 00:25:24,300 --> 00:25:25,340 to a remote server. 480 00:25:26,260 --> 00:25:27,540 In this case, 481 00:25:27,700 --> 00:25:29,160 I've actually sent the whole packet. 482 00:25:30,000 --> 00:25:32,700 You can, of course, do a much more reduced, 483 00:25:33,300 --> 00:25:34,360 you know, kind of size, 484 00:25:34,360 --> 00:25:36,160 which is you can have certain header fields, 485 00:25:36,480 --> 00:25:38,600 depending on whatever your algorithms 486 00:25:38,600 --> 00:25:39,940 would probably like to use 487 00:25:39,940 --> 00:25:41,200 for threat detection, right? 488 00:25:44,680 --> 00:25:47,500 So, once I receive the PCAP files, 489 00:25:48,940 --> 00:25:51,100 I end up using a tool 490 00:25:52,640 --> 00:25:54,620 which I had written two years back 491 00:25:54,620 --> 00:25:55,960 and released at DEF CON, 492 00:25:56,160 --> 00:25:58,500 which is PCAP to XML and SQLite. 493 00:25:59,140 --> 00:26:00,380 So, what this does is 494 00:26:00,380 --> 00:26:01,840 this takes PCAP files 495 00:26:02,720 --> 00:26:04,340 and looks at everything 496 00:26:04,360 --> 00:26:05,420 in every single header field 497 00:26:05,420 --> 00:26:07,760 and maps that to a column 498 00:26:07,760 --> 00:26:08,860 in a SQLite database. 499 00:26:10,120 --> 00:26:13,200 So, now you can actually run arbitrary queries 500 00:26:13,200 --> 00:26:15,660 on any header field. 501 00:26:15,900 --> 00:26:17,780 And this is extremely useful 502 00:26:18,180 --> 00:26:20,520 when you want to create an IDS on a budget. 503 00:26:24,680 --> 00:26:28,380 So, some attacks which we can detect very easily, 504 00:26:29,440 --> 00:26:30,760 deauthentication floods anyone? 505 00:26:31,040 --> 00:26:32,240 Wi-Fi deauth floods? 506 00:26:33,340 --> 00:26:33,980 Okay. 507 00:26:34,360 --> 00:26:35,400 So, deauthentication packets 508 00:26:35,400 --> 00:26:36,280 are really packets 509 00:26:36,280 --> 00:26:38,660 which are meant to disrupt a connection, 510 00:26:38,940 --> 00:26:39,780 terminate a connection 511 00:26:39,780 --> 00:26:41,740 between any two devices. 512 00:26:42,820 --> 00:26:44,640 It's a very common way 513 00:26:44,640 --> 00:26:47,420 by which denial of service attack happens, right? 514 00:26:47,520 --> 00:26:49,080 It's also a common way 515 00:26:49,080 --> 00:26:52,340 by which attackers have authorized clients 516 00:26:52,340 --> 00:26:54,160 disconnected from the real AP 517 00:26:54,160 --> 00:26:57,000 and then have them hop over to their honeypots. 518 00:26:58,200 --> 00:27:00,240 So, generally, deauth attacks 519 00:27:00,240 --> 00:27:01,860 are very bursty in nature. 520 00:27:02,020 --> 00:27:03,760 The attacker is going to be sending 521 00:27:03,760 --> 00:27:05,680 a couple of hundred packets a second. 522 00:27:06,160 --> 00:27:08,500 Probably slower speeds will do as well, 523 00:27:08,680 --> 00:27:11,520 but most people just rely on ready-made tools. 524 00:27:15,180 --> 00:27:16,940 So, what we do 525 00:27:17,620 --> 00:27:19,400 is we try to figure out 526 00:27:19,400 --> 00:27:21,180 the number of deauth packets. 527 00:27:21,380 --> 00:27:23,380 We figure out the different timestamps 528 00:27:23,380 --> 00:27:24,300 at which they have arrived. 529 00:27:25,140 --> 00:27:27,540 Now, keep in mind that this is interesting 530 00:27:27,540 --> 00:27:29,900 because eventually you also want to do 531 00:27:29,900 --> 00:27:32,740 both time-based and spatial correlation. 532 00:27:33,200 --> 00:27:33,640 Right? 533 00:27:35,480 --> 00:27:37,120 Let's say you deploy this sensor 534 00:27:37,120 --> 00:27:38,560 around your enterprise 535 00:27:38,560 --> 00:27:41,140 and the attacker is actually driving 536 00:27:41,680 --> 00:27:42,900 around in the parking lot 537 00:27:42,900 --> 00:27:44,600 trying to attack or trying to do something. 538 00:27:44,960 --> 00:27:47,860 So, you will be able to spatially correlate that 539 00:27:47,860 --> 00:27:50,240 if you preserve a lot of that information, 540 00:27:50,580 --> 00:27:52,200 which is really what I was trying to do. 541 00:27:54,860 --> 00:27:55,460 Excuse me. 542 00:27:56,940 --> 00:27:59,020 After that, of course, you can run Python. 543 00:27:59,160 --> 00:28:00,740 You can pretty much do a lot of things. 544 00:28:00,820 --> 00:28:01,660 I prefer Python. 545 00:28:01,660 --> 00:28:03,440 It's pretty simple to use. 546 00:28:03,600 --> 00:28:06,560 All of this code is available along with the talk slides, 547 00:28:06,760 --> 00:28:07,940 so you can try it yourself. 548 00:28:08,540 --> 00:28:10,800 What we really try to do here 549 00:28:10,800 --> 00:28:13,360 is for every single device, 550 00:28:13,480 --> 00:28:16,440 we start seeing how many deauth packets 551 00:28:16,440 --> 00:28:19,300 it is either sending or receiving over time. 552 00:28:20,100 --> 00:28:22,800 And we have time thresholds. 553 00:28:23,100 --> 00:28:26,660 Based on that, if you see more than n number 554 00:28:26,660 --> 00:28:29,220 in a specific time slot, 555 00:28:29,540 --> 00:28:31,620 we actually say that's a deauth attack. 556 00:28:31,660 --> 00:28:33,980 Now, what is that threshold? 557 00:28:35,200 --> 00:28:37,740 The truth is the thresholds actually change 558 00:28:37,740 --> 00:28:39,420 based on the network a lot of times. 559 00:28:40,120 --> 00:28:41,980 And this is really at the very end 560 00:28:41,980 --> 00:28:43,280 I'll talk about machine learning, 561 00:28:43,460 --> 00:28:45,500 so maybe you can even try to decide 562 00:28:45,500 --> 00:28:47,880 or learn baselines on your own. 563 00:28:48,320 --> 00:28:51,480 My home network might hardly see any deauths, 564 00:28:51,480 --> 00:28:54,300 but a larger enterprise network might see 565 00:28:54,300 --> 00:28:57,360 genuine deauth packets getting sent a lot. 566 00:28:58,360 --> 00:29:00,480 So, baselining, just like any other 567 00:29:00,480 --> 00:29:01,600 intrusion detection system, 568 00:29:01,660 --> 00:29:03,540 is a hard thing to get right. 569 00:29:04,220 --> 00:29:05,480 The best way, of course, 570 00:29:05,580 --> 00:29:07,060 is you really know your network well. 571 00:29:07,920 --> 00:29:09,420 Alternately, at the very end, 572 00:29:09,440 --> 00:29:10,320 we'll talk about ML. 573 00:29:12,800 --> 00:29:14,980 So, detecting different attacks, 574 00:29:15,460 --> 00:29:17,560 deauth flood, evil twins. 575 00:29:19,520 --> 00:29:20,860 Anyone, what is an evil twin? 576 00:29:25,300 --> 00:29:27,680 I'm going to give out like a free ESP8266. 577 00:29:27,800 --> 00:29:28,260 Evil twin? 578 00:29:30,680 --> 00:29:31,260 Go ahead. 579 00:29:33,160 --> 00:29:33,580 . 580 00:29:42,200 --> 00:29:42,620 . 581 00:29:45,320 --> 00:29:45,740 . 582 00:29:45,740 --> 00:29:45,760 . 583 00:29:45,760 --> 00:29:45,780 . 584 00:29:45,780 --> 00:29:45,800 . 585 00:29:45,800 --> 00:29:45,840 . 586 00:29:45,840 --> 00:29:45,900 . 587 00:29:45,900 --> 00:29:46,280 . 588 00:29:46,280 --> 00:29:46,340 . 589 00:29:46,800 --> 00:29:47,220 . 590 00:29:47,220 --> 00:29:47,260 . 591 00:29:51,680 --> 00:29:52,100 . 592 00:29:52,100 --> 00:29:52,460 . 593 00:29:52,460 --> 00:29:54,100 might even have the same MAC address 594 00:29:54,100 --> 00:29:56,360 as the authorized AP, but on a different channel. 595 00:29:56,640 --> 00:29:57,200 Here you go. 596 00:29:59,020 --> 00:29:59,500 Clap. 597 00:30:05,620 --> 00:30:07,560 Yeah, so what is an evil twin? 598 00:30:07,920 --> 00:30:11,020 Evil twin is, let's say we have an authorized access point, 599 00:30:11,580 --> 00:30:13,920 and now an attacker wants to create an AP 600 00:30:13,920 --> 00:30:15,200 with the same SSID, 601 00:30:15,700 --> 00:30:17,900 a lot of times even with the same BSSID. 602 00:30:18,320 --> 00:30:20,060 The reason to kind of do that 603 00:30:20,060 --> 00:30:22,160 and also mimic all the security parameters 604 00:30:22,160 --> 00:30:26,180 is the attacker would ideally want to de-auth the client, 605 00:30:26,300 --> 00:30:29,360 the authorized client, from the real AP 606 00:30:29,360 --> 00:30:31,300 and have that client hop over 607 00:30:31,300 --> 00:30:34,500 to the attacker's evil twin or honeypot. 608 00:30:35,220 --> 00:30:36,860 It's a very common attack, 609 00:30:37,120 --> 00:30:40,080 and a lot of enterprises actually have to go ahead 610 00:30:40,080 --> 00:30:40,900 and deal with this. 611 00:30:42,440 --> 00:30:45,300 Okay, so evil twin detection. 612 00:30:48,020 --> 00:30:52,140 Now, evil twin detection with MAC address spoofing 613 00:30:52,160 --> 00:30:53,500 is actually very hard to get. 614 00:30:54,460 --> 00:30:56,920 There are companies which get bought and sold 615 00:30:56,920 --> 00:30:59,660 based on how they solve this problem in Silicon Valley. 616 00:31:00,740 --> 00:31:03,140 One of the approaches which is very common 617 00:31:03,140 --> 00:31:05,460 is to look at a field called sequence number, 618 00:31:05,700 --> 00:31:08,760 which is supposed to increment once every packet typically. 619 00:31:09,380 --> 00:31:11,460 So when you have two access points 620 00:31:11,460 --> 00:31:14,760 with the same MAC addresses and communicating, 621 00:31:15,180 --> 00:31:17,440 you are going to actually end up seeing 622 00:31:17,440 --> 00:31:19,660 different patterns of sequence numbers 623 00:31:19,660 --> 00:31:20,600 kind of move forward. 624 00:31:21,080 --> 00:31:22,140 Even if the attacker wants to create an AP, 625 00:31:22,140 --> 00:31:24,100 even if the attacker were to try to go ahead 626 00:31:24,100 --> 00:31:27,660 and trail the authorized AP as close as possible, 627 00:31:27,860 --> 00:31:31,220 you would still end up seeing a lot of duplicates, right? 628 00:31:31,460 --> 00:31:34,280 Because the real AP sends a sequence number 10, 629 00:31:34,480 --> 00:31:37,100 the attacker sees that, he also sends 10. 630 00:31:37,280 --> 00:31:40,240 But now there is a collision in a very small time slot. 631 00:31:40,760 --> 00:31:44,780 So you can detect it with Python. 632 00:31:44,920 --> 00:31:47,600 Interestingly, you can even visualize it. 633 00:31:49,200 --> 00:31:51,880 So just by going ahead and plotting, 634 00:31:52,140 --> 00:31:56,040 the sequence numbers with respect to time 635 00:31:56,040 --> 00:31:57,680 for a given MAC address, 636 00:31:58,430 --> 00:32:01,140 if you actually end up seeing two patterns 637 00:32:01,140 --> 00:32:04,200 which are overlapping during the same time slots, 638 00:32:04,620 --> 00:32:06,380 you actually know for sure 639 00:32:06,380 --> 00:32:08,700 that MAC address spoofing is happening. 640 00:32:09,260 --> 00:32:11,440 This is one of the most common ways 641 00:32:11,440 --> 00:32:16,600 industry intrusion detection systems for Wi-Fi 642 00:32:16,600 --> 00:32:17,800 actually pick this up. 643 00:32:17,980 --> 00:32:19,480 It's a very common technique. 644 00:32:23,600 --> 00:32:24,820 Client spoofing detection, 645 00:32:25,080 --> 00:32:26,780 very, very similar to Evil Twin. 646 00:32:26,880 --> 00:32:28,340 The only difference is now you're dealing 647 00:32:28,340 --> 00:32:31,060 with a client device and not an access point. 648 00:32:33,420 --> 00:32:36,360 Again, what we really do is figure out 649 00:32:36,360 --> 00:32:38,860 how the sequence numbers are getting bunched over time. 650 00:32:39,280 --> 00:32:42,680 And then we try to see if there is a feed forward 651 00:32:42,680 --> 00:32:45,960 or feedback on the sequence number trails 652 00:32:45,960 --> 00:32:47,640 for the same device. 653 00:32:48,460 --> 00:32:50,340 In a sense, we are essentially doing 654 00:32:50,340 --> 00:32:51,380 what we just talked about. 655 00:32:52,840 --> 00:32:55,360 And again, looks pretty similar. 656 00:32:59,000 --> 00:33:02,620 So device fingerprinting with ML. 657 00:33:02,800 --> 00:33:03,740 How much time do I have? 658 00:33:08,380 --> 00:33:11,780 So till now, what we've really seen is 659 00:33:11,780 --> 00:33:15,140 different mechanisms by which we can go ahead 660 00:33:15,140 --> 00:33:18,140 and create an intrusion detection system 661 00:33:18,140 --> 00:33:20,780 which requires help, right? 662 00:33:20,880 --> 00:33:22,080 You have to tell it, 663 00:33:22,140 --> 00:33:23,560 what the authorized devices are. 664 00:33:23,880 --> 00:33:25,440 At the very same time, 665 00:33:25,910 --> 00:33:27,540 think about back address spoofing. 666 00:33:28,740 --> 00:33:31,000 The case which I've taken right now 667 00:33:31,000 --> 00:33:33,480 is really when the real authorized device 668 00:33:33,480 --> 00:33:36,460 and the MAC address spoofing device 669 00:33:36,460 --> 00:33:38,980 both exist at the same time. 670 00:33:39,560 --> 00:33:44,560 So what happens if the attacker brings in his device 671 00:33:44,560 --> 00:33:46,600 which spoofs the MAC of an authorized one 672 00:33:46,600 --> 00:33:49,420 when the authorized device is not around? 673 00:33:49,600 --> 00:33:51,580 How do you detect MAC address spoofing now? 674 00:33:57,740 --> 00:33:58,300 Anyone? 675 00:33:58,680 --> 00:34:02,100 So the problem is now actually quite difficult. 676 00:34:02,920 --> 00:34:06,720 Because when two devices coexist with the same MAC address 677 00:34:06,720 --> 00:34:09,800 at the same time, you can do a lot of the analysis 678 00:34:09,800 --> 00:34:10,660 which I talked about. 679 00:34:11,020 --> 00:34:15,640 But what happens if now only the attacker device exists 680 00:34:16,320 --> 00:34:18,060 with the authorized MAC address? 681 00:34:18,320 --> 00:34:21,780 The real device is left, maybe it's 6 p.m. and, you know, 682 00:34:21,780 --> 00:34:24,080 the authorized client device just went home. 683 00:34:24,420 --> 00:34:24,960 Yeah? 684 00:34:25,820 --> 00:34:26,360 . 685 00:34:30,400 --> 00:34:31,900 Okay, what exactly? 686 00:34:31,980 --> 00:34:32,760 You're on the right track, 687 00:34:32,920 --> 00:34:35,540 but what exactly in probe requests could be interesting or... 688 00:34:36,320 --> 00:34:38,340 What are we going to do with that information? 689 00:34:39,880 --> 00:34:40,420 . 690 00:34:42,920 --> 00:34:43,460 . 691 00:34:43,460 --> 00:34:43,680 . 692 00:34:43,680 --> 00:34:43,740 . 693 00:34:43,740 --> 00:34:44,020 . 694 00:34:46,100 --> 00:34:46,640 . 695 00:34:52,300 --> 00:34:52,460 . 696 00:34:55,580 --> 00:34:55,740 . 697 00:34:56,680 --> 00:34:56,840 . 698 00:34:57,140 --> 00:34:57,300 . 699 00:34:58,560 --> 00:34:58,720 . 700 00:34:59,240 --> 00:34:59,400 . 701 00:34:59,400 --> 00:34:59,520 . 702 00:34:59,760 --> 00:34:59,920 . 703 00:34:59,920 --> 00:34:59,960 . 704 00:34:59,960 --> 00:34:59,980 . 705 00:34:59,980 --> 00:35:00,000 . 706 00:35:00,000 --> 00:35:00,020 . 707 00:35:00,020 --> 00:35:00,040 . 708 00:35:00,040 --> 00:35:00,060 . 709 00:35:00,060 --> 00:35:00,080 . 710 00:35:00,080 --> 00:35:00,100 . 711 00:35:00,100 --> 00:35:00,140 . 712 00:35:00,460 --> 00:35:00,620 . 713 00:35:00,620 --> 00:35:00,640 . 714 00:35:00,640 --> 00:35:00,660 . 715 00:35:00,660 --> 00:35:00,680 . 716 00:35:00,680 --> 00:35:00,880 . 717 00:35:00,880 --> 00:35:00,960 . 718 00:35:04,240 --> 00:35:04,400 . 719 00:35:08,080 --> 00:35:08,240 . 720 00:35:08,240 --> 00:35:15,980 as well so we would really have to go ahead and basically hardcore those values which isn't 721 00:35:15,980 --> 00:35:20,740 scalable this is really where machine learning comes in yeah go ahead 722 00:35:24,540 --> 00:35:29,760 absolutely but keep in mind how do you program that because what you're essentially saying now 723 00:35:29,760 --> 00:35:36,560 is learn from data right because if we just had the code we wouldn't know for your network 724 00:35:36,560 --> 00:35:42,880 what could be the inter beacon time or how frequently does the client actually send out probe 725 00:35:42,880 --> 00:35:48,840 requests there is no fixed metric you can have a new device driver update and that can completely 726 00:35:48,840 --> 00:35:57,780 change so this is a fantastic problem to apply machine learning because essentially what you 727 00:35:57,780 --> 00:36:05,360 want to do is look at different characteristics of all of these devices and figure out by looking 728 00:36:05,360 --> 00:36:06,480 at more and more data 729 00:36:06,560 --> 00:36:14,260 how each of these characteristics or features behave some of those features may always be the 730 00:36:14,260 --> 00:36:23,140 same value some may vary some may vary within bounds some may vary randomly so what we also 731 00:36:23,140 --> 00:36:27,260 did and I'm going to give that out along with all the code which I showed you today 732 00:36:39,180 --> 00:36:39,820 . 733 00:36:46,400 --> 00:36:47,640 is we looked at 734 00:36:47,640 --> 00:36:53,700 different machine learning techniques but began of get you do a summary slide 735 00:37:00,860 --> 00:37:06,400 so here is what we did we actually picked up different IE elements and you 736 00:37:06,400 --> 00:37:06,460 . 737 00:37:06,460 --> 00:37:14,060 can visualize this, every I element as a dimension in an n-dimensional space, right? And based on 738 00:37:14,060 --> 00:37:19,920 that, we can try to see if we can figure out interesting clusters and patterns. Machine 739 00:37:19,920 --> 00:37:25,320 learning is very interesting, a topic by itself. We can talk about it, you know, after the talk. 740 00:37:25,500 --> 00:37:32,440 But what we did find by using k-nearest neighbors and a lot of other algorithms is we actually got 741 00:37:32,440 --> 00:37:41,360 pretty high scores of accuracy in detecting at least classes of devices. What I do want to do 742 00:37:41,360 --> 00:37:49,040 after this is also see how we can combine different metrics out of different frames and use what are 743 00:37:49,040 --> 00:37:54,440 called ensembling techniques. I don't know if any of you heard of it. Ensembles, which is really 744 00:37:54,440 --> 00:38:01,300 combining multiple algorithms and taking their scores and weighing them in some logical way 745 00:38:01,300 --> 00:38:02,420 and trying to figure out how to do it. And we can do that by using k-nearest neighbors and 746 00:38:02,420 --> 00:38:07,580 trying to see if we can go ahead and then find out, you know, which one is a better predictor. 747 00:38:08,960 --> 00:38:17,580 Okay. I'm going to release all of this. A couple of other things I wanted to mention is when you 748 00:38:17,580 --> 00:38:26,380 look at information elements or IEs, it's a pretty big chunk of data. So what I did was 749 00:38:26,380 --> 00:38:32,400 first I just took a Boolean, which is, is that IE present or not, and used that Boolean to 750 00:38:32,400 --> 00:38:39,420 take that as a feature vector and then looked at how well the scoring is. The next stage was actually 751 00:38:39,420 --> 00:38:45,240 to pick up that along with the length. Then to pick up the length with the hash of the value, right? 752 00:38:45,500 --> 00:38:51,560 Because IEs can actually vary in size. So by taking a hash, then what you're dealing with is, 753 00:38:51,640 --> 00:38:57,560 is this value fixed? Does it vary? What values can we have, et cetera? And then, of course, 754 00:38:57,600 --> 00:39:00,860 finally, the actual value, which is very difficult to work with in general. 755 00:39:02,400 --> 00:39:08,960 So this is really where we have progressed so far. All of this code and everything is going to be 756 00:39:08,960 --> 00:39:14,940 released, hopefully today. I'm tempted to connect to the DEF CON network and upload everything, 757 00:39:15,780 --> 00:39:20,500 but I'm not very sure about the kind of security of the server, which I've kind of rented out for 758 00:39:20,500 --> 00:39:24,280 this. So, but I'm going to do it tonight. By tonight, you should have all the code. Any questions? 759 00:39:28,540 --> 00:39:31,540 Any questions? Okay. Yeah. 760 00:39:34,240 --> 00:39:41,200 Yeah. And that is really what we're kind of looking at, is how do you kind of go ahead, 761 00:39:41,260 --> 00:39:46,040 correlate that with something like time series and see what all we can do. And it's an extremely 762 00:39:46,040 --> 00:39:52,580 interesting, challenging problem. But that's where we are, the research. It's a good point. 763 00:39:58,140 --> 00:40:01,820 Could you mention? Forgot about it. 764 00:40:09,360 --> 00:40:15,660 So his question was, what about prevention? Good news. We can actually send out de-auth packets 765 00:40:15,660 --> 00:40:23,240 using the ESP8266. So currently, the prevention, which I haven't implemented but plan to, 766 00:40:24,000 --> 00:40:29,620 is at any point, if we see a misassociation of any kind, send de-auths to go ahead and break 767 00:40:29,620 --> 00:40:32,380 that connection. That way, we can ensure that we're able to send out de-auth packets. So that's 768 00:40:37,900 --> 00:40:46,080 what we can do. And that's what actually all the industry AP, sorry, VIPs do as well, wireless IDSs 769 00:40:46,080 --> 00:41:01,280 and IPSs. So here is an actual de-auth attack using the ESP8266. The code is there as a separate 770 00:41:01,280 --> 00:41:02,360 file. I haven't integrated it yet. So that's what we can do. And that's what actually all the industry 771 00:41:02,380 --> 00:41:04,160 AP, sorry, VIPs do as well. So that's what we can do. So that's what we can do. And that's what 772 00:41:04,160 --> 00:41:09,960 Okay. Thank you so much. I hope you enjoyed it.