Analysing CVE-2024-24919 and its possible impact on a vulnerable system

Check Point SSL VPN: CVE-2024-24919 from an Incident Response Perspective

The recently discovered vulnerability in Check Point firewalls (gateways), tracked as CVE-2024-24919 is an information disclosure vulnerability with CVSS score 8.6 (High). The Truesec CSIRT team has analysed it from an incident response perspective to better understand the impact of an attack leveraging this vulnerability.

Summary

  • The vulnerability allows for an attacker to access (read/download) all files on a vulnerable Check Point Security Gateway (a.k.a. a gate)
  • The Mobile Access blade needs to be enabled or IPsec VPN blade enabled with the gateway in the Remote Access VPN Community.
  • Password hashes disclosed can be cracked with tools such as “hashcat”.
  • Local accounts, which may be used for VPN access, have a maximum password length of 8 characters.
  • It has not been discovered how to forensically, with some degree of certainty, determine if the sensitive files on a system have been compromised.
  • Tracking threat actor activities is possible only if they have accessed the environment, i.e., logged in to the VPN service or the gateway.
  • All vulnerable devices should be considered as compromised and handled accordingly.
  • All passwords configured or stored on the devices should be rotated (if possible, usernames should be changed too).
  • Usage of local accounts should be avoided/disabled.
  • Security Gateways should be upgraded even if the Mobile Access blade is not enabled/used.
  • Reference the Check Point advisory for information about fixed software

The vulnerability

CVE-2024-24919 is a path traversal bug allowing a remote attacker to access all files on the Gaia OS (i.e., expert mode) of an affected Check Point device. The bug is enabled when the Mobile Access blade is active[1]. See the figure below.

Figure 1 – “Mobile Access” blade enabled on a Check Point Security Gateway

The reversal of the patch by watchTowr Labs[2] showed that the shadow file can be extracted. This means that the exploit runs with root privileges and allows for an unauthenticated remote attacker to traverse the GAIA OS file system and access all the files on it[3]. This includes files and databases containing user information such as locally stored usernames and encrypted passwords (including the expert password and AD integration account/password), system backups, the ruleset, certificates etc. The tests in the lab thus far have shown that it is not possible to make changes to any files on the system or run commands on the system by exploiting this vulnerability.   

To better understand the impact of this vulnerability, what the possibilities are to detect if a device has been compromised, and what relevant mitigative actions IT admins should take, the Truesec CSIRT team tested the exploit and analyzed the findings as if it was a real cyber security incident[4].

For clarity, the analysis segments the potential attack into three distinct phases.:

  1. Exploitation phase (Initial Access): When the attacker exploits the devices and access sensitive information.
  2. Network access phase (Entry Point): When the attacker leverages the sensitive information disclosed in the previous step to gain access to the environment.
  3. Lateral movement and privilege escalation phase: When the attacker use their foothold to further compromise the environment.

These phases should not be confused with known attack frameworks such as Mitre ATT&CK or Lockheed Martin Kill Chain.

Exploitation Phase (Initial Access)

Given how easy it is to use and automate the exploit, it is very likely that an attacker will use it to find vulnerable systems (i.e., run the exploit in reconnaissance). An attacker could read an arbitrary target file (e.g., the “/etc/shadow” file or the “fwauth.NDB” file) across different systems and compile a list of vulnerable devices to revisit at a later stage.

The attacker could also take the approach to access multiple vital files on each system in their first interaction with their target. This way the malicious actor would gain access to multiple sets of sensitive information through their first interaction with the target. Being able to detect initial access is therefore important. By repeatedly executing the exploit in the lab environment and reading various system files, multiple analyses were conducted to determine whether exploiting CVE-2024-24919 would leave any detectable traces on the device. This analysis, if successful, would potentially reveal if a system has been exploited or not.  

Detection: Initial Compromise (Exploitation of CVE-2024-24919)

