Important security update - stay protected against VPN Information Disclosure (CVE-2024-24919)

[_Val_]

Update June 5, 2024

We now have fixes for CVE-2024-24919 for releases dating back to R77.30 with latest JHF.

Update June 4, 2024

The procedure to identify vulnerable Security Gateways in sk182336 - Hotfix for CVE-2024-24919 was updated.

The Gateways script was replaced with v3. The updated script checks if the Hotfix is installed.

Update June 03, 2024

Automatic interim preventative measure deployed through AutoUpdater utility

Security Gateways that were configured to the Check Point's Auto Update process are gradually receiving an update (as of June 2, 2024), which helps protect them from various attempts to exploit the CVE. This is an interim preventative measure until the Hotfix is fully installed on customers’ Security Gateways. It is important to emphasize that installing the Hotfix in sk182336 is the best way to stay protected from this vulnerability.

This is relevant for gateways running R80.40 and above. Instructions to confirm this is enabled are in sk182336.

Update June 01, 2024

Quantum Spark

We now have a specific SK related to CVE-2024-24919 for Quantum Spark appliances! : sk182357

In addition to providing links to updated firmware, this SK lists the specific remediation steps that may be necessary on Quantum Spark Appliances, which includes: 

1. Disable the Remote Access VPN blade
2. Change the Administrator passwords and use complex passwords
3. Restrict access through "Reach My Device"
4. Enable Two-Factor Authentication for Administrators (R81.10.10 and higher)
5. Enable Two-Factor Authentication for Remote Access VPN users (R81.10.10 and higher)
6. Enable notifications for administrator access

 

cccd

In R81.10 we added a feature to improve VPN performance - named CCCD

This feature is disabled by default, and we know about few advanced customers who are using it.

Customers who enable CCCD are still vulnerable to CVE-2024-24919 even after installing the Hotfix!

YOU MUST DISABLE CCCD TO BECOME PROTECTED!

Instructions below and also on SK182336:

Run the command: vpn cccd status
The expected output is: vpn: 'cccd' is disabled.

If the output differs, stop the CCCD process by running the vpn cccd disable command.

Updated May 31, 2024

To streamline information flow and simplify actions for our customers and partners, we have consolidated all relevant details about CVE-2024-24919 and its remediation into a single SecureKnowledge article: sk182336.

Please revisit it now, as we have added some updates.

Updated May 30, 2024

To remain protected from CVE-2024-24919, it is mandatory install this on Check Point Quantum and Spark gateways following fix.

In addition, you should take the following extra security measures, which are documented in sk182336:

1. Change the password of the LDAP Account Unit
2. Reset password of local accounts connecting to Remote Access VPN with password-only authentication
3. Prevent Local Accounts from connecting to VPN with Password-Only Authentication
4. Renew the server certificates for the Inbound HTTPS Inspection on the Security Gateway
5. Renew the certificate for the Outbound HTTPS Inspection on the Security Gateway
6. Reset Gaia OS passwords for all local users
7. Regenerate the SSH local user certificate on the Security Gateway (see the SK for more details)
8. Renew the certificate for the SSH Inspection

Update May 28, 2024

Yesterday (May 27th) we delivered a solution that addresses attacks we saw on a small number of customers’ VPN remote access networks.

Today we found the root cause for these attacks and are now releasing a fix. To remain protected, it is mandatory install this on Check Point Quantum and Spark gateways following fix.

The vulnerability we found (CVE-2024-24919) affects Security Gateways with remote access VPN or mobile access blade enabled. It is potentially allowing an attacker to read certain information on Gateways once connected to the internet and enabled with remote access VPN or mobile access.

The fix we developed prevents the use of this vulnerability, once deployed on the relevant Gateways. Install this now to stay protected.

The attempts we’ve seen so far, inline with what we alerted you yesterday, are focusing on remote access on old local accounts with unrecommended password-only authentication within the known small customers we referred to yesterday. Check Point’s network is not affected by this.

More information on today’s notification can be found here.

Customer security is our top priority. We will continue to investigate this issue and provide additional updates.

For additional information, please contact Check Point Support Center or your Check Point representative.

Originally posted on May 27, 2024.

Over the past few months, we have observed increased interest of malicious groups in leveraging remote-access VPN environments as an entry point and attack vector into enterprises.

Attackers are motivated to gain access to organizations over remote-access setups so they can try to discover relevant enterprise assets and users, seeking for vulnerabilities in order to gain persistence on key enterprise assets.

