DEF CON 29 -Justin Perdok - Hi Im DOMAIN Steve, Please Let Me Access VLAN2

00:13 - My name is Justin Perdok. I am a pen tester at Orange Cyberdefence.

00:17 - 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.

00:23 - And if you want, every want to reach me, you can then contact me on Twitter.

00:26 - So today, we’re gonna talk about a feature in firewalls that allowed me to apply security policies to my IP.

00:32 - To start off, we’re gonna talk about an assessment where I initially discovered this as if it was a thing that firewalls do.

00:37 - Then, I’m gonna shortly cover how a traditional network segmentation is implemented and how the tool is implemented from the vendor.

00:44 - 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.

00:52 - Lastly, we’re going to close off the talk by speaking about the National Security Research as concluding takeaways from this research.

01:00 - So to start off, let’s tell you about a day in the life of a pen tester.

01:04 - I was at a student project during college times working on getting towards, working towards getting the domain access within a network.

01:10 - 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.

01:19 - So, the easiest way to do this, I thought was to spin up an SMB server using Impacket’s implementation.

01:24 - While doing so, out of nowhere, someone tried to authenticate to me.

01:29 - 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.

01:41 - And besides that, this wasn’t like a one-off thing.

01:44 - The user kept authenticating to me over and over and over.

01:46 - So, you know, usually when this happens, you start to relay the credentials.

01:51 - 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.

02:08 - 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.

02:19 - 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”.

02:26 - 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.

02:38 - 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.

02:45 - 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.

02:55 - From there, it requested their file called the wkssvc file.

03:00 - Then executed a function called NetWkstaEnumUsers function, which at the time I presumed was a request to collect information from users.

03:08 - 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.

03:14 - So in Windows there are these three default and mysterious shares, the C$ share, this share basically gives rights to the entire disk.

03:23 - 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.

03:31 - Besides that, there’s also the ADMIN$ share.

03:34 - ADMIN$ share basically gives access to where the windows folder is located within the installation disk.

03:40 - And besides that, there’s also a special share called the IPC$ share.

03:45 - IPC stands for interprocess communication. The share itself does not give access to files, but actually give access to processes running on the system.

03:54 - It gives access to these processes by exposing them through named pipes. So let’s look at an example here.

03:59 - Here we have Bob, Bob the named pipe, and it’s giving access to thebuilder. exe by exposing it only IPC share.

04:08 - This means if you want to read and write data to thebuilder. exe you would do this by talking to Bob.

04:14 - 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.

04:27 - 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.

04:35 - 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.

04:44 - So to understand why this process was instrument to attack, we’re first gonna take a step back and look at traditional segmentation.

04:52 - We’ll cover how this tradition implemented and then why this gets hard and complicated over time.

04:58 - Then we’ll also show how a network intrusion could help with this.

05:03 - You would like to know that this won’t be a comprehensive guide on VLANs themselves or networking.

05:08 - It would just be enough to get a basic understanding of how VLANs works.

05:11 - So here’s an example for a new network, presumably for a new company, here, everything is connected to the same switch.

05:18 - Everything can talk to each other because it’s a flat network.

05:22 - Then the company hires a pen tester, he comes along and provides an assessment.

05:27 - 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.

05:36 - So the client starts to think about this and they get the idea to implement some form of zones.

05:42 - This, example, a blue client zone and an a yellow server zone.

05:45 - The idea here is to not allow traffic to flow freely between these zones unrestricted by default.

05:51 - To do this, the client would presumably use VLAN.

05:53 - 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.

06:03 - Basically what this does the blue color represents VLAN2 two and a yellow color represents VLAN1.

06:09 - Whenever devices is connected to a blue port, it will only allow traffic to flow to other ports, which are also blue.

06:17 - 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.

06:25 - Configuring ports this way is also referred to ONTAP ports.

06:29 - But, you know, a switch doesn’t actually use colors.

06:31 - 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.

06:51 - Which means, whenever the ethernet frame passes through the corresponding VLAN ID is added to the ethernet frame.

06:57 - 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.

07:07 - This isn’t all the switch can do though. This switch can also be configured using different IO ports called stack ports.

07:17 - So let’s take, another example with two switches.

