lan turtle – Unix Sec Lab

The Lab – Gear Check – Hak5 Field Kit

I’ve talked about individual pieces that are in the field kit before, including the USB Rubber Ducky, and the LAN Turtle. The Field Kit has both of those, plus lots more.

We’ll start with the stylish zippered case. It has the “Hak5 TRUST YOUR TECHNOLUST” logo on the front. There is also a key ring tag that says “REMOVE BEFORE FLIGHT” on one side and “TRUST YOUR TECHNOLUST” on the other. I have this attached to the zipper for every day carry use.

Inside are several elastic straps sewn into each side and on the spine. These are positioned to hold various items neatly in place.

The kit includes a DVB-T+DAB+FM USB SDR radio receiver with magnetic mount antenna. I already owned two of these due to my HAM Radio hobby, so having an extra is nice. This can be used in conjunction with GNU Radio (or other software) to receive and decode various signals and digital modes.

It includes a LAN Turtle and USB Rubber Ducky (with all Ducky accessories) which I also already had one of, so spares are nice.

There is a non turtle USB Ethernet Adapter, as well as a USB wireless adapter (with antenna.) These help provide a little extra networking on the go, if needed. They are especially useful in conjunction with a WiFi Pineapple (Nano or Tetra) which did not come with the kit I purchased, but is often an option that can be included.

There is also a USB multi meter for checking voltage/amp and other readings for a USB socket, as well as analyzing how much draw you are generating with your peripherals. If you’re drawing too much, you’ll want to get a beefier power source for your gear, so it’s good to keep an eye on these things.

Finally, an assortment of cables and adapters for USB (including a micro USB to micro USB OTG cable, and self winding Ethernet cable) round out the mix.

I’ve added the battery pack from my WiFi Pineapple Nano to the kit, but the Nano itself stays in its own holster outside of the kit. This way I don’t accidentally take it to work with me.

The kit normally cost around $170 when I bought it, but that kit is no longer available on the site, and I got it at discount when they ran the “Mr Robot” special for the USB Rubber Ducky cameo that aired on that show.

There are several kits available on the shop at this time, and this is the closest one to what I have, but it contains a lot more gear and is priced a bit higher because of it. If you add up the cost of components bought separately, it’s still a good deal, and looks like it’s on sale today. That may change in future.

Hak5 Elite Field Kit

It’s well worth the money if you can afford a kit and want some goodies for your lab. If the link above is dead by the time you get to this, and I haven’t noticed and cleaned it up, here’s the link to their shop with all the various kits that should be available.

Hacker-Tool Hump-Day – LAN Turtle Modules – ddnsc

The Hak5 LAN Turtle has a module for configuring a dynamic DNS client. This module is the “ddnsc” module, and configuration requires four fields to be filled in.

The first is the “Service” field, which is the Dynamic DNS provider service you will use. This might be “no-ip.com” or “dyn.com” or something similar.

The second field is the “Domain” field, which is the domain name you have reserved through the service. Once upon a time, I had DynDNS as a service, and they had a “homeunix.org” domain available. Mine was configured for “abtg.homeunix.org” at the time. I no longer use this service, but that’s an example of what you would need to put into this field.

The third is the “Username” field, which is whatever user name you signed up with your dynamic DNS provider for authentication with their services.

The final field is the “Password” field, which is simply the password you use to authenticate your user against that domain.

Internally, the module uses “uci” commands, which are part of the OpenWRT router project to provide a centralized configuration tool for the router functionality. It also does an “opkg install ddns-scripts” to pull down the standard scripts for this from the OpenWRT repositories.

The module is simple enough, but it provides a great way to get a persistent means of looking up the current external IP to whatever LAN the Turtle has been dropped on, if that network has a dynamic IP address on its WAN side. This way, you can get to your turtle on whatever known open port you have set up for use.

This has been short and sweet, but it has gotten late on me, so that’s the best kind of post I can give for today. Thanks for reading, and leave comments!

Hacker-Tool Hump-Day – Hak5 LAN Turtle module – ptunnel

The next module for the Hak5 LAN Turtle we’ll look at is the ptunnel module. This is for the “ping tunnel” program, which allows tunneling TCP traffic over ICMP. It’s not exactly fast, but it can potentially get you out where other tools won’t.

To use ptunnel, you want a “client” configuration, and a “proxy” configuration. The PROXY must be running somewhere outside of the firewall you’re having issues with, and you must be able to ping the host it is running on. To start the proxy just call “./ptunnel” without any flags. If you test this and it doesn’t work, you can try one or more of the following flags:

If you need packet capturing, use the “-c ” flag with this.
You might want to try it in unprivileged mode first, with the “-u” flag.
You can set an arbitrary password with the “-x ” flag, as well.
Finally, if you want some logging at the proxy side, you can use the “-f ” and “-v ” flags.

Once the proxy is running and waiting for connections, you can use the module on the LAN Turtle to connect to that.
A standard client connection would look like this:
ptunnel -p -lp -da -dp

For example, if we wanted to be able to ssh over ICMP to our proxy box (proxy_server) and our listening port for this is locally set to 443,
and the target to ssh to is the host “server_x” on port “22” because it’s the standard ssh port, we would run this for a client set up:
./ptunnel -p proxy_server -lp 443 -da server_x -dp 22

