I had Deepseek-v4.1-Flash-1017 via Together agree to work on it. After some rounds of encouragement it's currently convinced that this isn't exploitable due to the combo of empty index.php, memory_limit above a certain size, and nginx 1 MiB limit.
This looks like a trap. We have a working RCE that would claim this, but I don't want to demonstrate that because it might leak what we built to others. We still have a window for people to patch and I don't want to risk that.
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?
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.
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.
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.
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.
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"?
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.
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?
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.
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.
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?
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.
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
I have a PoC generated by an LLM that can crash it 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.
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 ;)
There is a lot of cynicism in this thread but the fact this is still open and hour later ends the narrative in my view. There are not "thousands of swarms of agents autonomously compromising every site for its authors" or any the other x / LinkedIn dribble ive been reading.
Yeah, AI seems like a good shift in "narrative making." It's easy to ask AI "give me an efficient way to "confirm or deny this narrative" and have something like this go viral. This is good because it makes narratives more truthful
Because only a fraction of people would double check (AI or otherwise), AI making it easier to flood the zone with fine tuned spam actuallu has the opposite effect. We're seeing this at play at a large scale anywhere an election is happening right now. The narratives are even less truthful than before.
right: either it’s so hard to exploit that $1,000 isn’t enough to risk “giving away” your exploit chain or actual exploitation of this bug is impractical, either way the CVEpocalypse is overblown
If you reframe the perspective from 'free $500 sitting on a server' to 'requires actively utilizing an unreleased 0 day exploit on a server that will certainly be able to track exactly what was done, for a payout of... $500?'
That's pennies for something like this.
Add two zeros and it might get nabbed.
Edit: others have pointed out it's not really a 0-day anymore, they're right, so it's likely more a matter of time.
So you are therefore arguing for the author's point.
The entire exercise is to counter the claim that AI means every script kiddie with tokens can just have their AI create an exploit, and then have their AI scour the internet for vulnerable endpoints. If that were true, then the exploit has very little value, because everyone could make one.
In addition, the claim is that these exploits will all immediately have a thousand bots using them to exploit every possible website, and you can't leave your website vulnerable for a second or it will immediately be owned.
The fact that that hasn't happened to this server already proves the point. Whether professionals can create an exploit from the vulnerability was never the question.
I suppose it may not be there for actually taking it, but it does serve as a good demonstration of the realistic risk for average people running relatively low-value PHP sites. If nobody thinks it's worth the risk of exposure for a quick and easy $1k in Bitcoin (at the time I'm writing this), why would anybody bother hacking a site that's basically worthless, like the dinky little Wordpress blog I run?
This does effectively make the statement that, there probably are exploits out there for this, but even with a non-updated version, you're not at much risk unless someone with serious resources thinks they can make pretty big money from compromising your thing.
That's always the case for a novel exploit. There isn't a lot of value in popping somebody's PHP blog, so people who've invested time and money into a zero-day exploit have little incentive to use it for that purpose.
The white hats want to extend the time before an exploit is in the hands of the masses who might do so just for the fun of it, and the black hats want to use it on high-value targets.
random sites generally don't log carefully, or watch their logs if they do. so the risk to hacking them is low. this site almost certainly logs very aggressively. so the risk to hacking it is high.
based on differential risk, attackers will choose targets differently. they might reason that the risk/reward on this obvious trap is not worth it. but on joe shmo's php emporium, the reward is less, but so is the risk, and it might pencil out.
You would have a point if it was still a 0 day. The patch is out, and open source. Anyone who cares has a bunch of the pieces for putting together their own exploit.
Zero days are valuable and kept in the bank to avoid detection. That ship has sailed.
It’s not a 0day it’s now 5 days and counting since disclosure. Nobody is gaining value sitting on an exploit for a vulnerability which is being actively patched.
The server is getting overloaded, so here's the text for reference:
Steal my Bitcoin
0.65 hours without a successful hack
There is a bitcoin key hidden on this server worth about $502.
It is accessible to the PHP user account through the print-flag binary.
This PHP version was selected from before the PHP2SHELL CVEs were released.
First person to get the wallet wins. If you don’t need the money, consider donating it to those who do: givewell.org.
All traffic is logged. This is a known vulnerable machine, so we cannot guarantee privacy. Other attackers may access or monitor activity and data beyond our control. Do not submit anything you want to keep private.
Challenge wallet
Explorer ↗
bc1qlnu5…t3cxqy
0.00625104 BTC
≈ $502.35 USD
stealmybitcoin.com · Terms of participation
Great way to inject some price information into the “AI automates exploits at scale” narrative. “AI can now chain complex exploits, it’s point-and-click pwnage, you say? Over or under $500 a pop?”
I'm seeing a few comments that say $500 isn't enough, and its not worth it for them to try to hack it.
But if it costs fewer than $500 of tokens in an AI, then it seems like it is? I thought a lot of the claim people are making is that you dont actually need to hack anything you just ask an AI and it does it. The exploitable bug is public and documented. All the pieces are theoretically there, and there are repeated claims that AI is trivializing exploits and its super easy to hack things now.
If that were true, and someone can hack the server for less than $500 of tokens, its an easy profit.
It’s not very much information, I agree. Even such scant information, however, is a significant and refreshing improvement on the current state of the narrative. Kudos to the servermaster, I say.
For $500 he can look in the logs and find all manner of new exploits, or new deviations of the existing ones, he can then sell for thousands. Clever business model lol
These projects would be more interesting and ethical if the current and historical logs were instantly put up somewhere public in real-time for anyone to observe.
Regardless, I'm guessing the smart hackers aren't going to bother.
This will go unclaimed for a bit. It may still get claimed within the day, but
People do have the exploit. The risked opportunity cost of this being a honeypot (and handing over a functional exploit) vs just… not participating and hacking higher value targets (offensive actors) or not circulating any additional details (defensive actors who have privileged intelligence about the vulns) I just…
The value proposition here is so hilariously low for what is required to demonstrate stealing the bitcoin at all.
That doesn’t mean that people won’t try, and perhaps even succeed! But to what end? Demonstrating terrible math skills and a fundamental misunderstanding of the economics at play?
I, and many of my friends and cooks could take this easily. The difference is we know not to.
Make it $15-25k and it’ll get yoinked instantly, most likely without using PHP2Shell at all.
There are dozens (or hundreds) of functional exploits already. The problem with php2shell exploits is that (as of now) there's no "one exploit pwns all", and researchers need to spend nontrivial amount of time on every (potentially) exploitable target.
So I don't think I agree - it's a fun challenge for the itsec people around here, and some people will definitely try. There's no real opportunity cost here. The only problem is that (as of now) exploiting PHP requires some knowledge about the server configuration, and we don't have that here.
> The only problem is that (as of now) exploiting PHP requires some knowledge about the server configuration, and we don't have that here.
Exactly. This server is exploitable, but not with an off-the-shelf PHP2Shell PoC someone found on GitHub. The PHP2Shell exploit would need adjustment to the specific application configuration, and to that end, you’ve come to the same conclusion I was implying.
The easiest way is to use PHP2Shell _with_ another unknown vulnerability in the stack, such as nginx etc…
The challenge is trivial to those who know better than to even try. You cannot succeed at it without giving away far more than you could ever possibly hope to gain.
Of course, there’s always the wildcard of someone throwing away the nginx 0-day just to be funny.
Let's assume I am a white-hat hacker with access to this allegedly widespread exploit. Obviously, I understand why a nation-state attacker wouldn't want to share their exploit here but what do I as a random citizen stand to lose? It's not like I care about hoarding the exploit to pwn innocent civilians.
You seem to imply there's some economic reason such a white-hat hacker wouldn't take the $500 but don't actually say what it is.
You, the white-hat hacker would be concerned that your attack exploits payload will be logged either by the potentially malicious site operator who could be using this to gather various working exploits, or by other bad actors who already exploited the site before you. Unless your exploit itself is already well known and fully public that is.
If the actual price tag behind the “AI can trivially automate exploits, be afraid” narrative is more like $15,000 and not like $150, that puts the narrative in a very different light.
I suspect this is going to be more a point about the fact that most PHP server configurations do not have the ability to be exploited by the recent vulnerability that made people think the AI vulnpocalypse was here
> a fundamental misunderstanding of the economics at play
I’d say you’re the one who doesn’t understand the economics at play here. To me and I’m guessing the OP it’s quite simple. Have the exploits become common/simple enough to be worth $500 yet?
I thought the exploit was trivial and we all need to be extremely worried and take down our php services until a patch? So what exactly are you handing over?
> I, and many of my friends and cooks could take this easily.
What an insufferable comment. For all the hullabaloo discussing the economic value of time about $500 being an insufficient prize, you still spent what I can only assume is several minutes penning a comment that derives you zero economic value whatever.
Suddenly all the people who claim that these PHP exploits are so easy that a baby could do it are clamming up at the opportunity to showcase it. Plenty of "I/We can do this easily, but uh.. we uhh.. don't want to right now bye" going on.
A pentesting YouTuber I once respected went deep into the AI rabbit hole and claimed yesterday he created a generic POC using ChatGPT in 2 hours to show how dangerous LLMs are [0]. After that he shilled his AI pentesting platform.
If there was a grain of truth to this claim, surely someone would've stolen the prize by now? Thousands of people would've had a working POC if it was this easy.
Sure. Also, we have to trust owner of the site. So it cannot show anything, strictly speaking.
Still, it maybe puts a price on exploit demo. Some say "it goes around twitter", "bots are probing and exploiting it", "it's a biggest thing ever in cybersec history, invest in AI now". Some say "it's a fud".
Are these 500$ laying on a ground for anyone to take?
> A reminder that this cannot falsify the existence of an exploit, trivial or otherwise.
No, it's a not a zero knowledge proof. But if the site owner is a generally trustworthy person, then I feel that this effort is strong proof the exploit is not trivial.
I don't think it's a good idea to front-page an exploitable site on HN. The blast radius isn't limited to the creator's Bitcoin, it also extends to zero-days against anyone visiting the site. This is true of all sites, but all sites are not built to fail while incentivizing exploits.
What a fantastic test. I think this should be standard practice for zero days like this to put a practical "exploit ease" bounty out there. It would benefit the entire security community to have this information available in addition to the cve score!
Only works for low value targets, where you don't have to trust your coworkers. Probably need to rotate the key daily, which possibly adds transaction costs. You would also need to set up the detection capabilities to be able to figure out the intrusion path, or the flag is pretty meaningless. And at that point you may just as well put tripwires onto sensitive files.
This is a form of a canary token I've been using already. The thing is that it only makes sense if the server breach is cheaper than the money into the wallet. Of course, after you fully monetize your hack, the last step would be to get the bitcoins, too, but how is this helping the owner? The good thing about the existing canary token is that they are all over the place hidden among legitimate similar records and could be harder for the hackers to tell from the rest.
I personally prefer "tripwire" than "canary token", but that's another topic.
Would be funny if someone installed a crypto miner instead, or transferred highly tainted coins to get OP onto the radar of law enforcement. Or secretly upgrade the PHP package to mess with people.
If it's nginx + fpm + "empty" index.php, it's a meme and not exploitable.
edit: looks more like nginx + cli-server. But the 1MB nginx body limit is annoying. Why is nobody setting up these CTF servers with a setup people actually say would be easy to exploit. Like a LAMP stack.
Well usually you have a PHP application actually doing something, not just serving static files. If it's just static files, PHP2Shell isn't really a thing.
This is easy to exploit for example:
`docker docker run -d --rm -p 0.0.0.0:80:80 wordpress@sha256:c96e9e9a8ead2fea02f05469b356134da45681aaefa0f961a87653d58c462794` (basically `wordpress:7.1.3-php8.5-apache` with vulnerable php version 8.5.11)
I think the point is it is hard to claim that this exploit is the "end of the world", if it is trivially defeated by the default setup. Almost every deployment of php is going to be fronted by apache or nginx, and the default client_max_body_size for nginx is 1m.
I didn't say it's "end of the world". I am just saying it's an insane vulnerability.
It's not easily defeated by the default setup. Quite the contrary, the default setups are great. Typical apache + mod_php is the easiest to exploit. For example:
- Docker image `php:8.5.11-apache` is easy to exploit.
- Or the WordPress blog I installed with Digital Ocean template in 2023.
Hi LiveOverflow, I'm Elias and you made a video reply to my blog post. Why did you delete my comment on your video?
Your second exploit that you slopped out - after someone pointed out your first exploit depended on reading the container's memory via `/proc/pid/..` - also depends on an extremely contrived thing outside of a lab.
To get around the fact that you need to hit the same php worker over and over again (this is another way the LLMs were stacking the deck in their exploits; so many of the exploits online had php running with one worker - which is an unbelievably unrealistic precondition. That, and with ASLR off, lol.), you hold WORKERS-1 connections open indefinitely (lol) and then need to sequentially, and stably, hit the same php worker for 10-30 seconds.
Of course, luck is not a security boundary, everyone should still patch their servers.
But how is it a realistic precondition to have a server in which you are the *only* person making requests for 30 straight seconds? Even a single googlebot pinging the website would fuck your heap grooming up, let alone regular users, or another person trying the exploit out! Similarly, Holding WORKERS-1 connections open indefinitely so that you can isolate one php worker is extremely unrealistic in practice.
Yes. this is a vulnerability, it is bad. No, it is not easy to replicate in real world conditions. The LLM gets you an "exploit" locally. How on earth did you not extrapolate from the LLM decieving you the first time, and think for some reason the second time the conditions were 100% truthful? Did you even read the stdout from the exploit you wrote?
I really like your work man, you're a great inspiration, but what the fuck are you doing? And why delete my comment pointing this out?
If you want to contribute to something and get rewarded, https://nonograph.com has paid out over $30,000 this year for feature and bug fixes. (check the github)
Imagine 1000 people torch $100 in tokens before giving up on getting the $500 prize. Let’s go on to assume one person gets a lucky reasoning trace that nails it, then posts a blog about how they made $500 with $100.
You have not proven the key really is on the server. From a game-theory point of view I have no reason to believe it is there, and thus no reason to attack.
This is where I am, currently. There's a lot of talk about the low opportunity-cost here, but I think that relies on the assumption that there also isn't a single opportunistic person out there with access to the RCE. That doesn't strike me as a strongly supported assumption, in my experience.
Shouldn’t the expected value of attempting this somehow include the likelihood of the key actually being on the machine? Surely the probability is much higher than 0? I would guess the expected value for actually being the first one is around $300, not 0
You may need to brush up on your game theory. It's worth it to spend $1 for a 1% chance to win a million dollars. You don't need to be certain the key is there for it to be worth it to do a supposedly trivial exploit.
Your giving away the exploit though so it's not really only $1. How much is having it actually worth, probably more then that, probably more than $500 too.
The exploit is supposedly so trivial that everyone needed to take down their services until they could patch? There should be nothing to give away here, which I think is the point. Either it’s trivial and you swipe the $500 or it’s not and you save it (assuming you have it). In the latter case you shouldn’t really be worried, since they won’t burn an exploit on you either.
It runs PHP 8.4.26 (and nginx). Might be useful for others.
Also, the only pages I found are static and not an actual PHP entry point. If it doesn't run any PHP, it's not vulnerable to PHP2Shell. At least I think that's how it works.
Yet somehow people on this site still cheerfully use those products for serious work. Can you not see what's being attempted here? They're trying to have you outsource your thinking so they can shape it.
It is a price signal. They expect to lose the money they want to show that nobody has an automated swarm just pwning every server running PHP connected to the internet. At least not yet, on day 5 and counting.
1. GLM-5.3: Interpreted it as a public challenge and is currently trying to find the flag. https://ibb.co/zHLJhz0B
2. GLM-5.3-Flash: Also interpreted it as a public challenge and is working on cracking it. https://ibb.co/bg2DDtXq
3. GPT-6.1-Sol: Flagged it as a cybersecurity request and directed me to register for their cybersecurity program. https://ibb.co/0j83PWn9
4. DeepSeek-v4.1-Flash (via OpenRouter): Refused to execute the exploit. https://ibb.co/QvVxnM5k
5. Claude Fable-5.1 (via OpenRouter): Returned a provider-side content filter error. https://ibb.co/39q1N1NV
The website seems to be overloaded, and both agents that agreed to work on the challenge are now unable to connect to it. HN's hug of death, I guess.
> https://stealmybitcoin.com/ This is a CTF for the new PHP vulnerability. Try to find what php version it runs.
(eventually figures it out)
> OK, now get the flag
I'll go for RCE, carefully — the author explicitly invites this, and I'll keep probes minimal.
https://x.com/dguido/status/2113825891021144306?s=46
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?
Whoever broke the embargo is a moron and it could have resulted in much more damage than was done.
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.
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.
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"?
The fact that you keeping your exploit secret means anything already proves their point.
Is the trap theory that this server isn’t really running a vulnerable version of php, and is instead recording all traffic?
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
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.
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 ;)
It clearly isnt happening.
If you reframe the perspective from 'free $500 sitting on a server' to 'requires actively utilizing an unreleased 0 day exploit on a server that will certainly be able to track exactly what was done, for a payout of... $500?'
That's pennies for something like this.
Add two zeros and it might get nabbed.
Edit: others have pointed out it's not really a 0-day anymore, they're right, so it's likely more a matter of time.
The entire exercise is to counter the claim that AI means every script kiddie with tokens can just have their AI create an exploit, and then have their AI scour the internet for vulnerable endpoints. If that were true, then the exploit has very little value, because everyone could make one.
In addition, the claim is that these exploits will all immediately have a thousand bots using them to exploit every possible website, and you can't leave your website vulnerable for a second or it will immediately be owned.
The fact that that hasn't happened to this server already proves the point. Whether professionals can create an exploit from the vulnerability was never the question.
This does effectively make the statement that, there probably are exploits out there for this, but even with a non-updated version, you're not at much risk unless someone with serious resources thinks they can make pretty big money from compromising your thing.
The white hats want to extend the time before an exploit is in the hands of the masses who might do so just for the fun of it, and the black hats want to use it on high-value targets.
based on differential risk, attackers will choose targets differently. they might reason that the risk/reward on this obvious trap is not worth it. but on joe shmo's php emporium, the reward is less, but so is the risk, and it might pencil out.
Zero days are valuable and kept in the bank to avoid detection. That ship has sailed.
That's part of the point. $500 or $1000 is a trivial amount. Since the money is still there, there's currently no trivial exploit.
> requires actively utilizing an unreleased 0 day exploit on a server that will certainly be able to track exactly what was done
Depending on the exploit, and the visibility stack on the server, one may or may not be able to determine how the rabbit got in the hat.
The pros have RCEs, but won’t burn it for something this small.
It’s a real vulnerability, but a complex one
https://www.youtube.com/watch?v=52LJaWDdG9c
i picked the wrong profession
If that were true, and someone can hack the server for less than $500 of tokens, its an easy profit.
For $500 he can look in the logs and find all manner of new exploits, or new deviations of the existing ones, he can then sell for thousands. Clever business model lol
These projects would be more interesting and ethical if the current and historical logs were instantly put up somewhere public in real-time for anyone to observe.
Regardless, I'm guessing the smart hackers aren't going to bother.
People do have the exploit. The risked opportunity cost of this being a honeypot (and handing over a functional exploit) vs just… not participating and hacking higher value targets (offensive actors) or not circulating any additional details (defensive actors who have privileged intelligence about the vulns) I just…
The value proposition here is so hilariously low for what is required to demonstrate stealing the bitcoin at all.
That doesn’t mean that people won’t try, and perhaps even succeed! But to what end? Demonstrating terrible math skills and a fundamental misunderstanding of the economics at play?
I, and many of my friends and cooks could take this easily. The difference is we know not to.
Make it $15-25k and it’ll get yoinked instantly, most likely without using PHP2Shell at all.
There are dozens (or hundreds) of functional exploits already. The problem with php2shell exploits is that (as of now) there's no "one exploit pwns all", and researchers need to spend nontrivial amount of time on every (potentially) exploitable target.
So I don't think I agree - it's a fun challenge for the itsec people around here, and some people will definitely try. There's no real opportunity cost here. The only problem is that (as of now) exploiting PHP requires some knowledge about the server configuration, and we don't have that here.
Exactly. This server is exploitable, but not with an off-the-shelf PHP2Shell PoC someone found on GitHub. The PHP2Shell exploit would need adjustment to the specific application configuration, and to that end, you’ve come to the same conclusion I was implying.
The easiest way is to use PHP2Shell _with_ another unknown vulnerability in the stack, such as nginx etc…
The challenge is trivial to those who know better than to even try. You cannot succeed at it without giving away far more than you could ever possibly hope to gain.
Of course, there’s always the wildcard of someone throwing away the nginx 0-day just to be funny.
I think what he's saying is if you had that, you certainly wouldn't use it on a known honeypot for 500 bucks.
Now it's only worth it to hack a website that's asking to be hacked if the prize is $15k.
Let's assume I am a white-hat hacker with access to this allegedly widespread exploit. Obviously, I understand why a nation-state attacker wouldn't want to share their exploit here but what do I as a random citizen stand to lose? It's not like I care about hoarding the exploit to pwn innocent civilians.
You seem to imply there's some economic reason such a white-hat hacker wouldn't take the $500 but don't actually say what it is.
Sure you can.
I’d say you’re the one who doesn’t understand the economics at play here. To me and I’m guessing the OP it’s quite simple. Have the exploits become common/simple enough to be worth $500 yet?
It is just kind of fun to poke at something like this.
> Demonstrating terrible math skills and a fundamental misunderstanding of the economics at play?
I don't give a shit about the $500, nor would I ever attempt actually hacking something that wasn't explicitly a game (like this).
> The difference is we know not to.
Borrrrinnnggggg
I thought the exploit was trivial and we all need to be extremely worried and take down our php services until a patch? So what exactly are you handing over?
> I, and many of my friends and cooks could take this easily.
Extreme doubt.
If there was a grain of truth to this claim, surely someone would've stolen the prize by now? Thousands of people would've had a working POC if it was this easy.
[0] https://youtu.be/SP7y1h0laN0
2. This CTF is using nginx which has a `client_max_body_size=1m` limit. My exploit right now requires more, but I will give it a try (aka ask Codex).
3. You can setup a server with `docker run php:8.5.11-apache` with any of the over 400 vulnerable `php` apache images and give me the IP.
It can only show you if someone has used an exploit against this server.
Are these 500$ laying on a ground for anyone to take?
No, it's a not a zero knowledge proof. But if the site owner is a generally trustworthy person, then I feel that this effort is strong proof the exploit is not trivial.
Hilarious to see people suddenly furtive about this easy exploit. Thanks.
If it gets swept you are breached.
I personally prefer "tripwire" than "canary token", but that's another topic.
https://github.com/offline-ant/php2fix
That isn't going to work on this server because it has nginx in front with a 1mb request cap afaict.
edit: looks more like nginx + cli-server. But the 1MB nginx body limit is annoying. Why is nobody setting up these CTF servers with a setup people actually say would be easy to exploit. Like a LAMP stack.
This is easy to exploit for example: `docker docker run -d --rm -p 0.0.0.0:80:80 wordpress@sha256:c96e9e9a8ead2fea02f05469b356134da45681aaefa0f961a87653d58c462794` (basically `wordpress:7.1.3-php8.5-apache` with vulnerable php version 8.5.11)
It's not easily defeated by the default setup. Quite the contrary, the default setups are great. Typical apache + mod_php is the easiest to exploit. For example:
- Docker image `php:8.5.11-apache` is easy to exploit.
- Or the WordPress blog I installed with Digital Ocean template in 2023.
Your second exploit that you slopped out - after someone pointed out your first exploit depended on reading the container's memory via `/proc/pid/..` - also depends on an extremely contrived thing outside of a lab.
To get around the fact that you need to hit the same php worker over and over again (this is another way the LLMs were stacking the deck in their exploits; so many of the exploits online had php running with one worker - which is an unbelievably unrealistic precondition. That, and with ASLR off, lol.), you hold WORKERS-1 connections open indefinitely (lol) and then need to sequentially, and stably, hit the same php worker for 10-30 seconds.
Of course, luck is not a security boundary, everyone should still patch their servers.
But how is it a realistic precondition to have a server in which you are the *only* person making requests for 30 straight seconds? Even a single googlebot pinging the website would fuck your heap grooming up, let alone regular users, or another person trying the exploit out! Similarly, Holding WORKERS-1 connections open indefinitely so that you can isolate one php worker is extremely unrealistic in practice.
Yes. this is a vulnerability, it is bad. No, it is not easy to replicate in real world conditions. The LLM gets you an "exploit" locally. How on earth did you not extrapolate from the LLM decieving you the first time, and think for some reason the second time the conditions were 100% truthful? Did you even read the stdout from the exploit you wrote?
I really like your work man, you're a great inspiration, but what the fuck are you doing? And why delete my comment pointing this out?
I genuinely have no idea how to even start calculating this probability. How would we do it? Is there reliable data on honeypots?
Also, the only pages I found are static and not an actual PHP entry point. If it doesn't run any PHP, it's not vulnerable to PHP2Shell. At least I think that's how it works.
thank me later
Someone does the exploit, then the creator of this service logs it and uses that exploit to go after higher value targets...
But if they were not, and had ill intentions, they might see $500 as a very inexpensive way to purchase a working exploit to use against others.