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.

[EngineerActo]

After patching, reading as much information as was published the last weeks and finding evidence in our logging that also our gateway (and not any of our many other IP adressess !) was visited by some of the published 'Bad actor IP adresses' with white-red-blue country flag icons...

In several topics 'we', the CheckPoint customers, asked voor measures to easily GEO fence our VPN/Access rules for example. There were no clear answers or instructions how to convert the Implied Rules to explicit rules that really worked. This left us (me) a bit unsettled about how to improve our Gateway securiy after enabling the Mobile Access blade, which openend a new attack surface to the whole world to try and crack.
So as per sk105740 we changed the access from 'Through all interfaces' to 'According to the Firewall policy', just to see that the logging showed that all https access to the outside interface of the gateway from anywhere was STIL ALLOWED Implied Rule 0, except for the traffic that hit our own Firewall rule, which was allowed by the corresponding Access Rule Number.

Now we've seen that any good product/solution may contain flaws and besides the very good support by CheckPoint on patching and changing stuff like passwords and certificates, it seems to me that it's about time to have more control over the Implied Rules. For example Single click to convert them to Explicit Rules that can be edited and then be able to replace 'Any'one to use HTTPS to the Gateway, with for example Updatable Objects like GEO objects. Or just showing them in the Policy manager with just a strong warning when someone starts to edit the Implied Rule. Or any better solution to get what is general best practise:
Only allow access from the sources and access to the destinations that the business needs, without surprising bonus rules that are hard or impossible to change.

If we / I would have had better understanding on how to limit the access to our VPN/Acces blade, we would had it limited to just a few countries and the attackers would not have been able to exploit the vulnerabity from the IP addresses that they used in this attack.

Of course, if there already is a working solution that limits access to HTTPS on the external interface, I would be happy to use it. Please let me know.

[the_rock · Accepted solution]

See if below post I made recently helps.

Andy

https://community.checkpoint.com/t5/Remote-Access-VPN/Geo-VPN-blocking/m-p/214040#M10593

[Tomer_Noy]

@EngineerActo, I understand your frustration and we (in R&D) are doing a deep learning process to see how this access can be managed better, and will then find a way to incorporate improvements into the product.

First, it's important to emphasize that the most important step is to install the HF or JHF that fixes the vulnerability. That is the most effective way to be protected.

Following that, I also understand the motivation in having more control over who can access the gateway's portals (even after patching). I want to share a bit more info and a configuration suggestion that may do what you are looking for.

It will help to understand a bit how implied rules work. Implied rules are meant to simplify configuration and help avoid situations where customers drop basic networking access that is needed for the gateway to function properly. For example, we don't want admins to have to explicitly allow Management access to push policy to the gateway, and we don't want them to get locked out if they accidentally block such access.
Implied rules can be embedded in different places in the policy. “Before drop” means that they are applied before the first drop rule. “Before last” means that they are applied just before the cleanup rule, but if the admin defined conflicting rules, those rules will be applied before those implied rules.

The implied rules that open access to the portals are defined by default as “Before drop”, which means that any explicit blocking (such as geo-fencing) in your policy will not take effect. The reasoning was that many customers define an explicit “stealth rule” for their gateway, blocking any external access to it. Without the implied rule before the policy, many wouldn’t understand why the portals that they activated aren’t working.

We actually encountered this challenge when we released Playblocks. We have a very effective playbook that fully blocks IPs of machines that attempted high-confidence IPS attacks. We saw that our blocking was very effective for access attempts into the network, but the attackers could still access the portals of the gateways. Changing the default of the implied rules could cause unexpected network changes, so we worked with the gateway R&D team to create an opt-in variable that allows customers to move the portals' implied rule to “Before last”. This keeps open access before the cleanup rule, but if those customers have a stealth rule, they need an additional rule to open access to the portals from desired networks.

