CrowdStrike Struck, PHP CVEs, Race to Exploitation Mountain and KEVs
Hello! This week, AaronJB is here as your editor looking back at the notable security news of the last week (July 15th through July 21st); I can't avoid talking about CrowdStrike just a little, a couple of PHP vulnerabilities (CVE-2024-4577 and CVE-2017-9841), how long it takes adversaries to weaponise vulnerabilities after a PoC is released, and a few notable CVEs that you should really take action to patch ASAP.
CrowdStrike Struck
Let's get it out of the way - I can't not talk about CrowdStrike, at least briefly. I have reason to believe my colleague MegaZone will talk about the aftermath at more length in next week's edition of This Week in Security so I don't want to drag this out too much.
It can't have escaped anyone's attention that there was a "global IT outage" which began on Friday the 19th of July, with Windows computers all over the world blue screening and, in some cases, getting stuck in a reboot loop of BSoDs, after a broken CrowdStrike update was pushed out to their customers. I'm not going to drag on them too much here. We all know that mistakes can happen and sometimes they can have far reaching consequences. McAfee found this out in 2010 when something similar happened after a McAfee update; incidentally, the current CrowdStrike CEO and founder was, then, McAfee's CTO. But I digress...
What surprised me here is that CrowdStrike updates are - as I understand it - pushed out without any opportunity for control by IT admins. Unlike Windows Updates which can be controlled by corporate policy and are often deployed in a staggered fashion after internal testing, CrowdStrike Rapid Response Content updates are delivered immediately and... that's that. Now that I sit back and think about it, this makes complete sense. Your EDR is responsible for detecting malicious activity on your endpoints, we know that threat actors are continually evolving and implementing new techniques, and you don't want the opportunity to detect that activity to slip by waiting on internal processes so delivering updates in a timely manner is essential - but that opens you up to this kind of problem suddenly impacting a huge number of systems.
It is hard to see a way to prevent something similar from ever happening again beside a shift away from a single vendor having enormous market dominance. Perhaps companies will need to look at having split solutions with half of every function running one EDR and half running another? I'm sure that in the aftermath of this incident, advice from folks more familiar with running endpoints will come out and. As I said, I'll let MegaZone dive into the aftermath as it is still unravelling!
PHP still Pretty Happy to Pwn
PHP popped up in the news last week because multiple threat actors have been seen to exploit CVE-2024-4577 in the wild. The CVE was originally disclosed in early June. My experience is that high profile CVEs are usually weaponised within days or hours rather than months; but this CVE flew under my radar as it impacts only (what I assume to be) a narrow subset of systems - those running Windows with either Chinese or Japanese locales. Still, on those systems it is an RCE and as expected, Akamai researchers saw exploitation begin after only a few hours.
What caught my eye here, though is that PHP continues to crop up a lot. F5 Lab's recent DDoS report has information taken from our own sensor intel showing that even very old PHP CVEs (CVE-2017-9841) are still being actively scanned for today, In fact, as of the date of that report, it was the second most commonly scanned for vulnerability after a TP-Link RCE (CVE-2023-1389). In the case of PHP, I think this probably demonstrates the market penetration of the language itself but also the poor patch management associated with a vast array of hobby or volunteer-run systems; think of all those phpBB installs out there, all the hobby Wordpress sites, and so on.
If you run a PHP-based application, you really need to be absolutely on top of your patch strategy!
Race to exploitation mountain
(There's an obscure film reference in that title somewhere) I just talked about how my personal experience shows that attackers weaponise (at scale) exploitation of high-value CVEs (usually RCEs in common web frameworks) within 24 hours - we've seen it ourselves, unfortunately - but recent research by Cloudflare shows that the time to exploitation can be as little as 22 minutes after PoCs are made available. Twenty-two minutes! Let that sink in for a second. Even if we assume that PoCs are made available after patches are made available (which isn't always the case), the total delta between patch and exploitation-at-scale could be as little as a few hours.
Reading that research made it clear to me that it's irresponsible to suggest "Patch early, patch often" as a panacea for vulnerabilities and that a layered approach to security has to be the only sensible precaution - even then, if you are relying on negative security approaches (denylisting, WAF signatures) it's quite possible you'll end up behind the curve.
My first thought, then, is that for public services, we need to make better progress toward positive security as a default security model - allow only what is expected and disallow everything else. That approach comes with a huge set of challenges; keeping security policies in sync with the application, building those policies for existing applications, and managing false positives to ensure a good user experience. Those challenges need financial backing to solve, even where the tooling is already available (NGINX App Protect policies easily integrates with a CI/CD pipeline, for example), but how long can we continue hoping the current game of whack-a-mole is successful?
Notable patches
Finally, a few notable patches from the last week:
- CVE-2024-36401: Affecting GeoServer GeoTools, this is a 9.8 Critical unautneticated remote code execution (RCE) added to CISA's Known Exploited Vulnerabilities list (KEV) last week
- SolarWinds patched eight Critical severity vulnerabilities in Access Rights Manager, six of which were RCEs - CVE-2024-23469, CVE-2024-23466, CVE-2024-23467, CVE-2024-28074, CVE-2024-23471, and CVE-2024-23470
- CISA also added CVE-2024-28995, another SolarWinds vulnerability but this time in Serv-U to the KEV