We have recently witnessed compromised VPN solutions, including various cyber security vendors. In light of these events, we have been monitoring attempts to gain unauthorized access to VPNs of Check Point’s customers. 

By May 24, 2024 we identified a small number of login attempts using old VPN local-accounts relying on unrecommended password-only authentication method.

We have assembled special teams of Incident Response, Research, Technical Services and Products professionals which thoroughly explored those and any other potential related attempts. Relying on these customers notifications and Check Point’s analysis, the teams found within 24 hours a few potential customers which were subject to similar attempts.

Password-only authentication is considered an unfavourable method to ensure the highest levels of security, and we recommend not to rely on this when logging-in to network infrastructure.

Check Point has released a solution, as a preventative measure to address these unauthorised remote access attempts.

We encourage our customers to enhance their VPN security posture by:

• Check if you have local accounts, if they were used and by whom.
• If you don’t use them – best to disable them.
• If you have local accounts which you want to use and are password-only authenticated, add another layer of authentication (like certificates) to increase your environments IT security.
• As said, If you are a Check Point customer, deploy our solution on your Security Gateways. This will automatically prevent unauthorized access to your VPNs by local accounts with password-only authentication method.

Learn more and receive practical guidance for configuration monitoring and practices to enhance your VPN security posture.

For any additional assistance required, please contact Check Point technical support Center or your local Check Point representative.

We value the collaboration of our customers and dedication of our teams to reach a solution which effectively addresses any such attempts.

[_Val_]

Most probably not, it sounds like a file system issue.

[jgar]

@Tomer_Noy

Is it possible that the script doesn't work on FULL-HA clusters?

Tried it at 2 customers with such deployment type, and at both the cluster is reported as vulnerable, despite having the relevant hotfixes installed.
The script checks the cluster members individually,  and result is the following for each of them:

ALERT: The script identified vulnerable or potentially vulnerable gateways. Review sk182336 and details below for recommended actions.
Number of gateway(s) that are potentially vulnerable and need to be checked manually for hotfix installation: 1
- clustername

[PhoneBoy]

This is expected behavior and noted as such in the SK:

[Ilovecheckpoint]

I have just run the latest script:

https://support.checkpoint.com/results/download/133115

I installed the hotfix on all my gateway on different domains.

I was expecting they are seen as not vulnerable.

The ones with remote access disable are seen not vulnerable, and unexpectly all others yes, except one which has exactly the same hotfix installed.

This one is seen with no problem:

** Hotfixes **
** ************************************************************************* **
Display name Status
R81.20 Take 26 Hotfix for CVE-2024-24919 Installed
R81.20 Take 41 Hotfix for CVE-2024-24919 Installed as part of
R81.20 Take 53 Hotfix for CVE-2024-24919 Available for Download
R81.20 Take 54 Hotfix for CVE-2024-24919 Available for Download
R81.20 Jumbo Hotfix Accumulator Recommended Jumbo Recommended Jumbo Take 26 Installed
R81.20 Jumbo Hotfix Accumulator Take 65 Available for Download
R81.20 Take 53 Security hardening for Remote Access VPN users Available for Download
** ************************************************************************* **
** Blink Images **
** ************************************************************************* **
Display name Status
<b>R81.20 Security Gateway + JHF T26 for Appliances and Open Servers</b> Installed
<b>R81.20 Security Gateway + JHF T65 for Appliances and Open Servers</b> Available for Download

This one is seen as "potentially vulnerable and need to be checked manually for hotfix installation"

Display name Status
R81.20 Take 26 Hotfix for CVE-2024-24919 Installed
R81.20 Take 41 Hotfix for CVE-2024-24919 Installed as part of
R81.20 Take 53 Hotfix for CVE-2024-24919 Available for Download
R81.20 Take 54 Hotfix for CVE-2024-24919 Available for Download
R81.20 Jumbo Hotfix Accumulator Recommended Jumbo Recommended Jumbo Take 26 Installed
R81.20 Jumbo Hotfix Accumulator Take 65 Available for Download
R81.20 Take 53 Security hardening for Remote Access VPN users Available for Download
** ************************************************************************* **
** Blink Images **
** ************************************************************************* **
Display name Status
<b>R81.20 Security Gateway + JHF T26 for Appliances and Open Servers</b> Installed
<b>R81.20 Security Gateway + JHF T65 for Appliances and Open Servers</b> Available for Download

On all firewall local users have been deleted months ago, only ldap users are configured and mandatory machine certificate set.

