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.

[HeikoAnkenbrand]

I have created an oneliner so that you can test whether your gateway is vulnerable or not.

ONELINER - Check CVE-2024-24919 Vulnerability  

[flachance]

We've installed the hotfix but there is another recommended one available "R81.20 Take 53 Security hardening for Remote Access VPN users". I can't find what this one does?

[Tom_Kendrick]

Hi, the hardening update, is discussed here on the 27th May update: https://support.checkpoint.com/results/sk/sk182337 :

Is there a simple way to ensure that such users are prevented from connecting to my Security Gateway...

Yes, Check Point has released a Preventative measure tool that blocks local accounts from authenticating with a password, delivered in the form of a hotfix to be installed on the Security Gateway.
Upon installation, password-only authentication methods for local accounts will prevent them from logging into Remote Access VPN

[_Val_ · Accepted solution]

Hi @flachance If you deployed the HF marked by the arrow, you should be good. 

One from May 27 is to disable password-only VPN access, and it was released before the CVE was fully analyzed. If you do not have any RAS VPN users with a static password, you don't need it. If you do have those users, you want to move them to MFA. If you cannot, and you suspect some of their credentials can become compromised, you can deploy the HF in question to cut off their access completely.

[Ilovecheckpoint]

Hello,

I have installed the hotfix on all gateways, which have different jumbo hotfix.

I have run the script to check if my devices are vulnerable, and it showed on all domains, gateways are still vulnerable.

This is the ouput from a gateway where Jumbo hotfix 26 is installed on R81.20:

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 Recommended Jumbo Take 53 Available for Download
R81.20 Jumbo Hotfix Accumulator Take 54 Available for Download
R81.20 Take 53 Security hardening for Remote Access VPN users Downloaded
** ************************************************************************* **
** Blink Images **
** ************************************************************************* **
Display name Status
<b>R81.20 Security Gateway + JHF T26 for Appliances and Open Servers</b> Installed

On other gateways where the jumbo hotfix 41 or 53 is installed, I applied the related hotfix.

What is it wrong, the hotfix installation (on this case via central deployment) or the script ?

[Dilian_Chernev]

Hi, 

I have a GW R81.20 with JHF 53 installed and patched, but device is still vulnerable 😞
Checked with simple curl , from outside and inside networks.

 Remove the CVE patch and applied it again, but still vulnerable.

Are there any issue with CVE patch for R81.20?

[Ilovecheckpoint]

Hello, 

How to check if you are still vulnerabile with curl ?

[CaseyB]

The script will not detect that the hotfix is installed and your system is patched, it will only inform you that it needs to be installed.

[PhoneBoy]

From sk182336:

[Lesley]

Could someone please verify if I still require to install the patch in this situation?

Script does not work for this setup sadly 😞 

All users have this authentication form

All users have this form of authentication. There are no users with ''password''. 

Output from the 'legacy option''

This is the output of the button 'settings' in Allow older clients to connect to this gateway. 

[Christian_Sandb]

If remote access is enabled (like in your case) you should always install the fix that removes the information disclosure issue. If you have LDAP AU defined, you should also recycle those credentials.

[PhoneBoy]

If you use VPN/Remote Access, install the patch from sk182336.
This is the case regardless of how the user authenticates or where the password is stored (e.g. in RADIUS).
You should also rotate any relevant LDAP credentials (as noted in sk182336).

[the_rock]

Not sure if this makes sense, but I would say maybe change password to something super strong, should suffice.

Andy

[PhoneBoy]

That's what sk182336 says to do (rotate the LDAP credentials used).

[Lesley]

Thanks for the reply. I still don't fully understand, I have read both SK's again and I can read them in 2 different ways.

If I see this for example:

Analyze the script results.

• If the result is "No Local accounts with Password Authentication method found. No further action required" - no further action is required.
• If the result is "ALERT: the script identified Local Accounts with Password Authentication method. 
  Install Security Gateway Hotfix to prevent from such accounts to log-in, delete accounts or strengthen their authentication method" - proceed to the next step to install Security Gateway Hotfix.
• Install Hotfix to block Local Accounts with Password Authentication
  

  Do this step if the above script results in "ALERT: the script identified Local Accounts with Password Authentication method." message.
  The update is delivered as a Security Gateway Hotfix to enhance the overall security of the product by blocking local accounts that use Check Point password as the only authentication factor.

You would assume if the scripts gives a green light you will not need to install the fix. 

