Active Directory Integrated Network Appliances

That’s a Nice

Palo-Alto Firewall Forescout

Active Directory Integrated Network Appliance you have there … be a shame if it:

Exposed it’s PAN Agent hashes to the internet Used a weak password Used a shared existing AD account Used an Ad Account not following a least privilege model Use a non-interactive AD service Account

Let’s look at how this happens:

Proof of Concept goes Live

A group off people somewhere are relieved the project is finished … is it finished? here’s a security focused checklist:

The network position of the appliance is understood and approved by network admin and security team Approved Logging, monitoring, alerting and access is available to teams that need that data. (can you list the teams ?) Security has signed off the use of the system and have threat modelled independently of the vendor, and performed penetration testing against the use cases as a service, administrator, user, and residual exposed points of interest (or, of course, deeper). Any inherited risks are logged and discussed, countermeasures in place, risks accepted and revisited at nDate Security and IT get release information regarding updates and software patches, we know vendors like to keep security fixes low key. Transparency between Security and IT over configuration changes Deconstructing the Security Focused Checklist

Without a holistic view of the mechanics of how the system works we fall victim to unknown gaps, some of the research I had conducted in 2016 exposed over 400 systems surrendering their Active Directory service account (Domain:Username:Hash)

the thinking that lead to this discovery was to port scan the internet on selected ports, and from the same system, leave services running to see what is returned, it would be excellent to do research piece on ASN by ASN and full packet capture analysis of the results, but … that’s out of scope here.

What was happening ?

Let’s understand the standard topology of a Palo-Alto Appliance with VPN and Palo Alto Network Agent (AD integration)

VPN needs to have an external address, that’s how VPN clients reach from outside in,Internal addressing is just that, internal, using non routable IP’s and computer names that won’t resolve outside of the network.

The PaloAlto Network Agent (PAN Agent) will wake up when any IP Addresses that are defined as ‘the $organisations network’ receives hits on certain ports and then if that host isn’t already listed, it will take it’s network agent and traverse networks to the source of the connection, log in with it’s AD Credentials, see the system and or users profile, apply entitlements and it’s all golden.

at least 420 Internet facing PaloAlot’s had the interface of 0.0.0.0 for the PAN Agent, instead of internal networks only, what 0.0.0.0 means is ‘all interfaces available to this system’ … that includes the internet exposed VPN. So what that means is that if someone hits that external IP address the Internal PAN Agent will make it’s way across the internet to the source of the request, when it gets there if there is any credential challenges, it will surrender what it has been given

If something offers a cyber security researcher it’s password, it’s polite to take it. Here are some sorted common username responses:

ADMIN_PALO Administrador Administrator LDAP MasterAdmin Operations PA_userID PAagent PaloAltoSecurityLogs PaloAltoServiceLogon service.firewall superuser admin adminservizi backup backupadm bkupsa05 no-paloalto oarpauserid pa_userid paagent palo supervisor svc_paloalto paloagent paloalto paloalto-userid paloaltoldap paloaltoservice pan.agent pan.svcs panuser paservice sdadmin