Could somebody tell me if I need to be worried?

I'm not willing on interesting latest jumbo hotfix, which could have side effects. 

[the_rock]

What versions? Can you send output of random gateway with installed hotfix?

cpinfo -y all

Andy

[Ilovecheckpoint]

Hello, from the output is seen R81.20 jumbo take 26 + R81.20 Take 26 Hotfix for CVE-2024-24919.

[the_rock]

But thats not the output I was looking for. Can you send full output of cpinfo -y all from expert mode?

Andy

[Ilovecheckpoint]

Hello, 

On attachment cpinfo -y all.

I compared the one which is declared as potentially vurnerable with the one not vulnerable and the output is the same, and they both provide remote access using ldap users and no local users configured.

[the_rock]

Hm, thats odd. Can you check output of below command on the two fws?

vpn cccd status

Andy

[Ilovecheckpoint]

vpn cccd status
vpn: 'cccd' is disabled.

Checked on both cluster members.

I have run the script also for one domain only, same results.

[the_rock]

K, just an idea...can you transfer the .sh script locally on both fws, then run ./scriptnamefile and see what it shows

Andy

[PhoneBoy]

What hardware is used in both cases?
Possible this is a bug in the script we need to investigate.
I would open a TAC case so we can capture the relevant data and address: https://help.checkpoint.com 

[Ilovecheckpoint]

Hello, The management is Openserver, so a VM.

The gateways are mostly model 3600.

[the_rock]

As Phoneboy said, maybe bug in the script, as its weird as you said if you did say 2 indentical ones that they show different results.

Andy

[Ilovecheckpoint]

Hello, 

I executed the following command on management server to all gatways, as seen on one of the post, and no sensitive information found.

This is the output for all gateways:

[Expert@MDM:0]# curl_cli --silent --http1.1 --insecure --data 'aCSHELL/../../../../../../../etc/hosts' https://10.x.x.1/clients/MyCRL
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE> 404 File Not Found </TITLE>
</HEAD>

<BODY>

The URL you requested could not be found on this server.

</BODY>
</HTML>

[the_rock]

Maybe I explained it wrong...what I meant is below. See example from my mgmt lab.

Andy

[Expert@CP-management:0]# cd /var/log/scripts/
[Expert@CP-management:0]# ls
check-for-CVE-2024-24919.sh uptime.sh
[Expert@CP-management:0]# ./check-for-CVE-2024-24919.sh
All gateways are not vulnerable to CVE-2024-24919. No further action required.
[Expert@CP-management:0]#

[Ilovecheckpoint]

I executed the script directly from the management you showed and I got the same results.

To resume, executing this cript it shows my gateways are potentially vulnerable.

I installed the hotfix based on my installed jumbo hotfix.

Executing curl, I do not get sensitive information.

Can I declare my firewalls protected or something else I can do?

[the_rock]

Ok...here are my 2 cents, but if I were you, I would get an official CP answer to it.

IF it says gateways are vulnerable, then they are vulnerable. I am literally "forcing" everyone to install take 150 if on R81.10 and take 65 if on R81.20 and so far, that always shows gateways NOT vulnerable.

So if I were you, thats what I would do...just saying.

Best,

Andy

[Tomer_Noy]

The most important step to be protected is to install the relevant hotfix or jumbo with the CVE fix.
If you know that you installed the fix on your gateways, you don't need to use the script as an affirmation that you are protected.

The CVE script was created to help customers understand which gateways require the fix. The first version just tested the configuration to see if a fix is needed, and in later versions of the script we added code to remotely check the gateway if the relevant hf/jhf was installed. It's helpful for large customers with many gateways, to make sure that they didn't miss a gateway.

The script has just 3 optional outputs for each gateway. The logic is simple and just automates things that you can check manually.

1) The script says your gateway is vulnerable - this means that the gateway is using MAB or participates in Remote Access community, and the needed hotfix is not installed. For this you need to take immediate action and install the hf/jhf.

2) The script says your gateway is potentially vulnerable - this means that it's using MAB or participates in Remote Access community, so the fix is needed. However, the script was unable to verify if the hf/jhf is indeed installed. This could be due to some limitations documented in the SK (Spark, VS, ...) or it could be that there was some communication error to the gateway. The required action item is to verify manually that the fix is installed. If you did that, then you don't need to install anything else. It's OK if the gateway remains "potentially vulnerable" in the script output, because you verified the hf and the potential is gone.

