Reverse Shells

Image
>  A reverse shell is a shell session established on a connection that is initiated from a remote machine, not from the localhost. Attackers who successfully exploit a remote command execution vulnerability can use a reverse shell to obtain an interactive shell session on the target machine and continue their attack. A reverse shell (also called a connect-back shell) can also be the only way to gain remote shell access across a NAT or firewall. Let’s see how reverse shells work in practice and what you can do to prevent them. How a Reverse Shell Works To establish a typical remote shell, a machine controlled by the attacker connects to a remote network host and requests a shell session – this is called a bind shell. But what if the remote host is not directly accessible, for example, because it has no public IP or is protected by a firewall? In this situation, a reverse shell might be used, where the target machine initiates an outgoing connection to a listening network host,

Installing I2P Service

 The I2P service is pretty simple to install, simply use the apt repository

Gather the binaries

$ sudo apt-add-repository ppa:i2p-maintainers/i2p
$ sudo apt-get update
$ sudo apt-get install i2p

Once installed we can ensure it is running…

system status i2p.service

Basic config tweaks

Assuming that worked, the first thing we will want to do is to familiarize ourselves with the router config. The preferred way to do this is through the router console served on the localhost. Since our VM is tiny and we have not installed a desktop thus far, we will do this through lynx (or dillo or Seamonkey)

# Pick the browser you want...
# browser="seamonkey"
# browser="dillo"
browser="lynx -cookies"
http_proxy="http://127.0.0.1:4444" \
 no_proxy="127.0.0.1" \
 $browser \
 http://127.0.0.1:7657

The first thing I did was to lower the bandwidth by a factor of 3. Since GCE charges for egress (bytes in), you will want to keep track of this and not go overboard. This can be done manually in /var/lib/i2p/i2p-config/router.config, or at the URI http://127.0.0.1:7657

Next, I changed I2P to point to my existing Lighttpd server instead of spinning up the default Jetty webserver. First, find out what client app is associated with jetty

$ sudo egrep "main=.*jetty" /var/lib/i2p/i2p-config/clients.config
# yields clientApp.3.main=net.i2p.jetty.JettyStart

So, Jetty settings are in client app number 3. Now to prevent Jetty from loading we change its startOnLoad to false.

$ sudo vi /var/lib/i2p/i2p-config/clients.config
clientApp.3.startOnLoad=false # find this line and set it accordingly

Now, without a jetty, we will want to change the target port the tunnel is using to 80 since that is where our webserver is serving.

Find the tunnel using port 7658 (the default jetty port)

grep 7658 /var/lib/i2p/i2p-config/i2ptunnel.config
# yields tunnel.3.targetPort=7658

So in this test config,

$ sudo vi /var/lib/i2p/i2p-config/i2ptunnel.config
tunnel.3.targetPort=80 # find this line and set it accordingly

Open Firewall

Finally, once everything is set up, we can open up our incoming ports to participate fully in the network. First, determine what port to open

$ sudo grep -i port /var/lib/i2p/i2p-config/router.config

Although it isn’t clear from the config file, I2P opens both TCP and UDP ports. You need to enable both. See http://127.0.0.1:7657/confignet for more info.

Create a firewall in GCP for our VM to use that port.

gcloud config set compute/zone {zone}
gcloud compute firewall-rules create i2p-server \
--target-tags=i2p-server \
--allow=udp:{port},tcp:{port} \
--source-ranges=0.0.0.0/0
gcloud compute instances add-tags {vm-name} --tags "i2p-server"

Handle hosts file

At this point, the Lighttpd server is serving up content for both our Clearnet website and our i2p site (website). The website has one extra requirement which is a hosts.txt file. Usually, it is served out of the jetty site, but since we are not using that, we will just make a symlink to the appropriate file. But we will want to ensure we set the permissions appropriately.

$ sudo systemctl stop lighttpd.service
$ sudo systemctl stop i2p.service
$ sudo chown i2psvc:www-data ~i2psvc/i2p-config/eepsite/docroot/hosts.txt
$ sudo ln -s ~i2psvc/i2p-config/eepsite/docroot/hosts.txt ~www-data/html/hosts.txt
$ sudo systemctl start lighttpd.service
$ sudo systemctl start i2p.service

Of course, we will want to change our site build.sh file as well to read

#!/bin/bash
docroot="~www-data/html"
$ sudo -- sh -c "umask 0027; bundle exec jekyll build -d $docroot"
$ sudo chown -R root:www-data $docroot
$ sudo chmod -R g+r,o-rwx,g-w $docroot
$ sudo ln -s ~i2psvc/i2p-config/eepsite/docroot/hosts.txt ~www-data/html/hosts.txt
$ sudo chown i2psvc:www-data ${docroot}/hosts.txt

Final config tweaks

Finally, if you installed Seamonkey in the VM, you can finish the I2P configuration via VNC with the following xterm command

http_proxy="http://127.0.0.1:4444" \
no_proxy="127.0.0.1" \
seamonkey http://127.0.0.1:7657

From within Seamonkey…

Click ‘Router Console’
Click ‘Hidden Service Manager’
Click ‘Start’ for the HTTP Server
Click the config gear next to your I2P HTTP Server
Fill out Name, Description, and pick a ‘.i2p’ hostname
Check ‘Automatically start tunnel …’
Click ‘Save’
Click the config gear next to your I2P HTTP Server (again)
Click ‘Add to local address book’
Click ‘Replace’
Click Back navigation
Click ‘Add to local address book’ (again)
Click ‘Published’ (If you want to publish)
Click ‘Replace’ (If you want to publish)
Exit SeaMonkey
server -kill:1 to stop VNC

Comments

Post a Comment

Popular posts from this blog

OTP Bypassing

Setup Proxychains in Linux