I was presented with an interesting piece of python code:
It seems this originally came from: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion
It sparked a very interesting discussion in a Discord server I belong to about the mechanisms that create the temporary file upon using POST to upload with recursive file inclusion. It captured my attention and I had to see it work.
After many iterations of code, and changing combinations to permutations(order is very important here), I developed a method and made it work.
For the file upload to make a file in /tmp on the server, you must have LFI using the POST verb and recursive file inclusion. The easiest way to achieve this is with a browser. Tweak your php reverse shell from http://pentestmonkey.net/tools/web-shells/php-reverse-shell. Then go to developer>network>reload and change the verb to POST after shell upload to this vulnerable code.
Your browser will look something like this.
This will create a file that will look something like /tmp/php1k4i50. The following python code will exploit your uploaded shell if you have a lot of patience. I do mean a lot of patience.
In conclusion, the basic theory is sound, but the original code we were debating will not work. In order to get LFI on POST, I had to use php5, php7.3 would not work for me even with changing configurations in the php.ini file. Without recursive LFI on POST the tmp file will be purged just after creation, with recursive LFI, the tmp file will remain until reboot or discovery. Don't forget to have a netcat instance listening for when the python code hits your shell. Practical? I think as long as people use insecure, deprecated versions of php, this race against reboot and tmp file purging can lead to RCE. Of course the more shells you upload the faster the process will be, I will make a subsequent post when I automate the shell upload.
One of my previous conclusions was really off, "of course the more shells you upload the faster…" First, the original exploit has you uploading 4096 . . .