3) Not vulnerable - we don't print out these gateways, so if they are not in the script output, they were not vulnerable when the script ran. It could either be that they don't use MAB or Remote Access, or that the script successfully validated that the hf/jhf is installed.

In your case, it seems that the script is saying that the gateway is potentially vulnerable (case #2). You wrote that you installed the needed hf, so it's OK and you don't need to keep running the script or install another hf / jhf.

I hope this helps.

[the_rock]

I suppose about point 2, even my lab gateway has MAB on and is part of RA community, but possible does not show vulerable cause I installed latest jumbo?

Andy

[the_rock]

@Ilovecheckpoint 

Here is my reason why you should upgrade to latest jumbo, if its either R81.10 or R81.20. I have MAB on, also gateway is part of RA community and it shows NOT vulnerable.

I rest my case 🙂

Andy

 

  

[the_rock]

I will say, just for the context, I have eve ng labs and I updated all my gateways to jumbo 65 R81.20 and it shows valid when I run a script.

Andy

 

[HeikoAnkenbrand]

Hi Guys,

I have created three small emergency oneliners in the last few days. With which the following can be done:
1) Set all users to ‘undefined’. This means no more access via username and PW is possible.
2) Set all users to a new default password
3) Set all users to a randome password. List with set passwords is displayed and can be forwarded to the corresponding users.

This allows you to change many user passwords in a short time.

Link: ONLINER - Password Bulk Operation (CVE-2024-24919)

PS: These are not my real passwords 😉

[Duane_Toler]

I also posted a Git repo of Ansible modules to do this.  I adapted an existing Check Point management API module to do it.  Grab these two, add them to your Ansible location where you installed the Check Point mgmt collection.  Sample tasks included:

https://community.checkpoint.com/t5/Automation-and-APIs/Ansible-modules-for-cp-mgmt-user-and-cp-mgmt...

[the_rock]

Nice @Duane_Toler 👍

[jberg712]

I noticed some unusual activity from an IP address attempting different 'attacks' that may be related to the CVE-2024-24919 vulnerability, but I'm uncertain and wanted to see if anyone else has seen this.  

The IP address is 74.115.3.194.  I see numerous attempts at attacks that are just named:  command injection, dir traversal, http methods, sql injection (see screenshot below).

The attacks show what they were attempting.  The only thing is that while these were prevented, it doesn't list the 'Attack Protection Information' to specifically name that it's the 'Check Point VPN CVE-2024-24919' Protection that it's activating.  Could this be apart the same attack/exploit?  Is anyone else seeing this?

Directory Traversal AttackList of Attacks

[jberg712]

Has anyone else seen this?

I've noticed that yesterday, earlier in the morning, some unusual activity that may be related to this vulnerability.  At one point, one of my daily reports indicated a large increase of protections triggered.  When I looked deeper, this attacker attempted multiple attacks.  The logs, however, only indicate certain attacks like:  "dir traversal" or "sql injection".  The log does not indicate the Attack Information field with the Check Point VPN vulnerability being triggered.  Has anyone else seen this type of behavior?  And can this be resident of an attack on the premise of this vulnerability?  

Dir Traversal AttackLog of consecutive attacks

[Daniel_Hainich]

within the sk182336 you provide a list of ip addresses used by thread actors. is it possible to provide them as updateable objects?

[Tom_Kendrick]

@Daniel_Hainich 

I've written a set of mgmt CLI commands to add the current list (based on CVE_<something>, then adding these hosts, networks and a group, so it allowed me to see the any evidence of the recorded IP's. 

I shared to contacts in HQ, and we are in discussion about an updatable list as we speak. If it goes ahead, I'll let you know!

Tom

[Christoph]

Hello,

I need to update a customer to the latest fixed version. Right now the hardening hotfix is installed on an R81.20 T53. There is a large number of local vpn users present with passwords prior to R80.20. The mobile access blade was not enabled.

Reading the JHFA65 notes it states:

"UPDATE: Remote Access VPN for local accounts authenticated only with Check Point password created in R80.20 or lower, and not updated after the upgrade to R80.30, is blocked until the password is reset. Refer to sk182336."

The latest hotfix only states it would disable local accounts that can be reactivated with the blockSFAInternalUsers.

My question are

1. does the hotfix also disable the "R80.20 users" until their passwords are reset in addition to the normal blocking, or is it only blocking which can be turned on again?

2. Can the behaviour of the JHFA be turned off?

While I see the security side of it, there is a need of a few days to organize the password change by the customer.