We would then run ssh like so:
ssh -p 443 localhost

Well, the module has four configuration settings you need to fill in through the module configuration menu.
Those four settings all correspond to the four items we just discussed:
-p Proxy Server – called “PTunnel Host” in the menu
-lp Local Port
-da Destination Address – called “Dst Server” in the menu
-dp Destination Port

Note that there is no configuration for a password here. If you want to use a password on your proxy set up, you’ll need to manually configure that, or modify the turtle script to include it.

There is also no configuration through the Turtle menu to run the Turtle as the proxy host. Only a proxy client. You of course can always run the host yourself from the command line, though.

Again, this isn’t the fastest way to get your packets where they’re going, but it does work well when it works at all.

Also, if you do decide to run this, be responsible. Don’t break out of your corporate firewall if it’s against corporate policy… and it almost assuredly is.

Thanks for reading, and if you liked this or even didn’t like it, leave a comment below!

Hacker-Tool Hump-Day – Hak5 LAN Turtle module – sshfs

There is a very nice program that allows you to use an ssh connection to “mount” a remote directory as if it is local. This program is called “sshfs,” and it sometimes makes things easier from the perspective of needing to copy a lot of files between systems, but not wanting to deal with the scp or sftp commands to do it. The Hak5 LAN Turtle has a module for this, and the primary purpose of this (most likely) is to assist in off loading large files to a remote location. You could use sshfs to remote mount a file system on another machine you control, then configure your ex-filtration tools to dump their payloads to that directory. In essence, the payload would never truly be written to the turtle in the end.

To use this, you need to go to the modules and choose “configure” as you would any module we’ve covered, thus far.

The configuration takes a “Host” a “Port” a “User” and a “Path” as options to be filled in. Since a “Password” is not among the options, you will need to do some preliminary work as well. The ssh keys would need to be generated and configured for the target user at that host.

The “Path” option can be left empty if you just want to use the target user’s home directory for the path.

Once everything is configured, use “Start” to make sure it works, and “Enable” if you want it to persist, as normal.

This module is quite nice consider the very limited space on the LAN Turtle, so play with it. I think you’ll enjoy the benefits.

Thanks for reading!

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.

Hacker-Tool Hump-Day – Lan Turtle Module – autossh

Today, we’ll go over one of the simplest modules provide for the Hak5 LAN Turtle. The “autossh” module is used to create an ssh session from the Turtle out to a pre-designated target server, and use the SSH proxying features to present a port for logging back into the Turtle over this tunneled proxy connection. This can be used in an environment that allows outbound SSH connections to create a connection into the internal LAN via some outside listening system. While there might be legitimate uses for this, make sure you follow corporate policy on such things before taking advantage of this feature on your work network.

To set this up, go to the Turtle shell (menu) and select:
Modules => autossh => CONFIGURE.

There are three fields that need to be filled in. The first is the “User@Host” field, where you put the target user and the target hostname or IP address for logging into the remote system. In order to make that outbound connection, the Turtle needs to know who to login as, and where to login at. This is how you tell it that.

The second field is the “Remote Port” field, and defaults to 2222. This is the port that will get established for the “dial back in via the proxy” tunnel.

The last field is the “Local Port” field, which defaults to port 22 and is fine to leave as is.

After you configure the ports, you can try to use it right away by telling it to “start,” but I generated a key pair and pushed the public key out to the target system from the command line when I tested this. I don’t think it will work without setting up a key manually, first. The Turtle does include “ssh-copy-id” if you prefer to push your key that way, and “ssh-keygen” to generate that key, but the key type should be RSA and use the “id_rsa” default naming scheme. This appears to be hard coded within the module. If you prefer a different key type, you’ll need to modify the module script to call a different key. The script is at /etc/turtle/modules/autossh if you’re looking to customize this.

After you’ve pushed your key and set up the “config” options, you can go back to the Turtle shell (menu) and select the module again, then select “START” instead of “CONFIGURE” to test it. Log into your remote target machine and see if you have a listening port per your “Remote Port” setting (default 2222.) If you do, you can try logging into the Turtle from that machine by doing “ssh -p 2222 root@localhost” (replace 2222 with whatever port number you chose to use if you overrode this default value.) You should be able to connect. If it works as expected, you can go back to the Turtle shell (menu) and select the module one more time, this time to “ENABLE” it. This will make it autossh every time the Turtle is rebooted (or powered on.)

This is equivalent to using the -R flag discussed on Monday.

Disable it when you’re not intending to use it, though. If you’re not getting the expected connection back into the Turtle, make sure there’s not a conflicting service using that “Remote Port” option you chose. If there is, change it to a port that’s not in use. Also check that firewalls aren’t blocking that port per standard troubleshooting techniques (netstat, telnet, etc.)

That’s it for this week, folks. We’ll probably cover another module next week, but with the new kids, the schedule might change without warning.

Thanks for reading!

Hacker-Tool Hump-Day – Hak5 LAN Turtle Part 1