The Check Point Security Gateway keeps several logs in the “/var/log” folder. Three of these logs are related to the web server running on the device, namely “httpd_access_log”, “httpd2_access_log” and, “httpd2_error_log”. Our tests and analysis showed that the web requests generated when the exploit was executed were not logged in the “httpd” logs.

It should be noted that even a broad search across all log files did not show any traces of the exploitation.

As the traffic related to the VPN SSL service is permitted by the “Implied Rules”[5] , the “Log Implied Rules” setting was enabled, to examine if those logs were more revealing. Even though the traffic related to the exploitation of the device is in fact logged, the malicious traffic cannot be distinguished from other type of traffic. This is probably because the exploit runs over HTTPS and the firewall does not seem to inspect traffic destined to itself.  

Figure 2 – Extract of Implicit Rules logs, the entries highlighted with an orange box are known “malicious” connections.

The figure above shows logged hits on the “Implied Rules”. The IP address highlighted in the orange box show the connection logged when the exploit was successfully executed. The other IP addresses in the log output are generic Internet noise (scans etc.) traffic. As shown by the figure, it is not possible to distinguish between them.    

To further analyze potential traces of exploitation, changes of disk were examined. Furthermore, memory analysis were made both during and after exploitation of the vulnerability. No forensic artifacts were discovered that would reveal that the vulnerable Security Gateway had been exploited and information had been extracted from it.

This means that an attacker would be able to compromise a vulnerable Check Point Security Gateway without leaving substantial traces. For this reason, it is not possible to determine if a device has been compromised or not. A vulnerable device (a device with Mobile Access enabled) should therefore be considered compromised and efforts should be put in place to mitigate further compromise.

Cracking the Password

If local accounts (the so called “Legacy User Accounts”) are configured, they will be stored in “/var/opt/CPsuite-{Version} /fw1/database/fwauth.NDB” using DEScrypt. The legacy accounts come with a limitation of maximum eight characters long passwords.    

Figure 3 – Password limitation for Legacy User Accounts

This means that Local Account passwords can easily be cracked with a good dictionary and some rules. See the figure below.

Figure 4 – Cracking the password hash “rCGqljHCMOE/A” using hashcat.

If a “LDAP Account Unit” has been used as the Active Directory integration account, it will be stored locally on the Security Gateway. That account password hash can potentially be cracked and later used in the lateral movement activities.

Network Access Phase (Entry Point)

When an attacker has got access to valid credentials as described above, the next step is to enter the environment. The attacker will try to use the valid credentials on any publicly facing services related to the organization that is being attacked.

Login to VPN

As shown above, the local accounts can be obtained by exfiltrating the fwauth.NDB file and the passwords cracked using “hashcat”. After this step, an attacker will in most cases use the accounts obtained in every other phase of their attack. For instance, if the local accounts obtained are configured/permitted to log on to the SSL VPN Service, the attacker would be able to enter the environment using them.

These activities will however be logged. To detect if any suspicious sign-ins have occurred, the logs related to the Mobile Access blade can be analyzed (using the “SmartConsole” or the “SmartView”). See Figure 5.

Figure 5 – Extract of Mobile Access logs showing both legitimate (green box) and malicious (red box) logins.

While investigating the “Mobile Access” logs, source IP addresses of the connections related to the different usernames can be analyzed to find anomalies in terms of country of origin, logon time etc. In the figure Five above, the green box shows legitimate login sourcing from a Swedish IP address, and the red box shows malicious logins sourcing from an IP address geolocated to USA. Furthermore, it can be observed that the malicious IP address also tried to log in with the username “admin”.   

If malicious logins are identified, searching for all activities related to malicious IP addresses will give more insight into the time frame of the attack. In Figure 6 it is seen that the malicious IP address identified in the VPN logs started the activities around 20 minutes earlier, in what can be assumed as the exploitation of the device[6].

