upvote
Seems like everyone here has an exploit but they're all busy washing their hair, or thinking of the children, or making huge amounts selling their exploit on the darknet instead.

Given there are public patches and explanations of the issue, isn't it a little late to try to keep this under wraps?

Over a day or two we'll see whether people have an exploit - if more than a few people do, someone will claim this $1k soon. Out of curiosity, what do you plan to do with your exploit that you're holding back?

reply
Unfortunately I left all my easy PHP exploits together with my pre-2023 writing that Pangram flags as 100% AI in Canada with my long-distance girlfriend.
reply
Oh, you left your other pants with her?
reply
Yeah I had it all on a CASIO JD-6000 in the jeans pocket.
reply
My man
reply
I have discoverd a truly marvelous RCE which this margin is too narrow to contain.
reply
lmao
reply
It's done, anyone still talking about this is in the business of monetizing trending keywords (or crime), not in the business of cyberdefense.

Anyone that's thinking about defending basically stopped thinking professionally about this on Thursday midday when the PHP update was released and the patch was applied. Maybe on Friday we learned that there were no confirmed exploits or even theoretical exploits, so we discarded the marginal possibility of our servers being exploited stealthily and having a dormant attacker in our perimeter (it was a buffer overflow attack after all, very hard to execute).

So it's out of mind for us, it's almost saturday, the only reason to think about this anymore is to grift or to think about the social contagion angle. To many of us it was a random tuesday, business as usual, but some people are still thinking this was a somehow special event? My guess is that it was the fact that there was an embargo break and it caused some issues in that 12 hour period between the leak and the patch, but it was a nothingburger, now it just needs to die, at least after it makes its round through the content-creators whose 9 to 5 is looking at trend charts and monetizing views.

reply
It’s Sunday already! (or almost Sunday, depending on your timezone)
reply
The only reason Php2shell wasn't as bad as it could've been was because basically no malicious actors had exploits that were useful in time.

Whoever broke the embargo is a moron and it could have resulted in much more damage than was done.

reply
I think there's still going to be a massive long tail of sites that will never be protected or upgraded, unfortunately that's the reality. So no amount of delay will help them, and most active sites will have patched by now after 5 days.

There are already many people claiming they have an exploit, some in this thread, I think this is a useful measure of just how easy it is - thankfully it doesn't look too easy as it's still up at time of writing, though surely someone will manage it soon.

If it does get taken quickly I think that's useful information on just how serious this is.

If it doesn't, that's also useful info though not hard proof there is no exploit. It does mean that there is no exploit in the hands of script kiddies with chatgpt or similar.

reply
I too have various websites that dont get hacked.

I'm not sure what this page proves except that not all set-ups are in danger. Especially if the site does nothing and has a nginx in front that caps all requests to 1mb.

There are, afaict, at least half a dozen choices a PHP server could have made that mitigates all (known) exploits. Putting some bitcoins behind one of them isn't exactly proof of anything, except as a PR stunt to convince people PHP is not a pile of tightly coupled hot-c garbage.

---

Other projects that get CVEs talk about what went wrong and how to improve. So far i've only seen PHP people defensive and telling each other that ok because other projects also get CVEs.

reply
Hey, you're leaving out that nginx's default is to cap at 1m, btw.
reply
The Dutch government websites that went down have multiple endpoints to upload files that do not have a 1MiB cap.
reply
But the Dutch government websites do generally (I hope) have users, which is one of the ways the "I need to hit the same php worker, uninterrupted, for about 10 to 30 seconds while absolutely no other traffic hits the site AND I can isolate the one worker from the pool" approach to exploiting fails.

Luck is not a security boundary, they should patch their servers, everyone should. It's not a good thing to have shitty memory management on your server.

However, is this really that exploitable in real world conditions? (no)

reply
"There does not exists" and "I've not heard off" are different things. This is motivated reasoning on your part to tell the story that this isn't a big deal.

Most variants require a few requests to infer some settings, and then they can spam their arming-stage, and then their exploit stage. Granted, its not quite as easy as that, but hitting _a_ worker twice on a server once is not all that lucky.

Also, 03:00 at night is not a busy time.

reply
So according to you they could have just imposed an upload cap instead and been safe? If all the cybersecurity experts had given useful advice like that earlier in the week people could have been safer and less panicked.
reply
> I think there's still going to be a massive long tail of sites that will never be protected or upgraded,

Ok? But that's super common, and there's thousands of ways to exploit unmaintained systems, nothing special about this.

From a technical level as well, this is not an easy bug to exploit, it's CVSS Attack Complexity:High, it requires a lot of per-target work, it's definitely not copy.fail level

reply
Shared host Wordpress sites basically run in unprotected untrusted mode since WP has so many RCEs already and they can be in any random plugin someone adds at any time. So even if there's an RCE a lot of these sites just shrug at the attack. You would need to figure out how to chain it for something useful.
reply
But wait, weren't we all told that exploits where already happening all over the place and thats why the embargo was broken?

Cloudflare even claimed they mitigated a bunch of it.

Which is true here? There was widespread usage of this exploit prior to the patch and just after, or that there were "basically no malicious actors had exploits"?

reply
There's a lot of smoke being blown by companies with a financial stake in coming off as "security-minded" or something.

There's apparently _some_ exploit usage in the wild before the embargo breaking, but it very much looks like they didn't even achieve RCE, or if they did it was not widespread at all. It doesn't mean it wasn't possible by a group more sophisticated, it just didn't happen thankfully.

