 Hey, everybody. Welcome. Welcome. You've made it. We've made it. Today we're going to talk about man in the middle attacks on doing it on an IPv4 network using IPv6. And with that, we'll just kind of go ahead and get started. My name is Scott Barons. I work at Neohapsis as a senior security consultant. I'm also an adjunct professor at the Paul University. I teach some software security courses there. My name is Brent Benelgar. I also work as a security consultant at Neohapsis. Although he's not here, we have to give a big tip of the head to Nathaniel Cooper-Knolls, a principal security consultant at Neohapsis as well. He kind of got us started on this whole project. So what are we here to talk about? Well, we're going to touch on something that came out a few years ago, which is known as a Slack attack. And really what this is, is we have systems like Windows Vista and Windows 7 that listen to IPv6 by default. And a buddy of ours, Alec Waters, developed a guide to kind of exploit this fact. And it's known as a Slack attack. We'll walk through a little bit of how that attack works. One of the observations that we made when we were playing around with this in the lab was that it's kind of difficult to follow the steps he had outlined. We ran into a lot of issues. So what we did and what we're going to present to you today is how we've updated the attack to make it a lot easier to use and kind of a one-click install sort of approach. So. Right. And so here we have our plain vanilla legacy network. There's only IP version 4 in this network. There's a router, has DGP, DNS, and there's no IPv6 anywhere. We also have some hosts here, Windows 7, Windows Vista, 2008. All right. And so what Alec Waters put together was a guide to create our evil router here in the red. Although there's two nodes on here, the evil router and the evil DNS are intercepting traffic. They're running an IPv6 network, which is the node in the blue. And then it's passing it through their packages and their DNS. Again, this is their own host. And then it's re- sending that out over the IP version 4 network. Right. And so what this really takes advantage of is, you know, all these operating systems that have the IPv6 enabled by default, we kind of send out this router advertisement. And the clients say, oh, yes, I want to route over IPv6. That's what I prefer. And so we, you know, we really take advantage of that fact and we start routing all the traffic through our interface, for example. And then back out over IPv4. Right. Really transparent to the user. All right. So here's a little brief history of the guide as present by Alec Waters. First off, you'll note that Windows XP is not affected because it doesn't have an IPv6 stack. Vista and Windows 7 work for sure. And when we were trying it in the lab, we just got our hands on a copy of Windows 8 and we found that we couldn't get it to work properly the way that Waters had written it. Yeah. So although it might be a little difficult to see in the next screenshot here. So the way that kind of looks like is that we have some IPv6 router advertisements. But the Windows 8 no longer accepts the DNS server setting through Slack alone. Right. And so when we kind of run that issue then it tries to make a request. It does not get a DNS response. And then it falls back to IPv4, which is a technology known as happy eyeballs and we'll touch on that a little bit later in the presentation as well. Yeah. So there's some other issues with the guide that Waters had together as well. First off, there's a lot of configuration files you have to go through and edit. So these steps were very detailed, but there's still a lot of things to go through. A lot of IP addresses and ranges to keep track of. Lots of configuration flags to get through. And there's also used a lot of old and deprecated packages. So he basically said it was held together with string and sticky tape and that is pretty parallel to what we actually experienced when we were playing with this in the lab. And because of that, we kind of went back to the blog post and we were like are we the only ones that are having problems getting this thing working? And we were reading through the forms and this guy Duncan couldn't get it to work. Vox couldn't get a particular package to compile. So it was definitely a little bit too complicated for something that we were really thinking could be an awesome weapon on penetration tests or things like that. So what we ultimately decided that we needed it was. It's up. It's up. Sweet. Check that out. I got that from free banners.net. Automation domination, right? So, yeah. And really what this does is it's kind of one bash script to rule them all. After we spent all this time coming up with same defaults for the configurations, removing all the old deprecated packages, we came up with this basically one click install that takes care of all the dependencies, configures your host, and we also made some adjustments to the way that it works so that it actually does work on Windows 8. And it's been currently tested on Ubuntu, LTS, and we've tested on a variety of the Cali flavors. So you should be able to just pull the script and run it to start manning the middle all the things. Right. And we'll show you how that looks like in a bit. Before you get started, you're going to need to know the interface of your attacker host that you want to run it on. And you're also going to need an extra IPv4 address on the network that you're attacking as well to do net translation. Right. And you're going to want to test in your own isolated lab first. It is a relatively kind of aggressive attack. You're basically going to route everything through your host. So if you imagine doing this on a relatively flat network, where maybe you have 100, 200, or n number of hosts, you're going to be routing a lot of traffic through your host. So you need to be careful. You know, we suggest just testing that on a couple host first. And another thing that I wanted to mention that might have not been totally clear in the slides is that this attack only works on a local network. You know, you need to be on the same subnet as the victims that you're targeting. All right. Let's go ahead and see how the installation looks. And the reason we're showing you this is just because of how little time you actually need to get it running. Literally, we invoke the command and within a couple minutes, or less than a minute, it's going to pull down a number of packages, such as take it to do the net 64 translation, standard bind nine server, standard DHPV6 server. And that's pretty much everything you need to start setting up your IPv6 overlay network. Yeah. And actually we'll make kind of a side note here when we originally set this up before, you know, RTFM on bind here, I ended up writing a DNS resolver and scapey to do some super hack job and then at the end of the day, it was like one line of work in a bind. So just a lesson to everybody, please, you know, read your manuals. Yeah. So it's ready. Right. And so, although it went relatively quick, one of the other things that this script really does is it prompts you for two points of input. And as to the interface that you're going to run the attack on. So here, although it scrolled pretty fast, the attack is specified as zero. And you also need to specify a free IP address on the network that you're targeting. Right. And at the end, it starts up all of the relevant services, all the kernel modules that you need. Yeah. And we should also mention it's not persistent. So once you've actually set this up, you're going to need to run the script again if you reboot your host or, you know, switch networks or something like that. Yeah. It's two line fixes to make it persistent. If anybody's interested, well, we can talk later. Yeah. All right. So now we're going to see what this looks like on the client side on our own, those eight hosts. All right. First off, we see that the, it's received our IP version six addresses. And it has our IPv6 DNS server that's going to do translations for us. That's boss on call. Cool. Fire up our wire shark and we'll load up Google and another window. We'll see it's communicating over IPv6 on our configured prefix. And then we're going to pull up the flow to verify that it is our HTTP request. So we can see that the traffic, you know, un, you know, transparent to the victim, all the traffic is running over IPv6. All right. And here's how this looks like on the attacker side. So we have our attacker. He's running one click install and he's on Cali. Waiting for that request to happen. So we see the request come in and at this point now we're, you know, we're kind of seeing a combination of the IPv6 traffic and we're also seeing us do the translation back to IPv4 so we can actually get out of the network, right? Because we're taking advantage of the fact that we don't have a full IPv6 tunnel out to the network or to the internet here. Right. So that was the IPv6 request coming in from the client. So now we can see that the victims traffic, we have the headers there and some of the cookies and the data as well. And that's being re-transmitted back out over IPv4. So basically within the span of very quick, you are man in the middle of your victims traffic over clear text. Right. Thank you. So, yeah, we really think that, you know, the main focus here was just to improve the efficiency and, you know, it went from spending quite a bit of time in the lab to get it working to now it's just two variables you enter in about a minute of configuration time. So. Alright. Unfortunately not all is rosy in IPv6 land. We do have a couple of issues with the attack as it is. Yeah. And, you know, the hugest one is this disabling IPv6 by policy. So if, you know, you're in an organization that has it turned off, this attack simply isn't going to work. And in general, you know, one of the things that's kind of nice about this attack is that any time you set up a new Windows host, it has this turned on anyway. So unless it's explicitly turned off, there's a good chance that you're going to have hosts that have IPv6 enabled. One of the other things that we have to be on the lookout for are IPv6 network defenses. And these are specified in RFC 6105. There's also a guide that Cisco put out that talks about how to kind of protect against first hop sort of attacks. And they have a technology called RA Guard, Router Advertisement Guard. That basically stops, you know, when we send out that Router Advertisement packet, that guard basically blocks that packet from hitting any other ports on the switch. Right. And some of the other issues we've written into in the lab, when we're testing this is different operating systems will implement RFC 6555 differently, which specifies that there's heuristics for when the operating system will roll back to IPv4 if the IPv6 connectivity isn't coming back fast enough. It's kind of interesting too because it's not, it doesn't seem to be standard. I mean, the happy eyeball effect on Ubuntu is different than it is on OSX. It's different than it is on other flavors of Linux. So, you know, there's a little bit of room to figure out, you know, what those conditions are that actually trigger that fallback. And unfortunately, when the fallback happens, it seems it then just prefer IPv4. So, you know, if you're on a relatively latent network or your routing is latent for whatever reason and the hosts drop back to IPv4, there's a good chance that they're not going to actually route through your host again. So, once again, we kind of suggest if you are going to run this attack on a production network or something, you have some pretty speed, you know, have good network connectivity. Don't be doing this over a, you know, latent wireless network or something like that. Yeah. Another issue we're going into is different operating systems will prefer, will query their DNS servers in different orders. Sometimes they'll query their IPv4 servers first. And so we miss out on being able to translate their IPv6 traffic to IPv4 through our DNS server. Yep. So, yeah, there is some room for improvement and, you know, we think one of the biggest things is to actually specify the target scope because right now it snags the whole subnet. And that's a little noisy. I mean, if you're on a pen test and you're just targeting a specific server, you really don't want to route everything. And so that's definitely something that we're going to try to work out here. We also automate some basic network reconnaissance. Like, it'd be nice if the script just picked a free IP address for you so you didn't have to specify that. There's just one less step that somebody could either mess up or just make it easier for it. We'd also like to figure out a way to detect if there's already IPv6 countermeasures implemented on a network. For example, if being able to send out a router advertisement and then just waiting to specify the time and if nothing comes back, we can probably assume that there's nothing, that our stuff's being blocked. Yeah, that they have a protection enabled, correct. Right. We'd also like to be able to automatically configure a true IPv6 tunneling to enable true end-to-end V6 connectivity. And the reason for that is because sometimes clients will receive a legitimate quad-a IPv6 address and they're not going to be able to actually connect back to that site. And so they'll, happy eyeballs will kick in and they'll fall back. So we'd be, we'd like for that to be as easy as possible as well. Right, exactly. Right. Another thing we'd like to be able to automate and include is leveraging the Hacker's Trus IPv6 tools. Honor is a number of very nice tools in there. In particular, there's a tool that will listen for the, for the router advertisement responses. And I'll just basically just un-centered out, display the list of IPv6 addresses that are getting handed out. So you can see, and their MAC addresses. So you can see exactly which clients are being added onto the, I won't really network. Right, yeah. So they'll give you a little bit more kind of metrics and give you a better clue on actually what's going on with it. And we'd also like to see this expanded to more platforms. And we did a little bit, look at the mobile stuff. And it's just not, IPv6 didn't seem to be there, right? No. We were opening it on Android. And so... Andra's just not all the way there yet. And then on iOS, the DNS servers are created in linear order. So there, IV4, DNS servers are always going to go first. Yeah. And so, you know, we ran into some issues with that. So I think there's a little bit more research that could be done to, to figure out how can we get this broader array of operating systems. Right. And of course, we'd also like to get this ported to other attacking hosts as well to suit people's needs and preferences. Right. All right. So here's how you can help. Yeah, so go ahead and pull it off our GitHub here. Just one other, you know, we love people to help. So if you guys have ideas or have been working with similar stuff, you know, feel free to fork the project and make some changes and submit a pull request. We'll be happy to add whatever you guys come up with. And then just one other note, just be careful running this on production networks. It is a pretty, kind of aggressive attack. So, you know, test it out in your lab first before you totally blow it out of the water on, on somebody's network. Right. So. Yeah. All right. I love that. Well, thank you guys.