Skip to content

GitHub: https://github.com/BTtea/CVE-2024-4577-RCE-PoC


While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows operating system. This oversight allows unauthenticated attackers to bypass the previous protection of CVE-2012-1823 by specific character sequences. Arbitrary code can be executed on remote PHP servers through the argument injection attack.

This PoC is for learning and research purposes only. Do not use it for illegal activities; you are solely responsible for any legal consequences.

This vulnerability was found by Orange Tsai (@orange_8361) of DEVCORE (@d3vc0r3). Make sure to follow his outstanding research, our role was to only recreate and develop the exploit for this issue.

  • Why is it necessary to rewrite the exploit script when there are already many publicly available PoCs online?
    1. Since many publicly available PoCs are based on the same original exploit, many vendors have used these PoCs as references and blocked certain keywords to prevent their exploitation. However, they often overlook blocking all potential exploit vectors. To address this, the script includes a simple mechanism for generating random parameters, as well as different LFI-to-RCE exploitation methods, to enhance the success rate of PHP CGI injection leading to RCE.
    2. During a test where I was attempting to reproduce an environmental vulnerability, I discovered that my PoC consistently triggered an HTTP 500 error, regardless of adjustments. Since I was working in a vulnerable environment, I started investigating the cause of the error. Then, I recalled an article by Devcore mentioning that, in certain exploit scenarios, the server would return an HTTP 500 error, even though the RCE exploit was actually successful. With this in mind, I decided to test whether I could spawn calc.exe locally, and to my surprise, it worked—it was a blind RCE!However, when I checked the Apache error log, I found an error referencing allow_url_include, despite the fact that the attack had executed successfully (and I still don't fully understand the root cause; if you have insights, please contact me). This led me to create an exploit that includes an option to test for blind RCE as well😊.
    3. If your target is an operating system version prior to Windows 7, you can still escalate to a visible RCE or reverse shell through other methods. However, these techniques are outside the scope of this article, so we won’t go into detail. As a penetration tester or red team specialist, you should be able to find alternative solutions fairly quickly, which can be an interesting process😉.
  • Updated on November 15, 2024Due to work requirements, I have continued improving the script to make it as compatible as possible with all environments and maximize the chances of achieving RCE. This effort was driven by the fact that some targets could not successfully execute PHP using many public PoCs. Eventually, I unexpectedly resolved this issue, managing to overcome nearly all cases where error 500 occurred and successfully displayed the execution results of PHP. As a result, blind RCE no longer seemed as critical. 😧

Vulnerability PoC

  • Exploitation conditions
    • This PoC only tests exploitation of php-cgi.exe.
    • The target is using XAMPP service and has not patched the vulnerability.
    • The target server is running a vulnerable PHP version.
      • PHP 8.3 < 8.3.8
      • PHP 8.2 < 8.2.20
      • PHP 8.1 < 8.1.29
  • You need to install the dependencies:
    • $ python3 -m pip install requests

Run the script directly to get usage instructions. You can run the command below to verify if the target is vulnerable.

$ python3 CVE-2024-4577.py <target> <php shell>

If the exploit exists on the target, you can save the PHP execution results locally, which is helpful for those who need to view phpinfo.

$ python3 CVE-2024-4577.py <target> "phpinfo()" --save info.html

Blind RCE

When the target is vulnerable to blind RCE, the script will attempt to listen on a local port and trigger the target server to execute PHP, sending a request to verify the existence of the exploit. When the request is received, it indicates that the target server has successfully executed the command. 

References

Latest