After the embargo was broken, RCEs were still not widespread, especially not before a huge number of sites patched themselves.

So, no, the narrative that skids with agents were busting down doors as soon as the embargo was broken is not accurate. But breaking the embargo before a patch was ready only hurt the situation for defenders.

reply
Whether it is a trap or not doesn't change the OP's point... they are trying to push back on the idea that all servers that have this vulnerability are going to be instantly hacked by bot swarms. If AIs are at the point now where they can all instantly create an exploit from a known vulnerability, then you would have no need to keep your exploit secret because everyone would already have one.

The fact that you keeping your exploit secret means anything already proves their point.

reply
Wrong move. Exploiting this box proves it's exploitable. Not exploiting the box makes the entire computer security profession look like a bunch of worry worts and that the consulting fees are better off not paid. At worst, the owner of the box gets... what? Working exploit code that they'll have to reverse engineer anyway?
reply
The implication of your comment is that the exploit is not trivial and magically available to anyone with some tokens to bash together, which refutes the position that there is an horde of AI agents and people compromising sites en-masse.
reply
Yep. I pointed an agent at the Twitter post about the "working exploit that gets a shell on an unmodified MediaWiki installation.". 5 minutes later it spins up a stock MediaWiki and proves its POC. It modified someone else's POC from Github, but that's still trivial.
reply
Everyone knows that MediaWiki is exploitable. The story running around is exactly that this is generally exploitable even for simple apps serving static content like this.
reply
Lots of people said the embargo should be broken early because "the exploit is already in the wild". That does not normally mean an infosec researcher has a PoC on their private laptop, that means it has leaked, one way or another.

Had it, though? If it was in the wild at day -1, surely some script kiddie will be happy to run that exploit at day +4, because if they didn't someone else would.

There were many people saying things with great confidence and this is one interesting way to gauge what was behind those words.

reply
So an exploit that's difficult to reproduce even despite having access to the patch changes and all the insights into the vulnerability, would somehow be easier to recreate from just a few server logs?
reply
Can you explain how the trap works? The exploit gives you access to the machine which you can then use to wipe the evidence of your intrusion - right? There is nothing to leak by taking control of the machine.

Is the trap theory that this server isn’t really running a vulnerable version of php, and is instead recording all traffic?

reply
They can be running a vulnerable version of PHP but also recording all traffic in a way that does not allow for wiping evidence afterwards. For example, if the PHP server was behind another server routing the raw IP packets and running tcpdump. Since the author of the site controls the TLS cert private key, TLS does not protect again the author eavesdropping.
reply
The exploit gives you access to a machine, not necessarily the one terminating TLS and keeping logs.
reply
After the fact you are going to clean an append-only log on a separate box?
reply
really?

1. there's no actual evidence that the key to the wallet is on this machine at all. it would be trivial to add a service that would sign challenges to prove so

2. a working RCE against PHP is worth much more than $1000, attacking this machine would easily burn that

reply
Serious question: Worth more how?
reply
>it would be trivial to add a service that would sign challenges to prove so

If the author was being dishonest about the key, they could just keep the key on another secure server and have the vulnerable one forward the challenge requests to it.

reply
Yeah this smells bad. Especially given the box is set up to not accept the exploit (1mb vs 12mb).
reply
You mean the sever is setup with nginx defaults?
reply
No, author says right here in this threads that it's been hardened versus default:

> For those who are saying that the nginx config is unfairly difficult, intention was just to replicate a fairly normal config that was more realistic than you'd get in a lab environment. If we get to 24 hr+ with no solves I'll see about making it easier. In the meantime, seems like you can perhaps mitigate PHP2Shell with the right nginx config, so that's pretty neat!

reply
I have a PoC generated by an LLM that can crash sites using php2shell, but crashing != RCE. The issue is that, to achieve actual RCE, recreating the RCE PoC based on the git diff of the patch and blog posts about php2shell isn't enough. You would still need to develop a working exploit chain, bypass ASLR, and so on to actually achieve RCE.

Also, this site runs Nginx with PHP-FPM, not Apache, which is harder than using mod_php exploit mode for this exploit.

So you would need to develop a working exploit chain and then essentially "burn" it by exposing it to the site owner.

In other words, someone is offering $500 for a working exploit chain.

reply
Assuming you do have a working RCE - this is some weird game theory. Do it and potentially leak the exploit. Don't do it and you lose control of the narrative/lose your credibility/have people not take the risk seriously anymore (this comment is losing the fight with another comment for top comment, and the other comment is concluding that yeah this proof that the whole thing was overblown).

And then there's the third option that actually this server is unexploitable or there's no wallet or something and simultaneously you give someone the exploit and lose your credibility at the same time. Really no good way out huh?

reply
Your comment makes zero sense. You have nothing :)
reply
This is the CEO of ToB. It makes total sense why he'd not want to share his proof of concept.
reply
Expand on that acronym for us
reply
Trail of Bits is a well-known security research and audit firm
reply
And a lead on Patch the Planet https://openai.com/index/patch-the-planet/
reply
I can't possibly think of any conflicts of interest there.
reply
Thanks! Appreciated.
reply
deleted
reply
Nobody cares. The patches are public.

He doesn’t have anything that could generically target random websites and achieve shell. He may have something that works in a controlled lab environment, under specific conditions he controls. Or he might have something that relies on other, undisclosed vulnerabilities. Those things are not the same ;)

reply
Please don't affirm things that you perfectly know you don't know.
reply
Sure you do. My girlfriend is a model she just couldn’t come out tonight also. Clown.
reply
deleted
reply