- Hi, and welcome to my talk,
"Hi! I'm DOMAIN\Steve, please let me access VLAN2."
It's about tricking firewall user identity capabilities
into applying security policies
to arbitrary IPs on the network.
My name is Justin Perdok.
I am a pen tester at Orange Cyberdefence.
I enjoy drinking craft beers and long boarding
in my free time, and as you might've imagined,
I'm into hacking stuff, but also automating stuff.
And if you want, every want to reach me,
you can then contact me on Twitter.
So today, we're gonna talk about a feature in firewalls
that allowed me to apply security policies to my IP.
To start off, we're gonna talk about an assessment
where I initially discovered this
as if it was a thing that firewalls do.
Then, I'm gonna shortly cover
how a traditional network segmentation is implemented
and how the tool is implemented from the vendor.
Then, I'm gonna cover how I built a tool
that allowed me to respond to these requests
and that I was able to pwn through
different firewall vendors.
Lastly, we're going to close off the talk by
speaking about the National Security Research
as concluding takeaways from this research.
So to start off,
let's tell you about a day in the life of a pen tester.
I was at a student project during college times
working on getting towards,
working towards getting the domain access within a network.
And I will do my thing.
And at some point we wanted to move around some files
between a host and our workstation within the network.
So, the easiest way to do this,
I thought was to spin up an SMB server
using Impacket's implementation.
While doing so, out of nowhere,
someone tried to authenticate to me.
The username included something like palo_alto_userid,
and while he was authenticating to me,
the Impacket SMB server threw some errors
referring to an unsupported DCERPC opnum code two.
And besides that, this wasn't like a one-off thing.
The user kept authenticating to me over and over and over.
So, you know, usually when this happens,
you start to relay the credentials.
You know, luckily for me,
when I looked at my BloodHound data,
this was also a domain admin. So, you know,
you relay stuff, you pwn some hosts, gets credentials,
you know, do your thing,
and before you know it, the job's done, right?
Well, yes, but actually no,
I want to figure out
what it was actually doing under the hood.
So I started Googling a bit around
using the username as a reference,
and I figured out it was a feature that allowed firewalls
to probe clients on the network and gather information
about logged on users.
So I verified this with the client
if they used this feature, and they told me
"Yes, we do. We used to apply
script policies in the network".
Googling around a bit more,
I figured out most of the articles that described
this feature, from offensive side of things,
mostly talked about that it's SMB-based
and that it authenticates you.
They didn't look at it any further, you know,
how would we potentially return information for example?
So I started to look into it a bit more.
First off, I started to look at a packet capture
of one of the process authenticated to me,
what I saw is that the client
probing me was connected to the IPC share.
From there, it requested their file
called the wkssvc file.
Then executed a function called NetWkstaEnumUsers function,
which at the time I presumed was
a request to collect information from users.
To fully understand what's actually going on here,
I want to take a step back and talk about
how named pipes are implemented within Windows.
So in Windows there are these
three default and mysterious shares, the C$ share,
this share basically gives rights to the entire disk.
And depending on how many disks you have in your system,
you would have multiples of these shares,
corresponding with drive letter associated with the drive.
Besides that, there's also the ADMIN$ share.
ADMIN$ share basically gives access to
where the windows folder is located
within the installation disk.
And besides that,
there's also a special share called the IPC$ share.
IPC stands for interprocess communication.
The share itself does not give access to files,
but actually give access to processes running on the system.
It gives access to these processes by exposing them through
named pipes. So let's look at an example here.
Here we have Bob, Bob the named pipe,
and it's giving access to thebuilder.exe by
exposing it only IPC share.
This means if you want to read and write data
to thebuilder.exe you would do this by talking to Bob.
You can also ask Bob to activate
specific functions on the thebuilder.exe,
executing a function this way is often referred to as
distributed computing environment
slash RC remote procedure calls or DCE/RPC for short.
So we just learned throughout this process,
what firewalls do to connect to you on the IPC$ share and
try to collect information about logged on users.
This pretty much is the same thing
what I saw on the assessment and something was
authenticated to me and tried to enumerate logged on users.
So to understand why this process was instrument to attack,
we're first gonna take a step back
and look at traditional segmentation.
We'll cover how this tradition implemented
and then why this gets hard and complicated over time.
Then we'll also show how a network intrusion
could help with this.
You would like to know that this won't be
a comprehensive guide on VLANs themselves or networking.
It would just be enough to get
a basic understanding of how VLANs works.
So here's an example for a new network,
presumably for a new company,
here, everything is connected to the same switch.
Everything can talk to each other
because it's a flat network.
Then the company hires a pen tester,
he comes along and provides an assessment.
You know, he pwns some hosts
and presumably when writing the report,
he would recommend, among other things,
to implement some form of network segmentation.
So the client starts to think about this
and they get the idea to implement some form of zones.
This, example, a blue client zone
and an a yellow server zone.
The idea here is to not allow traffic to flow freely
between these zones unrestricted by default.
To do this, the client would presumably use VLAN.
So, you know, how would this VLAN work?
So let's take these four ports, for example,
there's four ports configured
with two different colors,
blue color, and a yellow color.
Basically what this does the blue color
represents VLAN2 two and a yellow color
represents VLAN1.
Whenever devices is connected to a blue port,
it will only allow traffic to flow to other ports,
which are also blue.
Meaning if we were to connect four physical devices
to the same switch,
they will only be able to see and talk to each other
with the corresponding color.
Configuring ports this way
is also referred to ONTAP ports.
But, you know, a switch doesn't actually use colors.
It's a network protocol.
So how does it do, how does it do this under the hood?
Well. Whenever a ethernet frame
passes through a switch port,
which is configured for a specific VLAN ID,
it will edit this ethernet frame to include an extra header,
the 802.1Q header, also referring to VLAN ID header.
Which means, whenever the ethernet frame passes through
the corresponding VLAN ID is added to the ethernet frame.
Then the switch will ensure only traffic with a specific,
specific VLAN ID is able to reach other ports
which have this corresponding VLAN ID.
This isn't all the switch can do though.
This switch can also be configured
using different IO ports called stack ports.
So let's take, another example with two switches.
Here, we have the same VLAN ID
as the blue one and the yellow one.
And let's say we have a device connected to Switch 1
on the blue VLAN and wanted to talk to the device
on Switch 2, also the blue VLAN.
To do this, what we would do is we would
configure two ports on corresponding switches
as stack ports.
What it does is will allow the traffic
from the corresponding VLAN to flow within the switches,
but it won't allow the blue VLAN to reach the yellow VLAN
even though it passes over the same port.
Having all of these devices segmented from each other
is great for security, but not too much for productivity.
You can use this device such as a firewall
to allow a segmented access within zones.
For example, you could tell the firewall
to allow clients from the blue zone
to reach a service in the yellow zone,
using a specific port.
This is the very basic concept of network segmentation
using VLANs.
And it's pretty easy to understand
within such a small scale network.
But, you know, companies usually don't have one VLAN
or two, they have multiple.
And, you know, after some basic rules it's initially set up,
they grow over time.
And before you know it, there is a whole bunch of rules.
Nobody knows what's going on anymore.
Everything is a fire and everybody's screaming.
So, you know, this is where
the alternative solution comes in.
One of these solutions, being a Palo Alto User ID,
a firewall SSO solution is what I call it.
Basically what it does.
Palo Alto User ID creates a user IP mapping.
And then the user IP mapping is able to allow you to see
with visibility within the network, you know,
which user's doing what,
and allows you to create firewall rules for specific users.
The Palo Alto User ID can be configured
to collect information from multiple sources.
For example, active directory, authentication logs,
syslog servers,
and the one in which we're gonna talk about today,
client probing.
So, by using it as its own feature,
instead of having to rely
on traditional ways of segmentation,
you could say a specific user in a blue VLAN
is allowed to access specific server
within the yellow VLAN.
Even though there are other users within the blue VLAN,
they are not able to access the server in the yellow VLAN
because the almighty firewall figures out who is logged on.
With only one client, then they are gonna dynamically assign
a firewall to the specific IP.
So after finding out this was a thing,
I had two trains of thought,
the sysadmin in me was like,
you know, this is awesome.
The other thought in me was my hacker,
talking in the back of my mind, you know.
"Now, wait, what? We're going to trust clients
to return truthful responses and base
our segmentation around that."
Seems like a bad idea.
So to explain why I thought it was a bad idea,
let's use an analogy to explain my thought process.
So in this analogy,
I'm staying in a hotel and this hotel has a VIP membership,
which allows you to buy into it
and gain access privileges within the hotel.
You know, being a cheapskate that I am, a Dutch boy,
I didn't decide to buy into this VIP system.
So, you know, naturally the first thing when you do,
when you arrive at a hotel, you visit the bar, right?
So when arriving at the bar,
I noticed there are two fridges of beer,
one fridge with beer, which I would call,
less desirable beers and one fridge with the good ones.
The only problem here is that the fridge with the good ones
has a meme, has a sign on it, which has VIP members only.
So. Even though it's says VIP only,
I still want one of the good ones.
So I walk up to the bartender and ask if
and asked if I can access the VIP fridge.
The bartender is then gonna look at his rule book
and he sees now only VIP members
are allowed to access this fridge
then he's gonna look at this digital hotel room system
and sees that he doesn't know who's currently
residing in my room.
He's then gonna ask me, you know, who are you?
So being a law abiding citizen that I am,
I would truthfully response his answer
and tell him that I'm Justin.
The bartender is then gonna look as rule book again
and look at the member of the VIP members and, of course,
you know, because I'm not on the list
he's gonna tell me no, you're not allowed
to access this fridge.
But you now, instead of giving up,
I want one of the good beers.
I started looking around the room and I see
there's a guy over there in the corner named Steve
drinking one of the good beers.
So I get this genius idea, you know,
instead of saying who I am,
let's lie about who I actually am.
So I walk up to the bartender, again,
asking to access the fridge.
This time I'm using different hotel room number.
The bartender is again gonna look at this rule book,
says VIP members are allowed to access the fridge.
He then is going to look at his digital hotel room system.
And sees he doesn't know who's currently
residing in this room.
So he's gonna ask me, you know, who are you?
This time instead of saying, I'm Justin,
I'm gonna lie and tell them that I am, my name is Steve.
He's then gonna take this information,
look at this rule book and sees, you know,
hey, Steve is a VIP member.
Of course you can access the fridge.
So, you know, seems like a plausible attack, right?
The user id entity feature might not expect us to return
false information.
And this would potentially allow us to access things
we aren't allowed to.
As for figuring out who you want to impersonate,
instead of looking at the bar, you would, could look at,
you know, active directory data collected using Bloodhound
and figure out there is a specific group
within an active directory,
which references firewall ACLs.
The idea of an attack scenario here
is basically the same as an app,
web application. We might have it, you know.
Whenever a web application just trust client input
without validating it,
you're usually able to break things within the web app.
But the thing is we can not know this for certain
that user ID system might try to revalidate
or correspond the information collected from user probing
with other sources,
such as active directory authentication logs,
but we can try to figure it out
by looking how the solution is supposed to be implemented.
So let's set up what we know for certain, the firewall ACL.
Besides traditional VLAN and IP-based filtering,
you can also assign extra source option within this ACL.
This extra source option being either a user
or an active directory group.
In this case, the firewall only allows
members of the VIP group
to access specific fridge equipment on another VLAN.
When implementing client probing,
you can either use, SMB or WMI.
The firewall itself only allows probing on WMI,
but there's also an agent, which allows for both.
Since our presumed protect methods relies on SMB,
we're going to talk only about the client today.
The agent itself needs to be installed somewhere on a system
within the network.
From its place it needs to be able to access the sources,
which we try to collect data from.
So in our test case,
we're gonna use some fair simple network design.
Everything here is, is connected to the same VLAN except,
except for the segmented fridge.
This, of course, is not a typical corporate network design,
but it will do for our demonstration purposes.
The Palo Alto User ID is then installed somewhere within
the VLAN1,
since there is gonna be able to access the clients
and as well as ex-factory domain controller,
even though it's called the User-ID Agent,
it's not installed on every host within network.
It needs to be installed on a host,
which is then able to connect with different sources.
You can, however, use multiple agents, if you want to,
but doing that depends on your network design
and the limitations of the software.
Now that we understand our network design,
let's look at how you would install the agent.
When installing the Palo Alto USER ID agent software
you are prompted to use a service account.
If we were to able a flat standard active directory user
as the service account, it would error out.
Because the minimum needed rights
are already logged on as a service user rights assignment.
Then depending on the collecting methods you want to use,
you would then add additional rights to this account.
When running the Vendor documentation
they actually properly explain how to implement
least privileges except they sadly don't do for SMB-based
client probing.
Meaning that, you know, when this stuff's implemented,
you and I both know that this is usually
over-privileged with either local admin
or in the cases that I saw,
even the domain admin privileges.
In the case that you're using SMB-based probing,
the overall security does heavily depends on all the
factors within the network. For example,
a network access control or a general system hardening that
will prevent SMB relaying.
I know Palo Alto even knows this.
Within multiple places in the documentation
where it addresses client probing,
they advise you to not use this.
Anyhow, after having set up the appropriate rights
for the user, you can start to configure the agent.
When doing so you would fairly easily figure out
that you don't need to do much.
Both the server collection method and client probing
is enabled by default on both WMI and SMB.
Yo know, and I think this is important one to note,
because you know, Palo Alto by default
recommends against doing this,
but it's enabled by default within the agent.
So if an administrator, wants to use the same defaults,
he might unknowingly implement a system,
that's going to spread hashes everywhere in the network.
And the other thing that you need to do
before the client starts, you know, collecting sources
for my server or start probing clients
is add a network service source.
In this example, a domain folder.
This is all that is required to start, to make the agent
start probing and collecting resources,
but it has another function I would like to cover
called caching.
So whenever the agent identifies a user to IP match,
it will not only forward this information to firewall,
but also source locally for a specific amount of time.
But if all this time is 45 minutes.
However, this caching time out
does not correlate to the probing in default.
Meaning even if the collected information
was done by probing and it's been cached for 45 minutes,
the system will still probe the clients,
regardless of this caching timeout.
Now that we've taken off the confirmation of
the client itself, we can look at the firewall.
So the first thing we do is just simply add the agent
to the firewall.
This will enable the firewall to talk to agent whenever a
specific ACL triggers the events to collect information from
the user.
Then what you would do
is you would enable user identification ACL
on zone where you would want to configure this.
And then, to allow the firewall to know
about users in your server, in your environment,
you would add a LDAP profile.
This LDAP profile is basically going to link, you know,
the resources from active directory to the firewall.
Then from this point onwards,
you're able to create firewall rules using users
as a source.
But if you want to also use groups,
you need to do one additional step.
This step being a group mapping.
Basically what this does is going to take the groups
using your active directory environment
and cache these members on the firewall itself.
So it doesn't need to perform an LDAP query every time,
you know, a user matches in ACL.
Then from this point forward,
and whenever you get an ACL and firewall
and generate some traffic matching this rule,
the firewall will send over a request to the agent
asking, you know, who's logged on.
And if it doesn't, the agent doesn't know,
it'll stop probing us.
In this example, we could see an Ubuntu client
performing a ping towards the fridge,
and you could see the agent starts probing us.
So as you now know,
instead of three components
there are actually four components in this flow.
There's the client, VLAN1,
there's User-ID agent,
the firewall and the fridge, which we want to access.
So irregardless of what we do,
the agent's going to collect information
from the active directory and store this information
to build out this User-ID mapping cache.
Then we come along and ask the firewall to access
the specific fridge in the segment of VLAN.
The firewall is then gonna block our traffic and tell us,
you know, hold up, I need to know who you are
because you know, there's a user ACL mapping.
The firewall is then gonna send over this information
request to the agent,
the agent is then gonna look at his cache
to see if he knows who we currently are.
And because he doesn't know he's gonna send over a bubbling
request to us, asking, who are you?
The only issue being, right now,
is that we currently don't support this.
So whenever a request comes in,
we throw an error like "Lolwut? unsupported DCE/RPC".
So at this point, I thought, you know,
maybe if I implement NetWkstaUserEnum,
nobody will be able to tell I'm Spiderman,
but before going off a building or something,
I would first like to know
what is actually happening under the hood.
So we're going to look at some Microsoft documentation and
we'll figure it out from there.
So again, if you look at a packet capture
we would see that the probing request,
tried to access a named pipe called wkssvc.
With a bit of Googling around
you could easily figure out that this actually called
the Workstation Service Remote Protocol.
Luckily for us am actually had this huge, handy PDF
which fully explains everything within this named pipe.
So when I actually want to build something around this
I was kinda looking up against, you know,
building this from scratch.
So after asking around internally on our meta post
I was redirected back to Impacket,
which in hindsight was actually, you know,
pretty obvious because of ref,
the readme references the, you know, the specific name pipe
we want to implement.
When it came down to actually implementing the
NetrWkstaUserEnum function, most of them,
most of the work was already done for me.
All this works. For the function to properly function
were already implemented in Impacket as Python classes.
Here on the left, you can see a simplified version
of the requests as Microsoft describes it.
And on the right,
you can see the class within the Impacket solution.
So all I have to do is just figure out, you know,
how I would implement some code,
which is gonna trigger and return information,
how I want it to.
But before I start extending Impacket
I want an easy way to verify from the code I was doing.
So with a bit of Googling, I found this function
called NetLoggedOn, which is Powershell function,
written by @harmj0y.
This function, basically does the same thing
as the firewall will do.
So this allows us to start, test our code,
without having to rely on a firewall.
With the firewall temporarily out of the way,
I could start implementing things with netpacket.
I won't bore you with every single line code I added,
but I would like to share a couple of things
that I found out, which might be handy
if you ever want to implement something similar.
So the first thing is whenever, currently,
whenever Impacket receives a probing request,
it has no idea how to handle this.
So in order for Impacket to support this,
what we would do is we would edit a dictionary
within the class.
which basically going to link this opnum code to a method
which you would define later.
This way, whenever Impacket receives a specific opnum code,
it knows which method should handle this request.
The next one's you shouldn't add arguments
on the SMB server clause itself.
If you want to supply it with CLR argument information,
to supply this information to the method feature
you're going to use,
is you would define a function,
which is gonna update a configuration file.
After doing this, within the clause itself,
you can use a dictionary to get the information back
you initially supplied on CLI arguments.
As you can see here,
the values that initially added the CLI agreements are
here used to return the actual information upon our request.
So let's actually look at this is an action.
Here, on the top we could see a Powershell session,
with the Get-NetLoggedon user function loaded.
And on the bottom,
we can see a Ubuntu client with our
modified version of Impacket.
Whenever we send off a Get-NetLoggedon request
to the Ubuntu client you can see the information
which we supplied on the SMB server
is now returned to the request.
Meaning that we're currently able to fully respond
to these probing requests.
So the issue being that we currently didn't support it
is now gone. So we're returning the spoof user information,
the agent is then gonna take this information
and enter his cache.
And then afterwards, port forward this to the firewall.
The firewall is then going to use the information
and either to give us access to the fridge
or not, depending on the information we supply.
You know, which is great.
Everything is in place for this attack.
So let's take this and apply it to the real thing.
So you can see a firewall configured with a user ACL.
Here it says that only VIP members within VLAN1
are able to access the fridge within VLAN2.
Then, here on the right.
You can see the Active Directory console
with the specific user group.
On the left. You can see you an Ubuntu client,
which we'll gonna cover more shortly.
If you open the VIP members group,
we can see that the user, Steve, is a member of this group.
Then, if you look at the palo_alto_userid agent,
here, we could see current user IP mapping cache.
To show you that I'm not cheating.
Here on the left.
We can see that the Ubuntu client has one IP address.
And this currently isn't listed
within the IP-User Mapping Cache.
Then it will start to generate some network traffic
matching firewall rule.
You would see we are now able to access
this specific fridge.
Here we can see the agent again.
And this guy currently receives a request from a firewall
to get information about us. The agent doesn't know,
So it's adding us to the probing queue.
Meaning if we were to start our own SMB server,
which is able to respond to these requests,
we can now return our spoofed user information.
Start the agent, we just have to wait a while
for it to start probing us.
And when it eventually does.
You can see they would just return
domains\steve as our logged on user.
You can see that then this information
is added through the user IP mapping cache.
And on the bottom-left, you could see our ping,
currently being allowed to access the fridge.
So we switch over to our browser again.
Here, we can see all the beers we want to access.
You know, great to see this.
We just succeeded in bypassing a firewall ACL.
So if you want to play around with this stuff,
it goes in GitHub.
You know the QR codes on screen so scan it in a phone.
You know, I after just pawning one of the firewall vendors,
I started looking around a bit more because, you know,
it might, there might be more out there.
So after Googling around,
I did figure out that most firewall vendors have some form
of user to IP mapping function,
but not all of them use SMB as their probing method.
Though, I did find one called SonicWall and they referenced
something called NetAPI.
So as I looking into it.
You know, NetAPI is something called SSO solution.
It's basically much the same as Palo Alto User ID.
It's a configurable agent,
which is installed somewhere on the network, you know,
and it starts collecting information on active directory
or, you know, client probing.
The only main difference being is that the documentation
of something called (indistinct).
Depending on what documentation you happen to be opening
your are either told to use these privileges,
or you're told to just use administrative rights.
Apart from that there's not much else going on
so we can just jump right into the demo.
Here, we can see the SonicWall SSO Age.
Being configured, you start probing clients using NetAPI.
And if we switch over to firewall,
we can see that clearly there's a rule which says,
if we wants to access Google,
we need to be a specific user
in this case being administrator.
Then, if we start to generate some traffic,
you can see we currently aren't allowed
to access this resource.
If we look at our SMB implementation.
You can see that we supplied the username administrator
and corresponding domain.
And after starting this server
we just have to wait a while
for the agent to start probing us.
And when it does, you can now see
by returning the correct information,
we're able to allow access through this firewall ACL.
So I just showed you how to pwn two different vendors
using no arbitrary exposed user information,
but there is this caveat I neglected to mention this far,
and this caveat basically covers, you know,
how as the guests access work within Impacket in Windows.
So, whenever SMB, Impacket SMB server is started
without any form of authentication.
Whenever authentication fails,
it will fall back to an SMB guest access session,
meaning that our probe requests thus far
have made use of an SMB session with,
as guest access enabled.
The issue being here, is that it shouldn't be possible,
by default, in a recent version of Microsoft Windows.
By default there should be no access in registry key,
which will prevent the client from accepting SMB server
session with guests access enabled.
But you know, up to this point,
we haven't had any problems with this.
So as it turns out.
Even though Microsoft says this registry key
should exist by default,
within a specific version of Windows,
it usually doesn't exist within Windows 10 clients.
However, it does on Server 2019.
Meaning if you were to install this agent
on a Server 2019 server, this exploit won't work.
If it's installed on a Windows 10 client,
I will recommend you to check if this register key exists.
If not, enable it.
So let's go over to disclosures.
I started my first disclosure with Palo Alto
and shared two findings.
The agent SMB hash disclosure and the actual bypassing
firewall ACLs.
I wasn't informed NetBIOS-based client probing
will be dropped from further version of Palo Alto User ID.
Though, at some time I was informed that this issue
would not warrant a CVE
because this was an issue with the
Microsoft protocol itself and not Palo Alto.
Then after that, after being told that,
I was added to the hall of fame.
I currently don't know the status
of the dropping of NetBIOS.
The latest response of the vendor was that the fix
is already present in the product
because the client doesn't need to use this.
Then we can call for the disclosure of SonicWall.
I started this disclosure at the same time.
And then after some while they informed me
that the issue was actually a duplicate.
Besides that they told me that they would add a warning
whenever the user administrator was used.
So on one hand, I thought it was a dumb thing
because we're just gonna take this whole if statement,
smack it on the issue there and call it a day.
So naturally I shared my concerns with the vendor
and I asked them, you know,
which of my vulnerabilities were a duplicate
from the other researcher.
After sometime I received an email,
which informed me that they released
associates CVE number for the issues.
So looking at the disclosure of the vendor,
I figured out who the other researcher was,
Sedric Louissant.
I then sent him a message asking, basically,
you know, what did he disclose to SonicWall?
Well, then as I talked to him,
I figured out that he didn't perform any ACL bypasses
he disclosed SMB hash disclosure part.
Meaning that SonicWall just took a vote for findings
tacked mine onto his and call it a day.
Anyhow, regardless of that,
I still wanted to figure out if there were any
auto fixes they implemented,
besides actual if statements,
which is gonna check user administrator.
So I installed the agent and, you know,
I did find out a couple of things.
The if statement is there.
It only does actually check if the username
is called administrator, it doesn't actually check
the effective rights of the user.
Meaning, if you were to create a user and gave it
domain admin rights it will not prompt this warning.
Besides that, this warning only prompts
when you configure the service account
in a later stage, not during the initial installation,
when this is initially set.
They also changed the default probing method.
Before the disclosures this was NetAPI.
Afterwards, they changed this to WMI.
They also updated the documentation.
They do now reference that you should use
a local administrator when you want to use NetAPI-based
probing.
So, you know, what's next for this research.
There's potentially $Vendor3.
I expected them to also be vulnerable.
Their implementation is slightly different
than we talked about today, but I think they're vulnerable.
So I already started a disclosure process with them.
Besides that I did notice there were a couple of vendors
which used in winreg named pipe.
This winreg named pipe references to a Windows registry.
And basically before my check within the registry to
enumerate a lot on users.
It would require some further research,
but I think this is also vulnerable
to the same thing which we talked about today.
Also, there was a lot of vendors,
which was WMI to form probing requests.
Currently, there are no open source implementation
of setting up a, your own WMI server.
So if we're able to implement this within some product
or some ops, or tools,
we might be able to break a lot of a firewall vendors.
Apart from implementing a new protocols
and that kind of stuff.
We might also be able to abuse the caching function
of the agents.
You know, let's imagine you have someone working
within the corporation, it's five o'clock to leave for home.
We might be able to reuse his IP,
statically assign it to ours.
And hopefully the IP address still hasn't used to
IP mapping cache.
Other than that, you know,
we talked about firewalls today,
but there might be other products out there
which uses similar technique.
You know, even though they,
I would think they wouldn't use SMB for probing with WMI.
It wouldn't surprise me if they were to support an SMB-based
probing method.
And I'll use the same idea we talked about today.
You might be able to trick the vendor or product
into doing something unexpected,
by returning arbitrary information.
So the conclusion and takeaways.
Now the first one,
why I think client probing is generally a bad idea,
besides the whole port spoofing and
hash disclosure part of doing a probing based on SMB.
I think that generally, client probing is a bad idea.
You know, regardless of the protocol used,
you're never sure that the end point you're talking to
is returning arbitrary or spoof information.
And, you know, basing a logic product
for production applying security rules around that
is, in my brain, a bad idea.
Finishing up today.
This can now be exploited by
the Impacket implementation build.
But it wouldn't surprise me
if you were to kill the existing named pipe within Windows,
and spin up your own
you would be able to exploit this natively within Windows.
Another big one being it's just because a vendor
supports a specific feature.
This feature does not mean it's secure, secure by default.
In both cases, defendants we looked at today
supported a method,
which is generally known to be insecure.
In both of the cases, you know, it was enabled by default.
You, as a person, really need to practice due diligence
when it comes to looking at these extra features.
You know, you need to look at it how to implement it
and ask yourself, you know, the what-if questions.
What if we're able to respond to these requests, you know?
Is it actually safe?
And you know, and slip a smart idea
to bate our rules around this.
So thanks for listening to me rambling
about firewalls for forty-five minutes.
If you think I got something wrong,
please reach out to me on Twitter.
If you want to play around with this stuff yourself,
the code is on GitHub.
That's all for me. Have a nice DefCon.