 Okay. We are in 802.1 ‑‑ sorry, 11 rather. Massive monitoring with Andreas Blanco and Andreas Casoli. Without further ado, gentlemen? Okay. Hi there. We are very glad to be here. It's our first time as speakers. We are ‑‑ thanks. We are from Argentina. We work at core security. And we are here to present our talk, which is 802.11 Massive Monitoring. And what is it about? Well, it's about how to monitor several Wi‑Fi channels at the same time in an easy way. Okay. Here are the outline and introduction. I'm going to say that. Then the main part of our talk will be explained by my partner and consists in approaches, the USB dilemma, and distributed system. Then I'm going to come back to explain why what, which is our last solution. Okay. Let's start. Who is this talk for? If you go around looking for access point or wireless routers in Cillins, for example, well, then this talk is for you. If you no matter what you are doing or where you are and you are trying to monitor wireless traffic, this talk is for you. If you have just a couple of routers at your home, if you like to spend your day watching TCP dam or playing with Warsaw, of course this talk is for you. Okay. Last year, we were doing some research about different protocols. We faced that with the problem with Wi‑Fi Direct. At that point, we realized that when two devices in Wi‑Fi Direct try to establish a connection, they start sending frames on different channels. And of course, we never know on which ones. It sounds trivial, but it wasn't. So at that point, we realized about two things. The first one, we didn't have a good way to do it. And the second one, there were more similar scenarios in which we might want to do that. So we defined the goals of our project and our talk. And here is the goals. Monitor channel hopping traffic such as Wi‑Fi Direct. Monitor access point with auto‑selection channel. There are access points that change the channel in which they are working according if there are so much traffic or other parameters. Monitor multiple access points at the same time. Monitor stations which can be connected to one access point using a channel and later connected to another one using another channel. Monitor multiple locations at the same time. And the last one of our goals, which is not about monitoring, but it's quite related to it, which is in check frames on different channels at the same time. Here, we can see a couple of tables with a list of Wi‑Fi channels. Wi‑Fi has several standards. They are named using letters A, B, G, N, et cetera. Standards can be grouped by the base frequency in which they work. For example, we have some standards that work on 2.4 GHz, other ones on 3.6, and other ones on 5 GHz. So each of these standards has a set of well‑defined frequencies called channels. So we have maybe 50 channels. When we try ‑‑ when everyone tries to monitor traffic, we can do two things. We can do channel hopping, which consists on monitor traffic on one channel, then hop to another one, then hop to another one. Or we can set a specific channel and monitor all the traffic in that channel. We have problems with the two approaches because we are losing a lot of Wi‑Fi traffic. So in this presentation and with our solution, we are trying to solve that problem. Hi, everyone. My name is Andres. Well, I'm going to start talking about the approaches we did. The first one was this one. As you can see there, we have six USB network cards with a food container. It was a really good one. It was a really nice one. Last year I brought it here for the wireless CTF. And it was nice to go through the airport with this. It was really fun. So the first one approach was only six card. The second approach that is one that I have here, I couldn't put it on the table because the cables are too short. But after the talk, you can come and see it. It doesn't go up. So ‑‑ okay. Later. Then you can see it afterwards. But this approach started giving us the idea of if this could scale or if the system was not going to be able to scale. So how we used these two approaches we made. One was using Warshark. Pretty easy to use. You open Warshark and you select all the interfaces you want to monitor. And you are able to use them. Really easy. And the other one was an approach of using Python and some libraries like pick‑up and in‑packet. So we can monitor and do processing of the frames and do some stuff. In this case, we are going to see a quick demo. As it says here, if you don't want your traffic to be displayed during the demo, please stop your Wi‑Fi. Let's hope it works. Okay. So the script is now ‑‑ is setting the wireless cards in different channels. And now we are monitoring for specific packages like pre‑request, DNS, DHCP and HTTP. So it's only a demo to show that it's quite easy to grab a lot of frames and process it with a lot of cards. It's also really fun to see the data going around in the air. But we are going to stop it. So no‑ones feel like bad about it. So what's the problem with these approaches that we made? We started seeing some things that they were not working as we expected. And we started thinking about that USB was the problem. Okay. So the first thing is scalability. Plugging one USB device on your computer is something that everyone knows it works and it works fine. What we are going to start playing and putting a lot of devices in your USB, sometimes it doesn't work like it should. Okay. 11 cards, it shouldn't be a problem. We are not plugging like 100 devices. It's only 11 cards. But the problem is the monitor mode, okay, that we are going to explain now. The thing is we plug 11 cards. We use LS USB command to see that every card is plugged in and it's working. And I'm going to show you another demo now. This demo is really short. We're going to see ‑‑ we're going to load USB module ‑‑ USB module in the Linux kernel to ‑‑ to analyze the USB traffic. And running Warshark again, we're going to be able to see what's going on and what's the problem here. So we go to interface list. We see as the image that we were seeing before, we have all the interfaces and we have the USB ‑‑ USB buses here. So we can monitor the buses. We start monitoring the buses. And we're receiving a lot of USB traffic. We are not now using Warshark or any other software trying to use the network interfaces. But once the network interface is put on monitor mode, it doesn't care. It's going to grab the frames in the air and it's going to send it through USB to the kernel. And there the driver is going to forward it to user land. So the problem here is that the card is not ‑‑ is not filtering the traffic, okay? It's sending all the time the traffic to the USB bus. So that's ‑‑ is the first issue that we find that is bus saturation, okay? Sometimes USB or usually USB devices, they are not using the bus all the time. Like you can use, I don't know, a hard drive or something and you use it sometimes, but it's not constantly sending information through the bus. When you put a monitor mode, a wireless interface in monitor mode, it's sending all the time the information and we start seeing USB saturation. And that is a problem for us. So as I was telling before, the filter is only applied on the kernel, okay? It's not applied on the wireless interface. So we end up having a couple of buses with a lot of people trying to get into the buses and go to the kernel. And we end up with something like this, okay? Something really bad. We're not going to be able to send all the people in the buses. So as I was showing before, as we can see here, I'm not able to show you with the laser, but wireless interface number 16, it says zero packets, okay? That is a problem of bus saturation. We are not receiving any frame from that interface, but the interface is working. And as we know, USB ‑‑ wireless interface is not listening in monitor mode, they receive frames all the time. It's almost impossible if you have devices going around to get zero frames. We always get something, okay? A pre‑request or some frame going around, we are going to catch it. So this is bus saturation problem. And we're going to talk another issue. Later, I'm going to catch up with this issue that I was mentioning, bus saturation, and we're going to talk about how maybe to fix it. Now we are going to talk about non‑removable devices. That is another issue that we have here. Let's say we use all these cards in my laptop to do a pentest or something. And I plug this in my computer and I say, okay, I'm going to use my bus, my USB bus, only for my interfaces. But this is not so true because nowadays computers already come with devices that they are using the USB bus without us knowing about them, okay? So in this case we have a webcam and a Bluetooth device that I don't know if it's clear to see. It's a little bit ‑‑ a little bit small, the letter. But these two devices, they are using the bus number one. So bus number one has already some traffic that we cannot control, okay? So we end ‑‑ again, we have a bus with some people that is already there and we are not able to take them down and they are going to be sending things in the bus. So that is the second issue. This one maybe we could fix it, removing kernel modules or drivers to see if the device stopped talking to us through the USB bus. But I don't know. It's something you have to test with every device. The other thing that is really funny about it is that in this computer we have four USB buses. So we said, okay, we have four USB buses. If we use ‑‑ like we balance the usage, like put some devices on the first bus, some devices on the second bus, we maybe mitigate the USB saturation issue. But it's not so true because when we start plugging devices in every port, we start saying something like this. We plug it card in the USB port number one and we are using bus number one. The same one that was using already my webcam and my Bluetooth device. I plug in the USB port number two. We are using now bus number three. I plug it in the last port I have in the machine. And I already ‑‑ I am again using bus number three. So I have three ports and I can use only two buses. There are two buses are not available. So mitigation of usaturation is not going to be able to do this. And the last issue I'm going to talk about is a power negotiation or power issue with USB devices. When you plug a lot of devices and they are trying to power negotiate with the kernel, the Linux kernel, sometimes we end up with less devices than the ones we plug in. And this is because there is some issue on the Linux kernel that I'm not sure why, because it's sometime now, from now that is going on. But this issue happens not all the time. Sometimes it happens and sometimes it's not. When you plug it, the device doesn't appear there. And oh, okay. I will continue. And when it doesn't appear, if we plug it and unplug the device, it's going to still be not appear. It's like it's blacklisted because kernel says it doesn't negotiate. And we have to reboot the machine to be able to see again that device. So it's really a bad, this issue, we don't, that didn't find a workaround for this. And, well, reboot your system and again try it again if you can monitor. Well, I'm, okay. I can continue. Yes. Ah, that is really, you have to eat it. It's really good. Oh, I'm going to eat it. So, but these are, it says Havana. What country are these from? Argentina. Argentinian chocolates. They didn't do anything small down there. These things you could probably, anyway. All right. Well, anyway, we are here. Thank you very much. This was a gift to us. So that's great. Where's mine? All right. Are these guys doing a good job? That's awesome. All right, guys. You know how hard it is to get on this stage. So congratulations. So, to DEF CON. And now let me pick up where they left off. Okay, I'm going to have to learn this first. Could I get some help? What? These computer things. I don't know. Excellent description. Thanks. So, so again, as far as I think I said this, I don't know. It was, we were talking about USB issues. We got USB saturation. We got non-removable devices that they are using the bus. We have power issues. And we have, I forget. Okay. It was non-removable devices. We have saturation, power issues, and available ports. USB buses. Okay. We have three ports. We have four buses. And with three ports, we are using only two buses. So they are designing really good these computers. So the solution for some of the problems could be applying a filter on the wireless interface instead of using the filter on the kernel side. So if we do this, we are able to filter only the traffic we are interested in. If someone do some traffic monitoring, you should know that we are not interested always in all the traffic. Sometimes we are interested in some traffic. So putting the filter on the wireless interface, it will be a thing that could work around some of the issues. But doing this is really hard. Really hard. Modifying firmware. If it's open source, okay, we maybe, we can, we can apply some changes and it will be easier. But applying on closed source and applying modifications also in the driver, we have to modify the firmware on the driver. It's really hard and you have to do it for every different card. And it's really a work that is not so good. Sometime ago, we give a talk about modifying the Broadcom wireless drivers, about to put it in monitor mode. And it was only two chipsets and we have to do a lot of work. And every time an update was in iOS again, we have to remodify, reverse again the code. It was really hard work. So it doesn't escalate so good. So we say, okay, we can modify this idea and try to extract of the, of the, of the scheme that we were using. We can say we have a worker or something that is monitoring and injecting frames. We have a manager that is in charge of analyzing or injecting traffic. And we have a bus. In this case, the bus is going to be internet. And we now can work and talk to the worker and say, okay, put this filter and only give me this traffic instead of giving every traffic. This way we can avoid the bus saturation and we can also avoid the other issues we were mentioning before. So how we can do this? We can do this with, we can do this this way. We can have a couple of machines with USB wireless devices or interfaces. And we can have a manager that is in the middle and we can talk to these machines and say, okay, you put in channel six, you put in channel four, now start monitoring, give me only traffic that works with the filter. Now you go inject or do anything. But what is the problem with this is you don't want to have like 11, 11 computers. If you want to get these computers to another site, you have to have like 11 computers in a bag. It's really expensive. It doesn't escalate so good for my pocket. So I don't want to use all that money for this. But nowadays computers are not always computers like we used to know. Like now we have embedded devices everywhere. So we can find some cheap embedded devices that has wireless. So there you go. We have a lot of wireless devices that they are really cheap and we can transport it really easily and we can have a lot of them in my bag and I can go around monitoring or injecting traffic. So using instead of computers we are going to use open WBD devices that run Linux and can work with wireless. Okay? So, well finally we are right to our last approach. We called it YWO, which means wireless workers. And we defined it as a distributed A02.11 monitoring and injecting system which was designed to be simple and scalable in which workers nodes can be managed by a Python framework. Okay, from one site we have routers converted into workers. We are using a custom open WRT. We removed several default packages and we added a new one called worker. We developed that package in C-language. From the other site we have a Python lib that we also designed and developed, sorry. And we communicate what workers and the manager are using a protocol that we design and implement it and it runs over Ethernet. In theory, each kind of router that can support open WRT can be converted into a worker. But we chose three different routers to work. This is the first one. It's a TP-LIN, TL, MR, 30-20. And it has not so much flash nor RAM memory. It has not such a good CPU, but it's cheap and small. We also chose this other kind of router. It's another TP-LIN. The main feature of this kind of router is they have two wireless interfaces. One of them works on 2.4 GHz and the other one on 5 GHz. We designed and implemented YWO to support routers with more than one interface. And this is the last router that we use. It's pretty similar to the first one, but it can work with batteries. So this is important because we can implement the YWO system and do it mobile. From the other side, we have the manager. It's a Python lib. The main features of the lib are looking for workers on the network, getting information about the available interfaces in the workers, start monitoring a worker interface using a BPF filter. And in check frames, from an interface, from a worker interface, sorry. This is a scheme of how is our manager. There are three processes. The main one is the manager service, but we have other two processes which are for handle data frames and management frames. Why we decided to use Ethernet instead of IP? Our protocol runs over Ethernet. Okay, there are several reasons. We always try to keep it simple. IP may need some initial settings. And we also, our original idea was have our own network with the workers. We didn't want to plug workers in an existing network. So using Ethernet, we are able to connect a new worker and it starts immediately working. We also can control better the traffic on the network because we are not using IP and there are several services, several IP services that are not there sending frames. So we have a better control over the network. Then Ethernet has an MQ of 1500 bytes. And it has a very short header. So much shorter than IP. So we have more bytes available for our staff. Doing that we can keep fragmentation low. Well, here we have a couple of devices, a router and a switch. We are using these kind of devices in our POC here. They are of 10 100 megabits per second. And of course with this kind of devices, we are not able to monitor all the traffic with high performance. But the good thing here is that we can get better devices. Like these ones. Here we have a router, a Wi-Fi card and a switch. They are devices that work on one gigabits per second or 10 gigabits per second. And if we get better devices, we are going to get better performance. We are not going to have scalable problems. Okay. Why won't it not a tool? It's a framework. So you can do a lot of things with this framework. For example, you can build a distributed wireless IDS or IPS. You can do traffic analysis. We are getting a lot of traffic. We are getting a lot of traffic from different channels. So our analysis will be more complete unreliable. We can do device tracking. We can put different workers, for example, in a building. And in that way, we will be able to know every time where a device is. And finally, we can use it to perform protocol analysis like we did with Wi-Fi direct. Well, here is our POC. We have 11 routers, a couple of switches, and a USB hub just for power. The main idea behind this POC was have one router per channel in Wi-Fi standard B or G. And to have just one power plug and just one ethnic plug. Well, demo time. Please disable Wi-Fi. Not all of the Wi-Fi, please. So we're going to try this demo. Hope it works fine. So the framework comes with some examples. So if someone wants to use the framework to develop their own tools, it's easy to use these examples as guides. But we are going to bring, we're going to put a lot of information and documentation on the GitHub. Okay. Let's test the Warshark example. The Warshark example is going to find every wireless worker that we found in the network. It's going to search for the best optimal channel assignment. And once we have every channel assigned, we're going to sniff with some BPF filtering. And we are going to receive all the information and send it to Warshark. So we can use a tool that we know. We're going to say that we need the network interface where we are connected to the workers. We put a filter, let's say IP. When we put IP filter, it's going to only, the workers are going to only send me the traffic that they know that it's IP. So the thing they are going to do is search for an encrypted traffic. And then if it's IP, it's going to send it to the manager. So the manager is only going to process this traffic and not all the traffic that is in the air. And let's say a time out of three minutes, but you always can, like, kill the application. So now, as we can see here in the console, in the terminal, we will, manager is starting. He's going to look for workers. Hoping it found every worker we have. So there you go. We find 12 workers and one worker has two interfaces. This is this black one that has two interfaces, one at five sheahertz and the other one at 11. And now we are getting traffic. All this traffic is being captured by the workers and sent through a network encapsulated in internet and the manager is processing these frames. This way, the workers are doing the hard work, like filtering all the traffic and the manager is only processing the traffic he wants in every channel we find. So if someone now says, okay, I'm going to change channel or now someone plugs a new access point there, we're going to receive that traffic. Because we are monitoring 11 channels and one channel at five sheahertz. So we can see here, we have radio tap information and we can see that we receive frames in channel 11. Here we can see the channel. This is in five sheahertz. And we can see channel 11. It looks like there are two wireless devices here or two wireless access points that one is in five sheahertz and the other one is in channel 11 of 2.4. So we can now process any frame that is in there. So we have other examples, like for example, let me see. We can copy something. This example is going to find, it's going to say the workers to monitor only pre-request on every channel and then every time they see a pre-request, it's going to inject a pre-response. So we have a karma attack on every channel. There you go. So, well, future work. We think of adding IP support. We, original idea wasn't that, but we know that it's important in some scenarios. We are thinking of building new open WRT frameworks. We have already released this framework with some code examples and frameworks. We are thinking of building more frameworks and create more code examples. And finally we are thinking of adding interaction with some well-known tools. Well, that's all here where you can find the YWO project, our emails and our Twitter if you want contact us. That's all. Thank you so much. It's very interesting. Any question? Airbase works from one to one. It's like, it works like you have only one instance. For doing that, we should modify like air crack code to make it like work from one manager to multiple workers. We see a little bit of the code, but we wanted something that is also in Python so it could be a multi-platform. We will now, the manager works on Windows, Mac, Linux. It works everywhere because the manager is right in Python. So we thought about it, but we end up making a project. Thanks for your question and because you did the question, the first question, you won a WeWO worker and other advice. So