Figure 6 – Malicious traffic logged by the “Implied Rules”.

Accessing the Check Point Security Gateway

An attacker may gain access to the gateway itself by exfiltrating, the “/etc/shadow” file and cracking the passwords hashes in it. Even though many organizations restrict management access to the Gateways, this is a possible entry point, as it only requires an administrative mistake that exposes the management interfaces (SSH or HTTPS) of the device. As mentioned above, the expert password hash can also be extracted and cracked, which in such case will give an attacker root privileges on the Security Gateway.  It should be noted that the success of the password cracking is heavily dependent on the complexity of the passwords, and the time and resources an aggressor is willing to put in.

Analyzing either the “/var/log/audit/audit.log” or the “/var/log/secure” logs will help detect suspicious sign-ins to the security gateway. Using the latter is easier to read and it will provide timestamps related to the events. See figure 7.

Figure 7 – the “/var/log/secure” logs showing malicious SSH logons.

Lateral Movement and Privilege Escalation Phase

When the attacker has been able to successfully logon to the SSL VPN Solution, the next step is to probe the environment and find internal resources to compromise. These attempts are logged by the Check Point firewall blade, but only when logging has been enabled for the matching rule.  

Figure 8 – Probing attempts made by a malicious actor while connected to the SSL VPN Solution.

When the attacker manages to find internal resources, such as file shares, Active Directory servers etc, the accounts obtained in the previous steps can be used to move laterally in the environment.

Mitigation Steps

Our analysis has shown that it is not possible to determine whether a device has been exploited or not. Furthermore, the exploitation process can be easily automated. Check Point has also traced the exploitation of the CVE to early April 2024. With these known facts in mind, it is sound to consider a vulnerable device as fully compromised and every affected organization should take the correct steps to mitigate against potential cyber-attacks.

  1. Initiate a thorough investigation if you find signs of further compromise (i.e., malicious VPN logins).
  2. Ensure that all Check Point Security Gateways are upgraded with the latest hotfix to patch this vulnerability.
  3. Upgrade your device even if the Mobile Access blade is not enabled. This approach will protect the device if the blade is to be enabled in the future.  
  4. If possible, disable local accounts and use centralized authentication mechanisms such as LDAP.
  5. Do not allow Local Accounts to use the SSL VPN solution.
  6. Rotate all passwords configured or stored on the devices, especially AD integration accounts. If possible, change usernames as well.
  7. Make sure that all rules have logging enabled.
  8. Enable “Log Implied Rules” setting to capture traffic that could be associated with exploitation attempts.
  9. Continuously monitor logs for suspicious activities, particularly focusing on VPN and SSH access logs.
  10. Consider implementing additional security controls such as multi-factor authentication (MFA) in combination with VPN access.
  11. Consider restricting VPN users from management (RDP, SSH etc.) access to internal servers.
  12. Implement around the clock, active security monitoring of endpoints. Pay special attention to servers as it will increase the possibilities to detect and prevent intrusion before it is to late.    
  13. Do not allow Local Accounts to use the SSL VPN solution.

By following these steps, organizations can mitigate the risk posed by CVE-2024-24919 and better protect their Check Point Security Gateways and their internal environment from potential exploitation.

[1] According to the Check Point advisory, this vulnerability is also enabled when using IPsec VPN in a Remote Access VPN community, this scenario has not been tested by Truesec.

[2] https://labs.watchtowr.com/check-point-wrong-check-point-cve-2024-24919/

[3] It is not possible to list files when this exploit is used, it is therefore required for an attacker to know the exact path and name of any file accessed.

[4] The tests and analysis were conducted on a R80.10 installation, which is not supported. The results are however assessed to apply to even supported versions.

[5] Implied Rules are system defined default rules that apply to traffic not covered by implicit rules, many times system related traffic.

[6] It is not always the case that IP address used for the exploitation is also used to logon to the SSL VPN solution.

 

Cybersecurity