"This Hotfix adds to the Security Gateway  a new command blockSFAInternalUsers that allows to block or grant access to internal users with password-only authentication."

Why would I need a hotfix if I do not have users with password-only auth? Or is this hotfix used to not only solve this but more? 

"The vulnerability potentially allows an attacker to access information on Gateways connected to the Internet"

So it could happen a LDAP account password has been stolen. Even if I have no local users with only static password (so only MFA) and the scripts points out it is all good? 

[the_rock]

I will test this in my lab first, I would not feel comfortable asking anyone yet to install the fix, specially based on a feedback so far.

Best,

Andy

[PhoneBoy]

The vpnpatch script refers to finding locally defined users with a locally defined passwords.
The patch referred to by that script is specific to disabling locally defined users with locally defined passwords.

It does not mitigate the need to patch for CVE-2024-24919, which is separate from, but related to, the above.

[Lesley]

Thank you the the reply.

So to summaries, the patch(hotfix) stated in both SK's will make sure you cannot use locally defined users with password. But also will solve/fix an different issue related to CVE-2024-24919? So even if all my local users are all correctly configured I still need to patch in order to prevent that data get's stolen from the gateway itself? (in the example the LDAP account unit password was listed). 

[PhoneBoy]

The patches are related but different:

• One addresses CVE-2024-24919
• One hardens Remote Access VPN by disabling local users with locally defined passwords and adds the blockSFAInternalUsers command

[Lesley]

Ah I am getting it now!

So 2 patches

1 for vpn:  Remote Access VPN disable local account with only password (NoMFA)

and 1 patch for CVE-2024-24919

If all my users are good (also stated in test script and with MFA) , I would only need the patch for the CVE? 

And CVE-2024-24919 is related the info could be stolen from the gateway (like LDAP account unit details). 

Thanks a lot!

[the_rock]

Thanks for confirming @Lesley 

[ccsjnw]

I'm assuming I only need to install the Hotfix circled in red (dated 28-May-2024), and not the previous Hotfix circled in Blue (dated 27-May-2024):

Please confirm this is correct.

[PhoneBoy]

Yes, the once circled in red.

[TomasFy]

Hi All,

If, when runnung the script, you get the following error message:

"Failed to get participating GWs and user-groups"

a solution may be (at least was for me) to modify line 81 of the 'VPNcheck.sh' (v3) script

From:

command = "show-vpn-community-remote-access details-level full"

To:

command = "show-vpn-community-remote-access"

I.e. remove "details-level full"

This let me run the script showing right results.

I hope this will be helpful for somebody.

Cheers

[Itai_Minuhin]

Hi Tomas, 

My name is Itai, I'm a manager in Check Point R&D.
I will be glad to review the failure (with details-level full), will you kindly share the logs with me so I'll be able to look into it?
I will email you with more details. 

Thank you

Itai

[Ben_Dunkley]

Following install of the hotfix, we're seeing SAML authentication fail, where the callback/post from the IdP gets a 500 response from the gateway/cluster.

So we're rolling the hotfix back for the moment, and will probably chase up with TAC during office hours tomorrow.

Edit: May not be the hotfix that was the cause... merely an unfortunate coincidence with time drifting (due to bogus ntp config) just over 5 mins from the IdP time at the same time as the hotfix was applied (assume I put a 'facepalm' emoji in here, can't find it in the picker)

[Erling_Strand]

Hi,

Just checked with a customer that has 10 SAML RAS gateways running. All running R81.10 T139. No issues.

The 500 error could be due too a cert change in Azure. It is possible the IDP metadata object needs to be updated after the cert has been rotated.

Erling

[Euge]

Hi, it may be a silly question but does 81.10 Take 139 cover CVE-2024-24919 or do we need to use Take 141?

[Gera_Dorfman]

We have hotfixes available on top of both versions Take 139 and Take 141. 

So if you're using Take 139 (which is recommended Jumbo take for R81.10) you need to install the hotfix on top of this version. 

Customers using latest Take 141 version should install hotfix which is available on top of Take 141.

[Christian_Sandb · Accepted solution]

To help you following best practices moving away from local users with passwords, Peter Elmer created a video to demonstrate how to move such users to client certificate authentication instead. This example use P12 cert files on the clients, you can also choose to use CAPI/KeyChain enrollment which is very similar.

Peter is traveling today so I´m posting on his behalf. Please give kudos to him for this and not to me..

Christian