Executive Summary
On 2024-05-26 Check Point published an article12 about the new CVE-2024-24919 classified as a high severity vulnerability that leads to an arbitrary file read and created a preventive hotfix for it.
Subsequently on May 30, watchtower team published a blogpost3 where they carried out the vulnerability analysis making possible the creation of different PoCs of the exploit by the readers without too much effort nor technical knowledge. On May 31, 2024, Check Point stated that the first exploitation attempts using this CVE began on April 7, 2024.
From that point, a lot of activity began to emerge in the cyber community. A massive increase in exploit PoCs was seen and Check Point products have begun to be exploited worldwide.
Vulnerability
Successfully exploiting this vulnerability can allow an attacker to read certain information on Check Point Security Gateways once connected to the internet and enabled with remote Access VPN or Mobile Access Software Blades.
This means that the high severity of this vulnerability does not lie in obtaining direct access when it is exploited, but rather it allows the attacker to access and read arbitrary files.
Impact
A successful exploit of CVE-2024-4956 can have severe consequences for organizations relying on Check Point appliances for protection. An attacker could:
Figure 0: Impacts
Check Point Affected Products
The products affected by the vulnerability are reported in the following table:
| 製品 | Versions |
|---|---|
|
CloudGuard Network, Quantum Maestro, Quantum Scalable Chassis, Quantum Security Gateways, Quantum Spark Appliances. Any Security Gateway and Cluster that has either of the following setups:
|
R77.20 (EOL), R77.30 (EOL), R80.10 (EOL), R80.20 (EOL), R80.20.x, R80.20SP (EOL), R80.30 (EOL), R80.30SP (EOL), R80.40 (EOL), R81, R81.10, R81.10.x, R81.20 |
Check Point released a script to identify vulnerable Security Gateways, it is available at this link:
Crafting the exploit
The vulnerability exploited is a path traversal4 one which permits to read any file within the vulnerable system.
The exploitation technique targets the data inside the following path:
| /clients/MyCRL/ |
|---|
Used for the delivery of the static files in the Check Point Gateway.
Figure 1: Attack diagram
By requesting a file with a
Figure 2: Hardcoded strings in ELF
The vulnerability lies in mainly two factors:
- String comparison,
- Folder path inside string table.
String Comparison
The implementation of the requirement that the file must be one of the internal strings results in a bug. Instead of making a comparison, the strstr function is used, which, in C language, checks whether one string is inside another. This, which could be understood as a comparison, can also rise errors and vulnerabilities, as in this case.
strstr function example:
|
char s1 = “random_dir/”; char s2 = “random_dir/Iamthebadguy/file.exe”; p = strstr(s1,s2) if (p) { |
|---|
The value of p (result of strstr) is checked, if it is null, it means that the string s1 is not inside s2, but it does not mean that it contains more characters in the string, which is what is used to exploit the vulnerability. In the example above the result would be “String s1 is inside s2!”.
Figure 3: strstr call
Folder path inside string table
One of the valid strings refers to a directory instead of a file, so it can be used as an anchor to be the initial directory from which our path vulnerability traverses and redirects access to the arbitrary file we want to read.
- The string that permits it is: ‘CSHELL/’
Figure 4: Path traversal vulnerability
Since there is an endpoint to obtain a file and the existence of a path traversal vulnerability that we can exploit from the ‘CSHELL’ directory, it allows us to pivot to the file we want within the system and read it.
The implementation of the exploit is very simple since it is based on making a request to the endpoint with the CSHELL argument and the path traversal.
The exploitation is achieved by making the request as in the example below.
Figure 5: lab PoC
The majority of public PoCs are implemented by using a POST request, but as we can see, with other types of requests such as GET/HEAD/PUT methods (although it is not a typical behavior within them) and passing the argument of the file to be read, it can also be exploited successfully.
Due to its simple nature, writing a script in python or any other language to exploit this vulnerability is trivial and that’s why there are so many public repositories that are coding “their version”.
In the wild exploitation
As we mentioned previously, this vulnerability was exploited in the wild, but the fact that it is a very simple and replicable vulnerability means that dozens of public PoCs have emerged along with scanners and tutorials explaining how to use Shodan or other network scanners to detect vulnerable targets of the new CVE.
With Shodan (or similar tools) we can obtain many potential vulnerable targets. By doing a quick test we obtained more than 20,000 targets where companies, public institutions and countless infrastructures are between them.
Figure 6: Shodan results on CVE-2024-24919
Threat Actors currently exploiting CVE-2024-24919 primarily seek to obtain an initial vector of entry to the infrastructure or access to system accounts/users to continue moving laterally.
Examples are:
- Obtaining SSH keys to gain access to the target machine by reading “root/.ssh/id_rsa” and accessing through SSH.
- Obtain hashed credentials to break them locally and thus gain access to the machine or allow the attacker to perform lateral movements through the network.
NetWitness Network Threat Detection
On the different IRs that we are carrying out we are facing the exploitation of CVE-2024-24919 by different actors and groups. We have created internal rules and queries that allow the quick and concise detection of any attempt to exploit this vulnerability.
Find below a query in Netwitness XDR technology that can be used to detect any attempt to exploit this vulnerability.
Query
| direction = ‘inbound’ && directory = ‘/clients/’ && filename = ‘MyCRL’ |
|---|
Figure 7: Example of Netwitness Network view upon attempted exploitation
Log Monitoring – Remote access with password authentication
It is highly recommended reviewing the connection logs of remote authentication with password access. To do that, In SmartConsole, go to the Logs & Monitor > Logs tab.
In the top Search field, enter this query:
| blade:”Mobile Access” AND action:”Log In” AND auth_method:Password |
|---|
Verify that the connection along with all its identifying fields (OS, IP, client name, application…) are legitimate.
Suspected IPs used by threat actors
- 5.188.218[.]0/23
- 23.227.196[.]88
- 23.227.203[.]36
- 31.134.0[.]0/20
- 37.9.40[.]0/21
- 37.19.205[.]180
- 38.180.54[.]104
- 38.180.54[.]168
- 45.135.1[.]0/24
- 45.135.2[.]0/23
- 45.155.166[.]0/23
- 46.59.10[.]72
- 46.183.221[.]194
- 46.183.221[.]197
- 61.92.2[.]219
- 64.176.196[.]84
- 68.183.56[.]130
- 82.180.133[.]120
- 85.239.42[.]0/23
- 87.206.110[.]89
- 88.218.44[.]0/24
- 91.132.198[.]0/24
- 91.218.122[.]0/23
- 91.245.236[.]0/24
- 103.61.139[.]226
- 104.207.149[.]95
- 109.134.69[.]241
- 112.163.100[.]151
- 132.147.86[.]201
- 146.70.205[.]62
- 146.70.205[.]188
- 146.185.207[.]0/24
- 149.88.22[.]67
- 154.47.23[.]111
- 156.146.56[.]136
- 158.62.16[.]45
- 162.158.162[.]254
- 167.61.244[.]201
- 167.99.112[.]236
- 178.236.234[.]123
- 183.96.10[.]14
- 185.213.20[.]20
- 185.217.0[.]242
- 192.71.26[.]106
- 193.233.128[.]0/22
- 193.233.216[.]0/21
- 195.14.123[.]132
- 198.44.211[.]76
- 203.160.68[.]12
- 217.145.225[.]0/24
- 221.154.174[.]74