You gave a workshop, what, a couple of days ago?
You gave it yesterday, and you'll also be on the big stage tomorrow, right?
Tomorrow afternoon.
Tomorrow afternoon.
And, you know, it's a very good one, too, to start off the Saturday at the speaker workshops.
And it is, give me the, actually, I'm not sure.
I'm just going to wait for it, wait for it, wait for it, and mute the mic.
I mean, don't worry about it.
This is pretty common.
We're really right on schedule, like on the dot, which is excellent.
Story yesterday, I don't know if anyone caught it yesterday.
We had a...
We had plenty of AV issues, but one of the more, the worst one was,
imagine if you bring in a work laptop from, I'm not going to name who the company is,
and imagine that the company laptop you're trying to use for the presentation got everything locked down.
No devices, no Ethernet, no USB, and you can't even get your laptop working on one of these things.
How in the world are you ever going to be able to, I mean, it was like the most wonderful,
the most wonderful thing.
Lockdown machines, like, basically, it's normal to a point where it's useless, and we had a 15-minute delay.
Nothing could be worse than that.
I think we're, but I think we're ready, but without much ado, it is absolutely my pleasure to introduce you to Gabriel Ryan.
How you doing, everyone?
You guys recovered from last night?
Not yet, still working on it?
It's all right.
Whoa, wait a minute.
I have to do some slide shenanigans.
This might be the wrong slide deck, but it's okay.
I have it, the other one, like, right here.
Uh-oh.
It's okay.
This actually,
this isn't the demo gods, it's the slide gods.
So, I mean, if I can just settle for the slide gods, that's, I mean, I can deal with that.
But as long as this, does this have, does this have everything that we need?
Yes, it does.
Okay.
Next year, I think we're going to have a, you know what, this reminds me, I think next year we're going to have bingo cards.
Like, you know, if people have AV issues, speakers have AV issues, you know, say, if someone brings alcohol and says,
push this, we get off it.
We go?
I mean, we could just do, like, the DEFCON AV issues drinking game.
Eh, it's not.
Because I don't think any of us would make it out of this room, so.
All right.
So, disclaimer.
Okay.
So, my name is Gabriel Ryan.
I'm a security engineer at Gotham Digital Science.
We're a New York and London-based security consulting company.
Just do infrastructure testing, red teaming.
I'm not going to drive this part out too long, because time.
So, new stuff in this presentation.
So, we're going to be looking at a couple of new attacks today, which, I mean, really are just kind of, like,
building off of, like, the previous, you know, 15 years of rogue X1 attacks and just kind of adding a little bit to the top of that
and just doing some new stuff.
So, we're going to be talking about hostile portal attacks, in which you can actually steal Active Directory credentials
without actually being associated with the network, which is pretty cool.
And we're going to look at indirect wireless pivots, which is a way of bypassing port-based access control mechanisms on wireless networks.
But before we talk about any of this stuff, we need to talk about WPB.
WPBA2 EAP.
Reason being, it's kind of the background info that we need to understand everything that we're going to be doing later in this talk.
So, anybody here familiar with rogue X1 attacks?
Okay, about 50-50.
So, rogue X1 attacks, I mean, they're the bread and butter of modern wireless penetration tests.
You can use it for all kinds of cool stuff, including stealing radius credentials, performing really, really stealthy man-in-the-middle attacks,
you know, making, like, little fake phishing logging portal things, et cetera.
If you ever use a pineapple, that's the kind of attack they use.
There are a lot of different kinds of rogue AP attacks.
I mean, the most basic one is the evil twin attack.
So, let's say that we are, we have this access point, DEF CON open, and it's operating on channel 6.
We have these four clients that are associated with it.
So, let's say that we were to, an attacker were to create, can you guys hear?
Can you guys hear now?
Oh, this is a really directional mic.
Okay, so I've got to hold it like this the whole time.
Cool.
Awesome.
So, we're going to walk around just kind of like, all right.
All right.
So, I'll just pick up.
Okay.
So, the first thing we're going to talk about are, like, rogue X1s.
Rogue X1 attacks.
Just going to repeat that section because I wasn't, yeah.
So, let's say that we have this access point here, DEF CON open.
It's operating on channel 6.
And we have these four clients associated with it.
And, you know, let's say that an attacker were to create an access point that was an exact duplicate of that.
So, same ESS ID, same channel.
Do you guys know how, show of hands, do you guys know how these clients would be able to distinguish between the two access points?
Signal strength.
Yeah.
So, like, if the attacker just creates another access point that is these exact same attributes,
but is able to amplify the gain on that ever so slightly stronger than the target access point,
all these clients will actually drop their connections and connect to the attacker.
So, of course, from here, you have a bunch of stuff connected to you, and you are a router,
and you can do man-in-the-middle attacks, all this really, really delicious, awesome stuff.
And these have been around for, like, a really long time.
Actually, the first documented case that I could find was in 2002.
You know, this FAQ on how to make wireless.
Land security more secure, and that was by C.W. Klaus.
Of course, in 2003, we had the classic ASleep tool by Josh Wright.
Moving forward a bit, we have Karma attacks, which are a more sophisticated attack,
which we're not actually going to talk about today, but worth looking into,
by Dino Diazovi and Shane McCauley.
That was in 2004.
And then, of course, in 2008, we have, and this is where we actually start building off of,
Free Radius WPE by Josh Wright and Brad Antonowitz.
Very classic tool.
And then, of course, back in DEF CON 2013,
2022, you know, 2014, this was actually the talk that got me into Wi-Fi.
We have improved Karma attacks by Dom White and Ian DeVilliers,
because, you know, at this point, Karma had actually been broken for a while,
and they managed to fix it.
And they also did some EAP stuff that we're going to be building off of as well.
And then 2017, very recently, we had Lure 10 by the guy who wrote Wi-Fi Fisher.
And this was, this is actually a way of, like, exploiting Wi-Fi sense in Windows 10
to get stuff to connect to you.
So, as you can see, these attacks have been around for a really, really long time.
And, you know, they haven't really found a way of fixing this with open networks.
So, pretty much the thing that you use to prevent these attacks is your WPA.
And we're going to look into that further today.
So, traditionally, rogue AP attacks have been used to fill two basic roles.
You know, man-in-the-middle attacks, which is stealing creds,
and also gaining access to the wireless network.
But in this talk, we're going to look into rogue AP attacks as a means of lateral movement,
which is kind of newish, new, yeah.
So, I mean, let's talk about evil twin attacks against WPA2 EAP.
And to do this, we first actually have to cover EAP.
Anybody know what EAP is?
Or how it works?
Okay, so EAP is the, and for those of you who do know how this works,
yes, I'm going to oversimplify this for, like, two minutes,
but I'm going to actually go into the full definition later.
So bear with me.
Logically, EAP, it's an authentication process that occurs between the supplicant
and the authentication server.
What is the supplicant?
The supplicant is just a fancy way of talking about your wireless client.
And the authentication server is like your radio server running in the back end.
So the first stage of EAP, if we're talking about EAP-PEEP and EAP-TTLS,
which is what we're focusing on today,
the first stage of this is that the client makes an authentication request
to the authentication server.
And at this point, the authentication server responds to an X509 certificate.
And the goal of, you know, the reason why it responds to this X509 certificate
is the authentication server needs to be able to prove to the client
that it is who it says it is, right?
Otherwise, you don't know what you're actually connecting to or authenticating with.
So at this point, if the client accepts that certificate,
it's valid, which is essentially saying that it trusts the authentication server.
We've moved from, we were just at the outer,
what we call the outer layer of EAP authentication
to the inner authentication protocol.
And what that is, essentially, we set up a secure tunnel
between the client and the authentication server,
and all authentication process happens through there.
So, you know, the reason why, by the way, we use a secure tunnel
is that without it, this entire authentication process can be sniffed.
Remember that, you know, regardless of the fact that this is WPA2 EAP,
the EAP is actually what we're using as the authentication mechanism.
That means that the WPA, the encryption from that,
doesn't actually kick in until after authentication finishes.
So up until this entire process finishes right here,
what we're actually looking at is an open access point.
So this is all, like, open.
And without that secure tunnel, you can just sniff the credentials, right?
So, in fact, legacy implementations of EAP were very susceptible to this.
You know, EAP...
EAP-MD5 is a really good example that comes to mind.
So when I mentioned that there were, like, two components to the EAP authentication process,
I kind of...
That was a bit of a simplification.
There are actually three, right?
There is a supplicant in the authentication server,
or that is the wireless client and the RADIUS server in the background.
But there's this intermediary that has to be between the two of them
in order to make this work, and that's the authenticator,
a.k.a. the access point.
So, you know, in the back end, you have a RADIUS server,
and at the very end, you have a WPA2 EAP.
You know, at the front of it, you have the supplicant or the wireless client
that's trying to authenticate with the RADIUS server,
but all this communication has to go through the access point.
You know, and, in fact, the communication between the supplicant and the access point
is going over layer two,
and, of course, the access point is communicating with the authentication server
using RADIUS, which is higher up on the protocol stack, layer seven.
So our complete picture of how EAP works kind of looks more like this, right?
So you have the initial...
The client is sending the authentication request to the authenticator,
and then, you know, once again, you're getting this response,
this X509 certificate, and that's coming from the authentication server,
but it's being sent to the client by this AP.
And at this point, you know, once again, the client has to accept the certificate,
and, you know, if the client accepts the certificate,
the secure tunnel's established, and, you know, the actual credentials,
you know, the EAP challenge and response go through that secure tunnel.
So remember that this authenticator is an open access point.
Anybody see a problem with this yet?
Whoops.
No one?
Okay.
So remember that, you know, we were talking about earlier
how open access points are susceptible to these evil twin attacks.
Well, and up until this whole process finishes, this is an open access point.
So what an attacker can do is actually, you know,
use an evil twin attack to force the client to associate with the attacker
and begin this authentication process.
And then the attacker just runs a...
the rogue radius server in the background,
and, you know, goes through this entire authentication process.
The first thing that happens is the victim is upsetting the auth request to the attacker.
The attacker responds to the forged X509 certificate.
At this point, the onus is on the user to reject the certificate,
you know, barring situations where the client device is actually misconfigured
and just blindly accepts invalid search,
which that actually does happen quite a lot.
But leaving aside that scenario,
basically the responsibility is completely placed on the user
to identify this as an invalid certificate,
that they should not accept, and to reject it.
If that does not happen,
this inter-authentication process that goes through the secure tunnel
actually happens with the attacker,
then the attacker receives both the challenge and response
that can be cracked offline to obtain credentials.
So, I mean, I'm going to do two kinds of demos in this.
Like, if it's just like a background demo,
I'm not going to bother with the live stuff,
because why tempt the demo gods?
So this is going to be a video.
I'm just going to get later on in this presentation,
we're going to do...
We're going to do more live stuff.
But for the sake of time,
this is what this attack would look like
from the perspective of the attacker.
So as you see here,
the attacker is creating a forged certificate.
And it's kind of filling in bogus values here.
I'm going to kind of skip through this.
Bless you.
And at this point,
the attacker is actually going to start up this rogue access point.
And as you can see,
at this point, we have this...
We have a client, you know, where it says...
If you see...
I don't know if it's...
It's probably pretty small from the back.
I apologize for that.
But you have a client that's associating with the attacker.
And then there you go.
You have credentials.
Or not the credentials, but the challenge and response
that can be used to obtain credentials.
And then, of course, from there,
you can crack this challenge and response
using ASleep,
which, by the way, as we mentioned,
was, you know, came out, like, well over 10 years ago.
And there you go.
You have plain text credentials.
So, that's pretty cool.
You know, about the same time that this attack came out,
have you guys heard of EAP-TLS?
Or have you seen that form of WPA2 EAP
where you have to put, like, a cert on every single machine?
Have you heard of that?
Yeah, so that protocol actually came out,
I believe, in response to these attacks
around the same time in 2008.
And, you know, the idea is that
you have to put a cert on every single machine.
And, you know, because you're using mutual authentication,
using X5-9 certificates,
you know, from the get-go,
none of this would work, right?
Because the client would identify...
It wouldn't even enter the first phase of the authentication.
So, the strength really lies in these client-side certificates.
Any network administrators out there?
Anybody, like...
I mean, raise your hand if you, like,
think that, you know,
putting a client-side certificate
on every single device in your network sounds fun.
Is this something that you'd like to do?
Okay, we have one guy.
But, I mean, so EAPTLS,
although it protects against this,
it's wildly unpopular.
I mean, it's really arduous.
You have to put one of these certs
on every single device in your network.
And not only that, you know,
it's possible that you may have devices
that aren't even compatible with this.
I mean, especially, like, if you work, like,
in healthcare or, you know,
industrial control systems, stuff like that,
they may not even support client-side certs.
So, I mean, you run into this classic
security versus convenience scenario
where you're forced to choose between
an authentication mechanism with a known weakness,
or a highly secure authentication mechanism
that is just really difficult to implement.
So, of course, you know,
anyone go to a certain other security conference
with lots of vendors and flashing lights earlier?
Yeah, so, like, of course,
this creates a market gap.
You know, someone is going to come in
and try to create a product
that can be used to compensate for these security issues
while still being easy to use.
So, and the current trend, actually,
is to focus on breach containment
rather than prevention.
So, the idea is that, you know,
yes, you acknowledge the risk associated with
using EAPP or EAPTTLS,
and that this network, you know,
is vulnerable to these attacks,
but the idea is that, you know,
once the attacker gets on your wireless network,
you immediately contain them
and, you know, prevent them from accessing
anything important.
So, what we're going to explore today
is whether this actually works.
So, the, I guess the most common way
of approaching this scenario
is to use a network access control mechanism.
And I'm just going to present to you guys
this little cartoon before I continue.
So, network access control mechanisms.
I mean, this is like one of the most popular ways
of containing wireless breaches.
And the idea is that, you know,
when a new device is added to the network,
you immediately, you know, flag it
as either authorized or unauthorized.
If it's authorized, you let it continue
and access stuff.
And if it's unauthorized,
you place it on a quarantine VLAN
or flat out, you know, block the port
and not, you know, disconnect it entirely.
And it's not allowed to do that.
It's not allowed to do anything.
So, I mean, there's two ways of doing this.
You know, there are two traditional varieties of NAC.
Yes, there are next generation NACs
and we'll talk about them more later.
But traditionally, we've had two different kinds
of network access control mechanism.
We've had agent-based and agentless.
So, with an agent-based NAC,
you actually have a software component
that's installed on every single author's endpoint.
You know, this agent, the job of this agent
is to communicate with the brain of the NAC
and pretty much, you know,
allow the brain of the NAC
to perform deep interrogations on the endpoint.
You know, it's really effective,
but, you know, once again,
you're in a situation where you have to install something
on every device on the network.
So, it's very impractical,
kind of like the APTLS.
You also have agentless NACs,
which it just uses passive fingerprinting
and also does, like, external scans
to try to identify what's authorized and what's not.
You know, as you can imagine,
this is pretty easy to deploy,
but, you know, you can't examine
the internals of the devices,
so it can be bypassed pretty easily
by masquerading as something valid.
So, you know, once again,
you run into this recurring dilemma
where, you know, you have a more,
more insecure solution,
but that's pretty practical,
but you also have a very secure solution
that's very impractical.
So, we're kind of, you know,
back to square one here.
And, of course, this creates yet another market gap,
you know, where there's this high demand
for a solution that, you know,
offers the deep interrogation capabilities
of an agent-based NAC,
but has the convenience of an agentless NAC.
So, you know, this led to the rise
of something called the next generation NAC,
and there's a lot of different,
there's a lot of different approaches
that people have taken,
and we're just going to explore one
just to kind of, you know, as an example.
So, there's a particular NAC
that I wanted to bring in here
to do a demo with.
So, I actually tried to get approved
to bring one here,
so I put in a ticket to my company's IT department.
Of course, these things cost $10,000 a pop.
As you can imagine,
yeah, that didn't go very well,
but not only that, you know,
our legal department just kind of said,
yeah, you shouldn't go up,
keep this vendor neutral.
So, for the sake of keeping
this vendor neutral,
the vendor that we're going to talk about
is going to be referred to as Vendor A,
and if you're really curious
and want to know, you know,
who or what I'm talking about,
do some research,
you can probably figure it out,
but I know nothing.
So, you know, Vendor A uses, you know,
a good example of a next generation NAC,
and an approach to kind of like,
you know, bridge this, you know,
gap between agentless and agentless,
agent-based and agentless solutions,
is Vendor A.
Vendor A uses WMI to interrogate new devices,
and this allows it to, you know,
to perform deep internal checks
without using an agent.
And to do this,
it authenticates over S and B,
using a single administrative service account,
and this single administrative service account
runs with, you know, pretty high privileges.
I think it actually runs as DA,
if I remember correctly,
and this allows it to perform deep interrogations
without the use of a network.
Unfortunately, does anyone see a problem with this?
Yeah, you have this single point of failure.
You have this device that, you know,
can access everything on the network
with high privileges,
and it's sending hashes to every new endpoint
that accesses the network.
So, you have Godmode hashes
sent to any device that's got
access to the network,
and you have a single point of failure.
So, background info,
raise your hand if you do not know
what an S and B relay attack is.
Okay.
What about those of you who do know
what an S and B relay attack is?
Raise your hand.
Oh, there are a lot of undecided people here.
Great.
It's okay, it's early.
So, you know, S and B relays,
you know, pretty much,
they take advantage of the NTLM protocol.
You guys familiar with NTLM at all?
It's a simple challenge response mechanism,
very similar to PEEP,
which is what we talked about earlier,
and the way that this works,
actually, I need two volunteers.
You start with the tattoos.
Okay, so you want to authenticate
with that guy on the computer, right?
So, what you're going to do is
you're going to send him a plain text string, right?
Or, actually, no, you're going to say,
I want to authenticate with you,
and you're going to say, okay,
that's great, right?
Here's a plain text string,
encrypted for me using your password hash.
And you're going to say, okay,
you encrypted using password hash,
send it back to him,
and then at that point, you know,
he's going to say,
he's going to decrypt the encrypted string.
Using your password hash,
and if the decrypted string matches the original string,
then the authentication attempt succeeds, right?
Does everyone kind of get how that works?
All right, that's NTLM, guys.
So, no need to over-complicate it.
So, with an SMB relay attack,
okay, now I need three people.
Can someone stand right there?
Yes, excellent.
And, actually, I'll tell you what,
can you guys like pass it,
I don't know what this is,
but I'm going to borrow it.
All right, can you head it to that?
Yeah, so, now,
you are going to attempt to authenticate with this dude.
But the thing is, you think that he is him, right?
So, you're going to pass your authentication attempt
to him, right?
And you're going to just pass it directly on to this dude.
No, you're not going to keep it.
And then you're going to pass it back to him, right?
And that's the encrypted string you're passing back.
You're going to, or the plain text string.
You're going to encrypt it,
and pass it back to this dude.
Yes, exactly.
And now you're going to just, you know,
relay it back to the server,
and you're going to decrypt it,
and, is it good?
It's good, okay, so you're going to pass it to this dude.
And, oh, shoot, he's authenticated with him instead of him.
And that's an SMB relay attack.
And, you know, you can kind of explain this
using diagrams, too, but,
I mean, does everyone get SMB relay now?
Okay, good stuff.
So, you know, going back to, you know,
these next generation NAGs, or this particular one,
you know, of course, if you have everything authenticating,
you know, using NTLM,
then, and you're sending, you know,
hashes to every new thing on the network,
at this point, you have the risk of SMB relay attacks.
Where you can just, you know,
authenticate with the network,
and wait for the hash to be sent to you,
and then relay them to anything
that you want to authenticate with.
So that's bad.
But you could also, you know,
of course you could mitigate this
by enabling something called SMB signing,
which is where you digitally sign packets
to confirm their authenticity.
You know, but by default,
this is actually disabled on Windows machines,
except domain controllers.
And that's because group policy
is actually downloaded over SMB.
So, you know, and the cool thing is,
in this case, you don't actually need
a man-in-the-middle attack,
because the NAC appliance is trying
to authenticate with you.
Of course, you know, if you do turn it on,
it'll, SMB signing on, it will mitigate this issue.
But you still have a situation where you have,
you know, hashes being directly sent
to untrusted endpoints.
So, I guess, you know,
that wasn't just a tangent for a reason.
I mean, this tangent actually serves a purpose,
and that's to show that, you know,
there really is no magic bullet.
I mean, here's actually a really solid attempt
to kind of bridge these gaps
between security and convenience.
But unfortunately, the problem is
that security with convenience is often a paradox.
And, you know, that goes right back
to the issue of EAP-TLS,
which we're gonna look at later on.
So, let's talk about client isolation.
Are any of you familiar with it?
Have any of you tried to get on, like,
a hotel network or something recently
and tried to ping something and you couldn't?
That's because client isolation's enabled.
So, the way that 802.11 is supposed to work
is that the AP is supposed to mediate all traffic
between, you know,
the clients associated with the AP
and, you know, other endpoints of the network.
So, for example, you have these two clients
associated with this access point,
and in theory, the AP's supposed to mediate
all the packets going between these devices.
So, to enable client isolation,
you know, you basically just prevent,
if you see a packet that's going
from one of these client devices,
and instead of going upstream,
it's going to another device
associated with the access point,
you just deny it and don't let it through, right?
And on a wired network, this is actually possible
at the physical level.
But the problem is that on a wireless network,
client isolation is a logical control.
It's not a physical control.
So, you know, this raises the question,
you know, how do you prevent radio transceivers
from communicating with one another?
And this awesome researcher,
unfortunately, he's no longer with us,
but this awesome researcher named Cedric Blancher,
in 2005, his answer was, you can't.
And, you know, he introduced this tool called Wi-Fi Tab.
And this was first released by Cedric Blancher,
as we mentioned, in 2005.
So, once again, quite a long time ago.
And it was revived more recently.
By Oliver Lavery of Gotham Digital Science,
way before my time.
And, you know, the idea here is,
what this does is it reads packets.
It has a, you have two interfaces.
A ton tab interface that's attached
to a monitor mode interface.
And this monitor mode interface just listens
for packets coming from, to and from the AP, right?
And, you know, when you see a packet being sent
from the client to the AP, you inject the response
as if it came from the access point.
And this actually allows you
to get the data in isolation.
And, you know, of course, there were,
there's some later tools that build off of this.
Air Ton and G, it supports WEP.
And, you know, T-CAP Ton and G, it supports WPA1.
These are both part of the Aircrack Suite,
if you were here earlier this morning.
And actually, there is one that, apparently,
you theoretically could use it against WPA2,
although I don't believe it, called Hull 196.
You know, it's worth mentioning,
just because it's been talked about.
But it's also, you know, a considerably important tool.
And I think it'll be debatable whether it actually works.
So, to kind of demonstrate how this, how this does its thing,
let me just check the time really fast.
Okay, we're doing decently, we've got to hurry.
So, over here, we have, you know, the bottom right,
we have one terminal, right?
And this terminal is the host operating system.
In the top right, we're going to create an access point.
And this is going to be the access point
that we're going to be, you know,
the network that we're going to be attacking.
And then on the left here,
we have an attacker machine.
This is an SSH into an attacking machine.
So, what we're first going to do is,
we're going to send five ping packets,
you know, to the AP on this target network.
And that's happening on the bottom right here.
As you see, we sent five ping packets,
and we have five responses.
So, and then, why did that do that?
Okay.
There you go.
Okay, so, and then on the left,
we're going to, in this terminal here,
we're going to run a tool called Wi-Fi Ping.
And it's essentially a modified version of Wi-Fi tab
that just sent,
if there's an ICMP request that it sees,
it'll send an ICMP response.
So, it's a pretty good way to do a proof of concept of this.
So, now, you know, on the bottom right,
now that we're running this Wi-Fi Ping tool,
you'll notice that we're doing the ping again.
But this time, this time you can see,
you know, although we sent five ICMP packets,
we've received 10.
And that's because,
and you see all these warnings saying
they're duplicate ICMP packets.
And that's because we're actually sending packets
to this device without even being associated
to the network.
So, that just kind of shows you how,
you know, Wi-Fi client isolation
can be bypassed.
So, yeah, anyways, back to NACs, right?
You know, some, food for thought.
You know, we've been focusing on whether or not,
you know, NACs in general are effective against,
you know, stopping direct attacks, right?
But, I mean, what if we're missing the point?
And not approaching this the right way at all.
The role of a NAC in containing a wireless breach
is to prevent an attacker from accessing
sensitive resources after the breach occurs.
And, you know, unauthorized endpoints detected
is either placed in quarantine or the port is blocked.
When this happens on a physical or on a wired network,
this is actually a physical restriction.
So, it's pretty solid.
But on a wireless network,
this can only be a logical restriction.
And more on this later.
So, you know, I think to understand
the implications of this,
it's best to use an example scenario.
You know, we're attacking a wireless network
and it's used to access sensitive resources.
And we've already breached the perimeter
using the attack we did in the first part of this talk.
This is us on the left.
You know, we're an attacker on this quarantine VLAN.
And on the right, we have the victim
that's on this restricted VLAN.
And we obviously, you know,
we don't want to be on this quarantine VLAN.
We want to be able to get over to this restricted VLAN
and access, you know, the sensitive resources and stuff.
Unfortunately, we've been flagged
by this network access control mechanism as unauthorized.
So, you know, we're kind of, you know, we've been jailed.
We can't really do much.
So, the question is how do we get out?
Well, let's talk about some more stuff.
Anybody here use Responder before?
Okay, cool.
So, I mean, some of you probably are familiar
with LMNR or MBTN.
That's poisoning.
Once again, quick review.
Who here knows how NetBios name resolution works?
Okay, a couple people.
All right, so, you know, quick refresher.
The way NetBios name resolution works,
you know, basically there's a cycle that goes through.
The first thing that happens is that the Windows host
checks the local cache of stuff
that's previously sent information to.
It'll also check the LM host file,
which it has, it's a hard-coded file of,
that resolves, you know, host names to IP addresses.
If that fails, it'll use a local DNS
to attempt to resolve these names.
And finally, if all those options are exhausted,
it'll fall back to two protocols that,
although under the hood, work a bit differently
from a higher-level logical perspective,
and also in terms of the security implications
associated with them,
can be thought of as logically equivalent.
And that's LMNR and MBTNS.
And these protocols are best, you know,
best understood through example.
You know, let's say that you have two, you know,
NetBios machines on the network,
named Alice and Leroy.
Alice wants to get a file from Leroy,
but Alice does not know Leroy's IP.
So Alice is first gonna exhaust those three options, right?
You know, attempt local resolution,
also try local DNS.
And if that fails, Alice is going to, you know,
make a broadcast request across the entire subnet
using LMNR and MBTNS.
So at this point, every computer on Alice's subnet
is going to receive this request.
And the idea here is that, despite all of them receiving it,
only Leroy will respond.
Does anyone see a problem with this?
Yeah, so like, it's kind of an honor system.
It's very similar to ARP, in fact.
Although it came out like 10 years later,
so I don't get it exactly.
But the problem is, like, if Alice receives two responses,
only the first one is considered valid.
You know, this creates a race condition
where an attacker can just wait on the network
for LMNR and MBTNS queries and respond to all of them.
At that point, the victim will end up sending traffic
to the attacker instead, creating a man in the middle.
So a quick demo on how that works.
We have the attacker on the right, or the left, should I say,
and a victim on the right.
And the attacker is going to run a tool by Lawrence Joffe
called Responder that's going to do this.
As you can see, we're poisoning LMNR and MBTNS,
and we have these rogue servers here
that are going to wait for the authentication attempts.
And on the right, we're going to attempt
to access a non-existent SMB share.
And the reason why we're doing a non-existent SMB share
is because it's guaran- you know, the host is going to see that,
and it's going to- it's guaranteed not to be able
to be resolved locally, or using local DNS.
So it's going to automatically- we know that it's going to fall
back to LMNR and MBTNS.
So we're going to do this.
As you can see here, we end up with hashes very quickly.
So we're about 5% through a little escape attempt
from that thing, but I mean, this is- alright.
The other thing we need to understand in order to figure
out, you know, understand how we can get out of this is another
attack that we'll briefly cover called redirect to SMB.
So anyone know what redirect to SMB is?
Alright, it's pretty straightforward, right?
You trick the victim into accessing a URL that takes them
to a server, and all this server does is redirects them
to an SMB share on the attacker's network,
or an SMB server.
So they get redirected to this SMB server, and at this point,
IE or whatever it is they're using is forced to do NTLM
authentication with the attacker, and you get hashed
as much as we previously saw.
Requires a bit of social engineering.
Okay, back to wireless, and this is where we go into new
stuff, which is cool.
Let's talk about hostile portal attacks.
Hostile portal attacks are a way of stealing active directory
credentials without direct network access.
So how many of you guys seen something like this recently?
Yeah, so that's a captive portal, and the way a captive
portal works is that all DNS queries are resolved to the
captive portal.
You know, the DNS server is pushed out through a DHCP
option, and then that's- the DNS server then sends every
thing to the captive portal.
Of course, you can also redirect DNS traffic in case
they're manually specifying a DNS server, and of course you
can- if that fails, they're trying to access stuff directly
using an IP address, you can actually redirect HTTP traffic
to the portal as well.
So a hostile portal attack is very similar to this.
It's based on, you know, the redirect to SMB attack, but,
you know, instead of being forced to- the victim being
forced to visit this captive portal login page, they're
actually just forced to have access to the portal.
They have access to an SMB share, so you redirect to an SMB
share instead of a login page.
Very simple, but very effective.
You force the- if you look at this- oh, in the background, by
the way, you poison all LMNR and MBTNS in case they're just
completely idle.
But, you know, this is how it would work.
You have an attacker, and you have a victim on the target
network.
Use a rogue access point attack to force the victim to associate
with you, and then you immediately redirect them to
this SMB share using the same technique we use for a captive
portal.
And this results in lots and lots of hashes.
And, you know, we're first going to show you a demo
here.
And I actually have- it looks like 15 minutes left, so I'm
just going to fly through this video, because- so here on the
top right, we have a- you know, we're going to create our
legitimate access point.
This is our target network.
And we're going to connect to it from our victim machine
that's on the bottom right.
And, you know, as I said, we're going to do this with an open
network first.
Because there are a couple more steps that we have to do in
order to get this to work with EAP, or WPA2 EAP, should I say.
But yeah, we'll get to that in a second.
So- and I just got prompted to update when I recorded this.
But- so we're first going to associate it with this target
network at some point here.
Okay, there we go.
Yeah, so our client device is now connected with the network.
And on the left here, we're going to launch the rogue
access point attack.
So the first thing that's going to happen is we're going to start
our rogue access point.
And then we're going to send some DL packets to kind of force
it to roam from the target BSSID to our rogue access point.
So as you can see here, we have an association.
And then, interestingly enough, as soon as the victim opens IE,
which we're going to do in a second, we have hashes.
So if they're, you know, previously doing anything that
requires HTTP, it'll- you know, it's going to be a little bit
So we'll just send hashes to the attacker.
At this point, the attacker- and actually, thing to note, look how
many times it's actually sending us authentication and that-
or hashes, should I say.
And that's because every time we type in a new character into
the address bar there, that's actually sending out an HTTP
request to Bing search.
And that, you know, of course, we're just redirecting that.
So every time you type in a character, we're trying to
authenticate with the attacker.
So, all right, so, you know, if we're doing this with WPA EAP networks, it's going to require
a little more work.
And this is because, you know, in most cases, we're going to be talking about EAP-TTLS
and EAP-PEAP.
Both use MS-CHAPI2 as the inter-authentication method, although it's- you can kind of- you
can often get EAP- you know, clients that are connected to an EAP-TTLS network to agree
to something a little less secure than that.
But especially with EAP-PEAP, you're stuck with MS-CHAPI2.
So what this means is that with MS-CHAPI2, it's actually a mutual authentication protocol.
So this means that the server- the RADIUS server must prove knowledge of the supplicant's
password in order for the inter-authentication to have to succeed.
So this means that although the- you know, you can force a device to connect to you and
do that authentication process and give you an EAP challenge or response that you can
crack offline, you know, there's still that very, very, very final step, that final stage
of the inter-authentication process in which the client will actually not be able to fully
associate with the attacker because it's going to- you know, the RADIUS server is going to
fail that final stage of the authentication.
So the solution to this is- well, we have a couple of them, depending on the strength
of the RADIUS passwords in use.
We can use something that- this came out in the same talk I mentioned earlier in DEF CON
22 by the guys from SensePost, Don White and Ian DeVilliers.
They came up with a method called auto-crack-and-add where you basically- you perform that first
attack that we saw in the very beginning where we captured the challenge response, but then
we immediately append it to the kind of the database file that our RADIUS server reads
from.
And we'll talk about that in a second.
But if the- if the creds are stronger, you actually have to, you know, crack them offline
and finish the attack later.
And that's actually pretty feasible, too, and we'll talk about that in a second.
So talking about the first method, the way the auto-crack-and-add thing works is that
you take the challenge- you receive the challenge response, and that's the thing that you're
cracking to obtain creds.
At this point, what is supposed to happen at the very end of the MSHAP v2 authentication
protocol is that the RADIUS server, or host APD in this case, is going to crack the challenge
database, loads the password from a file called the EAP user file.
It's basically a very simple database that's implemented using a text file, and it has
information like the user name, password, then information about how that user is allowed
to associate with the network.
So it loads this password, and it uses that to forge the authentication response, which
is sent with the success message to the victim.
And you know, of course, you know, if the- if it was able to load that file, and it's
able to provide a valid authentication response, the association attempt succeeds.
Or authentication attempt succeeds, should I say.
So with the auto-crack and add technique that we talked about, what's going to happen is
that the, you know, the attacker, instead of immediately loading that password from
the EAP user file, the password actually- the attacker is going to take that challenge
and response and then immediately send them off to a cracking rig.
And the idea is that especially if you're using a remote cracking rig like, you know,
Cloud Crack or something like that that, you know, that has, you know, a significant amount
of horsepower behind it.
You should be able to, or at least within a couple attempts, you know, crack that in
time to then add it to the end of your EAP user file, just kind of append it to the
end of the file, and then send the, you know, use that to create the authentication response.
So it's almost like this race condition.
And if that doesn't work the first time, you just try it immediately again.
This time you already have it, and as the client tries to re-associate with you, you
pull off the attack.
So the second, you know, of course that works with weaker credentials.
But our second option is, you know, the offline crack.
And, you know, you may be thinking, yeah, this is going to take a little more time.
But remember that, you know, it actually isn't as bad as you think, you know, rather
than the attack taking, you know, minutes to an hour, it's not going to take a few
hours to maybe a week.
And of course, you know, real attackers aren't time-blocked, so even if you have a really,
really long radius password, you still have your APTs out there, like the guy on the right.
But so, one more thing to consider.
It's a little bit more complicated.
It's the fact that you already have the credentials if you're on the network in the first place,
which is how we're trying to get out of this situation.
But yeah, here we are once again.
We're going to use the auto-crack and add technique to perform the previous attack
against this time using a WPA2 EAP.
I'm going to fast-forward again because we have ten minutes.
So we're going to connect the victim device to the legitimate access point on the top
right.
And then we're going to start the roadmap.
Rogue access point attack.
And that's going to happen right here.
So we're now spotting the rogue access point on the left.
And then we're going to lob deauth packets at this, you know, at the legitimate access
point, at the client associated with the legitimate access point.
And that's going to cause it to roam over to our rogue access point.
As you can see, we've roamed over.
And you know, it's tried to authenticate.
It's kicked us off because we failed the initiative.
It's the initial, the very last phase of the, of the inter-authentication.
But you know, at this point, you know, we've also just cracked the, we've performed the
auto-crack and add, which you can see on the left here.
And it's going, you know, at this point we just relaunched the attack, you know, restart
the access point.
And do it again.
And we'll notice that the victim associates with us.
So hit connect.
And at this point we're actually associating once again.
With the target access point.
So we can rinse and repeat.
And here we go.
Bear with me.
Will happen like, I'll just skip forward a little bit.
Okay.
Yeah.
So.
Okay.
So.
Where is it?
Yeah.
Oh.
Okay.
Um.
Where's the, oh.
So we're getting a weird, like, start warning thing.
But.
There we go.
Okay.
So we, you know.
At this point the, the victim has just associated with the rogue access point.
As you can see we have hashed on the left.
And, you know, as we type stuff in the address bar, you know, we're sending out these HTTP
requests and it's just forcing more authentication demo with the attacker.
So that, that's a hostile portal attack against, you know, HTTP.
against WPA2 EAP.
So what does this get us?
I mean, it gets you similar results
to LMNR and MVTNS poisoning.
There are a few key advantages here.
One, no network access required,
and we're also not limited to a local subnet
because you get everything that's connected to wireless.
It's also not a passive attack, which is pretty cool.
We're not waiting for an LMNR and MVTNS lookup request.
You're actually forcing stuff to authenticate with you.
So back to our scenario.
And now we're gonna move on to something
called an indirect wireless pivot,
and this is how you use rogue AP attacks
to bypass NAC mechanisms.
So here we are.
We're back at our scenario again.
And we have the attacker, which is us,
and we're on this quarantine VLAN over here.
And of course we wanna get over to this restrictive VLAN
and access these sensitive resources.
Unfortunately, as we mentioned earlier,
we've been jailed by this NAC
and we're kind of stuck over here.
Well, although, what if we use a second wireless interface
to perform a rogue AP attack
and then just force that authorized device
to connect to our rogue access point?
You know, at that point,
we could just use the hostile portal attack,
which we just talked about,
to get this device to send us NTLM hashes.
Crack those hashes offline,
and at this point you have the capability
to authenticate with the victim
and place a payload on the victim.
You know, you might have to come back,
repeat the first part of the attack
to get it to connect to you, but whatever.
So, at this point, we send this payload to the victim,
and what if we use a scheduled task or something like that?
For the sake of an example,
forget about being stealthy for a second,
but just for the sake of an example,
we use a scheduled task, a time payload,
and then we just allow the victim device,
which is an authorized member,
to re-associate with the wireless network
that it was originally associated to that we're attacking.
Well, at this point, it's still authorized,
so it just gets moved over to the restricted VLAN,
and now we just wait for the reverse shell.
And this NAC that you see in the middle,
this could have been the most effective NAC
in the world.
It wouldn't have mattered,
because we're still able to remove this device
from its habitat, from its target network,
onto a network that we completely control,
and we can attack it.
So, a better approach, a faster approach for doing this,
is to use an SMB relay attack, right?
So, you know, we talked about that earlier,
but let's say we have two devices now,
and you have to use two devices,
because unfortunately, since 2008,
due to a service patch by Microsoft, MS08068, I believe,
you can't actually just do an SMB relay attack
from one device and then back to it
because that's an SMB reflection.
You need at least two devices in order to make it work.
Let's say we have a couple of devices on the network, right?
You know, once again, you force them to associate with you,
and, you know, assuming that, you know,
you have an account that can authenticate with both,
you perform the SMB relay attack.
Well, you do the hostile portal attack,
and then that allows you, remember,
you're receiving NTLM hashes at that point,
so you can perform an SMB relay attack.
And then, you know, once again, we place a time payload,
on the victim, on one of the victims.
You allow the devices to re-associate with the target network
by killing your rogue AP,
and then, once again, just wait for the reverse shell.
And let's do, let's do this last,
let's show you guys this last, this attack in action,
and then we'll wrap this up.
So now we have, now we have two victim devices
on the top left and right.
We have Leroy and Jenkins.
And then on the bottom left,
we have our legitimate access point,
and then on the right, we have, you know,
we have the attacker.
So the first thing we do is we're gonna connect
both of these devices to the network.
And we're gonna start our rogue access point attack.
Like so, on the right.
And so our rogue access point is now live,
so we're gonna send DL packets to force it to roam,
the client devices to roam.
All right, one of them has authenticated,
as you can see right here.
And we're gonna do this again,
but this time for the second client device.
And there we have this second authentication.
So both devices are now associated
with our rogue access point attack,
or our rogue access point.
So now we're going to create a stager.
We're using the Empire PowerShell framework,
if you guys are familiar with it.
But it's, if not, it's kind of like Metasploit,
but using PowerShell, it's the easiest way to describe it.
But the stager, that's our payload.
So we're gonna, we've generated our stager,
and we're going to, at this point,
we're gonna find an IP address
of one of our associated clients.
And so we're gonna settle for Jenkins here,
and we're gonna use Jenkins' IP address.
And then we're going to take our stager
and use it as a payload for SMB relay X,
which is a SMB relay tool, right?
And, you know, as you can see, we interacted with IE,
that gave us HTTP traffic,
which is enough to set up the SMB relay.
And if we go back, there's a bit of a delay
on the reverse shell here.
We're going to receive our first reverse connection,
which is gonna allow us to place
that time payload on the victim.
There we go.
If you can see that little green text,
it says initial agent, you know, blah, blah, blah,
connected to 10.0.0.184, now active.
That's our payload, and we are now,
we are now actually executing commands
on the victim machine.
So now we're gonna use module,
we're gonna use a scheduled tasks module, to, you know,
place a scheduled task on this machine,
now that we're authenticated with it.
Before we do that, we're gonna run Who Am I,
and also just, so see, we have,
our privilege right now, our NC Authority system,
and we're also gonna just, to check the host name
and figure out which one we're connected to,
we're gonna use the host name command.
So we're gonna do shell host name,
and yeah, we're connected, we're currently, you know,
have a shell on Jenkins, so that one,
we're this guy on the left right there.
Yeah, we're gonna create that scheduled task.
And what's gonna happen here is that we're gonna set
the time for execution, just a couple minutes
in the future, right?
So, interesting thing happened when I was like,
recording this, which was that I actually forgot to,
to attach the virtual device that was associated
with the first wireless interface to the virtual machine,
right, and I was originally gonna just like,
re-record it, right, but then like,
something really interesting happened.
I did set 160 retries for that second, for that second,
for that second payload, the time payload.
So, what I ended up doing is like, you know,
I reattached the, what you're gonna see me do is
you're gonna see me reattach the first device,
you know, that I forgot to attach.
And then, you know, a couple seconds later,
I'm still gonna receive the reverse shell,
because this thing is still consistently trying to connect
over and over again to this device that wasn't there.
So I thought that was kinda cool,
so I kinda left it in there.
So we've executed it.
At this point, we're going to actually kill
our rogue access point attack
and allow everything to reconnect.
And you'll notice on the left here,
we have one association right there,
and our second association
should have happened as well.
At this point, you know, I'm gonna skip through
waiting for two minutes of this.
Two minutes.
Just enough time we need.
Okay, cool.
So I'm gonna skip through this.
And you see here,
you should see me reattach the network adapter,
because I'm trying to figure out what's going on.
And then I'm like, oh, yeah, time to redo everything.
And then I start clearing everything, right?
Oops.
And I start clearing everything.
And I hit the back button on this,
because I'm about to clear everything
and start from scratch.
And then I receive the initial agent.
So it actually did work,
as soon as I plugged in the network adapter again.
So that's an indirect wireless pivot.
So the equivalent technique of doing this
in a wired network would be literally unplugging an authorized
device from the wall and then connecting it
to a hostile network on which you can actually attack it.
You know, the reason why we're able to do that
is because port-based access controls rely on the assumption
that the physical layer can be trusted.
In a wireless network, WPA2 EAP is the means
through which the integrity of the physical layer
is actually assured.
You know, and if you can't trust your EAP implementation
and you have a weak form of it,
the attacker can freely control your physical layer
and it basically, you know,
renders port-based access controls irrelevant.
So what this demonstrates is that port-based NAC mechanisms,
they don't really effectively mitigate the risk
presented by weak WPA2 implementations,
or EAP implementations, and that, you know,
adding port-based NAC mechanisms to a wireless network,
it doesn't really make the use of EAP-TTLS or EAP-PEEP
any less inappropriate if the network in question
is used to grant access to sets of information.
And, you know, by sets of information,
we're usually talking about, you know,
something like PCI or HIPAA data.
Remember that compliance doesn't necessarily mean security.
So...
I'm just going to make, like, one last case for EAP-TLS.
You know, it's not as bad as it used to be.
You can use group policy to push out the certs
to the various network endpoints.
And your best option, I think, is to, you know,
to mitigate this kind of attack,
is to use a private CA within your network
and then leverage the Active Directory to deploy EAP-TLS.
You know, and of course, you can, if you have, like,
you know, bring your own devices, like BYOD policy,
and people can bring their own devices on the network,
at this point, you could use, like, a solid MDM
to get those certs on there,
or just have, like, a really streamlined
BYOD onboarding solution.
And you could actually use Let's Encrypt, as well,
to roll out EAP-TLS.
Although, even the people who make Let's Encrypt are like,
this is probably not the best way to do it.
Yeah, but just some closing thoughts.
You know, just because wireless and wired networks
operate similarly at a logical level,
and they're designed to do that,
so it should be transparent
when you're looking at higher levels of abstraction.
On a physical level, in terms of the physics behind it,
they work in a completely different way.
And, you know, so you have to keep that in mind
when designing security
as a mechanism to protect them.
And, of course, as a community,
we should really question whether it's a sound decision
to neglect EAP-TLS completely
in favor of more reactive approaches
that focus on access control
rather than threat containment, and threat containment.
And, of course, I think most importantly,
you know, the needs for convenience and security,
they're usually at odds with one another.
So I think we should just, you know,
be really honest with ourselves
and maintain a very healthy skepticism
toward proposed solutions that promise both.
And if you want to look at the tool
that I've been using to do this stuff
throughout the demo,
or throughout the talk,
you can go to github.com slash solstice slash EAP Hammer
and check it out.
It's open source.
Thank you.