Hacker-Tool – Page 2 – Unix Sec Lab

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

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.

Hacker-Tool Hump-Day – nping

Last week, we looked at a physical device that is usually used in pentests for social engineering (by dropping it in hopes than a curious random person will pick it up, plug it in, and deliver the unexpected payload.) I also showed how it could be used “for good” by a SysAdmin for normal, every day tasks.

This week, we’re going to look at a purely software tool; nping. The nping program is provided by the good folks at the http://nmap.org/ and http://sectools.org/ websites. It is provided by the nmap package, and is often overlooked by the SysAdmin community. Most companies restrict the use of nmap to the corporate security teams, and exclude use of the tool from the daily Unix SysAdmin teams. This is understandable, but if you’re in that situation, you might still find “nping” useful, and your corporate security team might be more willing to sign off on its use for troubleshooting network issues.

Many people make the mistake of thinking that ICMP Pings are great for testing latency. The truth is, they often give a false sense of how much latency exists between one system and another talking TCP for their connections. Many routers and firewalls have QoS settings that can add artificial latency based on protocol, and where ICMP might be blazing fast, TCP might be slow as dirt, and leave you scratching your head as to why. If you use a tool like nping to test your latency instead, you get a truer view of the latency involved.

How does this work?

The nping command will make a handshake request to a given port at a given IP/DNS name a given number of attempts, and then show statistics about the latency from there. There are options that let you change what kind of flags get sent for the handshake, just like with nmap, so you may have to write a wrapper script to get approval from your corporate security team, but as long as you always use the “tcp connect” option, it should do a full blown standard TCP handshake, which would prevent it from setting off any IDS/IPS alarms they may be concerned with.

nping -c 1 –tcp-connect -p 80 server_b.example.com

In the above example, we’re telling nping to make a tcp connect handshake (–tcp) to port 80 (-p 80) at server_b.example.com. We want it to stop after 1 attemp (-c 1.) This will print the time to send the packet, receive the response packet, and the max, min, and average round trip time of all packets:
SENT (0.0031s) Starting TCP Handshake > server_b.example.com:22 (127.0.0.1:22)
RECV (0.0032s) Handshake with server_b.example.com:22 (127.0.0.1:22) completed

Max rtt: 0.053ms | Min rtt: 0.053s | Avg rtt: 0.053s

Since we sent only one handshake attempt, all three “rtt” values will be the same. If we allowed more than one to be sent, we’d see different numbers there.

After the “rtt” values, it tells you how may TCP connection attempts were made, how many were successful, and how many failed.
TCP connection attempts: 1 | Successful connections: 1 | Failed: 0 (0.00%)

I usually like to send 4 to 10 packets and then check the average RTT when troubleshooting latency. Do that in a loop over several minutes (4 to 10 per iteration of the loop) and you start to see how the network is behaving over time. It’s a good tool for every SysAdmin toolbox, so don’t overlook it.

I know that there are some other tools that do similar things, such as Hping2 and Hping3, but nping is pretty straight forward.

If you have tools you’d like to see covered, leave a comment!

Hacker-Tool Hump-Day – USB Rubber Ducky

Every Wednesday (Hump Day) I intend to cover some topic related to hacking, penetration testing, making things do things they maybe weren’t meant to do in general, and so on. Eventually, Mondays will be more like what I envision “Blue Team” mindset should be, and Wednesdays will be more on what I envision “Red Team” mindset should look like. Since I’ve never had the opportunity to be on either kind of team at the place I’ve worked, I won’t say “this is how it is.” So if I use “Red Team/Blue Team” labels, understand this is from my perspective of how I understand them to be, from the outside looking in. I’ve mostly been in a Blue Team type of position (systems administration) but I’ve always tried to look at how to make things work in ways they maybe weren’t meant to work. This has helped me to be sure the stuff I run is run more securely. Any time I come up with a way to bypass, break, or otherwise torture a configuration, I look for ways to plug that hole.

Anyway, on to today’s topic. I’m a fan of Hak5 and the tools they create. Some people take a negative attitude toward them, but I think they’ve helped create some really nice tools for not only aggressive mentalities, but also for defensive ones.

Recently they held a sale in their Hak5 shop in celebration of one of their tools being shown on the show Mr. Robot. The tool in question is the USB Rubber Ducky. I bought one of these last year, and it has been useful from a SysAdmin perspective, so I thought I’d present it as my first topic. I bought one of their zippered kits during the sale, and it should be here by the time the next one of these posts goes live, so I might be covering other items from the kit at that point. I haven’t decided yet. The Ducky is available at the Hak5 shop, at this link:

USB Rubber Ducky Deluxe

