To be fair, the person who created the challenge stated that is was a fairly standard setup, replicating something outside a lab, but in reality is was something completely different, and not anywhere near how PHP is usually used.
It used the development server in PHP, and did not even run requests with fpm or mod_php. Instead, it used the built in dev server of PHP, and just proxied requests from nginx to the php dev server.
Literally the first thing on top of the PHP docs about the dev server used here is this:
"Warning
This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."
That is not something people do, and it also explains why the site was down all the time, cause the dev server is super slow, as it's not meant for this in any way shape or form. A real setup would add a few zeros to the requests per second a server could handle.
So all in all, this was very pointless, as it was nothing like real php sites. A shame, cause a realistic setup woild be more interesting and relevant to answer the question of how hard is it really to gain RCE on a normal site.
Namely that the vulnerability was not that easy to exploit, meaning that the myriads of servers that stayed unpatched during those initial days are probably not all members of botnets now. (Contrary to what the discourse might have made it seem like.)
I was sick when the news about php2shell broke, so ended up leaving two of my personal sites that use php un-patched for about 48 hours until my fever broke and I patched them. I didn’t get hacked. Was I just lucky and so shouldn’t infer anything about how hard it is to actually make use of this vulnerability? Probably.
I would take the opposite conclusion: the initial exploiting took _only_ 19 hours due the non-standard setup, but now the setup can be trivially exploited by tuning the PoC. By now, bad actors will probably have tools that can exploit most common setups.
As an outsider this was fun to watch. Namely, the dozens of l33t haxors including so-called "professionals" who claimed they'd be able to solve this in a jiffy with their magic exploits, yet couldn't.
The only professional I saw making that claim was the CEO of trailofbits who is a former NSA TAO member and doesn’t have anything to prove by talking a big game.
It wasn’t that difficult of an exploit, to be honest. I myself am not the leetest of the leet but I was most of the way there, having been set back by the downtime and my time zone. It’s definitely a fiddly, tricky exploit as most memory exploits are but I think the initial alarm was justified.
While waiting for the server to come back up, it took me about 3 hours with LLM assistance to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
The biggest win, as others have also observe, was the demonstration that there aren’t swarms of automated pwnbots out there that will insta-root your server.
Considering the amount of downtime, I think that flag got got pretty quickly.
I actually had GLM 5.3 run against the site on the day, but it was around 2 am and I was pretty sleepy by 3. GLM found the memory overflow vulnerability but I stopped it before it could continue into retrieving something useful from it.
In retrospect, I should have just given it a /goal and let it run overnight.
To be fair, the person who created the challenge stated that is was a fairly standard setup, replicating something outside a lab, but in reality is was something completely different, and not anywhere near how PHP is usually used.
It used the development server in PHP, and did not even run requests with fpm or mod_php. Instead, it used the built in dev server of PHP, and just proxied requests from nginx to the php dev server.
Literally the first thing on top of the PHP docs about the dev server used here is this: "Warning This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."
That is not something people do, and it also explains why the site was down all the time, cause the dev server is super slow, as it's not meant for this in any way shape or form. A real setup would add a few zeros to the requests per second a server could handle.
So all in all, this was very pointless, as it was nothing like real php sites. A shame, cause a realistic setup woild be more interesting and relevant to answer the question of how hard is it really to gain RCE on a normal site.
That's interesting because there were people complaining yesterday that this was a fully static website with no PHP involved lol
It was https://x.com/LiveOverflow/status/2114412072805208237
Nitter mirror: https://nitter.netbub.com/LiveOverflow/status/21144120728052...
HITCON CTF has a realistic php2shell challenge. Think it has ended up with 0 solves so far, not sure.
There are many PoCs online that work on realistic setups (like PHP docker image). If you're curious you can try to replicate it locally.
are you saying this lead to dos (and less competition)? or easier penetration?
At first glance, this wouldn't affect demonstration of the vuln.
I believe this managed to prove something.
Namely that the vulnerability was not that easy to exploit, meaning that the myriads of servers that stayed unpatched during those initial days are probably not all members of botnets now. (Contrary to what the discourse might have made it seem like.)
I was sick when the news about php2shell broke, so ended up leaving two of my personal sites that use php un-patched for about 48 hours until my fever broke and I patched them. I didn’t get hacked. Was I just lucky and so shouldn’t infer anything about how hard it is to actually make use of this vulnerability? Probably.
I would take the opposite conclusion: the initial exploiting took _only_ 19 hours due the non-standard setup, but now the setup can be trivially exploited by tuning the PoC. By now, bad actors will probably have tools that can exploit most common setups.
As an outsider this was fun to watch. Namely, the dozens of l33t haxors including so-called "professionals" who claimed they'd be able to solve this in a jiffy with their magic exploits, yet couldn't.
The initial server setup wasn't realistic and it wasn't exploitable apparently.
The only professional I saw making that claim was the CEO of trailofbits who is a former NSA TAO member and doesn’t have anything to prove by talking a big game.
It wasn’t that difficult of an exploit, to be honest. I myself am not the leetest of the leet but I was most of the way there, having been set back by the downtime and my time zone. It’s definitely a fiddly, tricky exploit as most memory exploits are but I think the initial alarm was justified.
While waiting for the server to come back up, it took me about 3 hours with LLM assistance to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
The biggest win, as others have also observe, was the demonstration that there aren’t swarms of automated pwnbots out there that will insta-root your server.
Considering the amount of downtime, I think that flag got got pretty quickly.
> to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
Ok but a mediawiki page is obviously not comparable
People were complaining that originally it was just using php to serve a static index.html file
It looks like after 18-19hours they updated it to serve a real .php file and it was hacked less than 2 hours after that
This is already linked by it's author in the Steal My Bitcoin thread (585 points, 458 comments) https://news.ycombinator.com/item?id=50224916
Does php2shell works with PHP-fpm nginx? I can’t truly replicate that poc locally.
I actually had GLM 5.3 run against the site on the day, but it was around 2 am and I was pretty sleepy by 3. GLM found the memory overflow vulnerability but I stopped it before it could continue into retrieving something useful from it.
In retrospect, I should have just given it a /goal and let it run overnight.
Related: https://x.com/JamesPavur/status/2114501212313653696
Apparently the wallet key wasn't on the server, like some in the original thread suspected, but perhaps not due to maliciousness after all.
between the challenge being updated to actually run php and this only like 2-3 hours passed
This was good wholesome fun! Some foundation should do this for future cve's