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.

[DanielAmlung]

Yeah thats just for the "current" state. Iam interested in "pre hotfix" phase. I want to know if there is an option to find indicators if someone accessed objetcs/files on the gateway that should not be accessed

[Alex-]

They're just not listed in the actions to take in the SK which is why I ask.

In some implementations, changing all PSK will require a decent amount of work and coordination, but out of precaution we might need to do it anyway.

[PhoneBoy]

I'm confirming internally, but I agree: it's probably best to change those PSKs.

[DanielAmlung]

So assume everything you had on your gateway was readable. Including Logs, Backups etc. etc. - Is there any chance to verify via audit logs that content has been accessed? Iam looking specifically for the option to find out if someone got a "copy" of the local ruleset. And also - how strong are the local rulesets protected?

[Danny]

I second this question.
I checked $CVPNDIR/log and even searched the entire Gaia filesystem on an affected VPN gateway to verify which files have been accessed via the MyCRL weakness. I wasn't able to find a solution yet.

[Ob1lan]

Hi,

Following the notification we received around CVE-2024-24919, I've installed the following package:

(R81.10 Take 139 Security hardening for Remote Access VPN users)

I tried the other R81.10 Take XXX Hotfix for CVE-2024-24919, but it says it's not compatible with our device:

We have Check Point 15400 appliances.

While R81.10 Take 139 Security hardening for Remote Access VPN users has been installed, we received reports we are still vulnerable. 

When issuing the following command from anywhere, unauthenticated, we get sensitive informations back:

curl --silent --http1.1 --insecure \
--data 'aCSHELL/../../../../../../../etc/hosts' \
https://vpn.domain.com/clients/MyCRL

What shall we do to mitigate this entirely?

Thanks ! 

[_Val_]

The fix you installed does not close the vulnerability, it only disables password-only VPN accounts.

Please follow  SK182336 and apply a different hotfix for the vulnerability itself. I am also merging this post with the main discussion

[DanielAmlung]

Hi _Val_ - any update on my question?

[Fabz]

Hi,

Latest update on the SK, there are 2 similar hotfix but with different function that make me confused..

1. Install Jumbo Hotfix Accumulator to fix CVE-2024-24919
   This is the new one, and the only information provided is "problem was fix." What does this mean? What differentiates the second hotfix?
2. Security Gateway Hotfix to prevent exploit of CVE-2024-24919
   the second hotfix is to prevent the CVE, this is clear for me.

Can anyone explain to me the reason why when we installed the CVE hotfix, we also need to install the first one? Or alternatively if I completed the first hotfix and the problem has been resolved, can I use my local username and password without applying the CVE hotfix? Thanks!

[_Val_]

The first one is to close the vulnerability. The second one is to disable password-only local VPN accounts, which are the greatest concern if your systems are already exploited. If you do not have any local VPN users defined, or they are already using MFA, you may skip one. Just make sure you validate the situation with a script from the SK, before taking a decision.

[Fabz]

Hi Val,

Thank you for prompt response.

I used to think the same way you did. But with the new "Jumbo Hotfix Accumulator to fix CVE-2024-24919", im still don't understand about this one:

Because like you mention before, to prevent the CVE hotfix we can use this one below as per part "Security Gateway Hotfix to prevent exploit of CVE-2024-24919" 

For preventing local password, we should use hotfix that part of "Prevent Local Accounts from connecting to VPN with Password-Only Authentication" in the "Important extra measures" section:

Right now, there are 3different hotfixes. Last two hotfix options I mentioned above have been available since last week, but the first is new.

Please correct me if I have the wrong understanding about this CVE.

Thank you

[Moudar]

So, what kind of MFA solution that we can use along with password-only Mobile access?

[PhoneBoy]

For Quantum Spark appliances that are locally managed, you can use SMS/Email or Google Authenticator.
For regular Quantum appliances, you can use Email or SMS as a second factor, but you must use an external SMS provider.
In all cases, you can use the MFA provided through an externally configured service (RADIUS, TACACS+, or SAML).

[BorisL]

