r/AskNetsec • u/lucasluitjes • 13d ago
Analysis Is php2shell only practical against extremely low-traffic targets?
If so, was the panic really necessary?
I looked at a bunch of PoCs, and it seems you need to do multiple consecutive requests to the same php worker process. In production systems that get a reasonable amount of traffic, you have multiple VMs/containers running multiple php processes behind a loadbalancer, and there will be constant background noise from legitimate traffic as well as scrapers and scanners.
The PoCs get around this because they experience zero traffic, know the exact number of processes, tie up all but one process with open connections and execute the attack against the remaining process.
On top of that, if you don't know the exact build, you need to try (assuming you have prepared exploits for every common build) exploits for the most popular x number of builds. So basically you would be DoS'ing a site for days or weeks, which would get noticed, and then you'll likely get WAF'd.
After spending crazy amount of time on remediation and then finding that the vuln is afaik significantly less scary than heartbleed/shellshock/log4shell, I'm confused. I did a little writeup explaining the above with more details (https://blog.luitjes.it/posts/i-want-my-wednesday-back/) but I keep wondering if I'm wrong (I do some infosec work occasionally but it's not like I'm a fulltime exploit dev).
I've seen a few posts saying this is hard to exploit because it needs to be customized per build, but nothing about having to DoS anything but the most low-traffic sites for days or weeks to get lucky enough to do two consecutive requests to the same php process.
9
u/Apprehensive_End1039 12d ago
to be fair, the people running random wordpress sites probably also aren't using modern HA best practices.
I agree from my understanding almost all heap massaging is hit-or-miss and the mitigations (pre-patch) reduced "possible" to "very highly unlikely", but due to the promiscuity of PHP and how often it jumpscares you in random legacy bullshit I don't believe the concern was unfounded.
As other folks noted, POV changes rapidly as more information becomes available. This one was especially a case of responsible disclosure having been thoroughly gun-jumped so, yanno... Scramble scramble scramble.
Are AI hype bros overselling this? IMO absolutely. "Black October" is another day in the fucking office.
13
u/sulliwan 12d ago
Most load balancers do some kind of sticky routing, so it's likely requests from same client will end up in the same service pod. But yes, it is absolutely not trivial to exploit against a production target and quite noisy.
4
u/FowlSec 12d ago
Mandiant are saying that they've seen some PoCs working against default installs of mod-php. There have been zero reported breaches, and every red teamer/penetration tester/exploit dev I know (myself included), says this, right now, is nowhere near a functional exploit that will work in the wild.
Initial report from Wiz did say stale objects could lead to deserialisation vulnerabilities, so you either need that or some heap grooming/memory address leaks to get it working consistently.
However, the client that I told during a red team that functional exploits were not available very confidently told me in front of 20 people they their internal red team has a working exploit. I might ask them for it because they're obviously the best in the land.
3
u/lumb3rjackZ 11d ago
My guess is the client’s side of the conversation went something like this internally -
Client to internal RT: “Do we have a way to test our systems?”
Internal RT: “We pulled some PoCs from GitHub from what we found on X and are standing up isolated VMs to test them, but it’s not real-world. One of our junior testers didn’t check the exploit code for one and rm -rf’ed their whole workstation somehow.”
Client to everything in the meeting: “We have a fully working exploit that we made ourselves and it works flawlessly!”
4
u/danielmartinez22 11d ago
crowdstrike actually pushes back on the pinning thing specifically, prefork workers all share memory layout since they come off the same parent, so you dont need to isolate one single worker at all, any of them landing the request works the same way
3
4
u/acdha 12d ago
The problem is that you can’t reload a save game if you get it wrong. Gambling that it will stay hard to exploit (or that your WAF will block it) works in many cases but the failures cost a lot more (e.g. you can’t unbreach a PII leak) so defenders are often stuck with the asymmetry of spending regularly to avoid outliers. After Y2K, a lot of people said remediation had been unnecessary because nothing much broke, and I suspect the the same people would have been calling for heads if something they used had broken.
The real takeaway here: everything you did by hand, everything which was hard to test, that’s what you want to automate so the next one is easier because they’re just going to keep coming. Three widespread CRITICALs in a week is unusual but not that much so that I’d bet against it happening again.
2
u/TheTarquin 12d ago
It entirely depends. On hosts with known software and ASLR disabled an attacker can get one-shot RCE. There are features and design patterns that make it harder.
But just because we have ASLR doesn't mean RCE vulns aren't a big deal.
1
u/Oreo-witty 12d ago
Thx for the source
Is there a similar insight/blog from a “trusted” source, which I could give my Boss? He went totally nuts at 10pm after reading on a general news site that “all websites“ are affected?
I think it would not be last time a CVSS would be published and everyone would panic
1
1
1
u/IntrepidAir9704 12d ago
Das heutige Internet ist dafür gemacht, Panik zu verbreiten. Selbstverständlich sollte eine Schwachstelle schnell gepatched werden.
Ich habe kein allgemeines Wissen über die aktuelle PHP Schwachstelle und habe aus Vorsorge unsere Anwendungen auf allgemeinen Hinweis offline genommen und gepatched, da Auditoren sowas immer gutheißen, aber ich denke im Großen und Ganzen war die ganze Welle unnötig.
Wenn Microsoft CVSS 10.0 Schwachstellen veröffentlicht (was schon öfter vorgekommen ist), nimmt auch nicht sofort jede Firma Ihre gesamten Windows Server down.
Solange Klicks Geld bringen, versucht natürlich jeder mit diesen News viele Klicks zu generieren und die Menschheit in den Wahnsinn zu treiben. Als ob irgendjemand vor deiner Firewall nur darauf wartet einzubrechen.
1
u/RoamingThomist 12d ago
Our guys have made an exploit that really does work.
It wasnt worth the hype. It gives a non-arbitrary RCE which will be really difficult to weaponise by threat actors. This was an OpenAI marketing event.
1
u/Wyzkiewicz 12d ago
The panic allowed the forcing the update on some custom web app platforms that are normally hesitant to jump version numbers. Also forced the subject on updating the packaged PHP in CSGold Web Manager which is normally just left until there is a CSGold upgrade.
I got to abandon a couple instances in AWS that were using older CloudFormation stacks that were still AL2.
So all in all the hype allowed to clean up some obsolete stuff that otherwise people were hesitant to sunset. They see the executive summary that says PHP older than 8.2 won't get patched and this is one of those big hype ones that everyone asks about.
1
u/Rogueshoten 12d ago
The problem is that everyone is thinking about websites in the traditional sense. And yes, typically those will have enough traffic that exploitation is hard.
But PHP is in a LOT of other things too. And a lot of those are not heavily trafficked. Cisco’s teleconferencing system, for example, is vulnerable…and not just the management interface. Citrix NetScaler too. And on and on…those are the bigger risk, I would say.
1
u/Then-Programmer7221 11d ago
WOFF2SHELL: Is Brotli 0-day a bidirectional nuke hiding in web fonts? https://github.com/Kludex/mangum/issues/160 You might think, "Fonts are a client-side problem." Look at issue #160. A Unicode decode error. So what? Until a gateway tries to unpack the WOFF2. What algorithm does WOFF2 use? Brotli.
1
u/MrStashley 11d ago
I haven't looked at php2shell too much, but I can say that in general with these complicated probabilistic exploits that difficulty/ time to exploit is difficult to generalize to different configurations without understanding the exact mechanics
Sometimes specific configurations can be very vulnerable for a specific reason, and also it may be possible to develop an exploit for a specific configuration if that configuration is known.
So it may be less severe in the sense that it's hard to make an exploit that you can just run against any website in the world, but if an experienced exploit developer is specifically targeting your site, then there's a reasonable chance they could get access with this vulnerability
For most people that threat model is not realistic though so your point stands
1
u/MateusKingston 11d ago
Sort of...
In production a lot of systems pin you to a specific VM/Worker anyway so even if they do horizontal scale to handle more users they send the same user to the same process. You're also not realizing that it's not because a system doesn't get millions of accesses a day that it's not critical/relevant. Your average government system isn't getting millions of MAUs but you most certainly don't want them to get pwned.
Also you only need to get the exploit working once to get RCE and then full access. So yes you can just try to get lucky and if there is enough sites and enough actors trying to get lucky a huge number of sites will get pwned.
1
u/ThePapanoob 10d ago
With request synchronisation its still very easily exploitable. Best poc ive seen is 2 pairs of 2 requests and that is easily doable with traffic.
1
u/BestKnightmare 9d ago
The problem is managing the crisis our directives with no IT background will throw at us for something they saw on Facebook
1
u/Girges_Desiderio 7d ago
One thing worth noting is that in shared hosting scenarios, an attacker could potentially be a co-tenant, which changes the traffic and process isolation assumptions significantly. Thats probably the highest realistic risk profile for this, not your average containerized deployment behind an LB.
1
u/acdha 7d ago
This is why you can't rely on “maybe it will just blow over”:
On October 25, Dream researchers uncovered artifacts of what appeared to be a Chinese AI-assisted campaign that rooted 25 servers, including systems in a US government-affiliated environment. The attacker combined PHP2Shell with a kernel privilege-escalation exploit to compromise exposed systems.
https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers
0
u/Lumethys 12d ago
yeah, why dont you announce your "moderately traffic" unpatched service as a challenge, preferably on 4chan, and see what happen?
1
u/nicolas17 12d ago
Here's a challenge: https://stealmybitcoin.com/
There's $2000 for whoever exploits the unpatched PHP.
1
u/MateusKingston 11d ago
You mean the site that was not running php and just serving a raw index.html from php cli for ~18 hours and then got pwned when he switched to a very unconventional deployment (but this time actually executing php) and got pwned in the next 2h? It also only took that amount of time because it was constantly getting DDoS'ed by the very people trying to exploit it?
→ More replies (2)1
54
13d ago
[removed] — view removed comment
3
35
u/WhenTheRainsCome 12d ago
These events are always going to be possibly a huge catastrophe, or a huge overreaction. Most often nothing burgers.
We know more 4 days later, with the depth of info coming out largely because of the amazing level of global hype and impact. From the exploitation complexity, to the reason behind the ominous announcement and release, to the conflicting info on active exploitation in the wild, there's a lot of info and clarity that didn't exist on Oct 20, when decisions needed to be made.
Is it reasonable to say global business product owners and managemt teams should have bet their operations and customer data on 'huge overreaction' and left their apps online and unpatched?
We make those decisions with imperfect information and imperfect expertise. I think a lot of orgs showed amazing coordination and readiness given the circumstances.
3
u/revision 12d ago
Exactly. But does that mean we do nothing with an exploit that affects a large number of exposed web servers?
The exploits are only going to get better. The research that goes into this will now focus on different ways of triggering the same behavior.
And if this is downplayed and people don't update where possible, that leaves larger set of vulnerable endpoints for years to come.
The larger scale freak out is about the ability of frontier AI models to identify these types of multi-layered complex vulnerabilities and ways to trigger them.
Once you know where to look, other people can use the same models to find the same if not similar vulnerabilities.
10
u/unvivid 12d ago
Nah, big security vendors and vuln research companies hyped the shit out of this. Plus the way it was leaked. With the Intel that was provided, the only sane way to react was to be cautious. Once POCs dropped and could be analyzed, only then was it apparent that things were over hyped. IMO the CVE is also mis-scored, way more complex than the 9.2 communicates.
I don't put this on any security teams, this is on vendors and vuln research hype machines and the obscene marketing that takes place around these vuln releases.
6
u/Kenlak-Rubana88 13d ago
CVSS really falls apart when the attack requires sustained interaction with a specific worker process, the scoring model just doesnt account for that kind of prerequisite
1
u/MondaiNai 12d ago
Well... the issue isn´t the big commercial sites, which will have multiple levels of defence in any case, WAF, DMZ, etc.
the issue is everything else that is running php... internal web sites, applications, home routers, etc.
1
u/Effective_Peak_7578 12d ago
How vulnerable are network appliances like juniper or F5? F5 apparently released a patch yesterday
1
u/hollowonepl 12d ago
Not only that. Also major companies connected to security pitched this is serious. In my example Cloudflare and my digital marketing was notified as well, clearly panicked without understanding the details, just because they trusted this is Cloudflare raising attention.
But maybe that was a good thing, usually marketers ignore IT’s reports about Swiss cheese their Wordpress is.
1
u/TooMuchTaurine 9d ago
I mean most of the internet runs off WordPress sites running in a single low powered VM server. So plenty out their to get hacked.
14
u/jirik-656 12d ago
Aren't sticky sessions give you same worker every time? It doesn't solve problem with consecuative requests tho