Bottom line: here is the SK that moves the portals’ implied rules to “Before last”, which will make your explicit drop rules effective. You activate an environment variable on your management and it will apply to all gateways. Note that it was originally released as a hotfix, but after was integrated to Jumbo (JHF) and its been out for a while.
https://support.checkpoint.com/results/sk/sk180808

Once activated, your geo-fencing rules will take effect. Remember to explicitly open access to the portals if you have any block rules (beyond cleanup) that may block legitimate access to the portals.

I also want to relate to @the_rock's suggestion to limit external https access to the portals via https://support.checkpoint.com/results/sk/sk105740. It's not a bad measure, but AFAIK it's not hermetic as it only applies to port 443, while port 80 may still be accessed.

[the_rock]

Super valid comment @Tomer_Noy 👌👍

Andy

[jberg712]

@EngineerActo 

Hi EngineerActo,

We had this issue come up when we noticed a SQL injection attack attempt on our gateways through the MAB portal from a country that we have set to block in our geo protect rules.

In our case all we needed was a command to be set in the kernel.  This would explicitly block countries in the geo protect against accessing the MAB portal.

fw ctl set int fw_ignore_before_drop_rules 1

fw ctl set int -f fw_ignore_before_drop_rules 1  # to set in fwkern.conf to survive reboot.

[Tomer_Noy]

The kernel param fw_ignore_before_drop_rules will indeed force the gateway to ignore those implied rules that open access to the portal, but it might have additional negative effects by ignoring other rules that may be needed for your environment. Also, this setting needs to be applied per gateway.

I would suggest a more precise measure for the issue of the MAB / Remote Access portals access by looking into https://support.checkpoint.com/results/sk/sk180808.

[the_rock]

Thats what TAC guy told me as well for vpn geo blocking, but based on my lab testing, its all good, if you have the right rules in place.

Andy

[Moudar]

I got this log:

this is the first log i see trying port 80!, all the time it was port 264, or 18264

I checked the packet capture and find that it tries to reach to "/../../../../etc/shadow"

only one log under IPS blade CVE-2024-24919!

the problem is that there are some accepted port 80 to a web server we have and those does not have a packet capture!

The patch is installed, the IPS log is Prevent.

Is this only an failed attempt, or a successful one?

[PhoneBoy]

Do you see aCSHELL in the packet capture anywhere?
If not, it's probably a Directory Traversal attack unrelated to the CVE.
TAC can probably confirm this.

[Moudar]

I could find this "aCSHELL/../../../../../../../../etc/shadow" followed by some http accept packet??!!

What is happening here?

That was a log from CVE-2024-24919, how can it be unrelated to CVE-2024-24919

and now trying port 443:

[Moudar]

I quote from sk182336:

"To prevent any attempt to exploit this vulnerability, you must protect the vulnerable Remote Access VPN gateway behind a Security Gateway with both IPS and HTTPS Inspection enabled."

So, if the Mobile Access Blade is enabled on the same gateway with only IPS enabled (and no HTTPS inspection), is the gateway still vulnerable even if the hotfix is installed? If it remains vulnerable, what steps should be taken?

[the_rock]

Pleaseread what @Tomer_Noy wrote this week.

Andy

************************************************

The most important step to be protected is to install the relevant hotfix or jumbo with the CVE fix.
If you know that you installed the fix on your gateways, you don't need to use the script as an affirmation that you are protected.

The CVE script was created to help customers understand which gateways require the fix. The first version just tested the configuration to see if a fix is needed, and in later versions of the script we added code to remotely check the gateway if the relevant hf/jhf was installed. It's helpful for large customers with many gateways, to make sure that they didn't miss a gateway.

The script has just 3 optional outputs for each gateway. The logic is simple and just automates things that you can check manually.

1) The script says your gateway is vulnerable - this means that the gateway is using MAB or participates in Remote Access community, and the needed hotfix is not installed. For this you need to take immediate action and install the hf/jhf.