07:20 - Here, we have the same VLAN ID as the blue one and the yellow one.

07:23 - 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.

07:31 - To do this, what we would do is we would configure two ports on corresponding switches as stack ports.

07:36 - 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.

07:45 - Having all of these devices segmented from each other is great for security, but not too much for productivity.

07:49 - You can use this device such as a firewall to allow a segmented access within zones.

07:53 - 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.

08:01 - This is the very basic concept of network segmentation using VLANs.

08:04 - And it’s pretty easy to understand within such a small scale network.

08:09 - But, you know, companies usually don’t have one VLAN or two, they have multiple.

08:13 - And, you know, after some basic rules it’s initially set up, they grow over time.

08:20 - And before you know it, there is a whole bunch of rules.

08:22 - Nobody knows what’s going on anymore. Everything is a fire and everybody’s screaming.

08:26 - So, you know, this is where the alternative solution comes in.

08:29 - One of these solutions, being a Palo Alto User ID, a firewall SSO solution is what I call it.

08:36 - Basically what it does. Palo Alto User ID creates a user IP mapping.

08:40 - 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.

08:51 - The Palo Alto User ID can be configured to collect information from multiple sources.

08:55 - For example, active directory, authentication logs, syslog servers, and the one in which we’re gonna talk about today, client probing.

09:04 - 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.

09:16 - 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.

09:24 - With only one client, then they are gonna dynamically assign a firewall to the specific IP.

09:29 - 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.

09:35 - The other thought in me was my hacker, talking in the back of my mind, you know.

09:39 - “Now, wait, what? We’re going to trust clients to return truthful responses and base our segmentation around that. ” Seems like a bad idea.

09:48 - So to explain why I thought it was a bad idea, let’s use an analogy to explain my thought process.

09:54 - 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.

10:02 - You know, being a cheapskate that I am, a Dutch boy, I didn’t decide to buy into this VIP system.

10:09 - 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.

10:22 - 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.

10:29 - So. Even though it’s says VIP only, I still want one of the good ones.

10:32 - So I walk up to the bartender and ask if and asked if I can access the VIP fridge.

10:38 - 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.

10:52 - 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.

11:03 - 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.

11:12 - But you now, instead of giving up, I want one of the good beers.

11:15 - 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.

11:21 - So I get this genius idea, you know, instead of saying who I am, let’s lie about who I actually am.

11:27 - So I walk up to the bartender, again, asking to access the fridge.

11:31 - This time I’m using different hotel room number.

11:34 - The bartender is again gonna look at this rule book, says VIP members are allowed to access the fridge.

11:40 - He then is going to look at his digital hotel room system.

11:42 - And sees he doesn’t know who’s currently residing in this room.

11:45 - 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.

11:53 - He’s then gonna take this information, look at this rule book and sees, you know, hey, Steve is a VIP member.

11:58 - 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.

12:08 - And this would potentially allow us to access things we aren’t allowed to.

12:13 - 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.

12:27 - The idea of an attack scenario here is basically the same as an app, web application. We might have it, you know.

12:32 - Whenever a web application just trust client input without validating it, you’re usually able to break things within the web app.

12:40 - 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.

12:59 - So let’s set up what we know for certain, the firewall ACL.

13:02 - Besides traditional VLAN and IP-based filtering, you can also assign extra source option within this ACL.

13:08 - This extra source option being either a user or an active directory group.

13:12 - In this case, the firewall only allows members of the VIP group to access specific fridge equipment on another VLAN.

13:21 - When implementing client probing, you can either use, SMB or WMI.

13:25 - The firewall itself only allows probing on WMI, but there’s also an agent, which allows for both.

13:31 - Since our presumed protect methods relies on SMB, we’re going to talk only about the client today.

13:38 - The agent itself needs to be installed somewhere on a system within the network.

13:42 - From its place it needs to be able to access the sources, which we try to collect data from.

13:47 - So in our test case, we’re gonna use some fair simple network design.

13:50 - Everything here is, is connected to the same VLAN except, except for the segmented fridge.

13:56 - This, of course, is not a typical corporate network design, but it will do for our demonstration purposes.

14:02 - 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.

