PAN-SA-2023-0004 - GlobalProtect fix being worked on for this vulnerability?

[TonyDeHart]

https://security.paloaltonetworks.com/PAN-SA-2023-0004

This bulletin states that there is no fix for the GP Client. Does anyone know if they are working on one?

The idea of locking down completely the local LAN could prove difficult and after a discussion with GoDaddy (our cert provider) they state they will not issue a cert with an IP address in the SAN (I'm aware others might do so).

Seems that according to other sites other VPN clients are fixing this so is a GP update imminent?

[Claw4609]

Just out of curiosity do you have links stating that other vendors are applying updates to fix this? Microsoft said they weren't releasing anything for the build in Windows client and it doesn't look like Cisco plans a release either. It looks like Ciscos response is pretty much the same as Palos. 

Bypassing Tunnels: Leaking VPN Client Traffic by Abusing Routing Tables Affecting Cisco AnyConnect S...

TunnelCrack: Widespread design flaws in VPN clients (mathyvanhoef.com)

[TonyDeHart]

The https://tunnelcrack.mathyvanhoef.com/details.html references Mozilla VPN, Surfshark, Malwarebytes, Windscribe, Cloudflare.  Maybe I'm reading more into that than is intended but it says explicitly they worked with these vendors and produced a patch

If others are taking the approach that no further action is necessary and Palo Alto does the same, I suppose we'll have to live with it but its odd, in my opinion, for a vendor to throw up their hands and say, "Sorry, you'll have to live with this."

Full excerpt below:

To protect users, security updates were prepared during a 90-days coordinated disclosure in collaboration with CERT/CC and various VPN vendors. Some example patched VPNs are Mozilla VPN, Surfshark, Malwarebytes, Windscribe (can import OpenVPN profiles), and Cloudflare's WARP. If updates for your VPN are not available, you can mitigate the LocalNet attack by disabling local network access. You can also mitigate attacks by assuring websites use HTTPS, which many websites nowadays support.

[Claw4609 · Accepted solution]

Yeah not disagreeing with you on that, maybe just given the setup its something that just simply cant be address with a Global Protect update, not sure. Both pieces thought, ServerIP and LocalNet attacks, can be addressed with configuration changes. 

In you case it looks like youre referring to the ServerIP attacks. You could still have the GoDaddy cert for the GlobalProtect portal, then a self-signed cert with the IP address for the GlobalProtect gateway, and hand this out on the portal connection. 

[TonyDeHart]

That is a brilliant idea thank you!  I've got a backup VPN setup that I can test this with.

Honestly, though, the bigger concern is the LAN cutoff as we have users who need to print (yes...printers) so cutting them off could prove problematic but that might be easily worked around with some exceptions and perhaps dictating a subnet they need to use.

I'm really hoping they can address this with a client update however.

[TonyDeHart]

So I guess I'm not smart enough to figure this out.  I created at first a self-signed certificate and checked the CA box when creating it and could add the certificate to the portal but it always fails saying the server certificate can't be verified.  I then signed it using the root CA for the firewall that I had created some time ago and it'll let me add the root CA to the trusted root ca list but of course not the self-signed one and with that it still doesn't work.

So I thought I had to change the SSL cert profile on the Authentication profile (GP Gateway->Authentication->SSL/TLS Service Profile) but then, much to my surprise, the PORTAL cert changes (https://portalfqdn.com)

which made no sense to me.  Why would the PORTAL cert change when I'm at the gateway level changing the certificate.

Not sure where to go with this for self-signed now or what part of this I'm missing.

[Claw4609]

You'll need two different ssl/tls service profiles, one for the gateway and one for the portal. Heres examples of how the config would look.

Self-Signed cert chain:

SSL/TLS Service Profile (you'll need another one in addition to the image I have attached, one for your godaddy public cert):

GlobalProtect Portal Service Profile:

GlobalProtect Agent Certs:

GlobalProtect Portal Agent Config:

GlobalProtect Gateway Cert:

Self-Signed Cert:

Does this help? I was able to test a similar setup and it works as intended

[TonyDeHart]

I'm not near where I can make this change and test but I'll do so in the morning and give it a try.  The only difference in your config vs what I tried that I can see is the addition of the two Certificate Attributes for IP address and SAN name.  I only had the IP address in the common name field.  What is throwing me is that the step where you set the GP Gateway Cert - when changed - effectively knocks out the PORTAL HTTPS WEB GUI cert (where you'd go, authenticate and then download the GP client).  That was unexpected as I would have thought your step (and mine too) where the GP Portal Service Profile is set would control the cert attached to the GP Portal Web Site.  As soon as I change the cert on ONLY the gateway I get a cert error on the Web GUI for the Portal which makes no sense to me.

[TonyDeHart]

So I tried this and while it does fix the login to the VPN client itself it does NOT fix the certificate error with the Portal Web GUI.  If I go to a device that has never logged in before the portal uses the self-signed cert instead of the proper cert assigned to the portal.

Possibly the only real solution is to get a proper SAN cert with IP addresses in SAN component but I'm still baffled why the portal cert changes when modifying the gateway.

[TonyDeHart]

It appears that this can't work with a self-signed certificate when the portal and gateway share the same IP address. So the self-signed certificate on the gateway breaks the ability for a public machine to get to the web portal w/o a certificate error.

Guess its off the the SSL cert store. 😀

See here: https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/get-started/enable-ssl-betw...

• If you configure a gateway and portal on the same interface, we also recommend that you use the same certificate profile and SSL/TLS service profile for both the gateway and portal. If they do not use the same certificate profile and SSL/TLS service profile, the gateway configuration takes precedence over the portal configuration during the SSL handshake.

[dwooldridgeLOU]

So what does one do when telling the agent to install the new root ca cert doesn't work? It's not pushing these certs out to users machines when they try to connect so it fails at gateway cert invalid. Suppose Ill push the cert out later today with group policy since palo alto's tools are ineffective at the moment.

Ultimately simply telling us to disable FQDN functionality is a hack and palo alto needs to directly and publicly address this to let us know they intend to restore safe FQDN functionality, or they intend to let globalprotect die so we know to look to other solutions. Ticket entered with support. We shall see what they say.

[TonyDeHart]

I'm right with you there as the thought this isn't getting fixed seems like passing the buck to me.

Worse, right now, it appears I need to do a SAN with an IP Address in it and I can find nothing documented on Palo's site that shows how to validate the IP address with the portal using the industry standard DCV method.

Their workaround isn't even clear how to make it work with a public cert let alone a private one.

[dwooldridgeLOU]

I have the portal and gateway (using the same external IP) using different certs, and I am sure I can get the machine to accept the self signed one I will just have to push the root another way. I just can't keep testing on a production system with unclear solutions.

To take away FQDN and then make us start doing self signed certs flies in the face of a bunch of best practices. With their security advisory emails having gone out recently I bet their call center is still on fire with people trying to get it to work with self signed certs.

[TonyDeHart]

Sort of a double post here but I've confirmed with Palo Alto they have no mechanism in place to validate the IP via the GP Portal using industry standard methods.  Essentially the workaround/mitigation of the server component of Tunnelcrack doesn't work.

I didn't hear back here so had opened ticket with Palo and I'm told that DCV isn't possible.  Basically they've put out this bulletin:

https://security.paloaltonetworks.com/PAN-SA-2023-0004

Asking us to assign an IP and change our certificate but have absolutely no way of doing so since a public cert can't be verified properly as the industry standard method of doing so is not available on the portal.  Just perfect!

For reference this is an example of the validation method from Digicert but others are similar process:

https://docs.digicert.com/en/certcentral/manage-certificates/dv-certificate-enrollment/domain-contro...