PHP2Shell: Exploitation attempts and remediation trends

As one of those comments I dispute your characterization of it as the reported vulnerability being fake, very few people were saying that. The main thing being called fake was the narrative that with AI it was trivial to exploit the vulnerability.

It has not escaped me that the successful exploit did in fact just say “codex, exploit this” and got it.

I had assumed the rash of commenters saying “lol I am not revealing my AI’s exploit for a measly 500 bucks” were saying that because their AI attempt failed. Now I know they didn’t even try!

I mentioned this a couple times there but the unintended consequences of that challenge are wild. 2 hours after it the server was fixed there was a successful exploit but because it was originally misconfigured a huge number of people walk away thinking the vulnerability was not serious. At the least we now know a good way to convince large swarths of technical folks to not take new vulns seriously! Which seems not good

The main kickback was against the hype and it was "so easy for AI" and would take "15 minutes to compromise everything".

Either way, this was not true.

I was trying to steal those, but when I setup my local version, I things a little different: php-fpm and glibc because I thought this how everyone would run php with nginx. PHP-FPM recycled OOM workers, so there were no corrupted state to exploit and then when I switched to "php -s", glibc with ASLR made it not very practical to exploit.

Changed my lab to use the same alpine + php = tada working exploit.

To be fair, he hasn't had time to do the write up yet. When he does I fully expect it to hit the front page.

Two things can be true:

1) A motivated human eager for $500 and internet cred can exploit a vuln (perhaps using AI tooling to help)

2) The vuln is not easily exploitable at scale by driveby bots.

> because it wasn't actually running PHP

Yea and no, I mean it was an even worse setup than typical, probably because the person setting it up didn’t have php experience or used an LLM that misinterpreted “route requests from nginx to php” or something too literally and set up a hacky solution.

But my impression isn’t that they set it up in some cheeky way to avoid exploits, it looks like they just asked for nginx to be in front.

And is “hacked in two hours” fair if they had to make it easy for people because their noob setup ended up not being exploitable?

Let me know if my read of what happened is wrong.

Which companies? The earliest claim of an exploit attempt in the wild I had heard was October 17th, and that was “extant”, not “rampant”.

I don’t suppose you’re thinking of when the issue was discovered? That was August 1st, according to https://calif.io/php2shell/#the-discovery.

Should we expect logs from a compromised system to be truthful?

Preach, brother.

There's a difference between walking on the woods at night blind, and with a 20K lumens torchlight.

A successful universal exploit is all about making it land on the correct memory address for each set up, and that is nigh impossible.

As was stated by many groups that do this for a living (E.g., Crowdstrike) "PoC yes, RCE no"

Every single group I read published with the same caveats "RCE _in our labs_" as in, they knew a lot regarding the configuration of the system. Wiz themselves had an article out last week that stated "AI written, tread carefully" and almost all of them made no effort on distinguishing how the 2 vulns operated (Or, differed)

What does being from a particular country have to do with a verified CVE?

It’s not like it was their first rodeo and they got lucky. There are lots of competent security companies located in countries all around the world, including ones you may not politically agree with.

So was the Intel/Apple-silicon/Nvidia chip your PC is likely using. Consider judging companies based on their actions and not their ethnicity

That's the definition of a White Hat to me.

Instead of what patch? I just said this is for those who have NO PATCH AVAILABLE. I guess you need the strawman to make a valid point, though…

Php is still under active development, and has seen a lot of architectural changes at the language level over the last decade that have seen real benefits.

Now, imho, it still isn't a good language, but I wouldn't call it "old". It's not COBOL or FORTRAN where the people who wrote a lot of the mission-critical stuff that banks, research labs, hospitals, and government rely on died 20+ years ago.

A lot of it not receiving investment doesn't come at the language project level, but the individual project level. Accounting likes to pretend that the maintenance portion of the SDLC doesn't exist past a certain point because "what about the shareholders!?" and there are, to date, very few incentives for them to look at the problem in any other way. Let's say you run a Php application that's got Php2Shell vulns and you want to patch it but the only way to do that is to shift major versions, meaning a rewrite of some or all of the code. The code "works fine" according to the bean counters, and there's nothing saying they'll get fined or jailed if a breach occurs as a result, so your project doesn't get funded.