Active Directory Network Agents and not-good deployments
That’s a Nice Palo-Alto Firewall Forescout Active Directory Integrated Network Appliance you have ther
Sounds like the nerdiest Harry P otter title doesnt it ?
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 username responses from the collection:
- 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
What is to be learned from this?
As an attacker, if I collect Administrator, Administrador I’m highly confident it’s domain admin for me, or a canary.
Usually providing maximum privilege to a service account is a side effect of ‘just get it working, we’ll worry about it later’ and lack of maturity within the support team. let’s say these aren’t available, altho very popular in my collection of data.
we move to what appeals the most: MasterAdmin, Operations, backup, superuser all look ripe for the picking for me the point I’m drawing too here is these appear to be shared multi-role accounts, possibly possibly yield an interactive desktop privilege, just like domain admin, or failing that a foothold on other systems that will use these shared account details. useful as an attacker because the confusion of the account being used where might be enough fog to assist your goals.
Lastly some sensible names that look specific to the service: paservice, pan.agent, svc.paloalto look like someone has read the manual, altho I remain skeptical as I have those credentials too, But the takeaway here is a meaningful, easy to read naming convention personally I favour solution.svc.group, papana.svc.itops for example you know it’s ITops baby, you know it’s a service account and if you spoke to them and said ‘what’s papana‘ they would tell you.
Passwords and Password Considerations
Service Accounts are should be non-interactive, so there is no reason why you can’t use a big fat juice random string. do that. equally, my collection data was NTLMv1 and NTLMv2, Kerbros Is better, if you can use that, do so, NTLMv1 and NTLMv2 are very easy and easy to attack with good wordlists, known passwords and rules I use hashcat, JtR is amazing too.
Stock Check
If Two-Form Authentication isn’t enabled on the VPN, and I can steal the credentials given to the PAN Agent, … now I’m authenticated against the domain and layer 3 on your internal network, how far do these credentials reach, what opportunities are available?
For a junior pen tester this is a walk in the park, then fact that these issues exist is also compelling the assertion that NAC probably isn’t present and if it is, probably irrelevant to the access you have, you may even be in an admin position to reconfigure the Palo Alto.
Moving away from the attack view
Security involvement in business critical infrastructure is important, if you don’t have time outsource it, *hi*, Retrospective assessments are still valuable, even if you’re stuck with a product because of budget and roadmap, knowing is useful, knowing and changing is better, – something about the real world- . having a security team member participate in IT roll out’s of appliances that automate complex tasks in a bid to relieve pressure from teams, these appliances are often miss understood, they need intelligent configuration, but vendors will tell you it’s plug and go, they want the sale, they don’t care about their own support team, money is money. it’s important those managing the appliances agree on logging monitoring, alerting, standard operating procedures, backups and change control not to mention feel comfortable commanding the settings and understand the impact of those changes.
keep security in the loop, even if it’s just to spectate or better yet, push accountability onto them, make them say it’s fine.
Moving away from Palo
Any network device that has an active directory integrated agent that logs into clients is fair game here, but in a different context, a LAN context, removing the silly 0.0.0.0 issue from previous versions of PaloAlto appliances, the common flaw in AD Appliances is that they assume all network members are AD members, if you have DHCP and don’t lock the ports down, you’ll know anything asking for an IP will get one, if you’re having an internal penetration test, and are using appliances that operate similar to PAN Agent or Forescout, unless you have a really long passphrase there is a good chance that’s how the pen tester is getting a foothold on the domain, they will do it anyway, even with the least privilege model in place, it just might take them too long, or there may be other issues to work with (not the point), a lot can be drawn from address book only access from a domain, but I’ll leave that for another day.
Takeaway
- Threat Model.
- The system generally
- The particular requirements from the system
- Pentest
- Maintain visibility of changes
- Updates
- Config Changes
Apply this to anything on your organisations networks pro-actively or retrospectively, make sure you have the right minds asking the right questions, if you think there are skill gaps, use externals.
If I can’t help… I can help.