Palo Alto Networks firewalls have the ability to create security policies and generate logs based on users and groups, and not just IP addresses. This functionality is called User-ID.
User-ID™ enables you to map IP addresses to users on your network using a variety of techniques. The methods include using agents, monitoring domain controller event logs, monitoring terminal servers, monitoring non-AD authentication servers and syslog servers, and even through captive portals (that prompt the user for login). In addition to its use in policies, logging access and threats by user can be invaluable in incident response and forensics. To take full advantage of this feature, it is ideal to map as many IP addresses to users as possible.
With all these great methods to map users to IP addresses, we often miss many systems. They include non-domain joined systems, Linux/Unix systems that don’t centrally authenticate, and potentially many other devices (phones, cameras, etc.). Palo Alto has yet another feature for mapping users, but one that comes with great risk.
To identify mappings for IP addresses that the agent didn’t map, the firewall can probe and interrogate devices. The intention is to only probe systems connected to trusted internal zones, but a misconfigured zone could even allow sending probes out to the internet. Taking that misconfiguration aside, client probing is still a significant security risk. By default, Palo Alto agents send out a request every 20 minutes to all IP addresses that were recently logged but not mapped to a user. It does this assuming that the IP belongs to a Windows system and it uses a WMI probe to log into the unmapped system.
SynerComm believes that a large number of PAN
customers have enabled WMI and/or NetBIOS Client Probing within the User-ID
settings. Our AssureIT penetration
testing team is regularly detecting this on internal pentests. SynerComm
recommends disabling Client Probing in the User-ID Agent setup due to the risk.
Many networking and network security devices use Microsoft WMI probing to interrogate Windows hosts for things like collecting user information. For authentication purposes, a WMI probe contains the username and hashed password of the service account being used. When a domain account is used, an NTLMv1 or NTLMv2 authentication process takes place. It has come to our attention that our penetesters are finding Palo Alto firewalls that are using insecure User-ID methods. Specifically, those that are using WMI and NetBIOS probes to attempt user identification. This allows an attacker to obtain the service account’s username, domain name, and the password hash (more likely the hashed challenge/nonce). Because the service account requires privileges, this becomes a serious security exposure that could be easily abused.
An October 30, 2019 Palo Alto Advisory “Best Practices for Securing User-ID Deployments” recommends ensuring that User-ID is only enabled on internal/trust zones, and applying the principal of least privilege for the service account. Again though, SynerComm recommends also disabling WMI probing completely.
(By: Brian Judd, VP Information Assurance)
In a perfect world, we could trust that every device on our internal network is owned, managed, and monitored by our company and our staff. That includes having full trust that no systems are already compromised, and that no intruder or insider could place a rogue device on our network. Because this is rarely, if ever the case, it’s a stretch to think that it’s safe to share valid domain credentials with any device connected to an internal network.
Using well-known penetration testing tools like responder.py, it is trivial to setup a SMB server that that can listen for and respond to NTLM authentication requests. When good OPSEC isn’t a factor, responder.py also includes abilities to respond to LLMNR and NetBIOS broadcasts to poison other local systems into authenticating to its listening SMB server. It then stores the username and the hashed challenge (nonce) from the authentication messages. Depending on the strength of the password, these captured “hashes” could be cracked and the account could be used to log into other systems.
While all of that sounds scary, it isn’t the concern of this article. If configured to use “Client Probing”, Palo Alto firewalls and their User-ID agents make WMI and NetBIOS connections to map unknown IP addresses to their logged in user. Also, because WMI is IP based, it’s possible to probe any reachable (retable) network/system. To be effective, User-ID almost always uses a domain service account so that it can access any domain member system. An attacker with the ability to run responder.py on an internal network is likely to receive authentication requests from Palo Alto User-ID agents without any need for noisy poisoning attacks. By default, the agent probes every 20 minutes and anytime a new log is written to the firewall without user identification.
OK, let’s make this a bit worse… What if we didn’t need to crack the service account’s password? What if we could just relay the agent’s authentication request to another system and trick it into authenticating the attacker instead? Again, this is trivial and easy using well-known tools like ntlmrelayx.py or MultiRelay.py. Even worse, these tools are not exploits, this is how NTLM authentication was designed to work. If the relayed account’s privilege is sufficient, ntlmrelayx.py will even dump the system’s stored hashes from the SAM database, or execute shell code.
Oh, remember earlier when I mentioned that Palo Alto’s agent probes anytime a new log is written by an unmapped IP address? Using this “feature”, we can script something as simple as a DNS lookup or wget request to generate access logs on the firewall and trigger a User-ID authentication request. With a little time, these logins could be relayed to log into every other system on the network. Considering that older Palo Alto documentation was vague with regards to the necessary service account privileges, it is common to find them as members of highly privileged groups including Domain Administrators. To an attacker, this could be game, set, match in just a few minutes.
The include and exclude lists available on the User-ID
Agent, as well as agentless User-ID, can be used to limit the scope of User-ID.
Typically, administrators are only concerned with the portion of IP
address space used in their organization. By explicitly specifying
networks or preferably a host address /32, to be included with or excluded from User-ID,
we can help to ensure that only trusted and company-owned assets are probed,
and that no unwanted mappings will be created unexpectedly. See above image.
WMI, or Windows Management Instrumentation, is a mechanism that can be used to actively probe managed Windows systems to learn IP-user mappings. Because WMI probing trusts data reported back from the endpoint, it is not a recommended method of obtaining User-ID information in a high security network. In environments containing relatively static IP-user mappings, such as those found in common office environments with fixed workstations, active WMI probing is not needed. Roaming and other mobile clients can be easily identified even when moving between addresses by integrating User-ID using Syslog or the XML API and can capture IP-user mappings from platforms other than Windows as well.
On sensitive and high security networks, WMI probing increases the overall attack surface, and administrators are recommended to disable WMI probing and instead rely upon User-ID mappings obtained from more isolated and trusted sources, such as domain controllers.
If you are using the User-ID Agent to parse AD security event logs, syslog messages, or the XML API to obtain User-ID mappings, then WMI probing should be disabled. Captive portal can be used as a fallback mechanism to re-authenticate users where security event log data may be stale.
User-ID deployments can be hardened by only including the minimum set of permissions necessary for the service to function properly. This includes DCOM Users, Event Log Readers, and Server Operators. If the User-ID service account were to be compromised by an attacker, having administrative and other unnecessary privileges creates significant risk. Domain Admin and Enterprise Admin privileges are not required to read security event logs and consequently should not be granted.
Detailed process to create dedicated secure Windows service account
While the User-ID service account does require certain
permissions in order to read and parse Active Directory security event logs, it
does not require the ability to log on to servers or domain systems
interactively. This privilege can be restricted using Group Policies, or
by using a Managed Service Account with User-ID (See Microsoft TechNet for more
information on configuring Group Policies and Managed Service Accounts.)
If the User-ID service account were to be compromised by a malicious user, the impact
could be reduced by denying interactive logons.
Typically, service accounts should not be members of any security groups that are used to grant remote access. If the User-ID service account credentials were to be compromised, this would prevent the attacker from using the account to gain access to your network from the outside using a VPN.
Prevent any unwanted traffic (including potentially unwanted User-ID Agent traffic) from leaving your protected networks out to the Internet by implementing egress filtering on perimeter firewalls
For more information on setting up and configuring User-ID see the following or contact SynerComm today:
User-ID, PAN-OS Administrator's Guide
https://docs.Palo Altonetworks.com/pan-os/9-0/pan-os-admin/user-id/user-id-concepts/user-mapping/client-probing.html
Getting Started: User-ID
Create User Groups for Access to Whitelist Applications, Internet Gateway Best Practice Security Policy
User-ID Resource List on Configuring and Troubleshooting
https://www.helpnetsecurity.com/2019/06/11/microsoft-ntlm-vulnerabilities/
