| ▲ | paxy 8 hours ago |
| It's funny that when stealmybitcoin.com was posted on HN (https://news.ycombinator.com/item?id=50224916) there were hundreds of top voted comments saying "see no one has been able to steal it, the reported vulnerability was fake, it's all AI marketing" etc. 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. |
|
| ▲ | fwlr 7 hours ago | parent | next [-] |
| As one of those comments I dispute your characterization of it as the reported vulnerability being fake, very few people were saying that. The main thing being called fake was the narrative that with AI it was trivial to exploit the vulnerability. It has not escaped me that the successful exploit did in fact just say “codex, exploit this” and got it. I had assumed the rash of commenters saying “lol I am not revealing my AI’s exploit for a measly 500 bucks” were saying that because their AI attempt failed. Now I know they didn’t even try! |
| |
| ▲ | ratscylla 4 hours ago | parent [-] | | If you follow the threads, it looks like the original post wasn’t exploitable. It looks like it was hacked within an hour of being made exploitable (actually running php). Would be cool to get an accurate timeline / postmortem from the author of the site. | | |
| ▲ | fwlr 4 hours ago | parent [-] | | Yes, I followed along at the time. As I recall, the explanation of why the server wasn’t exploitable read exactly like an excerpt from a session with a frontier model explaining why its exploit failed. |
|
|
|
| ▲ | vikramkr 7 hours ago | parent | prev | next [-] |
| I mentioned this a couple times there but the unintended consequences of that challenge are wild. 2 hours after it the server was fixed there was a successful exploit but because it was originally misconfigured a huge number of people walk away thinking the vulnerability was not serious. At the least we now know a good way to convince large swarths of technical folks to not take new vulns seriously! Which seems not good |
|
| ▲ | syshyk 8 hours ago | parent | prev | next [-] |
| The main kickback was against the hype and it was "so easy for AI" and would take "15 minutes to compromise everything". Either way, this was not true. |
| |
| ▲ | vikramkr 7 hours ago | parent | next [-] | | It was true. The author had messed up the server and it was not exploitable. It was hacked within a couple hours of the author fixing it (even with the server being down) but the author had also messed up and not put the actual Bitcoin wallet in it so it took an additional 5 hours for them to fix that. It was a mess but the vulnerability was very real | |
| ▲ | Tadpole9181 8 hours ago | parent | prev [-] | | The author didn't even have an accessible PHP server at first. When they actually added one, it got cracked in 2 hours. | | |
| ▲ | milkshakes 8 hours ago | parent | next [-] | | also it was under hn load which makes this much harder | | |
| ▲ | NorwegianDude 7 hours ago | parent [-] | | HN load isn't exactly a high load for a server. The automated traffic was most likely much higher, but not high, as the server used the super slow single threaded php dev http server, so high traffic was not possible, everyone had to wait their turn. | | |
| ▲ | elysianfields 7 hours ago | parent [-] | | The vulnerabilities kinda rely on having to make quite a number of requests to exploit + can crash the process as I understood, so if many people try to force their way in at once 2h doesnt seems like a long timespan. |
|
| |
| ▲ | jgalt212 7 hours ago | parent | prev [-] | | yes, but 70% of the world's websites were (and many still are) accessible PHP server(s) that hand not been patched. |
|
|
|
| ▲ | 0x457 6 hours ago | parent | prev | next [-] |
| I was trying to steal those, but when I setup my local version, I things a little different: php-fpm and glibc because I thought this how everyone would run php with nginx. PHP-FPM recycled OOM workers, so there were no corrupted state to exploit and then when I switched to "php -s", glibc with ASLR made it not very practical to exploit. Changed my lab to use the same alpine + php = tada working exploit. |
|
| ▲ | howunfortunate 8 hours ago | parent | prev | next [-] |
| To be fair, he hasn't had time to do the write up yet. When he does I fully expect it to hit the front page. |
| |
|
| ▲ | ForHackernews 8 hours ago | parent | prev [-] |
| Two things can be true: 1) A motivated human eager for $500 and internet cred can exploit a vuln (perhaps using AI tooling to help) 2) The vuln is not easily exploitable at scale by driveby bots. |
| |
| ▲ | NitpickLawyer 8 hours ago | parent | next [-] | | IIUC, the first setup couldn't be exploited because the site didn't run any php. You kinda need the server to run some php if you're gonna use a php vuln. It got solved ~2h after they added a php-version.php ... | | |
| ▲ | ForHackernews 8 hours ago | parent [-] | | FTA: > 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. |
| |
| ▲ | 8 hours ago | parent | prev [-] | | [deleted] |
|