Show HN: Steal My Bitcoin
Made this because I'm curious if anyone out there has figured out how to actually use this PHP RCE we spent the last few days panicking over. Have fun!
Made this because I'm curious if anyone out there has figured out how to actually use this PHP RCE we spent the last few days panicking over. Have fun!
j / k
|
Down or up a comment |
h / l
|
Previous or next link |
?
|
This help |
It clearly isnt happening.
> Yes! Was serving pure html through PHP before 13:00-ish UTC when I added that page
I suspect that they in fact do not particularly care about what you think.
Interestingly enough, virtually all of these come from the Google Cloud IP space. There was a single hit from China and two from Europe.
https://news.ycombinator.com/item?id=50188948
I am still waiting for them to put their money where their mouth is.
Sometimes thought leaders make mistakes ;-)
Clearly people aren't cynical enough.
I find it strange no one in this thread has even considered the possibility that the private key of the wallet isn't on the machine.
OP gets their working exploit neatly logged (or even multiple approaches), keeps the money, strengthens the illusion the exploit isn't that bad, and gets a free $500 on top from someone who added to the wallet.
Which is how hundreds of previous exploits have had people publish information on what to temporarily tweak/disable/block, such that the exploit wouldn't work.
What is novel about this case, and for which i do not know the explanation, is that nobody in-the-know was willing to confirm them before the CVE dropped.
No it doesn’t. An equally plausible explanation is that nobody has tried. (Replace “PHP server” with “someone’s vehicle.”)
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.
No, I will not spend $5 in tokens to claim your $1000 bounty. My $5 exploit is worth more than $1000. Thank you very much.
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.
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.
Well that's good news because my webserver also has logging
In the future, every website will carry a little blurb of text in the footer of their pages intended to scare off would-be hackers and their AI agents:
“The server of this website employs append-only remote logging and state-of-the-art monitoring and intrusion detection. Unauthorized access or attempts there of WILL be prosecuted to the fullest extent of the law. The outcome of such prosecution is and always will be astronomical amounts of money in damages that the guilty party will pay to the victim, alongside decades of prison time for the party guilty of computer crimes. Do not even try.”
What risk?
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.
It may not have happened this time, but we are rapidly approaching a future where this will be the case for every exploitable bug.
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.
If prompting an AI could exploit this for less than $500 in token spend, then you should immediately do so, since if you don't, in a few minutes' time someone else will.
The pros have RCEs, but won’t burn it for something this small.
It’s a real vulnerability, but a complex one
Any attempt at logging so I can make a blog about the successful solve is gonna be best effort, don't have disk capacity to keep up with the traffic (at peak it was rotating every 12 min...). If you win the challenge, write-ups are definitely welcome.
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!
OP added php-version.php roughly 18–19 hours into the experiment (I'm not sure of the exact timing), so that period should be subtracted from the publicly displayed challenge duration.
Based on my external fingerprinting, I now believe the setup should actually be exploitable!
However, the server is being absolutely hammered with requests and crashes. Making it significantly harder to pull off. This is imo still an unrealistic target. If you are not taking the top 1% PHP websites, then they will have long periods (1 minute) of no traffic.
If someone manages to pull off a working exploit under these conditions, that would be crazy to me.
[0]:<https://news.ycombinator.com/item?id=50225861>
Shouldn't you be the one doing the proving here?
> It was index.html but served from PHP's webserver.
Lol, what does that even mean?
Would be fun to see what it's actually running. :)
"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."
It's also singel threaded and very slow, so that explains why the site was so damn unusable.
It's a shame, as a realistic setup would be much more informative.
Those 4 hours the server was barely up due to repeated segfaults from so many people attacking it at once!
I imagine if it'd been setup and there werent so many attackers it probably wouldn't have lasted more than 1-2 hours.
Edit: he turned off request body parsing. This breaks the exploit.
If you can get the php process to run the `print-flag` binary you will get the flag.
curl -X POST -d 'message=ping' https://stealmybitcoin.com/ping.php
I ask because I think that would incentive a few more people bumping the bounty.
you say $500, some comments say $1000, and the web page says $2000
Can't _prove_ that the server is running PHP, but I added a `/php-version.php` page to help calm the conspiracists. Still no changes to the default nginx configuration since it seems we've got a few people getting close with those segfaults, but aware people think it'd be easier if I made those.
edit: don't worry folks, kimi says a subagent "found a credible path to a real pointer leak". everything's under control and kimi will exploit the website in T-(?) minutes.
Post updates on bsky not your actual site as they will be dropping malware once they bop your BTC. Be ready to shut it down fast.
uhhh.... duh.. the CVE requires Memory allocation fails.. They are essentially ddossing you to get exploit the allocation.
Trying to scale this vertically is hilarious.
The experiment looks like "Steal my compute/storage scaling money and uptime", and it barely matters that there is some Bitcoin behind it: a company could lose more than $2000 if agents constantly break its website.
https://www.youtube.com/watch?v=52LJaWDdG9c
Another trick could be to increase hype. Original author could've done that, for example because they always planned to burn 1k USD in BTC on this for whatever reason.
And then there's the trick to hope others follow, after which he, ehh, magically takes the money. That's a bit akin to ICO scams.
Can I prove any of the above theories? No. But the author cannot prove their motives are sincere either.
≈ $2,018.29 USD
Now
i picked the wrong profession
Made my tax audit rather painful.... "I posted a joke on the internet about binary numbers not being worth anything and someone gave me $10k of bitcoin that I'm now declaring - is it income for the work of writing the joke, or a gift? The sender likely didn't know who I was, and was likely overseas but I cannot prove who they were or which country they were in".
Also, I live in a place where that was probably many months pay to the auditor.
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.
The non default php settings he set break the exploit.
If that's the case, then there is a mitigation for all vulnerable versions, but the team that released php2shell said there is absolutely no complete mitigation and every PHP version between 5.4 and these latest updates is absolutely vulnerable. So which is true?
Unfortunately that's only enough to serve a static site and definitely not why or how anyone deploys PHP.
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?
Then the guy never replied, "got busy", etc. A classic here.
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.
For some, it might be relevant to assess the actual risk of being exploited while you figure out how to upgrade the PHP 5.x (or 7.x whatever) stack. There are still important decisions to make when you're put into such a sucky situation: do you take the site down? do you rush the upgrade? (faster probably means more money and bugs) or is it feasible to just chill and upgrade the servers at the normal pace?
I'm glad I don't maintain anything related to PHP but sometimes you don't get to choose your circumstances.
It has survived perfectly fine so far and is on a _very_ vulnerable PHP version based on the php2shell writeup. Management knows it could supposedly get popped at any time, and we'd have to rollback to a snapshot, spin it back up, and wait for it to get popped again. Rinse/repeat.
I used httrack to create a static version of the site and thats whats public now. Has bought me time to talk with management and convince them of what needs doing.
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.
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
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.
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)
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.
Can you link any reports about any site being afflicted by this exploit? (Dutch government website, or other)
The parent comment is implying PHP servers arent at risk, because default nginx limits requests to 1mb. I'm saying that is a bad argument, and a lot of real websites that went offline voluntarily, like the dutch gov, would have endpoints that accept >1mb requests.
Putting https://stealmybitcoin.com/ behind a default nginx proxy and giving it no features is a toy PR stunt hoping to salvage PHP's reputation.
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"?
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.
The fact that you keeping your exploit secret means anything already proves their point.
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.
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.
https://news.ycombinator.com/item?id=50226366
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
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.
I think it's clear at this point that the exploit exists, but is very hard to discover even with AI. It's likely that only top security groups and nation states have it right now, no one who would care about $2,000
It’s easy to close this matter: Dan can communicate the wallet key to the contest operator out of band, and if the operator affirms, then we know it’s true (assuming they are not conspiring to deceive the public, which seems unlikely).
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 ;)
> 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!
That's the default though
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?
https://www.php.net/archive/2026.php#2026-10-21-5
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
All sessions with different agents are running on Tarvis (https://tarvis.io), an app I'm building. Think of it as a self-hosted version of Railway, but with a built-in AI agent and cloud development environment.
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.
EDIT: It's back online!
> 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.
> (AI) "A static handler (nginx’s static path, or php_cli_server_begin_send_static) just sends bytes; it never enters the PHP request lifecycle, so php_request_startup() never runs and the Zend executor/session/multipart parser the chain needs is never initialized."
The author is trying to prove their point that PHP2Shell is hard to exploit. But it's unrealistic because PHP servers usually run PHP code at some point.
I had an LLM recreate this Tweet and yes, it can make an exploit without reward hacking. It took 5 minutes. https://x.com/dguido/status/2113129153293897925
so basically the OP is doing a little trolling
What exactly did you "recreate"? RCE on a stock Docker image based solely on that tweet? In just five minutes? Who's trolling whom here?
You are not being trolled.
Just watch out, because once they've exhausted all the common approaches to bypassing ASLR etc, they'll resort to looping through addresses manually and trying to brute force their way through. So you can learn from their attempts, but only during the "easy" phase.
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.
Now it's only worth it to hack a website that's asking to be hacked if the prize is $15k.
Everyone with inside info was sounding the alarm so the rest of us had to take it incredibly seriously.
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.
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.
No, I don’t think actual working exploit is trivial either, but people are wayyyy overselling this stunt in this thread.
Also, an increasing number of admins of PHP servers probably are no longer alive, so they will not be applying security patches.
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?
Sure you can.
Hillarious how people are like "I don't want my AI agent to do this hack, because people are probably watching the server, so they will see what the agent outputs." Hah, they can also prompt an agent for less than $500 to find out (also the CVE is public info).
Your joke does remind me of a time I was doing a work errand with a colleague and he was upset that I didn't turn around and park so we could rush to pick up the cash that was on the ground that we passed. It was probably a dozen bills, but we weren't close enough to see face value. The premise was absurd to me but for him it would have been worth it. At the time we were just out of high school, and his very wealthy parents would have given him anything he asked for anyway, so I didn't see why he cared.
I suspect you could have quite an interesting experiment at Devos or Martha's Garden or similar; I suspect Warren Buffet would stop to pick up a dollar.
I'm probably not going to stop at freeway speeds for coins or a few bills, but at surface-street speeds? I probably would, more for the game than for the value.
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.
No, you couldn't.
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
Turns out exporting a well-formed bitcoin wallet key is hard. I put a wallet-branch WIF on the server, rather than the WIF for the funded address inside that wallet.
Server logs support this being the first (and indeed only) successful execution of the `print-flag` binary with exfiltration and the person who contacted me definitely knows the value of the WIF key on the server so I'm going to evalute this like a solve. I'm in touch with the person who has the flag now and will transfer the wallet to them shortly.
Transfer made. Next steps will be an operator writeup - thanks for keeping this weekend exciting everyone. Since I now own the stealmybitcoin.com domain (can't believe it wasn't taken), I'm sure some new challenge will end up there eventually ;)
Update 4.5: Challenge source (mostly courtesy of Codex...) posted here: https://github.com/pavja2/smbc-source-oct-2026
Was it actually php2shell, and/or some other exploit?
Going by the fact the setup was rather hostile to exploitation, for the longest time not even exploitable, and under heavy load, I think we can conclude the threat is very real. Again, assuming it's not funny games.
Edit: LiveOverflow got more info, apparently it was hacked hours ago by @killa lol: https://x.com/LiveOverflow/status/2114488571021398330
similarly to the guy from Trail of Bits talking about how it looked like a trap - apparently this PoC was not impossible for someone else to figure out, the window was not as long as you'd hope (again assuming no funny business), and the "trust me bro this exploit is real" messaging just kind of kills overall credibility and does more harm than good. As does a misconfigured CTF, potentially. People do not have a positive view of tech and especially AI right now and if there's a real threat then fueling the "it's just hype to boost stock price for IPO" narrative is maybe a bigger issue than the vulnerability itself no? Because you also tank your ability to get people to take any future vuln seriously.
Plus a broken CTF is apparently a good way to get people to not take a current vuln seriously while also working as a honeypot to get PoCs. Probably everyone involved with good intentions should make sure they're really thinking through all the implications (preferably ahead of time so there's a playbook). Meaning societal/psychological/narrative implications too and not just technical. Security of all fields should be deeply familiar with how human behavior is kind of critical, no? How many people reuse passwords? The AI industry is uniquely incompetent at this aspect. Like all the datacenter stuff where they make secret deals for tax breaks and cheap land with city councils under NDA and then are suprised that constituents react badly to being taken for a ride by an industry and elected officials they already don't trust. Like just from an optics perspective, charging for daybreak or similar frontier cyber-capable AI to defend from AI discovered/led vulnerabilities and attacks - y'all get how this looks like a protection racket right?
The worst outcome here is AI cyberwar/CVE-apocalypse hitting while the industry is treated as the boy who cried wolf even when there actually were previously wolves because everyone involved just sucks at comms and doesn't think things through and now has no credibility to organize a response.
No guarantee how long I can keep it up and you should assume people are doing all kinds of things to the server now that there is a PoC. Enjoy!
> in the binary itself does it perchance end in "fuL"?
Username and that comment earlier matches the "a few hours ago"/"confusion" statement by LiveOverflow.
if you want the poc, it's here https://github.com/KillaBoi/StealMyBitcoin-PoC
Ignoring OP's config fuck-up, I think you did a service to the world, showing this vulnerability is very much real.
again, i'm not sure if they actually succeeded (because the server is down and i don't really trust their local tests), but they seem to have done that.
I think we might not know about the actual exploit, as it would be given there was no further config change worth more than the 2k.
@OP, was it a final cap raise or another config change or was the the 1MB wall really broken?
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.
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?
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.
OpenAI and others are infesting the influencer space with what is basically dark money, not saying you're one of the guys on the take but I just don't trust any large influencer atm who only talks positively about OpenAI (or any lab).
I guess you can prove us AI cyber doubters all wrong with this CtF tho.
I wish I would be sponsored by OpenAI. I am spending way too much on subscription for it.
And this php2shell vulnerability perfectly hits the sweet spot for me and is one of the coolest vulns I have ever seen.
jAwECQEKMLU49MiDV9LSmgFyUbVA3GI6fCx5U2M+0vra/s81r2NWmfqtJTHM0Yn/J8jkzhq1rlXL5/DvyPNPXr0TJp1HeyLaYLvuGrQb/cDMGDeIOebk8yD48YKxUUTVJJFV0I3mzET1pngQEme9r2HrXrOgWVTASCQU/kEYbRfw9ogbCguFCu4qfVZq3JpzNDF52YS1kwtvKVA/wkb+sN5L5fgqEvsZqc8=
So the idea that is not enough money for someone to “give away” their exploit is going to reach a breaking point eventually if it continues. This might get more interesting the longer it goes on. Getting my popcorn ready right now!
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.
But apache + mod_php hasn't been the default setup for a very long time, that's what people are trying to tell you. Given your expertise, you must know that already. So I have to conclude that you're arguing in bad faith because it's the only setup you can break.
When I installed my WordPress blog with DigitalOcean template in 2023, it was Apache + mod_php.
Official WordPress docs mentions Apache before nginx: https://developer.wordpress.org/advanced-administration/serv...
Official php install instructions for Linux uses Apache + mod_php: https://www.php.net/manual/en/install.unix.debian.php
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?
It is an absolutely slopped exploit, hahaha, I fully agree. But that was exactly my point. Memory corruption exploits over the internet have been historically extremely difficult. And it took many days of building a PoC. And this is clearly different now. And of course there are a lot of practical challenges, but that does not make it unrealistic vulnerability to exploit.
> But how is it a realistic precondition to have a server in which you are the only person making requests for 30 straight seconds?
I think it's VERY realistic. My random blog from 2023 https://raisistance.com has hours or days without requests. I think a majority of (old) PHP sites barely anybody visits. And there are tons of random company or government website without any requests at night or so. Also depending on the setup, there ar methods to deal with concurrent traffic. For example Apache (see here: https://x.com/LiveOverflow/status/2113555517339480284).
I think it's clear so far that it's not mass-exploitation material. But once you are more targeted and have a random LAMP stack, it becomes very realistic.
Would you setup a random vulnerable php version from Docker image like `php:8.5.11-apache` on a server, put a flag there, and give me the IP? For me this is a realistic setup and it's fairly easy to exploit.
I think we can set up something interesting here, I'd be down to set up a little "PHP2Shell Olympics" as we change preconditions and see how well the exploits fare. I am pretty sure our opinions of "this can be exploited, and LLMs can aid a rapid exploit of previously-complex ASLR nonsense" and "it's difficult to do memory corruption over the internet; php2shell is not a log4shell moment" are mutually compatible.
My contact details are on the bottom of the blog post.
My datamining project for a game for example, that noone besides me and 2 friends use, gets thousands of requests per second, because all the AI bots found it and try to index every single page (thousands of ssr pages) and they repeat the requests when my cache-control headers expire (ie: when i consider the old page stale), so it's an endless stream (I dont mind the challenge of serving all of these at high performance xD).
My main website, in the same domain (not a subdomain), barely gets any requests, it only has the one main index page with a single link to the datamining subdomain, that's about it.
- 95.3% of seconds had zero logged requests
- 11,582 of 22,159 complete minutes (52.3%) had no requests. The longest quiet stretch was 27 minutes 26 seconds.
- 3,283 continuous quiet stretches lasted at least 120 seconds. Together they totalled 225 hours 27 minutes 27 seconds—61.0% of the logged timespan.
- Excluding Apache’s internal dummy connections: 3,305 qualifying stretches totalled 227 hours 1 minute 51 seconds—61.5% of the timespan.
- Of 38,389 seconds with exactly one request, 14,692 contained an Apache ::1 internal dummy connection. Others included homepage visits, WordPress login requests, crawlers, and scanner probes.
Currently at $2k.
Hilarious to see people suddenly furtive about this easy exploit. Thanks.
If it gets swept you are breached.
Do we know how many other websites were verifiably breached through this by now, if any?
I've always been security conscious and I role play my Arch as a Qubes "dom0" and use VFIO for GPU enabled VMs, which I know is not the Qubes way, but I'm also not that at risk.
EDIT: Now worth $2k
I personally prefer "tripwire" than "canary token", but that's another topic.
“Look! A hundred dollars!” he says, bending down to pick it up.
“Don’t bother,” says the other. “If it were real, someone would have picked it up already.”
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.
OP (and anyone else who exploits the server) would be able to see the transcript between the backend and the vulnerable server, containing the payload customised for the server, but not the actual code of the backend. This would be useful if it was a 0day vulnerability, but with a disclosed vulnerability getting a payload that doesn't work except on their server, without the code that generated it, might not be that much value over what they already have.
That said, there are other ways to scam by structuring things like the OP (none of this should be taken to imply the OP has actually done this, but rather why this structure as a general approach might be a bad idea):
* This could be a 'stone soup' scam where the OP has the wallet keys (obviously), and puts this up to bait the addition of more funds into the wallet by other interested people. The key might not actually even be on the server, or it might not be vulnerable. Once sufficient other people add funds, the OP could withdraw the funds, recouping their original funds plus anything others added. * This could be run as a propaganda scam either to falsely sell that it isn't an easily exploitable vulnerability when it is (by making it unreasonably difficult to exploit compared to real-life deployments), or to over-inflate how exploitable it is (by an insider withdrawal from the wallet). Manipulating public opinion could allow an attacker with a working exploit more time, or help to sell services to fix the problem.
I think an alternative scheme that is less vulnerable to scams would be to have a ZKVM (Risc0 or similar) executing vulnerable code, such that the attacker needs to produce a zero knowledge proof transcript of getting the ZKVM into a particular state that would not be possible if they didn't have an exploit. It should also take an Ethereum address as a public input. Then write an Ethereum contract that will allow funds to be transferred to the public input Ethereum address if submitted with a valid proof transcript, and back to the source of funds after some time has passed. Everyone who wants to add to the jackpot could deploy their own version of the contract, so the one proof transcript could claim from all of them, but if unclaimed the funds go back to the source.
Alternatively (avoiding the risk exploits may be so large as to make the cost of producing the proof transcript impractical), they could be built using a public cloud provider's trusted computing offering (e.g. Google Confidential VMs). The person making the challenge could make it so the derivation (NixOS for example) to produce the entire image executing on the cloud provider in a deterministic way (with publicly known source, and hash codes of each stage publicly available). Then, from the code with the known hash, they use the vTPM to generate an attestation that a key was generated while the vTPM PCRs were in a known state (corresponding to the publicly reproducible hashes), and ensure the only way to access the key from the instance is via an exploit. It would also include logic to generate and wrap a Bitcoin wallet key, and emit the public key (with the attestations and a signature linking back via a vTPM attestation to the cloud provider's key). This way, unless the cloud provider is also in on the scam, people could be assured that the OP isn't scamming them.
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.
I genuinely have no idea how to even start calculating this probability. How would we do it? Is there reliable data on honeypots?
Someone does the exploit, then the creator of this service logs it and uses that exploit to go after higher value targets...
If by chance I happen to break it, I’ll be sure to make contact with you and forward the logs I have, and perhaps let you chat with my agent if you’d like to see what it did.
thank me later
The wallet is at $2,016.73
C'mon guys, I get that OpenAI is involved and they want to make ten trillion dollars next year or whatever, but I thought we had put the idea of random nonexperts trying to judge how "hard" something is to exploit to rest years ago. The guys who used to try doing this lost repeatedly, publicly, until we finally realized that we have to secure our stuff. Sure it's annoying to update your computer every week and sometimes some guy at Forbes is going to tell you that if you don't install iOS 67 today you will get hacked by the Mossad which may not have been entirely true but when you have memory corruption in a reasonably common configuration that faces the public internet, you should patch your software. End of story.
We can argue all day about the cost to exploit something, whether it is "hard for humans" or what it would cost on the black market or in this case how many tokens are required, but that is mostly just a distraction. Just patch your stuff. The people involved here are (currently) paid by AI companies just like ten years ago they were paid by the ads companies but despite the annoying way our economy works they mostly know what they are doing. I get that this is annoying, I understand that nobody wants to hear the words memory safety again, but this is anti-intellectualism. "Ask HN: Can you explain how the PHP bug could be exploited?" would be far more productive than having a bunch of weary sysadmins duke it out in the comment section against security guys.
In Portugal we have a saying for this kind of joke: caça aos gambuzinos :)
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.