14:15 - It needs to be installed on a host, which is then able to connect with different sources.

14:20 - You can, however, use multiple agents, if you want to, but doing that depends on your network design and the limitations of the software.

14:28 - Now that we understand our network design, let’s look at how you would install the agent.

14:35 - When installing the Palo Alto USER ID agent software you are prompted to use a service account.

14:41 - If we were to able a flat standard active directory user as the service account, it would error out.

14:47 - Because the minimum needed rights are already logged on as a service user rights assignment.

14:52 - Then depending on the collecting methods you want to use, you would then add additional rights to this account.

14:59 - 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.

15:09 - 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.

15:19 - 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.

15:31 - 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.

15:41 - Anyhow, after having set up the appropriate rights for the user, you can start to configure the agent.

15:45 - When doing so you would fairly easily figure out that you don’t need to do much.

15:50 - Both the server collection method and client probing is enabled by default on both WMI and SMB.

15:57 - 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.

16:04 - 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.

16:14 - 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.

16:21 - 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.

16:31 - 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.

16:40 - But if all this time is 45 minutes. However, this caching time out does not correlate to the probing in default.

16:47 - 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.

17:00 - Now that we’ve taken off the confirmation of the client itself, we can look at the firewall.

17:05 - So the first thing we do is just simply add the agent to the firewall.

17:09 - This will enable the firewall to talk to agent whenever a specific ACL triggers the events to collect information from the user.

17:15 - Then what you would do is you would enable user identification ACL on zone where you would want to configure this.

17:21 - And then, to allow the firewall to know about users in your server, in your environment, you would add a LDAP profile.

17:27 - This LDAP profile is basically going to link, you know, the resources from active directory to the firewall.

17:32 - Then from this point onwards, you’re able to create firewall rules using users as a source.

17:37 - But if you want to also use groups, you need to do one additional step.

17:41 - 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.

17:49 - So it doesn’t need to perform an LDAP query every time, you know, a user matches in ACL.

17:55 - 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.

18:06 - And if it doesn’t, the agent doesn’t know, it’ll stop probing us.

18:10 - In this example, we could see an Ubuntu client performing a ping towards the fridge, and you could see the agent starts probing us.

18:16 - So as you now know, instead of three components there are actually four components in this flow.

18:21 - There’s the client, VLAN1, there’s User-ID agent, the firewall and the fridge, which we want to access.

18:27 - 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.

18:36 - Then we come along and ask the firewall to access the specific fridge in the segment of VLAN.

18:41 - 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.

18:48 - 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.

18:56 - 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.

19:06 - So whenever a request comes in, we throw an error like “Lolwut? unsupported DCE/RPC”.

19:14 - 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.

19:26 - So we’re going to look at some Microsoft documentation and we’ll figure it out from there.

19:30 - So again, if you look at a packet capture we would see that the probing request, tried to access a named pipe called wkssvc.

19:37 - With a bit of Googling around you could easily figure out that this actually called the Workstation Service Remote Protocol.

19:44 - Luckily for us am actually had this huge, handy PDF which fully explains everything within this named pipe.

19:49 - So when I actually want to build something around this I was kinda looking up against, you know, building this from scratch.

19:54 - 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.

20:08 - When it came down to actually implementing the NetrWkstaUserEnum function, most of them, most of the work was already done for me.

20:16 - All this works. For the function to properly function were already implemented in Impacket as Python classes.

20:24 - Here on the left, you can see a simplified version of the requests as Microsoft describes it.

20:28 - And on the right, you can see the class within the Impacket solution.

20:32 - 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.

20:40 - But before I start extending Impacket I want an easy way to verify from the code I was doing.

20:45 - So with a bit of Googling, I found this function called NetLoggedOn, which is Powershell function, written by @harmj0y.

20:51 - This function, basically does the same thing as the firewall will do.

20:54 - So this allows us to start, test our code, without having to rely on a firewall.

21:00 - With the firewall temporarily out of the way, I could start implementing things with netpacket.

21:04 - 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.

21:13 - So the first thing is whenever, currently, whenever Impacket receives a probing request, it has no idea how to handle this.

21:20 - So in order for Impacket to support this, what we would do is we would edit a dictionary within the class.