Hi.
We upgraded a branch office 1550 to build 996001750, then to 996002908.
Changed all passwords.
Our VPN users connect using username/password + 2FA using SMS. We have no Radius nor AD configured.

Everything worked well for about an hour after our users connected. Then, their remote sessions were interrupted and they are not able to re-connect.  The firewall rejects their connection and the VPN site cannot be re-created. Nothing is logged about these attempts.

Restarted the appliance with no success. 
Renewed the internal VPN certificate. No success.

In the "Advanced" section in "VPN Remote Access". I f I try to change any setting i get a pop-up error "Invalid RADIUS group list".
And settings are NOT saved.

Something has been restricted in the patch that is preventing our site from working.

If anybody has similar problems please help.

[BorisL]

Correction. Not 996002908 but 996002945

[BorisL]

Instead of using the internal VPN certificate we have installed one of our own SSL certificates for VPN and problem was solved. Users are connected again. For some reason internal certificate did not transition well to newer versions in 1550.

[the_rock]

I just installed jumbo 65 for R81.20 in the lab, ran script from https://support.checkpoint.com/results/sk/sk182336, still shows me below, though I installed it on cp-gw

Andy

 

[Aviv_Abramovich]

The above is expected. The script we provided for the management only checks for management side configuration that will expose a vulnerable gateway. It doesn't verify the existence of a hotfix or the JHF 65 or later.

[the_rock]

Thanks Aviv, yes, I responded on the other thread for jumbo 65. Sorry again, just trying to catch up on all this after the vacation.

Best,

Andy

[BorisL]

The problem came back. 
In the 1550 with firmware version is R81.10.10 (996002945), SSL for VPN stops working after some time of use.
If I test the FW URL with curl I get SSL_connect: SSL_ERROR_SYSCALL

Then, if I manually change to the internal certificate, it starts working again.
And if I revert back to our own certificate it continues to work until, after some time (have not timed it), it goes into SLL error again.

Any help would be appreciated

[Aviv_Abramovich]

We now have new full version images uploaded to our download center for R81.20 with the security fix as part of the base version.

https://support.checkpoint.com/results/sk/sk173903 

[PhoneBoy]

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. You can confirm this fix has been installed by running the following command as expert to ensure the update Take is 21 or higher

# cpinfo -y all | grep "BUNDLE_GENERAL_AUTOUPDATE"

This is Check Point CPinfo Build 914000231 for GAIA

       BUNDLE_GENERAL_AUTOUPDATE       Take: 21

[PhoneBoy]

We've just created a video on how to reset your LDAP credentials after patching for CVE-2024-24919, which is included below.

Note: When resetting the password, it is critical to ensure you are using a user with the minimum privileges required to read LDAP (i.e. not Domain Admin).

[Tomer_Noy]

Note the latest update to the vulnerability check script. 

It will now iterate over potentially vulnerable gateways and will run commands to check for relevant HF or JHF fix installation.

The updated script will no longer mark patched gateways as vulnerable.
Thank you for the community feedback!

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

[Danny]

Thanks Check Point!

Now we are all waiting for an automated way to check which files were actually accessed externally via the cve vulnerability. Read more.

[DanielAmlung]

I support that request -we need valid information which parts of the filesystem where accessible!

[_Val_]

After checking with R&D, the successful exfiltrations were most probably not logged. It is reasonable to assume that any part of the file system was available for an attacker on a vulnerable device.

Please follow the recommendations in the SK. Also, for an official answer for the matter, please reach out to TAC

[DanielAmlung]

Thank you for the answer. We will check with TAC to get some answers for our customers.

[Alex-]

After installing Take 150 over Take 110 on VSX running R81.10 (CP Appliances), the system rebooted and got stuck at startup wish the "sh4.4#" prompt after initial boot messages. No other hotfix than Take 110. Happened at each reboot.

Restoring R81.10, applying Take 139 and the CVE hotfix worked.

Don't know if related to the Take, just sharing.

[the_rock]

Thanks for sharing that info @Alex- . I had one customer upgrade to take 150 last night, he said all was fine, but this is regular cluster, not VSX though, so sounds like it might be related to VSX only : - (

Best,

Andy