Guests 'N Goblins: Exposing Wi-Fi Exfiltration Risks and Mitigation Techniques
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Desfigies, Peter
Brierton, Joshua
Islam, Naveed Ul
Wi-Fi is a pervasive part of everyone’s everyday life. Whether it be home networks, open hotspots at cafés, corporate networks or corporate guest networks they can be found virtually everywhere. Fortunately, for the security minded, some steps are taken to secure these weak points in one’s infrastructure. Usually this is done through some form of registration page which is common in the case of guest networks. But is this enough? And what new threats could be unleashed from even the most isolated of Wi-Fi networks? In the most paranoid of cases, companies will generally attempt to isolate Wi-Fi networks from their official networks in order to protect their own assets from attacks, while still ensuring that Wi-Fi is convenient for end users. But there is another way to attack a company that could be damaging to the host company and harmful to other targets. This presentation will go over the utilization of various techniques of getting onto and getting out through publicly accessible Wi-Fi networks for nefarious purposes, termed Wi-Fi Exfiltration. Through this technique one is able to obfuscate their identity by using the host of the Wi-Fi’s identity, thus implicating the host in the attack. During the presentation we will cover the findings through our tests along with a list of recommendations for what can be done to mitigate this risk. This is a must attend session to all security professionals and high level management. Speaker Bios: Peter Desfigies is a Security Consultant at TELUS Communications Inc. where he works with a team of other operations analysts to proactively investigate and analyze customer traffic, while also providing threat intelligence on attacks, campaigns, and zero-days in order to protect customer’s environment and enhance their security posture. During his time at TELUS, he has worked with a variety of teams providing LAN, WAN, Telco, Security and hardware break/fix support, and now Security Analysis for government and corporate customer. Prior to TELUS, he worked for 12 years in IT operation roles to provide backbone network support including DNS, SMTP, POP, dialup, T1 to OC12 , and Ethernet at various companies, with the bulk of his experience at UUNET / MCI. Joshua Brierton is a Sr. Security Analyst at TELUS Communications Inc. where he works with a team of SIEM specialists to provide customers with a cloud SIEM service offering. Primarily working on rule development and user work flows his other interests in the field includes developing tools to help automate and expedite repetitive work to increase user efficiency. During his time at TELUS he has worked with various teams providing security solutions from VPN services to IPS services along with outsourced development for a variety of other well-known SIEM’s. Prior to TELUS he worked for 5 years with Intellitactics Inc. doing development and device support for the content of the SIEM they provided. Collectively Josh has been working with a variety of SIEM’s for 10 years. Naveed Ul Islam (BEE Telecom/DSP, CISSP, SABSA-SCF) is a Managing Consultant at TELUS and Security Intelligence architect within the TELUS Cyber Security Investigation Unit. Naveed’s other interests are in application forensics and enterprise security architecture. Naveed’s prior duties with TELUS include securing of then world’s largest PKI infrastructure known as Secure Channel. In addition, he was responsible for secure implementation of TELUS Health Space infrastructure. He led application security practices within TELUS Health, where he was able to incorporate software security lifecycle into software development practices. Also, he has been a part of security incident response and penetration testing teams. Previous to TELUS, Naveed was a security consultant for Microsoft USA, where he performed security and privacy audits of Microsoft’s core-business related websites. He has secured several key sites such as Microsoft XBOX 360 host web site and Microsoft’s internal auction site known as Micronews.
 presentation here is called guesses in goblins, expose in Wi-Fi X filtration and mitigation techniques. With me is Pete and Naveed. We'll get to some more formal introductions in a little bit. Full disclosure, we all work for a company called TELUS. It's a yes. We have like one representative here. Two? Oh, hey, guys. So yeah, we're a telecommunication company based out of Canada. One of the big three there. So just to let you know. Anyways, as I already said, my name is Josh. I basically have been working with Sims for the past 10 plus years. By night I work on my boat that I've been living on for six years, even in winter, which is fun. So general hobbies, cards against humanity and movies that nobody should watch in their right mind whatsoever. All right. And on to Pete. Hi. Hi, I'm Pete. I live in a cave. I don't really get out that much. I don't really know how to talk either. That's why I got these two guys with me today. Thanks, guys. So by day I'm a security analyst. Just bearing my nose into screens and stuff, packets. By night I like to break things. And then my hobbies are breaking more things. I always end up with more screws. I don't know how every time. Damn screws. And here's Naveed. Hello, everyone. My name is Naveed as introduced already. I'm a team lead for the Cyber Security Intelligence Unit. Pete and Josh, we work together. My job is to keep an eye on the emerging and developing threats on the outside of the network. So what's happening, I keep an eye on the customer from the customer prem if it's a threat for them or not. So we do intelligent analysis and provide analytics for the events that are happening inside. So keeping an eye on all the IPs that are coming in is part of a job. So a little background of this project. So anonymity is important for many reasons. It's also a problem too. So a lot of people know about Tor, L2P, SpotLux and Hola. They hide your public IP address from the people who are monitoring them. But the question is what is your fingerprint? What is your IP fingerprint? And how good it is? So if you are on a Tor network, your fingerprint is going to be the Tor exit node. Is it going to help us, the people who are on the monitoring side, identify who the person is? So adding to that complexity, we are going to talk about Wi-Fi and using Wi-Fi as a way to hide your public fingerprint. Anyone here heard about proxy ham? Anyone who doesn't know what happened on proxy ham? We don't know either. So little introduction about Wi-Fi challenges. We all know the security is a big concern. But if you are an enterprise, you are deploying a Wi-Fi network, you only try to isolate it. You try to deploy the latest encryption, which is WPA 2.0, yes, everything is good. However, is it really secure? Is it helping you, helping you protect against any implications that you may have, which we will talk about more in the future. One reason is to deploy all these Wi-Fi networks is to have the competitive convenience, as you may say. Because if your competitor is providing this convenient interface, you want to do the same as well, right? So for the problem space and the risk associated, I'm going to switch to Josh. Thanks, Navid. So just a quick question for everybody. How many people here use Wi-Fi? Hands up. How many people trust Wi-Fi? But we all use it. That's a little weird when you think about it. Anyways, so as we're saying, as our presentation is titled, Wi-Fi exfiltration, what can you do going outbound versus inbound? So one thing that we're somewhat concerned about is a sort of post implication and as a result of that, smear campaigns. Great example, right? We have at TELUS, as most other places have, it's like an open guest Wi-Fi or other Wi-Fi that can be wiggled around. Oh, sorry. Is that better? Hey, all right. Sorry about that. Anyways, so one of the things that we're actually concerned about is sort of the results of people getting into your Wi-Fi and tunneling on out and doing stuff. Great example, TELUS has open Wi-Fi for users to get onto and we also have secure that maybe it can wiggle around. The problem is with exfiltration, not a lot of people are actually monitoring outbound traffic as to what's going on with it. A lot of people monitor outside coming in but not a lot monitor inside going out very well or at all as we've found. So let's paint a quick scenario. TELUS has open Wi-Fi, our major competitor up in Canada, happens to be Rogers. What if somebody decided to jump onto our network and launch a form of attack through our network to Rogers? The smear campaign would more or less read that TELUS was implicated in a massive attack against Rogers. Even though it wasn't, you know, TELUS itself actually doing the actual attack, it's already in the news, it's too late, people are going to lose faith in TELUS itself. So we were quite concerned about that. Is there anything? Sorry. In branding in general is just something that a lot of companies and corporations spend millions and millions of dollars for. So besides the whole TELUS thing, it could be anybody and it just takes one incident, even a small one, to have any amount there and you're done. All right. And on to Naveed. Okay. So when you're deploying Wi-Fi, we are generally in a catch-22 situation, right? Convenience versus security. And the challenge is that you have to provide a connection before you actually can authorize. So what you do, you ask for an email address, the person provides an email address and you have to blindly trust him. Because generally you need to send a verification code on the email and how are you going to check the verification code if the customer or your guest cannot access to his email address. So we just generally enter an email address and just blindly trust and let the guest join the network and here we go. So that is a big problem. Lack of figures, monitoring already mentioned. Default SSL is another problem. Every web page now is switching to SSL. So you can't really provide monitoring on what's going out from your guest network. In addition, on top of the spoofed MAC address is that if you have allowed someone, even though you have authenticated him, you can have a person spoofing his MAC address and here we go. Taking his identity. Introduction to our concepts. So our concept. We have developed a custom mobile app that relies on some batch scripts. Two servers with dedicated IPs. They scan for open Wi-Fi. Currently right now if there is anything dash guest that needs a page to log into, we are still kind of working on but for the sake of this, just straight open. It tags the location, connects automatically to the network, learns about the network, collects public fingerprints and syncs with the central server. So there is a list of stuff that we have spent many weekends banging our head against the wall and crash-coursing through for tools. Hardware, simple stuff. Cali Linux, Android phone and a couple of Ubuntu servers. The toolkit or suite is broken up into three pieces. It's more scamble which is the initial area scan and discovery. We're garbled at connectivity and data collection and finally we're repo reporting reports and does the results from all of the data collecting. All right. So back to me. This is my part. I made more scamble. So what is it in a nutshell? It's basically just a Wi-Fi scanner with some really handy features built right on into it. Such as it gathers coordinate information, which are encryption used, names, BSS IDs, etc. Anything that it can find, it will just store. So how does it do it? Step one, scan for all the access points. Step two, put all the results into an object that stores two types of values, static values, so things like your BSS ID, your ESS ID, etc. And then some flexible values, so your location and your signal strength. I'll come back to that later just to explain why that is what it is. All right. And then three, we enhance the location data by comparing new data to existing data and then through that process we select a signal. So let's go to the updating entries to cover that flexible data information. So when you first connect to an access point, it will generally tell you about how strong that signal actually is. We decide to take it one step further and compare it iteratively. So while you're walking, it's going to be taking samples on a frequent basis and as it's going along, as the signal increases, it's going to update the location of the wireless access point so we can find the exact location of where that access point actually exists. Once the signal strength starts to dip, it stops updating that location. There are some issues with this technique which I will cover right at the end of the presentation. But it actually works pretty darn good just by basically using this. All right. So how do we select a candidate? First, do we have any results whatsoever? If the answer is yes, then we look for the strongest access point. We then pass that off and say, hey, is it unencrypted? If the answer is yes, then we pass it off to Pete's scripts. If the answer is no and doesn't have weak encryption, then maybe we can pass it off to Pete's scripts and stuff will happen. In any case, we still store the information for later usage. You may end up in a situation where you actually get multiple strong access points but you're only going to be able to connect to one because let's face it, Android phones generally don't have like network cards hanging off the sides of them, just generally one. Yet. So then we store the results and we go back and we just start iterating over that information over and over and just keep updating the information. So here's a screen cap of the app itself. This is actually just something we picked up last night when we were wandering around our hotel room. So if you would like a live demo of this, come find me. I'll be hanging around a little bit and it's actually just currently running on my phone in sort of like a limited capacity just to make sure it's not doing anything iffy. And now we go on to Wargarble. So once all that data is collected, it's passed on to me or my module. Basically I take everything that he gave me, I strip it and parse it and I look generally for just open networks. I then connect to that same network, find out your public gateway from the inside and then I make an outbound handshake connection or I connect to an echo server to determine what ports are open based on a range or port specified in config. And what I mean is talking about ports that are allowed outside, 80, whatever that's allowed outbound from any policies, gateway firewalls, et cetera. I then store the results in a database for final parsing, for final phase of reporting and plotting, which is handed off to Naveed. How does it work? It uses a combination of bash, set, awk, SQLite, head banging, Python sockets to our mode server and lots of crying. So this one here, I'll get back to it again a little part of it. But basically this is just one question of some of the sets that we've collected and just to go over quickly, we've collected the BSS IDs, that's the MAC addresses of the APs, the names of them, the ESS IDs. Auth mode is encryption type. So in this particular app, ESS is open, there's WPA, WAP, ISMSS and cell. It also gets the latitude and longitude, which is taken from the phone or device itself and then the public gateway. Before Naveed talks about his part, one other section here is that for the echo server, it also grabs the, sorry, when you see the longitude, it's for the device. But when the echo server happens and we get those IPs, those longitude and latitudes are the longitude and latitudes of the public gateway, which you'll see later why that's important. Okay, so my part basically is the visualization of the data that we have collected using Josh and P. Sewell. So this is the basic idea of centralized collection. But there's a second part to it, which is our reversal scan engine. So in addition to just plotting the latitude and longitude for client and the server or the public side of the connection, we have a server that responds to all the ports which you ask and test for. So the client side scans and gets the response of the open ports which are available. So this server is running a node.js instance, which responds to pretty much a range of port which is preconfigured into it. The technology behind basically was planned to be SQL IP, PHP, IP tables and bash. But then I was like, let's give it a try with new technologies. So node.js plus Meteor is fantastic framework. It does let you have a real time web front end. Plus MongoDB is a JSON oriented object database. So it's very interesting. Feel free to try it out. Basically this is what it lets you plot. Once you have the data, the server shows you the client SSID, the public fingerprint that you will be represented as on the internet and the location. So if you are connected here to the monitoring people who are monitoring your traffic, you will appear here in this part of the city. And the scan results for the reversal tool that we just talked about. I will tell you that if you are using this open Wi-Fi connection, you are allowed to go out on all these ports. 1,000 to 1,572 and 1,574 to 2,000 as an example. This is a fixed range. You can expand to any ports you want. Now to demo. How much time we have? Okay. So the tool, like I said, is a meteor instance of real time web. So I'm going to start it here. Can screen is good enough? Big enough? No. It's best for retina display. Hold on a second. This is what happens when you use a Mac, I guess. All right. So once we have the meteor running, the website updates itself. And there's no need to zoom that. Okay. So what Pete skip does, it collects that data from Josh and attaches the coordinates. And once data is compiled and database, it produces a CSV file. So this instance here that I'm running, it can accept data using SSH. You can upload to the system. The system will keep an eye on the folder. Once CSV is detected, it's going to compile it. A better way, however, the second option I have is a manual upload too. And that's what I'm going to show right now. So let's plot the Toronto results that we scanned before coming here. The file is being uploaded. You can see it is reading the port information from the scan. And once done, I'm going to refresh the page. And it's pretty much the same plot that I showed you in the previous slide. I can open that information from monitoring VAN connected to this gas network. You're appearing here basically in GTA from Richmond Hill. A better example, however, was when Josh was taking a ride on V-Rail. I'm going to open this scan one, this CSV file. And once it's processed, yep, I'm going to refresh the page here. And you can see the rail was in Union Station Toronto. Sorry. So Josh, you can... Yeah, so basically I was just on a trip and I decided to poke around just to see where we were exiting. And while I was actually waiting for the train to move, my exit point for the free Wi-Fi on the train was saying that I was in Ottawa. So that got me to sort of thinking, well, at Union Station in Toronto, we also get Amtrak. Where does that exit? Right? So does it exit in the States? Who knows? We haven't actually tried it. I don't generally run on the trains as much as I should, I guess. But it also got us to thinking about other sort of situations such as multinational companies and stuff like that. Where did their access points actually exit? Did they just set it up local? In some cases, yes. Do they set it up remotely just by tunneling across a network? Quite possibly. So if you want to exfiltrate information from, say, one country to another, this could be a way you could do it. This is actually concerned about this sort of thing. Keep an eye on this. Just to add that, you know, have one more random sample. Once the data is imported, I'm going to refresh it. You can see some of the ‑‑ This is what happens when you have to make data manually in the last minute. Thanks, Pete. So entry point maybe in Canada, exit point in the different part of the world. Okay. So that's part of the server side. For the client side, the reverse or the one that detects the ports on the egress traffic, I'm going to show here in 12 plus again. So this is a Python script that talks to the server. And if you run it, the server which is responding on the other side is telling us that this port is allowed, that port is allowed. And you can ‑‑ we are making a list and the mapping based on the script here. Now, an interesting side of the story is that you don't need Python or any other server side script. The whole scanning can also be done on the client side using WebSockets. Thanks to HTML5. I think I have written a code script here that I can show you. So I have a Node.js instance running locally. So it's not listening to all the ports on this machine, but you will get the idea. So if I run the command in the browser, to reverse the local IP and the port range, it's going to tell me that all the WebSockets which are blocked and the ones that are allowed. So I guess the server is not running yet. Let me put this on. Yep. Now I'm going to turn it on on one port only and rerun my scan. You can see the client detected 1337 as open port. So you can map just with the browser. Okay. Off to Josh. All right. So like you can see, we are actually quite concerned about this. So, you know, full disclosure, this was not actually the first convention that we actually submitted this presentation to. This is the second one. The first one we actually tried to get ourselves into was Sektor, which tends to be more sort of for the sort of people that we end up working with on 9 times out of 10, right? So we presented this to them as like, you know, hey, you guys should really watch what sort of traffic is actually leaving your network. You could be implicated. Bad stuff could be happening. People could be using you for all sorts of really weird things. Please let us tell our story. And we got a resounding meh, which was kind of disheartening really. So, and unfortunately it happens more often than not. If it's not shiny and flashy, it's people just aren't interested. So the mitigation techniques that we would actually like to present as an option to actually just sort of try to hold back this, right? Auditon review your traffic and firewall policies both ways. A lot of people do ingress on a somewhat frequent basis, but egress is usually done when they decide to install the device. And that's about it. Tune your appliances and applications. In my line of work with Sims, I see a lot of logs coming from devices that have just been literally plopped in place, wires plugged in, power goes on, everybody goes, hey, it's doing something. And that's it. That's really bad. We really need to make sure you're actually tuning and looking at the right information and collecting accurate information. The third point is pretty obvious, right? Like just segment your infrastructure, isolate your wireless access points entirely. One that was sort of linked to the whole presentation where we got the resounding meh from people was listen to your minions, right? More often than not, we'll actually go on up and say we're really concerned about this. We could get hurt. Please, can we do something about it? It's not really in the budget. It doesn't sound all that interesting. How severe is it? It's bad. Please listen to us and believe us just once. And also, finally, know your clients. So know who is connecting to your wireless access points, which sort of ties back to just doing monitoring for all egress traffic and making sure everything is properly segmented. If you don't know who is connecting to you, how are you going to stop them from doing things that they shouldn't be doing? Any other guys? Very good. I blame POCs for vendors a lot of times. But it's exactly what Josh said is vendors go in and they, you know, create products and whatnot and they go in and catch the corporation, right? They just drop in, said IPS or said firewall or said whatever next gen. And who, who's caught everything? We'll leave it the way it is. We're secure. No. They need to understand or people need to understand, you know, that even port wise and policies, there's more to just a few things. So for example, there's some protocols have suite. So we all know VNC. VNC actually has a good O5 somewhere around there or plus ports that you can use. So to kind of, you know, talk about our points, well, okay, you've got VNC blocked in or blocked from the outside coming in, right? But, you know, port 5900, if I remember correctly, you can relay a session. So imagine, okay, well, I can't get in through VNC port from the outside, but they've got everything else inside open. I got a guest network. I haven't segmented my stuff. I can now, you know, after doing my bad deeds, I can now shovel that port outside and, you know, put it somewhere else on my server or somebody else and capture whatever I need to kind of also drive the point home, you know, where's your presentation? When I was talking about the ESS IDs now, think of what we just talked about and then apply that to corporations like, you know, if it's a bank, if it's a hospital, if it's a gas company, you know, these are common targets these days. These are something that most of us, not all of us are responsible for defending. And a lot of times, you know, when we do print out those reports and say, you know what, NTP, you have outbound? No. DNS, you have at least, you know, if you've got to go out, you have at least a trusted or, you know, up-isolate policy, you don't. And look at how many attacks are there. There's a lot of bad things happening. It's big and it can damage you really, really good. Remember I said earlier, it takes one or even a half. All right. So just to give sort of a neat light at the end of the tunnels, we do have road maps for the pieces of software that we've actually written. I hope that it would help other people mitigate these risks. So first off, I want to do better triangulation algorithms. It turns out that the strength value that I'm basing a lot of this, like sort of detection of where you are, is sort of, is really based on a static value that just some guy that was working on Android does sort of shovel on it and all strengths are based off of a comparison to that value. So you don't really know how accurate that information is. I would really like to add in like a real-time Wi-Fi map. So if you had like, say, two people walking around with this sort of stuff, you can actually complement each other's information as you're going. Two points are better than one. Triangulation. I'd like to absorb a lot of the scripts that Pete was showing from like just Python and shell scripts and everything like that, straight on into Java, right, in the Android app itself. It turns out that the, a lot of the stuff that he's doing, you can do if you're a little creative with the default libraries that Android provides. And also I would like to do easier integration points for any other tool to use this information somehow. So for the other module, end map scanning, I would like to, well, actually it's done and it works beautifully. Printed out a nice table and everything. But we couldn't do it this time. I'd like to make this section or WarGarble more modular. So instead of just using the, what do you call it? No, the cellular, the mobile section. You can take parts of it and then put that in other pieces of your network, say, you know, for mission critical sections or certain servers that, you know, need to talk to each other only. It's amazing what it does. Kind of goes through there without even knowing. A notification process, maybe, you know, shoot an email, make it reporting a little bit easier, you know, automate it, run it, send an email to your system and CIOs, managers, what not to see, you know, what's going on and kind of keep track of, you know, any outstanding issues and your plans to fix things. The last one, possible, bought like a deployment, you know, trying to make WarGarble a little bit more evil to kind of drive points home and, you know, another step above to make it a little bit more aggressive. There is a framework that's done. It's very in its infancy stages, but hopefully we really do want to come back and have a more finished and polished product. So for my part, I have a plan to integrate all the new features that the PDE and Josh are going to have on the client side. You want to add a search capability on the centralized system where if you are trying to analyze the source IP address in your system for your day-to-day analytics, you should be able to know that this fingerprint, this public fingerprint can mean the sources could be anywhere. So it's like a TorExit node, for example, right? So you should be able to identify them. So that feature would be nice. Also, a client-side browser-based JavaScript scanner would be a cool addition, which I showed you, it works flawlessly. You don't need to download any code. Go to the website and the scan will tell you for penetration testers or anyone who is trying to analyze your network from security perspective, but ports are allowed. So we'll let anyone do that. And lastly, I still need to do a lot of security sanitization checks. When you parse the CSV files, it's susceptible to injection attacks. So that work has still to be done. But nevertheless, this code that we are working on is going to be available on GitHub. It's not posted there yet, but within a week or two, we'll upload so anyone can have a copy of it. And that's about it. Open for questions. Have you heard of the legal issues? We talked to our lawyer. Yeah, we have a legal team at TELUS, right? So they can wait. Yeah, so for a scanning port, yes, scanning is not allowed, right? It shouldn't be done, but this is for penetration testers. So you need to have the authorization from the network you are trying to scan. Without that, of course, you shouldn't be doing it. But I think hackers don't practice legal laws, right? So we have to be aware of that, right? We're hopefully looking to change our name of the product to something better. Thanks guys for your time and we appreciate it. If you have any questions, let us know.
 presentation here is called guesses in goblins, expose in Wi-Fi X filtration and mitigation  techniques. With me is Pete and Naveed. We'll get to some more formal  introductions in a little bit. Full disclosure, we all work for a company called  TELUS. It's a yes. We have like one representative here. Two? Oh, hey, guys. So yeah, we're a  telecommunication company based out of Canada. One of the big three there. So just to let you  know. Anyways, as I already said, my name is Josh. I basically have been working with Sims for  the past 10 plus years. By night I work on my boat that I've been living on for six years, even in  winter, which is fun. So general hobbies, cards against humanity and movies that nobody should  watch in their right mind whatsoever. All right. And on to Pete. Hi. Hi, I'm Pete. I live in a cave. I  don't really get out that much. I don't really know how to talk either. That's why I got these two  guys with me today. Thanks, guys. So by day I'm a security analyst. Just bearing my nose into  screens and stuff, packets. By night I like to break things. And then my hobbies are breaking  more things. I always end up with more screws. I don't know how every time. Damn screws. And  here's Naveed. Hello, everyone. My name is Naveed as introduced already. I'm a team lead for the  Cyber Security Intelligence Unit. Pete and Josh, we work together. My job is to keep an eye on the  emerging and developing threats on the outside of the network. So what's happening, I keep an eye  on the customer from the customer prem if it's a threat for them or not. So we do  intelligent analysis and provide analytics for the events that are happening inside. So  keeping an eye on all the IPs that are coming in is part of a job. So a little background of  this project. So anonymity is important for many reasons. It's also a problem too. So a lot of  people know about Tor, L2P, SpotLux and Hola. They hide your public IP address from the people  who are monitoring them. But the question is what is your fingerprint? What is your IP  fingerprint? And how good it is? So if you are on a Tor network, your fingerprint is going to be the  Tor exit node. Is it going to help us, the people who are on the monitoring side, identify who  the person is? So adding to that complexity, we are going to talk about Wi-Fi and using Wi-Fi as a  way to hide your public fingerprint. Anyone here heard about proxy ham?  Anyone who doesn't know what happened on proxy ham?  We don't know either. So little introduction about Wi-Fi challenges. We all know the security is a big  concern. But if you are an enterprise, you are deploying a Wi-Fi network, you only try to  isolate it. You try to deploy the latest encryption, which is WPA 2.0, yes, everything is good.  However, is it really secure? Is it helping you, helping you protect against any implications that you  may have, which we will talk about more in the future. One reason is to deploy all these Wi-Fi  networks is to have the competitive convenience, as you may say. Because if your competitor is  providing this convenient interface, you want to do the same as well, right? So for the problem  space and the risk associated, I'm going to switch to Josh.  Thanks, Navid. So just a quick question for everybody. How many people here use Wi-Fi? Hands  up. How many people trust Wi-Fi? But we all use it. That's a little weird when you think about it.  Anyways, so as we're saying, as our presentation is titled, Wi-Fi exfiltration, what can you do going  outbound versus inbound? So one thing that we're somewhat concerned about is a sort of post  implication and as a result of that, smear campaigns. Great example, right? We have at  TELUS, as most other places have, it's like an open guest Wi-Fi or other Wi-Fi that can be  wiggled around. Oh, sorry. Is that better? Hey, all right. Sorry about that. Anyways, so one of  the things that we're actually concerned about is sort of the results of people getting into your  Wi-Fi and tunneling on out and doing stuff. Great example, TELUS has open Wi-Fi for users to  get onto and we also have secure that maybe it can wiggle around. The problem is with exfiltration,  not a lot of people are actually monitoring outbound traffic as to what's going on with it. A lot of  people monitor outside coming in but not a lot monitor inside going out very well or at all as  we've found. So let's paint a quick scenario. TELUS has open Wi-Fi, our major competitor up in  Canada, happens to be Rogers. What if somebody decided to jump onto our network and launch a  form of attack through our network to Rogers? The smear campaign would more or less read that  TELUS was implicated in a massive attack against Rogers. Even though it wasn't, you know, TELUS  itself actually doing the actual attack, it's already in the news, it's too late, people are  going to lose faith in TELUS itself. So we were quite concerned about that. Is there anything?  Sorry. In branding in general is just something that a lot of companies and corporations spend  millions and millions of dollars for. So besides the whole TELUS thing, it could be anybody and it  just takes one incident, even a small one, to have any amount there and you're done.  All right. And on to Naveed. Okay. So when you're deploying Wi-Fi, we are generally in a  catch-22 situation, right? Convenience versus security. And the challenge is that you have to  provide a connection before you actually can authorize. So what you do, you ask for an email  address, the person provides an email address and you have to blindly trust him. Because  generally you need to send a verification code on the email and how are you going to check the  verification code if the customer or your guest cannot access to his email address. So we  just generally enter an email address and just blindly trust and let the guest join the network  and here we go. So that is a big problem. Lack of figures, monitoring already mentioned.  Default SSL is another problem. Every web page now is switching to SSL. So you can't really  provide monitoring on what's going out from your guest network. In addition, on top of the  spoofed MAC address is that if you have allowed someone, even though you have authenticated  him, you can have a person spoofing his MAC address and here we go. Taking his identity.  Introduction to our concepts. So our concept. We have developed a custom mobile app that  relies on some batch scripts. Two servers with dedicated IPs. They scan for open Wi-Fi. Currently  right now if there is anything dash guest that needs a page to log into, we are still kind of  working on but for the sake of this, just straight open. It tags the location, connects  automatically to the network, learns about the network, collects public fingerprints and  syncs with the central server. So there is a list of stuff that we have spent many weekends  banging our head against the wall and crash-coursing through for tools. Hardware, simple stuff.  Cali Linux, Android phone and a couple of Ubuntu servers. The toolkit or suite is broken up  into three pieces. It's more scamble which is the initial area scan and discovery. We're  garbled at connectivity and data collection and finally we're repo reporting reports and does the  results from all of the data collecting. All right. So back to me. This is my part. I made  more scamble. So what is it in a nutshell? It's basically just a Wi-Fi scanner with some really  handy features built right on into it. Such as it gathers coordinate information, which are  encryption used, names, BSS IDs, etc. Anything that it can find, it will just store. So how does  it do it? Step one, scan for all the access points. Step two, put all the results into an  object that stores two types of values, static values, so things like your BSS ID, your ESS ID,  etc. And then some flexible values, so your location and your signal strength. I'll come back  to that later just to explain why that is what it is. All right. And then three, we enhance the  location data by comparing new data to existing data and then through that process we select a  signal. So let's go to the updating entries to cover that flexible data information. So when you  first connect to an access point, it will generally tell you about how strong that signal  actually is. We decide to take it one step further and compare it iteratively. So while you're  walking, it's going to be taking samples on a frequent basis and as it's going along, as the  signal increases, it's going to update the location of the wireless access point so we can find the  exact location of where that access point actually exists. Once the signal strength starts to dip,  it stops updating that location. There are some issues with this technique which I will cover  right at the end of the presentation. But it actually works pretty darn good just by basically  using this. All right. So how do we select a candidate? First, do we have any results whatsoever?  If the answer is yes, then we look for the strongest access point. We then pass that off and  say, hey, is it unencrypted? If the answer is yes, then we pass it off to Pete's scripts. If the  answer is no and doesn't have weak encryption, then maybe we can pass it off to Pete's  scripts and stuff will happen. In any case, we still store the information for later usage. You  may end up in a situation where you actually get multiple strong access points but you're only  going to be able to connect to one because let's face it, Android phones generally don't have  like network cards hanging off the sides of them, just generally one. Yet. So then we store the  results and we go back and we just start iterating over that information over and over and just keep  updating the information. So here's a screen cap of the app itself. This is actually just  something we picked up last night when we were wandering around our hotel room. So if you  would like a live demo of this, come find me. I'll be hanging around a little bit and it's  actually just currently running on my phone in sort of like a limited capacity just to make  sure it's not doing anything iffy. And now we go on to Wargarble. So once all that data is  collected, it's passed on to me or my module. Basically I take everything that he gave me, I  strip it and parse it and I look generally for just open networks. I then connect to that same  network, find out your public gateway from the inside and then I make an outbound handshake  connection or I connect to an echo server to determine what ports are open based on a  range or port specified in config. And what I mean is talking about ports that are allowed  outside, 80, whatever that's allowed outbound from any policies, gateway firewalls, et cetera. I  then store the results in a database for final parsing, for final phase of reporting and  plotting, which is handed off to Naveed. How does it work? It uses a combination of bash,  set, awk, SQLite, head banging, Python sockets to our mode server and lots of crying. So this  one here, I'll get back to it again a little part of it. But basically this is just one  question of some of the sets that we've collected and just to go over quickly, we've  collected the BSS IDs, that's the MAC addresses of the APs, the names of them, the ESS IDs.  Auth mode is encryption type. So in this particular app, ESS is open, there's WPA, WAP,  ISMSS and cell. It also gets the latitude and longitude, which is taken from the phone or  device itself and then the public gateway. Before Naveed talks about his part, one other  section here is that for the echo server, it also grabs the, sorry, when you see the  longitude, it's for the device. But when the echo server happens and we get those IPs, those  longitude and latitudes are the longitude and latitudes of the public gateway, which you'll  see later why that's important. Okay, so my part basically is the visualization of the  data that we have collected using Josh and P. Sewell. So this is the basic idea of  centralized collection. But there's a second part to it, which is our reversal scan engine. So in  addition to just plotting the latitude and longitude for client and the server or the  public side of the connection, we have a server that responds to all the ports which you ask and  test for. So the client side scans and gets the response of the open ports which are available. So  this server is running a node.js instance, which responds to pretty much a range of port which is  preconfigured into it. The technology behind basically was planned to be SQL IP, PHP, IP  tables and bash. But then I was like, let's give it a try with new technologies. So node.js  plus Meteor is fantastic framework. It does let you have a real time web front end. Plus  MongoDB is a JSON oriented object database. So it's very interesting. Feel free to try it out.  Basically this is what it lets you plot. Once you have the data, the server shows you the client  SSID, the public fingerprint that you will be represented as on the internet and the location.  So if you are connected here to the monitoring people who are monitoring your traffic, you will  appear here in this part of the city. And the scan results for the reversal tool that we just  talked about. I will tell you that if you are using this open Wi-Fi connection, you are allowed to  go out on all these ports. 1,000 to 1,572 and 1,574 to 2,000 as an example. This is a fixed range.  You can expand to any ports you want. Now to demo. How much time we have? Okay. So the tool, like I  said, is a meteor instance of real time web. So I'm going to start it here. Can screen is good enough?  Big enough? No. It's best for retina display. Hold on a second.  This is what happens when you use a Mac, I guess.  All right. So once we have the meteor running, the website updates itself. And there's no need to  zoom that. Okay. So what Pete skip does, it collects that data from Josh and attaches the  coordinates. And once data is compiled and database, it produces a CSV file. So this instance  here that I'm running, it can accept data using SSH. You can upload to the system. The system  will keep an eye on the folder. Once CSV is detected, it's going to compile it. A better way, however,  the second option I have is a manual upload too. And that's what I'm going to show right now. So  let's plot the Toronto results that we scanned before coming here. The file is being uploaded.  You can see it is reading the port information from the scan. And once done, I'm going to refresh  the page. And it's pretty much the same plot that I showed you in the previous slide. I can  open that information from monitoring VAN connected to this gas network. You're appearing  here basically in GTA from Richmond Hill. A better example, however, was when Josh was  taking a ride on V-Rail. I'm going to open this scan one, this CSV file. And once it's  processed, yep, I'm going to refresh the page here. And you can see the rail was in Union Station  Toronto. Sorry. So Josh, you can...  Yeah, so basically I was just on a trip and I decided to poke around just to see where we were  exiting. And while I was actually waiting for the train to move, my exit point for the free  Wi-Fi on the train was saying that I was in Ottawa. So that got me to sort of thinking,  well, at Union Station in Toronto, we also get Amtrak. Where does that exit? Right? So  does it exit in the States? Who knows? We haven't actually tried it. I don't generally run on  the trains as much as I should, I guess. But it also got us to thinking about other sort of  situations such as multinational companies and stuff like that. Where did their access  points actually exit? Did they just set it up local? In some cases, yes. Do they set it up  remotely just by tunneling across a network? Quite possibly. So if you want to exfiltrate  information from, say, one country to another, this could be a way you could do it. This is  actually concerned about this sort of thing. Keep an eye on this. Just to add that, you know,  have one more random sample. Once the data is imported, I'm going to refresh it. You can see  some of the ‑‑ This is what happens when you have to make data manually in the last  minute. Thanks, Pete. So entry point maybe in Canada, exit point in the different part of  the world. Okay. So that's part of the server side. For the client side, the reverse or the one  that detects the ports on the egress traffic, I'm going to show here in 12 plus again. So this  is a Python script that talks to the server. And if you run it, the server which is responding  on the other side is telling us that this port is allowed, that port is allowed. And you can ‑‑  we are making a list and the mapping based on the script here. Now, an interesting side of the  story is that you don't need Python or any other server side script. The whole scanning can  also be done on the client side using WebSockets. Thanks to HTML5. I think I have written a  code script here that I can show you. So I have a Node.js instance running locally. So it's not  listening to all the ports on this machine, but you will get the idea. So if I run the command  in the browser, to reverse the local IP and the port range, it's going to tell me that all the  WebSockets which are blocked and the ones that are allowed. So I guess the server is not running  yet. Let me put this on. Yep. Now I'm going to turn it on on one port only and rerun my scan.  You can see the client detected 1337 as open port. So you can map just with the browser.  Okay. Off to Josh. All right. So like you can see, we are actually quite concerned about this. So,  you know, full disclosure, this was not actually the first convention that we actually submitted  this presentation to. This is the second one. The first one we actually tried to get ourselves  into was Sektor, which tends to be more sort of for the sort of people that we end up working  with on 9 times out of 10, right? So we presented this to them as like, you know, hey, you guys  should really watch what sort of traffic is actually leaving your network. You could be  implicated. Bad stuff could be happening. People could be using you for all sorts of really  weird things. Please let us tell our story. And we got a resounding meh, which was kind of disheartening  really. So, and unfortunately it happens more often than not. If it's not shiny and flashy,  it's people just aren't interested. So the mitigation techniques that we would actually like  to present as an option to actually just sort of try to hold back this, right? Auditon review  your traffic and firewall policies both ways. A lot of people do ingress on a somewhat  frequent basis, but egress is usually done when they decide to install the device. And that's  about it. Tune your appliances and applications. In my line of work with Sims, I see a lot of  logs coming from devices that have just been literally plopped in place, wires plugged in,  power goes on, everybody goes, hey, it's doing something. And that's it. That's really bad.  We really need to make sure you're actually tuning and looking at the right information and  collecting accurate information. The third point is pretty obvious, right? Like just segment  your infrastructure, isolate your wireless access points entirely. One that was sort of linked  to the whole presentation where we got the resounding meh from people was listen to your  minions, right? More often than not, we'll actually go on up and say we're really concerned about  this. We could get hurt. Please, can we do something about it? It's not really in the budget.  It doesn't sound all that interesting. How severe is it? It's bad. Please listen to us and  believe us just once. And also, finally, know your clients. So know who is connecting to your  wireless access points, which sort of ties back to just doing monitoring for all egress traffic and  making sure everything is properly segmented. If you don't know who is connecting to you, how are  you going to stop them from doing things that they shouldn't be doing?  Any other guys? Very good. I blame POCs for vendors a lot of times. But it's exactly what Josh  said is vendors go in and they, you know, create products and whatnot and they go in and  catch the corporation, right? They just drop in, said IPS or said firewall or said whatever  next gen. And who, who's caught everything? We'll leave it the way it is. We're secure. No.  They need to understand or people need to understand, you know, that even port wise and  policies, there's more to just a few things. So for example, there's some protocols have  suite. So we all know VNC. VNC actually has a good O5 somewhere around there or plus ports  that you can use. So to kind of, you know, talk about our points, well, okay, you've got VNC  blocked in or blocked from the outside coming in, right? But, you know, port 5900, if I  remember correctly, you can relay a session. So imagine, okay, well, I can't get in through  VNC port from the outside, but they've got everything else inside open. I got a guest  network. I haven't segmented my stuff. I can now, you know, after doing my bad deeds, I can  now shovel that port outside and, you know, put it somewhere else on my server or somebody  else and capture whatever I need to kind of also drive the point home, you know, where's  your presentation? When I was talking about the ESS IDs now, think of what we just talked  about and then apply that to corporations like, you know, if it's a bank, if it's a hospital, if  it's a gas company, you know, these are common targets these days. These are something that  most of us, not all of us are responsible for defending. And a lot of times, you know, when  we do print out those reports and say, you know what, NTP, you have outbound? No. DNS, you  have at least, you know, if you've got to go out, you have at least a trusted or, you know,  up-isolate policy, you don't. And look at how many attacks are there. There's a lot of bad  things happening. It's big and it can damage you really, really good. Remember I said earlier, it  takes one or even a half. All right. So just to give sort of a neat light at the end of the  tunnels, we do have road maps for the pieces of software that we've actually written. I hope  that it would help other people mitigate these risks. So first off, I want to do better triangulation  algorithms. It turns out that the strength value that I'm basing a lot of this, like sort of  detection of where you are, is sort of, is really based on a static value that just some guy that  was working on Android does sort of shovel on it and all strengths are based off of a  comparison to that value. So you don't really know how accurate that information is. I would  really like to add in like a real-time Wi-Fi map. So if you had like, say, two people walking  around with this sort of stuff, you can actually complement each other's information as you're  going. Two points are better than one. Triangulation. I'd like to absorb a lot of the  scripts that Pete was showing from like just Python and shell scripts and everything like  that, straight on into Java, right, in the Android app itself. It turns out that the, a lot of  the stuff that he's doing, you can do if you're a little creative with the default libraries that  Android provides. And also I would like to do easier integration points for any other tool to  use this information somehow. So for the other module, end map scanning, I would like to, well,  actually it's done and it works beautifully. Printed out a nice table and everything. But we  couldn't do it this time. I'd like to make this section or WarGarble more modular. So instead of  just using the, what do you call it? No, the cellular, the mobile section. You can take parts  of it and then put that in other pieces of your network, say, you know, for mission critical  sections or certain servers that, you know, need to talk to each other only. It's amazing what  it does. Kind of goes through there without even knowing. A notification process, maybe, you know,  shoot an email, make it reporting a little bit easier, you know, automate it, run it, send an  email to your system and CIOs, managers, what not to see, you know, what's going on and kind of keep  track of, you know, any outstanding issues and your plans to fix things. The last one,  possible, bought like a deployment, you know, trying to make WarGarble a little bit more  evil to kind of drive points home and, you know, another step above to make it a little bit  more aggressive. There is a framework that's done. It's very in its infancy stages, but hopefully  we really do want to come back and have a more finished and polished product.  So for my part, I have a plan to integrate all the new features that the PDE and Josh are going to  have on the client side. You want to add a search capability on the centralized system where if  you are trying to analyze the source IP address in your system for your day-to-day  analytics, you should be able to know that this fingerprint, this public fingerprint can mean  the sources could be anywhere. So it's like a TorExit node, for example, right? So you should be  able to identify them. So that feature would be nice. Also, a client-side browser-based  JavaScript scanner would be a cool addition, which I showed you, it works flawlessly. You  don't need to download any code. Go to the website and the scan will tell you for penetration  testers or anyone who is trying to analyze your network from security perspective, but  ports are allowed. So we'll let anyone do that. And lastly, I still need to do a lot of security  sanitization checks. When you parse the CSV files, it's susceptible to injection attacks. So that  work has still to be done. But nevertheless, this code that we are working on is going to be  available on GitHub. It's not posted there yet, but within a week or two, we'll upload so anyone  can have a copy of it. And that's about it. Open for questions.  Have you heard of the legal issues? We talked to our lawyer. Yeah, we have a legal team at  TELUS, right? So they can wait. Yeah, so for a scanning port, yes, scanning is not allowed, right?  It shouldn't be done, but this is for penetration testers. So you need to have the authorization  from the network you are trying to scan. Without that, of course, you shouldn't be doing it.  But I think hackers don't practice legal laws, right? So we have to be aware of that, right?  We're hopefully looking to change our name of the product to something better. Thanks guys for your time and we  appreciate it. If you have any questions, let us know.
DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_0_815.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_816_12551.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_12552_12887.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_12888_15311.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_15312_16535.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_16536_17855.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_17856_18491.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_18492_24083.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_24084_25223.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_25224_25415.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_25416_25787.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_25788_25907.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_25908_26195.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26196_26267.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26268_26375.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26376_26459.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26460_26567.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26568_26963.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_26964_27011.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_27012_27599.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_27600_27755.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_27756_27887.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_27888_28391.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_28392_28499.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_28500_28595.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_28596_28703.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_28704_30647.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_30648_31127.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31128_31175.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31176_31223.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31224_31355.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31356_31427.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31428_31475.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31476_31583.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31584_31703.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_31704_32291.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_32292_32399.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_32400_32939.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_32940_32987.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_32988_33119.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_33120_33179.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_33180_33467.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_33468_40235.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_40236_41771.png DEF_CON_-_Panel_-_Guests_N_Goblins__Exposing_Wi_Fi_Exfiltration_Risks_and_Mitigation_H_Kp7Bul4I0_41772_49968.png