 our presentation here is called guests in goblins, expose 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. Nice. 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. Anyhow, 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 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, about L2P, Spotlux, and Hola. They're gaining popularity. They hide your public IP address from the people who are monitoring them. But the question is that 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're going to talk about Wi-Fi and using Wi-Fi as a way to hide your public fingerprint. Anyone here heard about proxy ham? We don't know either. So a little introduction about Wi-Fi challenges. We all know the security is a big concern. But if you're an enterprise, and you're 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 protect against any implications that you may have, which I will talk about more in the future? One reason is to deploy all these Wi-Fi guest 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. All right. 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, as most other places have, it's like an open guest Wi-Fi or other Wi-Fi that can be, you know, 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, like, secure that, you know, 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 just a quick scenario. TELUS has open Wi-Fi, our major competitor up in Canada, happens to be Rogers. What if somebody decide 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? Okay, sorry. In branding in general is just something that a lot of companies and corporations spend millions and millions of dollars for. So, you know, besides the whole TELUS thing, it could be anybody and it just takes one incident, even a small one, to have your name out there and you're done. All right, and on to Naveed. Okay, so when you're deploying a Wi-Fi guest network, you're 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 generally enter an email address and we 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 addresses 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've 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's anything dash guest that needs a page to log into, we're 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's a list of stuff that we've spent many weekends banging our head against the wall and crash-coursing through for tools. Hardware, simple stuff, Kali Linux, an Android phone and a couple of Ubuntu servers. The toolkit or suite is broken up into three pieces. It's or Scamble, which is the initial area scanned and discovery. We're Garbo. It's connectivity and data collection. And finally, we're repo for reporting reports and does the results from all 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. So such as it gathers coordinate information, which are encryptions used, names, BSSIDs, ESSIDs, et cetera, et cetera, et cetera. Anything that it can find, it will just store. All right? So how does it do it? So 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 BSSID, your ESSID, et cetera. 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 candidate. 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 decided to actually just 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 that 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 like, hey, is it unencrypted? If the answer is yes, then we pass it off to Pete Scripps. If the answer is no, and does it have weak encryption, then maybe we can pass it off to Pete Scripps 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 that we just picked up last night when we were wandering around our hotel room. So if you would actually like a live demo of this later on, 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 War Garble. 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, headbanging, 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 section 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 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 get 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. So 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, you can, 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 a demo. How much time we have? Okay. So the tool, like I said, is Meteor instance of real time web. So I'm going to start it here. Can screen is good enough? Like big enough? No. Oh, it's best for retina display, so I shouldn't complain. Yeah. Hold on a second. This is what happens when you use a Mac, I guess. So once we have the Meteor running, the website updates itself and there's no need to zoom that. Okay. So what PeteSkip does, it collects that data from Josh and attaches the coordinates and once data is compiled in 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 trontor results that we scanned before coming here. The file has been 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 VRail, 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... Yes, so basically I was just on a trip and I decided to poke around just to see where we were actually 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, right? 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 like other sort of situations such as like 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 like tunneling across a network? Quite possibly, right? So if you want to exfiltrate information from say one country to another, this could be a way you could do it, this sort of thing. This is why we're actually concerned about this sort of thing is keep an eye on this. Just to add that, you know, I have one more random sample. Very random. So you can, 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 this 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've 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'll get the idea. So if I run the command in the browser, it is reversal, the local IP and the port range is 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 build 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're 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 nine times out of ten, 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'd actually like to present as an option to actually just sort of try to hold back this, right? Audit and review your traffic and firewall policies, both ways. A lot of people do egress on a somewhat frequent basis, but egress is usually done when they decide to install the device. And that's about it, right? 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 in to looking at the right information, and that it's actually collecting accurate information. The third point is pretty obvious, right? 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, you know, please, can we do something about it? And it's like, well, you know, it's not really in the budget. It doesn't sound all that interesting. How severe is it really? It's like, look, it's bad. Please listen to us and like believe us just once. Anyways, 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 the egress traffic and making sure everything's properly segmented. If you don't know who's connecting to you, how are you going to stop them from doing, you know, things that they shouldn't be doing? Any one of the guys who are good? I blame POCs for vendors a lot of times, but it's exactly what Josh said is, you know, vendors go in and they, you know, create products and whatnot, and they go in and, you know, they catch the corporation, right? They just drop in, said IPS or said firewall or said whatever, next gen. And who, who's caught everything? Oh, we'll leave it the way it is. We're secure. No. You know, 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 of suite. So, we all know VNC. VNC actually has a good O5 somewhere around there 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, you know, segmented my stuff. I can now, you know, after doing my good, 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, I'm 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, do you have outbound? No. DNS, do you have at least, you know, if you got to go out, do you have at least a trusted or, you know, closed up, isolated policy? You don't. And look at how many DNS attacks are there, there are nobody's, you know, listening and taking into consideration that, you know, 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 bit of neat light at the end of the tunnels, we do actually have road maps for the pieces of software that we've actually written. I hope that it would actually help other people sort of 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 has sort of shoveled on in 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 two points or better than one triangulation yada yada yada. 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 like 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 like 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. Print 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, 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 else kind of goes through there without even you 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 ins, 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. Okay, so for my part, I have a plan to integrate all the new features that the PD 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 a 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 toll exit note, 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 whether it's a security system or a authentication test or anyone who is trying to analyze your network from a security perspective, but ports are allowed. So it will 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 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 will upload so anyone can have a copy of it. And that's about it. Open for questions. We'll talk to our lawyer. Yeah, we have a legal team at TELUS, right? So they can wait. Yeah, so for a scanning port, yeah, scanning is not allowed, right? It's not legally... 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? Yeah. We're hopefully looking to change our name of the product to something better. Well, thanks, guys, for your time, and we appreciate it. If you have any questions, let us know. Thank you.