Vulnerability Protection for CVE-2024-3400

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Vulnerability Protection for CVE-2024-3400

L3 Networker

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 (paloalton...

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.

2 REPLIES 2

Community Team Member

Hi @mb_equate ,

 

As always thanks for your insights !

 

Kind regards,

-Kim.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

L0 Member

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 

😉

  • 1061 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!