topic Re: Vulnerability Protection for CVE-2024-3400 in GlobalProtect Discussions

Vulnerability Protection for CVE-2024-3400

mb_equate — Thu, 23 May 2024 06:21:57 GMT

TL;DR: ensure you are applying Vulnerability Protection to web-browsing traffic hitting your GP portal interface, if you rely on the intrazone-default allow

I was responding to another case of this flu. Even though the best-practice strict VP profile was attached to the rule allowing access to the GlobalProtect interface, a test for the vuln (curl -kH "Cookie: SESSID=/../TESTVULN" https://<target>/global-protect/login.esp) yielded positive results.

What The Firewall? Turns out exploit traffic does not match the required apps in the GP rule (panos-global-protect, ssl) and instead matches web-browsing. Thanks to the default, intrazone-default rule, this traffic was permitted without Threat Prevention being applied.

The fix? Multiple. In order of effectiveness...

1. Change your intrazone-default rule to Deny

a. This is by no means a simple change, and should not be done without analysis and required policy adjustments

b. Why? See LIVEcommunity - Should I override the intrazone-default to deny? - LIVEcommunity - 581801 (paloaltonetworks.com)

2. Override the intrazone-default rule and enable Threat Prevention

a. Even better, create a security profile group based on best practices, call it default (lower case d) and use it everywhere

3. Add web-browsing to the rule that provides access to GP portal

a. Ideally you should not be permitting web-browsing to your GP interface, either explicitly or through intrazone-default. BUT if you must, do this.

Re: Vulnerability Protection for CVE-2024-3400

kiwi — Thu, 23 May 2024 09:51:35 GMT

Hi @mb_equate ,

As always thanks for your insights !

Kind regards,

-Kim.

Re: Vulnerability Protection for CVE-2024-3400

Frank-Bussink — Fri, 31 May 2024 12:58:07 GMT

Hi,

I would also add another layer of security, which came to mind after this **bleep** CVE.

Use a wildcard certificate as SSL cert. (by the way even Let's encrypt proposes wildcards).

Generate a random hostname for the GP hostname. Example : GP-123456.mydomain.com

Create a Custom URL category with only that FQDN (https://GP-123456.mydomain.com)

Add the URL category to your incoming rule policy for GP.

Add another rule below it, with the dest GP IP and action as Drop (silently)

This means, if a scanner or anybody uses not the correct FQDN, the communication will be dropped.

And by using a wildcard, it is not possible to guess the hostname

😉