2) The script says your gateway is potentially vulnerable - this means that it's using MAB or participates in Remote Access community, so the fix is needed. However, the script was unable to verify if the hf/jhf is indeed installed. This could be due to some limitations documented in the SK (Spark, VS, ...) or it could be that there was some communication error to the gateway. The required action item is to verify manually that the fix is installed. If you did that, then you don't need to install anything else. It's OK if the gateway remains "potentially vulnerable" in the script output, because you verified the hf and the potential is gone.

3) Not vulnerable - we don't print out these gateways, so if they are not in the script output, they were not vulnerable when the script ran. It could either be that they don't use MAB or Remote Access, or that the script successfully validated that the hf/jhf is installed.

In your case, it seems that the script is saying that the gateway is potentially vulnerable (case #2). You wrote that you installed the needed hf, so it's OK and you don't need to keep running the script or install another hf / jhf.

I hope this helps.

[Moudar]

That does not answer my question about HTTPS inspection and about IPS being installed on the same gateway?

[the_rock]

He never mentioned any of that.

[the_rock]

@Moudar Look how long it took to install policy in the lab with jumbo 65, 7 seconds...pretty good I say : - )

Andy

 

[Tomer_Noy]

The quote regarding IPS is indeed mentioned in the SK in the "Additional Frequently Asked Questions" in a question about whether there is an IPS protection that can help mitigate attacks using this CVE.

First I want to emphasize: installing the HF or JHF that includes the CVE fix is the most important and main action item that you need to do to be protected. This will make your gateway protected from future exploit attempts using this CVE.

The IPS protection is a possible extra measure to protect gateways that were not patched with the hf/jhf. It is not required if you installed the hf/jhf with the fix. Note that this IPS protection may be triggered by attacked trying to exploit, even when they are not successful.

Also note that the IPS protection is effective when it is applied to traffic going through the gateway, not traffic going to the gateway itself. Therefore it is only relevant if there is another gateway in front of the gateway doing remote access. It was recommended to have https inspection since some of the attacks are using https encrypted traffic, while other attacks may be over http.
It's not a bad idea to have IPS and https inspection on the gateway doing remote access, but turning these on does not provide extra protection for this specific CVE.

So bottom line: install the fix via HF or JHF. If for some reason, you cannot install the fix, you can add extra protections using another gateway and IPS.

** Also note that the fix makes the gateway secure from the moment it was installed. If you suspect that the gateway was exploited before installing the fix, there are additional measures in the SK related to resetting various secrets and passwords.

[the_rock]

@Moudar Here is all I will say. Again, I cant speak for anyone else, but this would be my argument to literally any customer out there asking these questions. Would you rather have headaches and doubts after installing only CVE patch for respected jumbo or would you rather clear any doubts by simply installing jumbo 150 for R81.10 or jumbo 65 for R81.20, which would contain ALL the fixes to begi with and would 100% show gateways are not vulnerable?

I know 2nd option is what I had been doing and so far, 6 customers had done the same and not a single problem.

I cant force anyone to do anything, but I believe logical choice is pretty clear here, at least to me 🙂

Anyway, if you need any clarification/testing, I have jumbo 65 installed in R81.20 lab with ssl inspection, mab, ra community enabled, ips, so we can do remote and perform any testing needed.

Just going to do some biking now, but will be back later, you can message me. You got my gmail as well : - )

Best,

Andy

[PhoneBoy]

We now have recommended JHFs for R81.10 (Take 150) and R81.20 (Take 65) that include the fix for CVE-2024-24919 (including fixing the issue with cccd enabled).
These JHF will also prevent users with local passwords defined in R80.20 and earlier that have not changed their password since upgrading to R80.30+ from logging in.

[the_rock]

Excellent 👍

[Christoph]

Can you clarify if the prevention mechanism for users with local passwords defined in R80.20 and earlier that have not changed their password since upgrading to R80.30+ not allowing them to log in can be disabled with the blockSFAInternalUsers command?

