Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add PHP-FPM Underflow RCE module #12863
This module exploits an underflow vulnerability in versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 of PHP-FPM on Nginx. Only servers with certains Nginx + PHP-FPM configurations are exploitable. This is a port of the original neex's exploit code (see refs.). First, it detects the correct parameters (Query String Length and custom header length) needed to trigger code execution. This step determines if the target is actually vulnerable (Check method). Then, the exploit sets a series of PHP INI directives to create a file (/tmp/a) locally on the target, which enables code execution through a query string parameter (?a=). This is used to execute normal payload stagers. Finally, this module does some cleanup by killing local PHP-FPM workers (those are spawned automatically once killed) and removing the created local file (/tmp/a).
Preparing the target:
Running the exploit:
- Add `OperationMaxRetries` option documentation - Add default value to `TARGETURI` and update the documentation - Remove `PosOffset` advanced option and hardcode the value - Update `Description` - Move URI encoding logic to `send_crafted_request` - Refactor `send_crafted_request` to handle the HTTP parameter and final & (%26)
I tested this successfully, it was good approximately 3 out of 5 tries. The other ones were failing with
Interesting, I think the server was probably in a "bad state" after a previous exploitation that didn’t cleanup correctly. I retested with the same dockerfile and I got 100% success. If the cleanup is successful, you should see this status:
In case something went wrong during cleanup, you will have to do it manually:
At this point, you should have a session or a shell, so you can run the cleanup command
However, if you don't have a way to execute commands to cleanup (payload execution also failed), I don't think you can get back to a "good state".
Module is running more reliably with a clean docker environment and an operator who follows instructions. I'll have this landed momentarily, thanks @cdelafuente-r7 !