SSH TUNNELING (III): DYNAMIC PORT FORWARDING WITH PROXYCHAINS
- Layout for this exercise:
1 - Introduction
- Port forwarding via SSH (SSH tunneling) creates a secure connection between a local computer and a remote machine through which services can be relayed.
- Dynamic port forwarding connections are forwarded via the SSH client, then via the SSH server, and finally to several destination servers
- Dynamic port forwarding turns the SSH client into a SOCKS proxy server.
- SOCKS is a protocol for programs to request any Internet connection through a proxy server.
- The -D 8080 option specifies dynamic port forwarding with 8080 as the SOCKS port.
- One of the most common uses for SOCKS is circumvention, allowing traffic to bypass internet filtering to access content that is otherwise blocked.
- In our scenario we will use SOCKS to create a dedicated tunnel between Kali and the Windows Server 2008.
- Proxychains allows to interface with the SOCKS tunnel, piping all data that an application would normally just push out to the network through normal means, through proxychains into the SOCKS tunnel up to Windows Server 2008's internal interface.
https://en.wikipedia.org/wiki/Tunneling_protocol
https://en.wikipedia.org/wiki/SOCKS
http://proxychains.sourceforge.net/howto.html
2 - SSH Dynamic Port Forwarding
- In this scenario we assume that the intermediate Windows Server 2008 (two inferaces: 192.168.1.24 and 10.10.10.1) has been exploited by the attacker Kali Linux (192.168.1.27).
- As part of the post exploitation step we will use the Windows Server 2008 machine as a proxy to attack the internal LAN (10.10.10.0/24), for instance the Windows 7 (10.10.10.2) machine.
- SSH -D (Dynamic) option allows to bind the local port 808:
- Running ssh with -D option against the exploited (so we know some credentials) Windows Server 2008:
- Runnig ipconfig we learn that Windows Server 2008 has got two Ethernet IP addresses, meaning that it is connected to outside trough 192.168.1.24 and to the internal LAN through 10.10.10.1:
3 - Proxychains
- Opening a new Terminal different than the one used for the SSH connection:
- Proxychains allows to perform a port scanning inside the internal LAN 10.10.10.0/24. To simplify, let's scan just the port 3389 (RDP-Remote Desktop Protocol) at the first 10 hosts:
- We have discovered that there is an internal host 10.10.10.2 that is running RDP service on port 3389.
- Now, using proxychains again let's run the rdesktop command for the internal host 10.10.10.2:
- The attack is eventually successful:
4 - Checking the ESTABLISHED connections
- It is interesting to check how each one of the hosts implied "sees" the connections.
- Kali Linux works on the SSH Dynamic SOCKS port 8080, and also it is connected to the port 22 of the Windows 2008 that acts as an SSH server:
- The Windows Server 2008 sees two connections, on the one side the mentioned one with Kali Linux, and on the other side a connection with Windows 7 at port 3389 (RDP):
- Finally, Windows 7 is only aware of its connection with Windows Server 2008, although it is actually Kali (the attacker) who is enjoying the Remote Desktop Connection session:
SSH TUNNELING (I): LOCAL PORT FORWARDING
- Layout for this exercise:
1 - Introduction
- A Secure Shell (SSH) tunnel consists of an encrypted tunnel created through an SSH protocol connection.
- Users may set up SSH tunnels to transfer unencrypted traffic over a network through an encrypted channel.
- To set up a local SSH tunnel, one configures an SSH client to forward a specified local port to a port on the remote machine.
- Once the SSH tunnel has been established, the user can connect to the specified local port to access the network service. The local port does not have to be the same as the remote port.
- SSH tunnels provide a means to bypass firewalls that prohibit certain Internet services so long as a site allows outgoing connections.
https://en.wikipedia.org/wiki/Tunneling_protocol#Secure_Shell_tunneling
- In this exercise we are using 3 Linux machines:
a) Kali Linux 192.168.1.27:
b) Ubuntu Linux 192.168.1.22:
c) CentOS Linux 192.168.1.23:
- From Kali let's check that Ubuntu is running an SSH service:
- From Kali let's check that CentOS is running an HTTP service:
2 - SSH Tunneling with LOCAL port forwarding
- Now, from Kali we establish a SSH tunnel from local port 8080 to the remote port 80 at CentOS (192.168.1.23) tunneling through the Ubuntu (192.168.1.22) device.
- The SSH tunnel connection is successful, as we can check once the Ubuntu's shell is achieved:
- Parameters used in previous command:
ssh <- protocol
192.168.1.22 -p 22 <- SSH server running on port 22
-L 8088 <- local port at Kali
192.168.1.23:80 <- HTTP server running on remote port 80
- Finally from Kali, browsing 127.0.0.1:8080 there is access to the remote web server at CentOS, so the final connection is also successful:
3 - Analyzing connections and corresponding ports with netstat
- It is important to notice that Kali only sees the SSH connection, not the HTTP one, regardless it is actually accessing the web server at CentOS. Using netstat:
- About Ubuntu it is also aware only of the SSH connection with Kali:
- Interestingly, the web server CentOS only recognizes an HTTP connection with Ubuntu ( not with Kali), and is totally unaware of the SSH tunnel from Kali, as the web access_log shows:
- The explanation of these results is that the local port 8080 at Kali redirects the traffic (encrypted with SSH cryptographic protocols) through the outbound SSH tunnel on port 22 to the remote web server.