21:26 - which basically going to link this opnum code to a method which you would define later.

21:30 - This way, whenever Impacket receives a specific opnum code, it knows which method should handle this request.

21:38 - The next one’s you shouldn’t add arguments on the SMB server clause itself.

21:41 - 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.

21:53 - After doing this, within the clause itself, you can use a dictionary to get the information back you initially supplied on CLI arguments.

22:00 - As you can see here, the values that initially added the CLI agreements are here used to return the actual information upon our request.

22:10 - So let’s actually look at this is an action.

22:13 - Here, on the top we could see a Powershell session, with the Get-NetLoggedon user function loaded.

22:17 - And on the bottom, we can see a Ubuntu client with our modified version of Impacket.

22:24 - 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.

22:33 - Meaning that we’re currently able to fully respond to these probing requests.

22:39 - 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.

22:51 - And then afterwards, port forward this to the firewall.

22:55 - 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.

23:02 - You know, which is great. Everything is in place for this attack.

23:05 - So let’s take this and apply it to the real thing.

23:08 - So you can see a firewall configured with a user ACL.

23:14 - Here it says that only VIP members within VLAN1 are able to access the fridge within VLAN2.

23:22 - Then, here on the right. You can see the Active Directory console with the specific user group.

23:29 - On the left. You can see you an Ubuntu client, which we’ll gonna cover more shortly.

23:34 - If you open the VIP members group, we can see that the user, Steve, is a member of this group.

23:42 - Then, if you look at the palo_alto_userid agent, here, we could see current user IP mapping cache.

23:49 - To show you that I’m not cheating. Here on the left.

23:51 - We can see that the Ubuntu client has one IP address.

23:58 - And this currently isn’t listed within the IP-User Mapping Cache.

24:03 - Then it will start to generate some network traffic matching firewall rule.

24:09 - You would see we are now able to access this specific fridge.

24:22 - 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.

24:33 - 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.

24:48 - Start the agent, we just have to wait a while for it to start probing us.

24:54 - And when it eventually does. You can see they would just return domains\steve as our logged on user.

25:06 - You can see that then this information is added through the user IP mapping cache.

25:10 - And on the bottom-left, you could see our ping, currently being allowed to access the fridge.

25:15 - So we switch over to our browser again. Here, we can see all the beers we want to access.

25:18 - You know, great to see this. We just succeeded in bypassing a firewall ACL.

25:23 - So if you want to play around with this stuff, it goes in GitHub.

25:25 - You know the QR codes on screen so scan it in a phone.

25:30 - 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.

25:37 - 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.

25:46 - Though, I did find one called SonicWall and they referenced something called NetAPI.

25:52 - So as I looking into it. You know, NetAPI is something called SSO solution.

25:56 - It’s basically much the same as Palo Alto User ID.

25:59 - 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.

26:08 - The only main difference being is that the documentation of something called (indistinct).

26:14 - 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.

26:22 - Apart from that there’s not much else going on so we can just jump right into the demo.

26:27 - Here, we can see the SonicWall SSO Age. Being configured, you start probing clients using NetAPI.

26:34 - 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.

26:54 - Then, if we start to generate some traffic, you can see we currently aren’t allowed to access this resource.

27:01 - If we look at our SMB implementation. You can see that we supplied the username administrator and corresponding domain.

27:27 - And after starting this server we just have to wait a while for the agent to start probing us.

27:41 - And when it does, you can now see by returning the correct information, we’re able to allow access through this firewall ACL.

27:48 - 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.

28:03 - So, whenever SMB, Impacket SMB server is started without any form of authentication.

28:09 - 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.

28:21 - The issue being here, is that it shouldn’t be possible, by default, in a recent version of Microsoft Windows.

28:27 - By default there should be no access in registry key, which will prevent the client from accepting SMB server session with guests access enabled.

28:34 - But you know, up to this point, we haven’t had any problems with this.

28:38 - 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.

28:48 - However, it does on Server 2019. Meaning if you were to install this agent on a Server 2019 server, this exploit won’t work.

28:56 - If it’s installed on a Windows 10 client, I will recommend you to check if this register key exists.

29:01 - If not, enable it. So let’s go over to disclosures.

