Dan Guido, of Trail of Bits, claims they have an "universal" exploit [2]. Knowing their track record, I don't currently have a reason to doubt this claim.
[1]: https://stealmybitcoin.com/
[2]: https://news.ycombinator.com/item?id=50226010
EDIT: The HN title has been changed since posting this comment.
Since it was successfully exploited there has been zero further discussion, and I bet most people who participated in the original thread aren't even aware.
It has not escaped me that the successful exploit did in fact just say “codex, exploit this” and got it.
I had assumed the rash of commenters saying “lol I am not revealing my AI’s exploit for a measly 500 bucks” were saying that because their AI attempt failed. Now I know they didn’t even try!
Would be cool to get an accurate timeline / postmortem from the author of the site.
Either way, this was not true.
Changed my lab to use the same alpine + php = tada working exploit.
1) A motivated human eager for $500 and internet cred can exploit a vuln (perhaps using AI tooling to help)
2) The vuln is not easily exploitable at scale by driveby bots.
> The failed leaks highlight a broader challenge: building a generalized exploit that works reliably across PHP versions and deployment configurations is difficult. The kit’s B1 layout was calculated for the official php:8.4.26-apache image with a 128 MB memory limit. Other instances like our Roundcube honeypot ran the same PHP version from a different build, with additional extensions and a 64 MB memory limit. These differences can affect heap layout and memory reuse, potentially preventing the leak from working as expected.
It sounds like it's hard to put together a generalized write-once-run-everywhere version of the exploit, so you need a human or an expensive LLM backing each attack and trying to adjust for the particulars of that target's deployment.
This is the winner: https://github.com/KillaBoi/StealMyBitcoin-PoC
The challenge website was not exploitable at launch because it wasn't actually running PHP; it got cracked in two hours aftewards
In the video, LiveOverflow shows his exploit that reliably gets RCE from two requests.
That's not correct. He claims they have A exploit. Based on the nature of the vuln, I assume every one that works in the are would be very careful to claim a universal exploit, and the comment by Mr. Guido seems to be align with that.
> 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.
So what he seems to be saying (My interpretation) is "I don't want to demonstrate thus risking giving ideas to other people regarding hhow to build exploits"
The steal my bitcoin exploit works for a specific stak, and that is the reason why the person that set that up did publish certain information in the site itself (reduced phpinfo)
I don’t suppose you’re thinking of when the issue was discovered? That was August 1st, according to https://calif.io/php2shell/#the-discovery.
If it needs to hit the same worker to get it to work, that is a whole other problem, and that was not a part of the steal my bitcoin challenge. And what if pm.max_requests is set to 1? Is it then 100 % safe, as it respawns for each requests, making any statement for an universal exploit completely BS, or is a single requests exploit possible?
There's a difference between walking on the woods at night blind, and with a 20K lumens torchlight.
A successful universal exploit is all about making it land on the correct memory address for each set up, and that is nigh impossible.
As was stated by many groups that do this for a living (E.g., Crowdstrike) "PoC yes, RCE no"
Every single group I read published with the same caveats "RCE _in our labs_" as in, they knew a lot regarding the configuration of the system. Wiz themselves had an article out last week that stated "AI written, tread carefully" and almost all of them made no effort on distinguishing how the 2 vulns operated (Or, differed)
It’s not like it was their first rodeo and they got lucky. There are lots of competent security companies located in countries all around the world, including ones you may not politically agree with.
> Warning. This web server is designed to aid application development. [...] It should not be used on a public network. https://www.php.net/manual/en/features.commandline.webserver...
There are 3 main PHP interfaces (SAPI):
1. mod_php which is obsolete and requires Apache prefork (which should also be avoided)
2. php-fpm (FastCGI) which has been the default for more than a decade.
3. FrankenPHP is a new official interface much more suitable for containers.
There were 2 vulnerabilities.:
1. "OOM corruption". The advisory says there was a proven exploit with mod_php, but only for that obsolete SAPI. "Source analysis therefore supports FPM as a susceptible, though *no complete FPM exploit* has been demonstrated for this SAPI."
2. "stale global state". The advisory is The last PHP release (8.5) was vulnerable when the debug parameter fatal_error_backtraces was on. There was a suspicion that an exploit could exist in the session code for php-fpm, but it was unproven and probably unrealistic.
The "evidence" given at the end of the article seems old news to me. The honeypot was based on Apache-prefork + mod_php. As stated in the CVE, there is a proven exploit for that (obsolete) stack.
Adel is doing an amazing job. Both in open source (https://github.com/perplexityai/bumblebee, https://github.com/perplexityai/numbat, https://github.com/0x4D31/galah) and with his reports.
So proud of him!
https://github.com/pizlonator/fil-c/blob/deluge/projects/php...
Have you been able to run any benchmarks? (Are there any benchmarks for this kind of thing?) IDK, seems kind of silly when talking about PHP and webservers but people were concerned when I suggested it in the original thread.
In particular, it is mentioned that the `Zend` allocator does not play well with fine-grained tracking (so would not have caught this issue?) and you need to swap to the system allocator.
And firing the OOM is memory_limit working as designed, not exploiting a system.
Pix, or GTFO.
https://claude.ai/artifact/5cZex56WutyVnpMBrWXxzV
TLDR is multiple entries that show successful exploitation against particular setups (quite often honeypots that were kinda set up to be exploitable e.g. single worker mod_php or lab setups that are unclear on how well they match real deployments), one claim from dan guido / trail of bits about a broad exploit (but few details), millions of attempts in the wild but very little evidence of actual compromise (unit 42 withdrew theirs).
Even if someone finds your wallet and returns it, full of its original cash, they still would have had time to snag your credit card numbers, figure out your address, what coupons you have.
The alternative is a guy in a suit walking up and saying "I saw your wallet in the bushes on 144th and 132nd."
- but anyone who deploys thousands of lines of vibe-coded C that implements a transforming HTTP proxy from scratch instead of a patch (hey, it “might even be safer than the patch”!) deserves what they get
edit: shocker https://news.ycombinator.com/item?id=50199456