Sunday, October 15, 2017

Port Redirection with RINETD to HTTP and Remote Desktop Protocol servers


PORT REDIRECTION WITH RINETD TO HTTP SERVER AND REMOTE DESKTOP PROTOCOL SERVERS

- Layout for this exercise:




1 - Introduction

rinetd redirects connections from one IP address and port to another with basic IP based access control.

- rinetd is a single process server which handles any number of connections to the address/port pairs specified in the file /etc/rinetd.conf

- Since rinetd runs as a single process using nonblocking I/O, it is able to redirect a large number of connections without a severe impact on the machine. 

- This makes it practical to run services on machines inside an IP masquerading firewall.


2 - Port redirection to HTTP server

- Installing the service rinetd at the Kali Linux machine:



- Editing /etc/rinetd.conf:





- The configuration parameters are:

bindadress          = 192.168.1.27 (Kali Linux)
bindport               = 3333 (redirected port at Kali Linux)
connectaddress  = 192.168.1.15 (CentOS where the HTTP server is enabled)
connectport         = 80 (HTTP port at CentOS)


- Restarting the service rinetd:




- Now, connecting normally to 192.168.1.27 (port 80) the Apache Server home page at Kali Linux is displayed:




- However, when connecting to port 3333 (192.168.1.27:3333) there is a redirection to the Apache Server located at CentOS Linux machine:




- Running netstat at Kali Linux, the redirected connection from Kali Linux local port 3333 to remote CentOS port 80 is displayed:




- It is interesting to notice that the CentOS Linux HTTP server does not have any news from its "hidden client" Windows 7 (192.168.1.6), because the only "connection" to its port 80 detected by netstat  is the one coming from the proxy Kali Linux (192.168.1.27):






3 - Port redirection to Remote Desktop Protocol server

- Editing again /etc/rinetd.conf:




- The configuration parameters are:

bindadress          = 192.168.1.27 (Kali Linux)
bindport               = 5555 (redirected port at Kali Linux)
connectaddress  = 192.168.1.24 (Windows Server 2008 where RDP server is enabled)
connectport         = 3389 (RDP port at Windows Server 2008)


- Restarting the service rinetd:




- Connecting from Windows 5 with RDP to Kali Linux trough port 5555:




- Authenticating:



- The RDP connection to 192.168.1.24 (Windows 2008) is successful, but let's notice that the connection is being redirected trough 192.168.1.27:5555 (Kali Linux Machine):





- Running netstat at Kali Linux, the redirected connection from local port 5555 to remote port 3389 is displayed:



- Interestingly, running netstat shows that  Windows 2008 is totally unware of the "hidden client" Windows 7 (192.168.1.6) that originated and actually is taken advantage of the RDP connectionIn other words, the only connection detected by Windows 2008 is from the proxy Kali Linux (192.168.1.27):









SSH Tunneling (III): DYNAMIC port forwarding with PROXYCHAINS


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 (II): REMOTE port forwarding


SSH TUNNELING (II): REMOTE PORT FORWARDING

- Layout for this exercise:




* This exercise is a continuation of the previous one

http://www.whitelist1.com/2017/10/ssh-tunneling-i-local-port-forwarding.html


1 - Exploiting Windows 7


- First of all Kali detects that Windows 7 has the vulnerable BadBlue service running on port 80:




- Exploiting the Windows 7 device with Metasploit:






2 - SSH Tunneling with REMOTE port forwarding

- Checking that Windows 7 is listening on port 3389 (Remote Desktop Protocol):




- In the same way, Kali detects that port 3389 is open:




- Plink.exe is a command-line connection tool typically used with the SSH protocol to enable to talk directly to a program running on the server: 

https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter7.html


- In case of not being present at the Windows 7 (it is included with PuTTY), plink.exe could be passed from the attacker Kali following these instructions:

http://www.whitelist1.com/2017/10/file-transfers-post-exploitation-with.html




- plink.exe help us to create a reverse SSH tunnel, exposing the RDP port on Kali's at port 3390:




- Let's see what are the parameters used in the previous command:


plink                                   <- enables ssh connection
-l root -pw rootpassword    <- user and password
192.168.1.27                      <- attacker Kali
-R                                       <- remote option
3390                                   <- local port at Kali
127.0.0.1                            <- localhost Kali
3389                                   <- remote port at Windows 7


- Once the tunnel is created, we need another terminal for opening an RDP session:





- The new RDP session is created for user marie and her password:




- Finally the attack is successful, because Kali has got an RDP session available in its own desktop:





3 - Analyzing ESTABLISHED connections and corresponding ports with netstat

- Let's check what connections are ESTABLISHED at Windows7 and what corresponding ports are implied:




- Same information (symmetrical) from Kali:











- There is one connection from Kali to Windows 7 on port 3389 (RDP)




There is a second connection from Kali to Windows 7 on port 4444 (Metasploit):




There is a third connection from Kali to Windows 7 on port 22 (SSH):












SSH Tunneling (I): LOCAL port forwarding


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.