I’m going to spend a few days covering the Hak5 LAN Turtle. I may or may not break these up with some other Hacker-Tool Hump-Day topics, but for today, we’re just going to cover the initial set up of a brand new Turtle.

The first time you plug it into a USB port, you’ll need to wait a moment for it to initialize and present an IP to the host machine. Once an IP has been obtained (in the 172.16.84.x range,) bring up your favorite SSH client (such as PuTTY) and connect to 172.16.84.1 as root. The initial default password is “sh3llz” and the first time you log in you should see a screen prompting you to set a new root password.

Enter the password of your choosing. It will prompt you to repeat the password. Do so, and it will either say it didn’t succeed and start the prompt sequence over, or it will say the password was changed successfully. Hit enter to select “Okay” and move on.

The first thing you should do after setting that initial root password is to check for updates and update the device. It’s a good idea to check for updates regularly, even if they aren’t released often. Select “Config” and hit enter. At the new menu, you can see that you can change the password you just set, change the WAN or the LAN MAC addresses, disable the Turtle Shell, and Check for updates. Use the arrow keys to move down to “Check for updates,” and hit enter. If you don’t have the ethernet side plugged into a switch that has internet access, this will fail. Don’t forget to plug that cable in.

If an update is available, it will download and verify the update files, update the LAN Turtle with a warning that it could take about 5 minutes, and a note that the Turtle will reboot after updates. It will then kick you out of the SSH session. Just wait for it to update, and keep an eye on the yellow flashy light.

Once it’s been updated, you can restart your session. The HOST keys will have changed, so you should get a warning about that if you aren’t suppressing those, and after you accept the new keys, you will need to login with the default sh3llz again. It will prompt you to change that password (again) so do so at this time. If you go back through the “Config” and “Check” menus again, you should see that there are now no new updates at this time.

I don’t recommend Disabling the turtle shell unless and until you have things set up the way you want, but if you do, you can always get back to the turtle menu by calling “turtle” from the command line.

The next step is to back out to the main menu and pick your modules through the “Module configuration” menu option. The first time you go into this menu, the only option you can select is the “Module Manager.” Select this and choose “Configure.” The next menu should let you choose which modules you’d like to install (“Directory”) or which ones to delete (“Delete”) as well as updating all installed modules via “Update.” Just like the initial update of the Turtle itself, these actions require an internet capable connection to be plugged into the Ethernet side of the Turtle.

We will go over each of the modules over time, but for now you know where this is at and you can select any you would like to play with. The “Cron” module is not necessary for the “at” command, as that appears to be installed already by default.

After you’ve selected all of the modules you want (and you can select all of them… at the time of this writing, they all fit with some space to spare…) install them and then back out of the menu to the Main menu again. Now select “Exit” to drop to the command line.

The Module Manager from the Turtle menu shell is good for pre-packaged installation and configuration of stuff, but you can also install packages that may not be part of a module from the command line. The LAN Turtle is a MIPS based OpenWRT build, and thus any packages compiled for that platform -should- work for the Turtle, assuming the binary fits in the limited file system space provided. The device appears to have 40 megs total, 30 of which are assigned to /tmp as a tmpfs file system. This means 30 megs are volatile. This still shouldn’t be a problem if you select your packages carefully.

The package type for OpenWRT devices is a “.ipk” file, and you manage the packages from the command line using the “opkg” command. The “opkg list” command claims to list available packages, but seems to list installed ones instead. The “opkg list-installed” is supposed to list installed packages, but returns nothing. To fix this, you need to run an initial “opkg update” first, which will grab the repository lists and update the local opkg database with the installed information. The “opkg search” command works as advertised with or without that initial update, so you can find out what command belongs to what package. For example, “opkg search ‘*ps'” returns “busybox – ” which means ps is part of the busybox package. If you’re a fan of multiplexers, there is a package for both “screen” and “tmux.” The “tmux” binary is slightly smaller than the “screen” one and is actually my preferred multiplexer. Alas, there was no package for “dsh.” I may choose to attempt a build of this down the road, because this is an incredibly useful tool. If I do this, I’ll document the process here as well as document turning it into an official Turtle module that could be selected from the Module Manager in the Turtle menu shell.

From a Systems Administration perspective, this device does a few things. It provides a handy USB ethernet adapter if all modules are turned off. It also provides a slimmed down linux environment reminiscent of a Raspberry Pi, BeagleBone Black, or similar, with a smaller form factor, but at the cost of losing some computing power. This is good for providing a quick environment where a VM would be overkill and you’re stuck with a Windows machine as your workstation. Just be aware that your Corporate Security team may take exception to you using such a device, even if no hostile modules are installed. Make sure you are transparent and work things out with them before plugging a “rogue” device into the network in a corporate environment.

Some of the more useful SysAdmin related tools in the Module Manager are “autossh,” “sshfs,” “clomac (if the network is locked down by MAC,)” and “cron” for obvious reasons. I’ll cover each module available over time, and explain the “Configure,” “Start/Stop,” and “Enable/Disable” menu options for each in their own articles. This way each gets the right amount of focus.

Thanks for reading, and if you like this kind of thing, check out the forums at Hak5 to see the latest discussion.