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.

[Moti]

Hi,

be advised that the SK https://support.checkpoint.com/results/sk/sk182336 was updated with the below info: 

Important extra measures (detailed step-by-step in the SK )

1. Change the password of the LDAP Account Unit
2. Reset password of local accounts connecting to VPN with password authentication
3. Prevent Local Accounts from connecting to VPN with Password Authentication
4. Renew Security Gateway's Outbound SSL Inspection CA certificate
5. Renew Security Gateway's Inbound SSL Inspection server certificates
6. Reset all Gaia OS admin, local users and Expert mode passwords

[Rene_Moeller1]

You're not serious. Why is this information only coming in bits and pieces?

[_Val_]

As said already, we inform the community as the situation develops.

[Srdjan_B]

At this time, the SK does not mention gateway VPN certificates, GAIA portal and/or multi portal certificates. Do these need to be revoked/reissued? It sounds reasonable that their private keys may have been comprised on vulnerable gateways.

Thank you.

[_Val_]

@Srdjan_B no

[YuriiBilyi]

Hi.

This article Check Point - Wrong Check Point (CVE-2024-24919) says that CVE-2024-24919 vulnerability allows to disclose information in etc/shadow file or any other OS file. Can you confirm the findings of the researchers?

[K_R_V]

You can easily test this yourself with postman, works on almost all unpatched firewalls, even the ones without local accounts !

[the_rock]

Yup, 100% true.

[Rene_Moeller1]

That was exactly my assumption, there is more to it than Check Point wants to say. To put it mildly, this is a disaster!

"...We’re a little concerned by the vendor’s statement, though - it seems to downplay the severity of this bug. Since the bug is already being used in the wild, by real attackers, it seems dangerous for the bug to be treated as anything less than a full unauthenticated RCE, with device administrators urged to update as soon as humanely possible. ..."

[BorisL]

Even though this is an extremely important security breach for Checkpoint going back a long time, good practices like 2fa, no access to fw managment from internet, and never repeating passwords would have diminished or eliminated the risks.

[the_rock]

Maybe not eliminated, but made it better, agree.

[Rene_Moeller1]

But the mere possibility of reading the /etc/shadow file at all shows that the problem is much deeper and that Check Point has played down the problem. It's not about the fact that mistakes have been made in the programming, it's about how you deal with the vulnerability and how you communicate it. This is a confidence-building process. In my opinion, there has never been a vulnerability like this at Check Point. Cisco or Forti have often been much worse off.

[jgar]

Something isn't yet totally clear to me at this point:

Could this vulnerability have been exploited, on unpatched systems with RA ipsec or mob enabled, even assuming there weren't any local password-only VPN user accounts?

And that if answer is yes:

the point of insisting so much about eradicating password-only accounts, is the assumption that exfiltration of those could already have occurred, and then the first & easiest vehicle for network penetration would be via VPN login?

[K_R_V]

The first answer is YES. I'm assuming that hashes from these VPN accounts are stored somewhere and can be accessed through this vulnerability. 

[sbutko]

Hello. 

Our firewall is CheckPoint 6600 running R81.10 Take 139. I succesfully installed the Hotfix on SMS and nodes (we have a cluster Active-Passive). When I am trying to run the script 'VPN check.sh' I am getting an error like 'Failed to get participating GWs and user-groups'. I have already edited the string 81 in the script and put just "show-vpn-community-remote-access" in there but result is the same. Could someone help me to resolve the issue? 

[_Val_]

The your you are seeing happens if you enter something in the script argument. On a SMS this field needs to be empty:

 

[ShemHunter]

Hello, help, after installing CVE-2024-24919, this error came out

[ShemHunter]

The problem has been solved updating IPS databases

[Moti · Accepted solution]

FYI a new tool has been added to the SK https://support.checkpoint.com/results/sk/sk182336 to help you with the triage 

3. Tool to identify vulnerable Security Gateways

Use the procedure below to run the script that scans all the Security Gateways configured in your Security Management Server or Domain Management Servers. The script shows a lists of Security Gateways that are vulnerable to CVE-2024-24919 and the recommended action to install the required hotfix.

[Aviv_Abramovich]

thanks

[ShemHunter]

Hi, Moti
, take a look at my mistake above, what's wrong with me?

[Rene_Moeller1]

Hi Moti, hi all,

it seems to be more and more proven that this vulnerability is suitable for reading all files of the OS system, then we should all look in our logs for the sources of the IP list that Check Point has provided, which have as target the firewall(s) and are / were allowed with https as service (according to Implied Rule).
If some logs are visible, it is very likely that some files and above all information have been extracted. As described in the SK, you should not only check from these IP addresses whether someone has dialled in with the local user via remote access.
I feel like I'm back in the days of Heartbleed.

If the list of SK 182336 becomes even longer (currently there are 9 points), then I might as well reinstall the firewall.
Please also bear in mind that the complete set of rules also exists in text form on the gateways.

[Lesley]

I share the same concern. I have a setup with MFA VPN accounts. But still i saw MANY log entries from the IP ranges mentioned in the SK. I will patch this firewall and reset the LDAP account password and GAIA password. But the log entries are of course before the patch install. Since I have no idea what harm has been done, would it not better to clean install it? Maybe the attacker left something on the system itself and now it has been compromised. 

[John_Tammaro1]

It looks so far to be a read only vulnerability - hence info disclosure. Not seeing any evidence so far it is write access. It would be level 10 critical flaw at that point? Hopefully nothing develops as security researchers prod harder to investigate alternative methods.

[Rene_Moeller1]

Read Only is sufficient.
look, the complete rulebase with all VPN information is visible in another location, which you don't know.
I also see access from several IP addresses from this list to our gateway, until yesterday.

[Mo_Patel]

Here is a video that demonstrates how to use this tool and identify if your security gateways are vulnerable. 

[CaseyB]

@Mo_Patel - I ran the script and it says my gateways are still vulnerable even though the hotfix shows installed on both gateways in our cluster.

[Rene_Moeller1]

Mee Too:
Domain: xxxxxxx
=================
ALERT: Number of vulnerable Remote Access gateway(s) identified: 1
Recommendation: Install Hotfix to mitigate CVE-2024-24919 according to sk182336.
- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
cpinfo -y all (snipped):

[CVPN]
        HOTFIX_ESOD_CSHELL_AUTOUPDATE
        HOTFIX_R81_10_JUMBO_HF_MAIN     Take:  110
[CPUpdates]
        BUNDLE_R81_10_JHF_T110_BLOCK_PORTAL__MAIN       Take:  3

[PhoneBoy]

This test script is currently a pre-patch check, not a post-patch check.
I've relayed this feedback to the relevant teams.

[CaseyB]

Thank you for confirming.