29:07 - I started my first disclosure with Palo Alto and shared two findings.

29:11 - The agent SMB hash disclosure and the actual bypassing firewall ACLs.

29:14 - I wasn’t informed NetBIOS-based client probing will be dropped from further version of Palo Alto User ID.

29:21 - 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.

29:31 - Then after that, after being told that, I was added to the hall of fame.

29:35 - I currently don’t know the status of the dropping of NetBIOS.

29:38 - 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.

29:47 - Then we can call for the disclosure of SonicWall.

29:49 - I started this disclosure at the same time.

29:52 - And then after some while they informed me that the issue was actually a duplicate.

29:57 - Besides that they told me that they would add a warning whenever the user administrator was used.

30:02 - 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.

30:09 - 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.

30:20 - After sometime I received an email, which informed me that they released associates CVE number for the issues.

30:28 - So looking at the disclosure of the vendor, I figured out who the other researcher was, Sedric Louissant.

30:34 - 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.

30:48 - Meaning that SonicWall just took a vote for findings tacked mine onto his and call it a day.

30:54 - 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.

31:03 - So I installed the agent and, you know, I did find out a couple of things.

31:08 - 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.

31:18 - Meaning, if you were to create a user and gave it domain admin rights it will not prompt this warning.

31:23 - 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.

31:33 - They also changed the default probing method.

31:36 - Before the disclosures this was NetAPI. Afterwards, they changed this to WMI.

31:41 - They also updated the documentation. They do now reference that you should use a local administrator when you want to use NetAPI-based probing.

31:53 - So, you know, what’s next for this research.

31:56 - There’s potentially $Vendor3. I expected them to also be vulnerable.

32:00 - Their implementation is slightly different than we talked about today, but I think they’re vulnerable.

32:04 - So I already started a disclosure process with them.

32:08 - Besides that I did notice there were a couple of vendors which used in winreg named pipe.

32:15 - This winreg named pipe references to a Windows registry.

32:17 - And basically before my check within the registry to enumerate a lot on users.

32:22 - It would require some further research, but I think this is also vulnerable to the same thing which we talked about today.

32:29 - Also, there was a lot of vendors, which was WMI to form probing requests.

32:35 - Currently, there are no open source implementation of setting up a, your own WMI server.

32:41 - 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.

32:48 - Apart from implementing a new protocols and that kind of stuff.

32:51 - We might also be able to abuse the caching function of the agents.

32:55 - You know, let’s imagine you have someone working within the corporation, it’s five o’clock to leave for home.

33:01 - We might be able to reuse his IP, statically assign it to ours.

33:04 - And hopefully the IP address still hasn’t used to IP mapping cache.

33:10 - Other than that, you know, we talked about firewalls today, but there might be other products out there which uses similar technique.

33:17 - You know, even though they, I would think they wouldn’t use SMB for probing with WMI.

33:23 - It wouldn’t surprise me if they were to support an SMB-based probing method.

33:27 - And I’ll use the same idea we talked about today.

33:31 - You might be able to trick the vendor or product into doing something unexpected, by returning arbitrary information.

33:38 - 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.

33:49 - I think that generally, client probing is a bad idea.

33:52 - 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.

34:00 - And, you know, basing a logic product for production applying security rules around that is, in my brain, a bad idea.

34:07 - Finishing up today. This can now be exploited by the Impacket implementation build.

34:13 - 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.

34:21 - Another big one being it’s just because a vendor supports a specific feature.

34:25 - This feature does not mean it’s secure, secure by default.

34:28 - In both cases, defendants we looked at today supported a method, which is generally known to be insecure.

34:34 - In both of the cases, you know, it was enabled by default.

34:39 - You, as a person, really need to practice due diligence when it comes to looking at these extra features.

34:44 - You know, you need to look at it how to implement it and ask yourself, you know, the what-if questions.

34:48 - 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.

34:55 - So thanks for listening to me rambling about firewalls for forty-five minutes.

34:58 - If you think I got something wrong, please reach out to me on Twitter.

35:01 - If you want to play around with this stuff yourself, the code is on GitHub.

35:05 - That’s all for me. Have a nice DefCon. .