Annie Shaw

Since people are yelling at threat intelligence professional for "downplaying the severity of the PHP vulnerability" (communicating clear concise information about what they're actually seeing). It feels necessary to explain what threat intelligence actually is. Consider a hypothetical hospital or a power company. A lot of systems are built using very old PHP versions. It's not uncommon for PHP to add/remove/change features from version to version. So if you're a certain number of versions behind, updating to the latest version will break your software by removing or changing functionality it needs. In that case, the provider has two options: 1) take their software offline until they can update the code to match the latest PHP version. 2) panic install the patch and break their software, leading to a massive outage. In both cases, that is basically a 100% chance of an outage. On the other hand, maybe they get hacked, maybe they don't. Maybe that hack causes an outage, maybe it doesn't. Realistically, under these circumstances, the chance of an outage is actually higher with patching than with not patching. If that outage would result in the hospital having to shut its doors or a power company's infrastructure going offline, what is the correct move? Chance being hacked, or knowingly cause an outage that threatens lives? Cybersecurity is important and all, but there are risks far greater than being hacked. I would absolutely love it if I could just log onto IDontKnowWhyTheyRenamedThisSite dot Com, be like "vulnerability bad, pls patch" and everyone installs the patch. That is not the world we live in. Now, if I start seeing people building ransomware that can copy itself from system to system using the PHP vulnerability, and I communicate that, it changes a lot of people's risk calculations. Their option shift towards either a 100% chance of an outage, or an extremely high chance of an outage + catastrophic data loss. In this case they would most likely pull the trigger on patching or taking their software offline. While the hypotheticals I gave are extreme cases, many organizations accept being hacked as a cost of doing business. Taking offline software that's critical to organizational function is not an easy decision to make, and does not get taken lightly. We don't live in LaLa land where every org installs every patch for every vulnerability the day it goes live. Cybersecurity is expensive and time consuming. Getting people to even patch systems at all is an endless uphill battle. Most orgs know that something like 1 out of ever 10,000 critical vulnerabilities actually gets exploited. And probably less than 50% of these "this is the worst of the worst vulnerability ever, the sky is falling" type vulnerabilities leads to significant damages. It takes a lot of time to build trust, and very little time to lose it. Overhype a couple of vulnerabilities and people will very quickly stop listening to you. It's extremely easy to end up being the boy who cried wolf. There's only so many times you can spin security teams into a frenzy before they stop listening to you entirely. Orgs also have limited resources, so when you yell fire, there is a good chance they're committing resources they don't have. Making people stay up all night, pulling people off other issues, bringing in outside help. You probably don't want to be responsible for some org getting ransomwared because they redirected all their security resources to some vulnerability you think is really cool. Nobody is downplaying anything. They are communicating exactly what they see/know about the issue so that organizations can make the most informed risk management decisions possible. That is the game, and that is what threat intelligence exists for. If you want to handle an organization's security for them and personally take on the risk of potentially costing them billions or killing their customers, join an MSSP or a critical infrastructure provider. I can promise you it's way more stressful than you think. It's not our job to decide organization's own risk models for them. It's our job to give the most information possible to the people who do. And just because some vulnerability researcher thinks we're not hyping up the vulnerability enough doesn't make them right. Last I checked, only something like 9.3 million out of 42 million systems had installed the patch. This is the reality we live in. If we yell fire, then maybe we can bump that number up to 10 million, but if nothing happens, it'll be at the cost of maybe 2 million less systems getting patched next time around. These are real risks we have to live with. These aren't one-off incidents. People will remember how accurate our advice was the next time around. And more or less people may decide to install security fixes based on how accurately we communicated the risks during previous incidents. Threat intelligence is an extremely complex numbers game where there is never any right answer.

Since my posts have been shared here ~30 times in the past few weeks, it seems like I'm going to be contributing to Space Karen's Ketamine Extravaganza whether I like it or not. I don't really intend to be active here, but I'll post some of the more important cybersecurity-focused stuff, since it gets screenshotted anyway. That way, people don't have to read post a week late and out of context.

Current information I have on php2Shell: - The RCEs requires the attacker to obtain memory addresses which are typically protected by ASLR. - I suspect the original author (lcfr_hax) likely has a reliable exploit which leads to stable code execution. - Most of the PoCs being posted are completely non-functional AI slop. - There is at least 1 working non-slop exploit being passed around, but it's reliant on bruteforcing for ASLR bypass, so not particularly impactful. - Rumor of ITW exploitation are patchy. There are attempts being seen using the non-functional leaked RCE, or variants that are config / system specific. - Some rumors point towards a known-working exploit being used by threat actors (I've personally confirmed this specific exploit works, but the ASLR bypass technique is unreliable at best and massively limits the potential impact). - I'd expect heavy ITW exploitation in the next few weeks based on how many people are looking at this. Though, success rates will vary heavily based on the specific exploit chain.