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 Behrens. I work at NeoHafsys
as a senior security consultant. I'm also an adjunct professor at DePaul University.
I teach some software security courses there. My name is Brent Benelgar. I also work as
a security consultant at NeoHafsys. And although he's not here, we have to give a big tip of
the hat to Nathaniel Cooper-Knowles, principal security consultant at NeoHafsys as well.
Yeah, 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 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.
Right. And so here we have our plain vanilla legacy network. It does only IP version for
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 doing ‑‑ they're
running an IP version 6 network, which is the node in the blue. And then it's passing
it through the network. And then it's passing it through the network. And then it's passing
it through their packages and their DNS. Again, this is their own host. And then it's
resending it out over the IP version 4 network. Right. And so what this really takes advantage
of is 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 really take advantage of that fact and we start routing all their
traffic through our interface, for example. And then back out over IPv4.
Right. And we transfer it to the user. All right. So here's a little brief history of
the guide as presented by Alec Waters. First off, you'll note that Windows XP is not affected
because it doesn't have an IPv6 SAC. 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 bit difficult to see in the next screen shot 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 put together as well. First off is
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.
Right. And there's ‑‑ you know, it also used a lot of old and deprecated packages. So, you
know, 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, you
know, because of that, you know, we were able to get it to work. And so we were able to get it
to work. 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, you know,
this guy Duncan couldn't get it to work. Vox couldn't get a particular package to compile. So,
you know, it was definitely a little bit too complicated for something that, you know, we were
really thinking could be an awesome weapon on penetration tests or things like that.
All right. To make that feasible, we need ‑‑
Yeah. So what we ultimately decided that we needed was ‑‑
I've got to click the button, man.
The button?
It's up. It's up.
Oh, sweet. Yeah, check that out. I got that from freebanners.net. Automation domination, right?
So, yeah. And really what this does is it's kind of one bash script to rule them all. You know,
after we spent all this time coming up with same defaults for the configurations, removing all the
old deprecated packages, you know, we came up with this basically one‑click install that takes
care of all the dependencies, configures your host, and it's a little bit more complicated than
it. And we also made some adjustments to the way that it works so that it actually does work on
Windows 8.
Right.
And it's been currently tested on Ubuntu, LTS, and, you know, we've tested on a variety
of the Kali flavors. So you should be able to just pull the script and run it to start
manning the middling, 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 it.
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 hosts first.
And another thing that I wanted to mention that might have not been totally clear in
the slides.
This attack only works on a local network. 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 how little time you actually need to get it running. 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 NAT64 translation, the standard
bind 9.
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 were originally setting
this up, before, you know, RTFM on bind here, I ended up writing a DNS resolver in SCAPE
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 the script
really does is prompts you for two points of input. It asks you the interface that you're
going to run the attack on. So here, although it scrolled pretty fast, the attacker specified
is 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 the relevant services, loads all the kernel modules
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 switch networks or something
like that.
Yeah.
It's two line fixes to make it persistent.
If anybody is interested, we can talk later.
Yep.
All right.
So now we're going to see what this looks like on the client side on our Windows 8 host.
First off, we see that the ‑‑ it's received our IP version 6 addresses and it has our
IPv6 DNS server that's going to do translations for us.
Right.
Let's pause.
Unpause.
Cool.
Fire up our Wireshark and we'll load up Google in another window.
We'll see it's communicating over IPv6 on our configured prefix.
Right.
And then we're going to pull up the flow to verify that is our HTTP request.
Right.
All right.
So we can see that the traffic, 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 Kali waiting for that request to happen.
So we see the request come in and at this point now 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.
Right.
Or to the Internet here.
All right.
So that was the IPv6 request coming in from the client.
So now we can see the victim's traffic.
We have the headers there and some of the cookies and the data as well.
And that's being retransmitted back out over IPv4.
So basically within the span of very quick.
You are man in the middle.
Revealing your victim's traffic over clear text.
All 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.
All right.
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 just 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 run 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, different
than it is on other flavors of Linux.
So there's a little bit of room to figure out what those conditions are that actually
trigger that fallback.
And unfortunately when the fallback happens, it seems to then just prefer IPv4.
So 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 we've done that.
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 latent wireless network or something like that.
Yeah.
Another issue we ran into is different operating systems will prefer ‑‑ will query their
DNS servers in different orders.
Sometimes they'll query their IPv4 servers first.
So we miss out on being able to translate their IPv6 traffic to IPv4 through our DNS
servers.
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'll also automate some basic network reconnaissance.
Like, it would be nice if the script just worked.
Just pick the 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 make it easier for everybody.
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 a specified
length of time and if nothing comes back, we can probably assume that there's nothing
‑‑ that our stuff is being blocked.
Yeah, that they have a protection enabled, correct.
Right.
We'd also like to be able to automatically configure our network.
We have 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 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, yeah, leveraging the hacker's
choice IPv6 tools.
There's a number of very nice tools in there.
In particular, there is a tool that will listen for the router advertisement responses and
it will basically just on standard out display the list of IPv6 addresses that are getting
handed out so you can see ‑‑ and they're MAC addresses so you can see exactly which
clients are being added on to the overlay 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 the attack.
And we'd also like to see this expanded to more platforms.
We did a little look at the mobile stuff and it's just not ‑‑ IPv6 didn't seem to be
there, right?
No.
On Android.
Android's just not all the way there yet.
And then on IOS, the DNS servers are queried in linear order.
So their IV4 DNS servers are always going to go first.
Yeah.
And so we ran into some issues with that.
So I think there's a little bit more research that could be done to figure out how can
we get this across a 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 ‑‑ yeah.
It's a kind of aggressive attack.
So test it out in your lab first before you totally blow it out of the water on somebody's
network, right?
Yep.
All right.
Well, thank you, guys.
All right.
Thanks.