HackiNews

• xx_ns
  "No successful PHP2Shell exploits seen so far"... in the wild, specifically in Wiz's honeypot. The vulnerability itself has been successfully exploited, most notably for the "Steal my Bitcoin" challenge [1] as one example.

  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.

  • paxy
    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
      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
        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
          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
      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
      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
        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
        The author didn't even have an accessible PHP server at first. When they actually added one, it got cracked in 2 hours.

        • milkshakes
          also it was under hn load which makes this much harder

          • NorwegianDude
            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
              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.

              • r_lee
                for the single threaded one it's easier from what I can remember
        • jgalt212
          yes, but 70% of the world's websites were (and many still are) accessible PHP server(s) that hand not been patched.
    • 0x457
      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
      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.

      • Topfi
        The person that succeeded already published [0]. Thread is barely active compared with the amount of engagement the challenges announcement received.

        [0] https://news.ycombinator.com/item?id=50237379

    • ForHackernews
      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
        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
          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.

  • cimi_
    More details about stealmybitcoin in LiveOverflow's video: https://www.youtube.com/watch?v=VhNiMWtOutw

    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.

    • rudedogg
      > because it wasn't actually running PHP

      Yea and no, I mean it was an even worse setup than typical, probably because the person setting it up didn’t have php experience or used an LLM that misinterpreted “route requests from nginx to php” or something too literally and set up a hacky solution.

      But my impression isn’t that they set it up in some cheeky way to avoid exploits, it looks like they just asked for nginx to be in front.

      And is “hacked in two hours” fair if they had to make it easy for people because their noob setup ended up not being exploitable?

      Let me know if my read of what happened is wrong.

      • 9029
        It was serving static html https://news.ycombinator.com/item?id=50224916#50234806
  • ericol
    > claims they have an "universal" exploit

    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)

  • nubinetwork
    Just last week companies were saying php2shell has been rampant for months, but if that were the case, wouldn't we all have strange errors in our logs? Something seems fishy to me.

    • minitech
      Which companies? The earliest claim of an exploit attempt in the wild I had heard was October 17th, and that was “extant”, not “rampant”.

      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.

      • nubinetwork
        Amazon said 4 days prior to patch, but I'm pretty sure the other one was cloudflare, I can't find the link in my browser history.

        • minitech
          So was “months” a typo for “4 days” or what?
        • makmanalp
          Both of those are coming from telemetry, and mainly show attempts. Those telemetry are generally heuristic based so they overcount and are most often unsuccessful - it took much layer for actual honeypots to be hit. See my timeline in my other comment if you’re interested in details and extract dates
        • red-iron-pine
          4 days is a month now is it?
    • jagged-chisel
      Should we expect logs from a compromised system to be truthful?

      • smolder
        No, of course not. Covering your tracks by manipulating logs and monitoring tools is stuff any sophisticated attacker would do
      • lambdaone
        Perhaps if those logs were streamed to a non-compromised machine and stored there

        • jagged-chisel
          And how do we know the logs that are emitted are trustworthy?
  • NorwegianDude
    The steal my Bitcoin challenge was nothing like a realistic common PHP setup. It was a extremely unrealistic and stupid setup, using the built in php dev server. It's even explicitly stated that it should never be exposed to the internet.

    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?

    • ericol
      Preach, brother.

      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)

  • nurettin
    What have they done to earn 100% of your trust?
  • [deleted]
    Comment removed.

    • yurishimo
      What does being from a particular country have to do with a verified CVE?

      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.

    • wazzaps
      So was the Intel/Apple-silicon/Nvidia chip your PC is likely using. Consider judging companies based on their actions and not their ethnicity

      • slowin
        Yes, they are also highly suspect. "Israeli" is not an ethnicity. I judge Israeli companies based on their actions, their ideology and their history. There is zero reason to trust an Israeli source. Do so at your own peril.
  • idoubtit
    As far as I know, there has been no proven vulnerability on a modern PHP (production) stack. The "Steal my Bitcoin" challenge was a toy project. The "lab" target used the embedded PHP server (`php -S`) which is for development only.

    > 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.

• pizlonator
  This is all it takes to port PHP to Fil-C and according to our tests this turns all of the exploits into DoS

  https://github.com/pizlonator/fil-c/blob/deluge/projects/php...

  • throwaway800BC
    Awesome that you looked into this!

    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.

  • ericol
    Which tests, and against which PoCs? The public php2shell kits already crash workers on stock 8.4 (8/8 crash, 0/8 shell) — so "turned into DoS" may be the status quo, not your result.

    And firing the OOM is memory_limit working as designed, not exploiting a system.

    Pix, or GTFO.

• denysvitali
  > but these scanners did successfully exploit Adel Karimi's honeypot, which was a likely contributing factor to CISA’s decision to include PHP2Shell in their KEV list.

  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!

• rprouse
  And at the same time Bleeping Computer is saying it has been successfully exploited, https://www.bleepingcomputer.com/news/security/php2shell-sec...

  • devmor
    Bleeping Computer also reported that PHP 6 was among the vulnerable versions. I’m not exactly sold on their verification standards.
• CircuitsFit44
  For teams still working through the patching, the practical first step is an inventory of which internet-facing hosts and containers actually run an affected PHP version, since that list is often incomplete. Patching also does not remove anything already planted, so on exposed hosts it is worth checking web roots and upload directories for new or modified PHP files and reviewing access logs from before the patch date. Honeypot data showing few successful attempts is a useful trend signal, but it says little about whether your own servers were hit.
• makmanalp
  This has been my hyperfixation for the last few days, and I've been trying to keep together a detailed and timestamped timeline of the evolving situation:

  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).

• paaloeye
  Everyday is a zero-day nowadays
• 6_7
  I'm so sorry, exposure is down how many percent?
• [deleted]
  Comment removed.

  • doctoboggan
    Maybe a grey hat should scan for all the vulnerable servers they can find, exploit them, and then patch them.

    • ghostbrainalpha
      That's the definition of a White Hat to me.

      • pizzafeelsright
        If there was a well known company, TrustedExploitAndPatch Inc, that had faces and contact info and dropped an 'oh by the way.txt' file with the details, screen recording, etc. after patching showing they didn't exfil all the coins - would people be happy?

        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."

  • minitech
    - please stop spamming this

    - 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

    • EGreg
      Instead of what patch? I just said this is for those who have NO PATCH AVAILABLE. I guess you need the strawman to make a valid point, though…
• phplovesong
  PHP just sucks so bad.

  • smolder
    It is an old, bad language and interpreter, so it's widely used and lacks an investment of money, effort and talent. Perfect target for exploitation.

    • lenerdenator
      Php is still under active development, and has seen a lot of architectural changes at the language level over the last decade that have seen real benefits.

      Now, imho, it still isn't a good language, but I wouldn't call it "old". It's not COBOL or FORTRAN where the people who wrote a lot of the mission-critical stuff that banks, research labs, hospitals, and government rely on died 20+ years ago.

      A lot of it not receiving investment doesn't come at the language project level, but the individual project level. Accounting likes to pretend that the maintenance portion of the SDLC doesn't exist past a certain point because "what about the shareholders!?" and there are, to date, very few incentives for them to look at the problem in any other way. Let's say you run a Php application that's got Php2Shell vulns and you want to patch it but the only way to do that is to shift major versions, meaning a rewrite of some or all of the code. The code "works fine" according to the bean counters, and there's nothing saying they'll get fined or jailed if a breach occurs as a result, so your project doesn't get funded.