Internal User, Single Factor Auth. Blocking Utility

Usage: blockSFAInternalUsers [flags]

-s show current status
-a allow internal users with password single factor to authenticate
-b block internal users with password single factor from authenticating

Default block

blockSFAInternalUsers -s

blockSFAInternalUsers: Blocked

[PhoneBoy]

Fairly certain this hasn’t changed but will confirm.

[Dale_Lobb]

  On 5/28/2024, as dictated, I downloaded R80.20.60 Build 992002850 for SMB 1500s and applied it to my small remote access cluster.

  Now, today, I see that sk182357 was updated over the weekend with a new build: 992002903 is now listed as required to address CVE-2024-24919, without any mention in the article revision history.  There is no mention of build 992002850 anywhere that I can find.

  So, what gives here?  Was Build 992002850 sufficient to protect my remote access gateway?  Or not?  Why was the build incremented without any mention of the fact?

Best Regards,

Dale Lobb

Praying that all the secrets I've updated in the last two weeks was not for naught.

[PhoneBoy]

From sk179922:

• Effective 30 May 2024: The R82.20.60 images were replaced with Build 992002903 (replacing Build 992002850) to protect against CVE-2024-24919. See sk182357.

[Dale_Lobb]

Exactly.  I already read that.  What does it mean?  Is the first image (Build 992002850) effective at closing the vulnerability, or not?

[the_rock]

To me, at least, reading that logically, appears build 850 is NOT effective for that CVE, but rather new one, but I could be mistaken. Personally, I would call TAC to get an official confirmation, better have it in writting.

Andy

[Dale_Lobb]

Yes, I agree, the statements in the SKs are not very clear. 

I opened a case with TAC.  Their reply concerning R80.20.60 Build 992002850 protecting against CVE-2024-24919:

Yes you are most certainly  protected."

[the_rock]

As long as you have that statement in writting.

But below statement:

• Effective 30 May 2024: The R82.20.60 images were replaced with Build 992002903 (replacing Build 992002850) to protect against CVE-2024-24919. See sk182357.

I know English is not my first language, but honestly, to me, pure logic reading that stement would dictate that ONLY build 992002903 is the one effective against the CVE-2024-24919

But again, if TAC told you otherwise, then I would accept that.

Best,

Andy

[Sergei_Shir · Accepted solution]

We apologize for the confusion.

For each of the firmware versions that are mentioned in the sk182357 - Preventative Hotfix for CVE-2024-24919 - Quantum Spark Gateways, two firmware builds were released very close to each other:

1) A firmware build based on the previous released build for that version - this build only contained the fix to protect against the CVE.

2) A firmware build based on a more advance build - this build contains the fix to protect against this CVE + additional various fixes that accumulated over time.

Note - sk181134 - R81.10.X Resolved Issues and Enhancements will be updated very soon.

Because these two firmware builds were released very close one after another, it was decided to mention only the last released build.

To resolve this confusion, the Revision History in each relevant Home Page SK was updated accordingly.

[the_rock]

Thatnks @Sergei_Shir . Hopefully, that clears any confusion you may have had @Dale_Lobb 

Best,

Andy

[cassiomaciel]

Maybe this is not an appropriate topic to ask about, my apologies in advance.

I'm wondering if anyone else has encountered a side effect due to the autoupdater update (sk182376).

I patched my clusters with hf sk182336 on June 02. I noticed that the autoupdater automatically installed bundle 21 (vpnf) on June 03, and everything worked fine.

In a specific cluster, I have Remote Access for "Endpoint Security VPN" for a few users. They reported that since Wednesday, this isn't working anymore.

I found out the issue is the default configuration of trac_client_1.ttm, which has MEP enabled (client decide). I performed the steps mentioned in sk78180 and fixed it.

My doubt is that everything worked fine until these 2 updates. I would like to know if someone has had the same scenario.

Cassio