 So if you've been hanging around in track one all day like I have, so far we've learned how to overthrow a government and cause mass anarchy. Then we learned how to create survival tools after you've created the anarchy. But just speaking more generally, I think we're going to learn something here that is practical, which is bypassing captive portals, which very clearly people have some interest in. So let's give Grant a big round of applause and our laptop loner. All right. Hello, everybody. I'm going to have to go pretty quickly as I've only got about 15 minutes here. So first of all, a bit about myself, but not very much. I've been hacking and coding for a long time, and I like giving talks at DEF CON. I'm a generalist in security. I've done various programming infrastructure, etc. I also have perimeter grid, which is my security blog and personal consulting. A few disclaimers. This is my own research. I have an employer. This talk has nothing to do with them. Also, this talk was submitted to DEF CON 101. They put me in the big room because they thought a lot of people would be interested in looking at this room. It seems they were right. But nevertheless, if you're a professional pen tester, you're going to be bored. This is not dropping great new attacks. This is showing you how to use some existing tools. And finally, in the United States, doing any of this stuff on a network, you are not authorized access is super illegal. So captive portals. Captive portals are a very primitive type of network access protection. And they consist of an open network, either Ethernet, DOCSIS, or open Wi-Fi, usually open Wi-Fi. And on initial join, you can only go to one website, the captive portal, and it doesn't let you into anything else. And then that limited website can authorize access to more. So you've seen these everywhere. Every store, office, restaurant, Wi-Fi, hotel, and airline internet, guest networks at corporations, and even some telecom networks like subscription hotspots. These are not real network access protection. They're not using 802.1x. They're not using real cryptography. They are attempting to put a small barrier in front of you that they hope you don't know the way around. And as a result, they don't have a real security boundary. And they're pretty easy to circumvent. They rely on obedient network clients, network clients that are going to behave the way network clients normally do. They use, they're either an authenticated proxy or Mac filtering on the gateway, usually Mac filtering on the gateway governed with IP tables, tables rules. There's very little variety in these. They may look all different, but there's a piece of open source software called ChiliSpot. It's built into OpenWRT. It's available in most Linux's package managers. It requires you to have a web server and a radius server if you want to authenticate users. It's fairly easy to set up. And basically everything's just ChiliSpot. WorldSpot.net, hotspot systems, Sputnik, hotspot express, Wi-Fi soft, SkyRove, they're all just ChiliSpot. If they're not ChiliSpot, they're for all intents and purposes a ChiliSpot clone to the point where I can't tell the difference just looking at the software from outside. In addition, even if it isn't ChiliSpot, it basically still is. It's still a website writing IP tables rules. So if you want to be able to get around this, you actually need to do some advanced preparation. You need to have an endpoint that you can tunnel your traffic to. And so tunneling is just moving one protocol via another. Usually you use an encrypted protocol, but you wouldn't have to. You can use a completely clear text tunnel. But you need some server to act as the other end of your tunnel. And that means you need a port or protocol that the captive portal isn't blocking. So sometimes HTTPS and SSH are unblocked on specific ports. In addition, DNS is basically always unblocked because of DNS recursion. You can reach the local DNS and it will then proxy your DNS queries out to the internet. So we need to set up a server. Any internet accessible server, any cheap VPS that lets you control all ports will use. So it will work. So you can't use like a shared web host account because you usually only get 80 and 443. You could even use your own home PC if you want to open these ports to the internet on it, which I don't think is a great idea because you can get a cheap or free AWS or Azure node from and just let Amazon or Microsoft provide you your endpoint. So some end points we want to set up. HTTPS proxy, SSH and iodine, which I'll talk a little more about. And also be sure you open the ports you set up on your server's firewall. So any decent VPS will come with SSH enabled. So go ahead and add port 3128 to that as well as any other ports you might think is useful to connect to. Depending on the specific captive portals you're after, the ports available may be different. While you're at a disabled insecure log on SSH, just because you should do that anyway. And ensure you have a public key available so you're not doing password login. So Google App Engine, Google uses a front door service. All Google services are behind the same IPs. So if a captive portal allows access to Google, it also allows access to Google App Engine, which means you can run your proxy behind Google's front door. And the same access the captive portals using the download ads will also let you get to your tunnel. So you just get your App Engine account, install Python in the App Engine SDK, and you can find code online, like there's a piece of software called Mirror with 3Rs that is an App Engine compatible Python proxy. Just go ahead and put that in there. And you can now browse to yourappid.appspot.com and get to your own proxy. Then there's a piece of software called Iodine. Iodine is IP over DNS. And there are several IP over DNS packages. I like Iodine because it's actually still supported and it works on Windows, which is not the case for most of them. So on your VPS, you install Iodine and then you run it as a root with password you make up and a subdomain that's going to be used to forward DNS queries to you. On your DNS server, you need to create a custom record for the subdomain and for the name server. So like mine is t.parametergrid.com. So I create a DNS record for ns, the nameserver.tparameter grid.com and then I create a name server record pointing back there. So now DNS queries on the internet to t.parametergrid.com will go to my Iodine install. And if you don't have a DNS server, namecheap free DNS is free. Amazon route 53 isn't free but is also configurable so you can use those. Finally, you may want to set up an HTTPS proxy. It's kind of low value. Most captive portals are too smart to fall for this. But if you have a network that allows web traffic and not other traffic, this can be useful as a way to tunnel other protocols. So then you need to prepare your client. The laptop you're going to actually use when you're wanting to do a bypass. So on a hostile network, you're not going to have internet. So that means you have to set all this stuff up before you're on a restricted network. Ideally, you're going to use Linux or Cali but Windows will actually work fine for most of these. The only thing it won't is potentially Mac changing. Most Windows drivers don't support changing the Mac address of your card but there are some USB network cards with great support for Windows. Like the Alpha Networks cards with real tech and atheros chipsets which by the way you can get down in the Defcon vendor room. I bought a lot of them there. And you can always run Linux or Cali in Hyper-V or Virtual Box and make use of it that way. Pre-install tools. You need an SSH client. Linux has it built in if you're on Windows. I like MOBA X term but you can use Putty or whatever you want. A copy of Iodine, a wire shark on Windows or Air Crack NG if you're on Linux. Nmap and an HTTP debugging proxy would be nice. None of the bypasses I go through in this talk use that but sometimes you can actually take advantage of the captive portal itself. They have bugs in them. So then we get to, okay what are we doing? We want to actually exploit this. So you're on a network with a captive portal. First thing you want to do is use IPconfig or IFconfig on Linux. See your current IP and find out what the gateway is. So once you know what the gateway is, go ahead and use Nmap to see what's on your local subnet, see what's on the gateway. You're looking on the gateway for proxies. TCP 3128 which is the default port for squid is always promising. But there are, it could be on any port really. They could have it to whatever they want. Also look to see if there's DNS. They're almost certainly is. And any other unknown ports that you might want to try sending traffic to in case they're proxy. So try connecting to possible proxy ports. Try connecting to your server through them. Overport numbers open on the gateway. Now admittedly that should never work just because the port's open on the gateway doesn't mean it should be open to anything else. But sometimes it does work. It was well known for a while that this worked on go-go in-flight. They have fixed that. But that was a vulnerability in a well-known hotspot service. So then try setting your proxy to your App Engine endpoint. If the Coptif portal is ad supported, this will probably work. If it's not ad supported though, this doesn't always work. So then try DNS look-ups. This is the most reliable method. And if a DNS look-up works, then try looking up your iodine domain. So if you have a route to a working proxy, whether App Engine or your server or the gateways, you're done. Configure your browser and you're out. Otherwise if you can SSH to your server through any of those ports, do that and then do an SSH-D, which creates a local SOX proxy on your computer that routes through that tunnel and configure your browser to go through there. If you can look up your iodine DNS, then you just run iodine with the appropriate password and subdomain and now you've got a tunnel out. And through that tunnel, you SSH and do the proxy. So you're using your own tunnel to get out. And I'll demo this one. And then finally, you need to fix your routing to point through the new tunnel. If you're using SSH-D, that's actually the easiest way to do it, just point to the SOX proxy and do it that way. Alternately though, you can actually edit the route table on your computer to make your new default route, go through the tunnel and at that point everything works through it. Alright, if nothing else fails, or nothing else works rather, ChiliSpot is just configuring MAC filters. So our last ditch way through is use AeroDumpNG to watch the traffic and look for a MAC address that is in use for a while then stops being used. That's probably someone who accessed the captive portal and then shut their laptop off. So you just clone your MAC address to that MAC address and jump on the network and you're already allowed through the IP filters. You want to look for a network someone stopped using because if you and someone else are both using the same MAC address, every time one of you transmits, you'll de-off the other and so your network connectivity will be absolutely horrible. It can work, but it's going to be really slow. On Windows, you can use Wireshark instead of AeroDumpNG and you can look in device manager and try to change MAC addresses. So mentioned earlier, most Windows adapters don't support that. So I'm going to give quick demos of these and hopefully have at least a couple minutes for questions. So, I hope that this will play. It will. Okay, so I get on my Wi-Fi at the super expensive hotel and I want to go and Google for food. But the super expensive hotel has state of the art blistering fast 256 kilobit 802.11b for only 29.95 per 24 hour period, limit two devices. Just give them my mobile phone date of birth, mother's maiden name, credit card number, social security no, I don't think I want to do that. So I'm going to go over to my command prompt. I do an IF config and I see I'm on a 10 dot network and check the routing table, gateways 10-001, just like I'd expect. So I'm going to end map 10-001 and see what's on the gateway. They've got 22, 23, 53, 80, 52, 80. So I would try SSHing or just set or HTTPSing to my local server or my app engine through those various ports first. That's the easiest way. For the sake of the demo, we're going to say those failed. The proxy is not configured that badly. So, since we can't get through it that way, our next option is running iodine. So we're doing IP over DNS. So I run iodine, I use the password I specified earlier and I specify a DNS packet size just because it makes it run faster and I give my domain t parameter grid com. Now it will attempt to connect. Normally you wouldn't use that dash M, I just used it to make the demo run faster. It will auto guess the size, but it takes it a couple minutes to do it, so that speeds it along. And I do an IF config and I now have this new interface, DNS 0, which is pointing to 172.16.02. So I'm going to ping 172.16.01. That is actually my server being accessed through the tunnel. Because remember, I'm on a 10 dot network. I shouldn't be able to get to 172.16. So I'm going to do an SSH-D, set up port 5000 and I'm going to log in to my own server using the tunnel address 172.16.01. And now I'm on my server. I'm going over, completely over DNS. So since I've got that SOX proxy set up, the next thing I want to do is reconfigure my local web browser and I'm going to tell it manual proxy config. Give it SOX v4 proxy 127.001 port 5000. And now when I go back here and I back out of this captive portal and I look for food, I have found food. So thank you. Now if that hadn't worked, we do have one other option and that is Mac spoofing. I'm running this one on a Kali VM because my Windows driver will not let me get away with these tricks. So I've got this one using a USB wireless adapter on Kali. So WLAN 1, I'm going to grab the Mac address of the access point. This is the hotspot network that I'm connected to. I'm going to run airmonng and turn on monitor mode on my wifi card. Monitor mode is now on. So I will run aerodumpng and I will pass it in WLAN 1mon and I will pass in the Mac address of the hotspot. That just makes it not show me any other networks in the area and only show me the network I want. And I look, oh look there are clients just connected, 98, 5F, D3, et cetera. Normally I would wait, see other clients connect, see if one of them drops off. In this case once again for speed I'm going to just break out of there. And on Linux it's really easy to change your Mac address. It's quite trivial. You just down the interface and then run macchanger-m and specify the new Mac address. And then we're going to up the interface again. And now we give it a good 30 seconds because this seems to confuse most of the Linux networking GUI tools. Try connecting again. Okay, now it thinks it's connected. So we're going to go back here and we're out. All right, I'm at 1 minute left so I can take like a question but otherwise I will be in the hallway on the right to answer any other questions people have. Got anyone? Okay, thank you.