So… the USB Rubber Ducky is a device that by default with stock firmware provided by the good folks at Hak5 simply emulates a USB keyboard device when you plug it in. It comes in a case with a swivel key chain piece, and you can take this apart to get to the Ducky internals. You need to do this, to do anything useful with it. The reason is simply this: the device has a microSD card that it reads a payload file from for the purposes of knowing what to “type.” The stock payload isn’t useful for anything more than amusement. You will need to be able to access this microSD card inside to put a useful payload on it. The default firmware doesn’t present a USB storage device for accessing the card, so you will have to take it apart to get that card out.

Take the swivel off, then use a large paperclip or a jewelers/glasses screwdriver to pop the two plastic pieces of the casing apart. There is a hole in the back opposite the USB connector. Just stick it in, give it a light twist, and it should come apart. The microSD card is sometimes stuck pretty good, so you may want a tool to catch the lip of the drive to get leverage for popping it out. It’s not glued in, I promise. The one that came with my first Ducky was 128 meg, so it’s not really useful for much more than keeping a payload on. The Ducky also came with a very small microSD card reader so that you can move your card to it and not have to buy a reader separately to get your payload onto the device. It’s formatted as vFAT, but I’m not sure if it can read the payload from an NTFS formatted card. I intend to test this.

There are alternative firmwares available. The only other one(s) I’ve tried are the Composite ones available as of the time of this writing, and upon initial testing, both seemed to behave identically as far as I could tell. The Composite firmware(s) present the Ducky as both a HID (keyboard) and a USB storage device. There used to be a version that would automatically launch the payload after a set amount of time, but the ones I tested seemed to have that functionality stripped. The version that has “4Cap” in the name lets you hit Caps Lock four times in a row to trigger the payload launch.

I tried the Composite firmware that had “Cap” in the name, expecting the payload to launch. I was disappointed. The only method that worked was actually pushing the button on the Ducky device itself to launch the payload.

I hopped onto the forums to ask about this, and after a few responses from forum members “winter_soldier” and “bored369” I was able to determine that the 4Cap hex file does indeed work as expected… on a Windows workstation. Another hearty “thanks” to winter_soldier and bored369 for the helpful responses on the forums. All of my testing had been done from Linux Mint, and only a press of the button on the Ducky would send the payload, there. I’ll research what the differences are to see if there’s a reason for this difference in behavior. The Mint laptop is a Lenovo ThinkPad W520, and the Windows laptop is a Lenovo Z50. I also noticed that if I do the caps lock key sequence to trigger this on Windows, it works the first time, but then starts flashing red on a second attempt without pulling it and plugging it back in. I can send the payload multiple times from one plug in if I use the button on the Ducky, instead. The button on the Ducky stops working if you use caps sequence to send the payload and it causes the flashing red light. I suspect this may be an error in the logic loop for handling the two different cases. Maybe the source is available for review. I’ll go looking to see if I can find it.

I also intend to try a case mod by drilling two holes into one side of the case. If I put a rod down in the hole to press the button, I won’t need to take the case apart, and if I use a small snip of strand from a novelty toy like the “glowing Christmas trees” you sometimes see on sale during the holidays, I can have a fiber to run down to the indicator light so I can see if it’s working (green) or if something went wrong (red) also without taking it apart.

So besides the actual USB Rubber Ducky, you also need to have a workstation to compile your payloads on, and update the firmware if needed. There are lots of examples of this on the Forums for Windows workstations, but I do my work from a Linux Mint workstation. I grabbed the encoder.jar from:
https://github.com/hak5darren/USB-Rubber-Ducky/tree/master/Encoder

This encoder lets you specify a keyboard layout along with the Ducky Script file. Speaking of the Ducky Script file, you need to write your payload in Ducky Script, then use the encoder to compile it into a binary file that the Ducky reads upon start up. The specific file name should be “inject.bin” for the Ducky to read it. The version of java used to call the encoder should be 7 or higher.

An example test Ducky Script might look like this:

DELAY 1000
STRING #this is a test of my first payload
ENTER

The “DELAY” is in milliseconds, so 1000 is “1 second.” You want a delay of 3 seconds or more with the stock firmware, most likely. Since I already had my Composite firmware in place, and it doesn’t launch until I push the button on the Ducky, I lowered my DELAY.

The “STRING” is the actual typed text that will get sent by the Ducky upon payload execution. Since the return key is a special key, the ENTER directive is needed to emulate that keypress. There are other meta keys that can be emulated. Review the documentation for what all are available, and visit the Forums if you’re having trouble with any of them. I seem to recall seeing a reported known bug about GUI vs. WINDOWS there a while back.

To encode a Ducky Script named “test.ducky” run the following:

java -jar encoder.jar -i ./test.duck -o inject.bin -l us

After you have your payload, copy it to the microSD card, slap the card back into the Ducky, and the next time you plug it in, it should type whatever you told it to type in your script.

