CheckMates Fest 2025!
Join the Biggest Event of the Year!
Share your Cyber Security Insights
On-Stage at CPX 2025
Simplifying Zero Trust Security
with Infinity Identity!
Zero Trust Implementation
Help us with the Short-Term Roadmap
CheckMates Go:
What's New in R82
We now have fixes for CVE-2024-24919 for releases dating back to R77.30 with latest JHF.
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.
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.
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:
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.
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.
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:
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.
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:
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.
Here's a video showing how to run this script on your management to determine if you need to apply patches/mitigations for CVE-2024-24919:
Just patched a dual room Maestro deployment, single MHO and single SGM per room - R81.10.
We patched a single SGM at a time. Until both SGMs had the same CVE patch we had serious network outages across all services, only restored when both SGMs came fully active/active.
Perhaps I missed it, but nothing in the SK to advise of this. Is this expected ? Have we found something new ?
Cheers
JT
Hi John, ping me an email with the TAC SR details, I will ask, but what you have done is exactly the same as I was advised when I asked. As our rack is being used for training, I can check, but only tomorrow, and I have 81.20 throughout.
Tom
Hi TK, it never went to TAC. We battled through and applied logic to the situation and thankfully came out on top.
So to clarify, as soon as the second SGM1 (1original SMO) went down for reboot, services resumed normal function. Upon reboot, joining SGM2 again and taking back over SMO role at no point were there issues.
Only whilst SGM1 and SGM2 had differing vpnd/cvpnd binaries operating.
Thanks
JT
OK, well, you are welcome to ping me an overview of what things were running, how the issue showed itself for you, and I will try to see if I can get nothing similar to happen. I can run breaking point traffic through for example if you tell me what sort of things you are expecting to be disrupted.
TK
Since the vulnerability allows for harvesting information, in SK182336, also indicates resetting the expert mode password. Is that just a precautionary recommendation or does the vulnerability actually allow for the harvesting of the GAIA account and expert mode password/password hash?
I published a git repo with Ansible modules for management API set-user and show-user (cp_mgmt_user and cp_mgmt_user_facts). Git repo and sample playbooks are posted to the CheckMates toolbox as well:
Good luck everyone!
Hello,
Yesterday we installed the hotfix "R81 Take 92 Hotfix for CVE-2024-24919" in a pair of 5400 appliances (HA ClusterXL). Today the active member flooded our nameservers with DNS queries on port 53/TCP until it caused the nameserver service to be intermitent. We have a lot of domain objects on our policy, but it did not happen before and we do not understan why it was over TCP instead of UDP, and why such amount of queries. Could it be related to the hitfix installation?
Regards
Logically, thats what it sounds like. I would open TAC case to be sure.
Andy
If you're looking for help resetting your Gaia OS admin and expert passwords on many gateways, this video from @Joseph_Audet might help. (Note does not work with Quantum Spark appliances)
just thinking about to use this commands.
On a R81.20 machine there is a sha512 in the /etc/shadow think this is the same as in the clish config.
cpopenssl passwd -6 instead of -1can I also use sha512 on older plattforms ?
any documentation on that ?
I also see expert with only md5 but admin with sha512
You can change the password hashing algorithm via clish on gateways starting from R80.10 JHF 167:
EDIT: Remove R80.40 reference since PhoneBoy confirmed R80.10+ more accurately.
You can change your default password hash type to SHA512 as well.
You can use Ansible to generate passwords and set new passwords on your hosts with the Check Point Gaia modules:
- name: "Generate new password"
set_fact:
user_pwd_hash: "{{ lookup('password', inventory_hostname+'.passwd.clish.'+user_item.name+' length=18 chars=ascii_lowercase,ascii_uppercase,digits,=,-,_,+,,') |
password_hash(hashtype='sha512',
salt=lookup('password', '/dev/null length=12 chars=ascii_lowercase,ascii_uppercase,digits'),
rounds=(600000 |random(start=20000))) }}"
vars:
user_item:
name: foobar
- debug:
msg: "{{ user_pwd_hash }}"
- name: Set passwords
check_point.gaia.cp_gaia_user:
name: "{{ user_item.name }}"
password_hash: "{{ user_pwd_hash }}"
no_log: true
This code generates a 12 character salt, randomly generates a SHA round value, generates a random 18-character length password and hashes it. The resulting hash is in the variable "user_pwd_hash". The REAL password is saved in a local file in the playbook directory, prepended with the name of the inventory host of the play, suffixed with ".passwd.clish." and trailing suffix of the username from the supplied dict.
The last task sets the Gaia user password. If you connect with Gaia API using 'admin' user, then you cannot change the 'admin' user password. You have to re-run your play as another Gaia API user in order to set 'admin' user password
The example provides a static "user_item" dict, but you should put this in a looped task list, provide the loop with a list of dicts.
The expert password is set with a different module: check_point.gaia.cp_mgmt_expert_password and provide it only the "password_hash" and value as above.
How about checking logs for last 30d for the mentioned IPs and action: Log In ?
Only a https from that IPs should not matter, right?
HTTPS connections (this is the information disclosure) and then followed with VPN logins from these IPs is the thing to look for, but the HTTPS connection and VPN login might not come from the same IP. Best is to look for VPN logins from any IP using local password and check if these are suspicious like explained in https://support.checkpoint.com/results/sk/sk182336.
Just noticed that the how to search for VPN logins is currently missing for the SK above. Should be back soon.
So if a customer has ONLY user + pw auth (local users OR ldap Users) I have no option to check that.
The SKs only talk about local users....but we should have the same issue if it is possible to have an pw-only auth with ldap users - right?
For local VPN users with LDAP password, the password cannot be disclosed. Basically, no.
But be aware that the LDAP AU user can theoretically be used as VPN user if the VPN Group defined include this user.
If we need to renew inbound HTTPSi certificates, I suppose it means they might have been exposed, which can be wildcards *.mycompany.com containing the full chain?
So it means an organisation needs to renew the entire public cert infrastructure.
You only need to make sure that this cert is revoked and put in the CRL.
That's what I thought, so much for the ease of use of wildcard public certs.
Indeed, if any file in the device could have been harvested, this would include the organization's ssl certificate used for the FW portal as well as the VPN certificate.
Can anyone confirm this?
If true, then we have to undertake a major certificate change on resources using those certificates.
I'd like to know more about this too BorisL.
@PhoneBoy @_Val_ Can someone confirm that this vulnerability if breached exposed the private keys of our certificates? This would definitely be a major under taking if this vulnerability left our certificate private keys exposed.
Can this also be confirmed with Gaia OS passwords as well?
According to our research, upon a successful exploration, attackers can exfiltrate ANY file on the gateway. All secrets (in form of hashes) are exposed this includes AD, Radius, SecureID, BGP, etc.
It is recommended to replace all but the priority highlighted in the SK are the ones that are more easily exploited over the internet:
Thank you for the info Val. @_Val_
Since the one item that invovles a user/password in an object which is the LDAP account unit, what about other objects with passwords/keys such as RADIUS server objects? Could those be affected as well?
As far as I can see, sk182336 does not mention RADIUS. However, if you need to double-check, you are welcome to ask TAC via a support ticket, to get a 100% official answer.
We make the recommendation to change RADIUS/TACACS+ Shared Secrets on SMB devices: https://support.checkpoint.com/results/sk/sk182357
I expect the same should be done for regular gateways as well, but will confirm and get the recommendations added to sk182336 if so.
Before the patch got applied, if I see a HTTPS connection from a suspicious IP but the following search returns nothing (blade:"Mobile Access" AND action:"Log In" AND auth_method:Password). Is that a definitive we're good?
Is there anything else I could check?
Seems you should be fine.
Hello!
I have a cluster 1470/1490 Appliance R77.20. and GAIA R81.20.
I install R81.20 take 53 security hardening for remote access vpn users.
I cant install CVE-2024-24919.
Please Help.
Please open a TAC case for this via https://help.checkpoint.com
We now have fixes for CVE-2024-24919 for releases dating back to R77.30 with latest JHF.
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.
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.
We now have a specific SK related to CVE-2024-24919 for Quantum Spark appliances! : sk182357
In addition to providing links to updat
...Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 9 | |
| 7 | |
| 7 | |
| 6 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY
.png "Wolfgang"){kind=avatar}
