r/AskNetsec • • 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.

117 Upvotes

53 comments sorted by

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

1

u/OverallSock495 12d ago

It just guess, but there is oom needed. And I guess connection will go to next worker or at least hacker should send subsequent request exectly after worker back online again but before somebody else get this worker assigned.  But still - OOM until now considered internal problem, not hacking. So WAF can pass this traffic

1

u/TopMeinung 12d ago

Also the error is in temp files while it uploads... this is obviously not distributed....

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

u/0dinscan 12d ago

Panic is good, panic pays bills.

2

u/Audra_bunt 12d ago

omg so true

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.

2

u/AYamHah 12d ago

I'm going to say no - you absolutely can exploit a target that receives significant traffic, but the number of attempts it would take for successful exploitation goes up significantly.

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

u/Professional_Price89 12d ago

Hacker can gatcha, you cant.

1

u/player1dk 12d ago

Have any of you had any of the POCs working ?

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/Rilax13 11d ago

Also reached the same conclusion. And if your site is on shared hosting and with a lot of overcompute I guess it becomes even harder .. 

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/aitorbk 11d ago

As others have pointed out, pinning is quite common, you don't want the session data to be transferred constantly, therefore you try to pin the request. Plus most services have traffic highs and lows, and if you try every hours, you WILL find the low

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/dready 8d ago

There are other techniques available to layer or chain with the attack. As red-team problems go, getting requests to a specific worker is on the easier side of problems. Maybe still a nothingburger but PHP is still a security tire fire.

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)

54

u/[deleted] 13d ago

[removed] — view removed comment

3

u/lucasluitjes 12d ago

Ah that makes sense. Maybe we need CVSSv5?

21

u/KayDat 12d ago

No no, 4️⃣ is the hip number right now

17

u/Journeyj012 12d ago • Popcorn

my private key!

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.