If you are bold enough to try out one of the alternative firmwares, visit the Wiki page below for instructions. I used the dfu-programmer software provided as a link from that site from my Mint workstation, and my instructions for getting it compiled will follow.
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Flashing-ducky

I had to install two development libraries first, since configure complained about them being missing:
sudo apt-get install libusb-dev libusb-1.0.0-dev

I still had problems compiling after this, so a little digging around on the internet using the might of my Google-FU, I came across instructions for “fixing” some broken code.

After installing the missing libraries, unpack the tarball:
tar xvfz ./dfu-programmer-0.5.4.tar.gz
cd dfu-programmer-0.5.4

Modify the configure.ac file to change all references of “LDFLAGS” to “LIBS” instead:
sed -i.bak -e ‘s/LDFLAGS/LIBS/g’ ./configure.ac

Run configure:
./configure

Before running make, modify the Makefile in the src directory to move the -lusb flags from LDFLAGS down to LIBS instead. If this sed statement is confusing, ask in the comments and I’ll explain all the pieces, but today’s topic is the Ducky, not “sed.”

sed -i.bak -ne ‘/^LDFLAGS =/{h;s/LDFLAGS = \(.*\)/LIBS = \1/;x;s/LDFLAGS =.*/LDFLAGS =/};/^LIBS = .*/{x;};p’

Now that you’ve “fixed” the problem children, run “make” per normal, and you should have a file “dfu-programmer” in your src directory.

You can grab one of the .hex firmware files from the github wiki links above, and use the following steps to update it.

Take the Ducky out of its case if you haven’t already (or if you haven’t modified the case as I described earlier.)
In order to put the Ducky into “DFU” mode, hold the button down, then insert it into the USB port. If you aren’t holding it down while you insert it, it’ll be in payload mode and will try to type the payload script. Wait a few moments for the Ducky to be recognized by the system, then use the dfu-programmer software to update the firmware as below:

This step isn’t necessary, but the wiki mentions it, so if you want to make a backup of the existing firmware, do this:
sudo ./dfu-programmer at32uc3b1256 dump >dump.bin

Before flashing a new firmware hex file to the Ducky, you need to erase it:
sudo ./dfu-programmer at32uc3b1256 erase

To drop your new firmware in place, use the “flash” command as shown below. I tried both versions of the Composite firmware, so both of these are shown, but you only run it against ONE .hex file. Pick your firmware and flash only that.
sudo ./dfu-programmer at32uc3b1256 flash –suppress-bootloader-mem Composite_Duck_S003.hex
sudo ./dfu-programmer at32uc3b1256 flash –suppress-bootloader-mem Composite_Duck_4cap.hex

Finally, you have to remember to reset the Ducky after a firmware update in order to make it run payloads again.
sudo ./dfu-programmer at32uc3b1256 reset

That’s it. After the firmware is updated, you should be able to remove the Ducky and reinsert it to test functionality. Remember that if you used a firmware like the Composite versions above that requires a push of the Ducky button, you won’t see the payload until you push the button. I recommend using a test payload that doesn’t press a bunch of meta keys, first. Open a text editor, then insert the Ducky. Press the button if needed, but watch that the payload actually gets sent to the text document to verify it is functioning properly.

Hak5 touts this as a device for social engineering by virtue of curiosity. Put your malicious payload on the Ducky, then drop it in a parking lot and wait. Your payload might call up a bunch of commands to offload a Windows password dump to a remote web server, for example. So how does this tool have any kind of legitimate use in a SysAdmin tool kit?

The answer is simple. There are two scenarios where I have personally already found this tool useful from an everyday SysAdmin perspective. The first is when dealing with a console session to a remote server, and the console does not allow copy/paste. When you are dealing with a blind console that doesn’t allow pasting commands into the terminal, you have to be meticulous in your typing. If you know all of the steps you need to get the task accomplished, you can carefully craft that out into a Ducky Script, compile it, and then make that console your focused window before plugging the Ducky in for your “I’m pasting my commands anyway, so take that!” workload.

The other scenario has to do with a long ssh private key passphrase that needed to be stored into an IAM solution, and people were present who should not see this passphrase. Instead of having to start over multiple times, because the laws of nature demand that I mistype the phrase at least four times before getting it right, I was able to put the passphrase into a Ducky Script, take the Ducky to the conference room where the IAM software was being configured, set the focus on the passphrase field in the software, then plug the Ducky in. Or at least, I would have if I’d had the Ducky with me that day. Instead I had to type it out. Multiple times. Because things. Since that was the “development” environment, I’ll be doing the “production” environment with the Ducky next time.

Thanks for reading this, and if you have any ideas on other legitimate uses of the USB Rubber Ducky as an every day SysAdmin tool, share in the comments!