The Lab – Gear Check – Hak5 Bash Bunny – Serial

The last attack mode we haven’t covered is the SERIAL mode. This mode presents a serial device to the “victim” machine, which can be connected to via any standard serial console software tool. On Windows machines, PuTTY can handle serial connections. For Unix and Linux systems, a variety of options exist including the traditional “cu” and “tip” command line programs, “screen” (the tool used in Hak5 examples,) “kermit,” “minicom,” and so on. If you have a tool you’re comfortable with, you might stick a statically compiled version of it onto the drive and access it via the STORAGE mode using a HID mode control mechanism, perhaps.

There isn’t as much use for this, given the complexity it presents, except where the network is blocked by some kind of corporate software control, but serial is not. It seems more like a niche attack vector, but it’s better to have it available than not.

As you should be aware if you have experience connecting to serial consoles, a serial connection has some control setting that need to be set correctly before a serial session can be reliably established. The settings for the Bash Bunny’s serial session are as follows:

Baud Rate: 115200
Data Bits: 8
Parity Bit: No
Stop Bit: 1

This is often abbreviated as 115200/8N1 for some serial console software.

Again, it is almost always going to be easier to just use one of the network based attack modes, and ssh to the Bunny using plink (Windows) or openssh (Unix/Linux.)

The Lab – Gear Check – Hak5 Bash Bunny – Network

There are two different network attack modes that come with the Bash Bunny.  Only one of these should be used at a time, since they conflict.  The difference is the type of device it presents when active.

ECM_ETHERNET presents an Ethernet Control Model device, which is more useful when the target is Linux, Mac, or Android.  Probably other unix like systems, but testing will vet this out.

RNDIS_ETHERNET presents a Remote Network Driver Interface Specification device.  This is more useful on Windows, but will work on some Linux distributions.

Both of these present a gigabit false network to the “victim” machine, complete with DHCP server which serves up an IP in the 172.16.64.10 to 172.16.64.12 range.  The IP address of the Bunny itself will be 172.16.64.1 to act as a gateway device.  Presenting this fake network is much like the connection you get from plugging a LAN Turtle into that USB port.  The LAN turtle presents a network, whether it bridges through to a plugged in RJ45 connection or not.  The Bash Bunny’s fake network is faster, however.

If you’re intended attack does not need to be connected to an actual network, the Bash Bunny will likely be a superior option.  If it needs to act as a man in the middle bridged network, the LAN Turtle is the superior option.  You can still tie networking in a host shared internet setup with the Bash Bunny, and instructions are provided to do so, but this requires a bit more work to get set up correctly.  To do this “manually” might take some time.  Of course, you could possibly combine attack modes and use a Ducky script to run some of the commands needed to set this up, as well.

You can connect to the Bash Bunny with SSH while it is in one of these two network attack modes.  The default root password is “hak5bunny” and root is able to do direct SSH login.  This is probably easier to use than the SERIAL mode we will cover next week.

The Lab – Gear Check – Hak5 Bash Bunny – Storage

Sorry for the late edition.  I got my days mixed up, yesterday.  This week had two Mondays in it, as far as my brain could tell.  I got the short end of the stick on that.

This week, we’re going very quickly look at the “STORAGE” Attack Mode on the Bash Bunny.

This is what it looks like when I plug my Bash Bunny into a Linux Mint 17 laptop:

[ 4966.425800] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[ 4966.444695] usb 3-1: New USB device found, idVendor=f000, idProduct=fff0
[ 4966.444707] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=7
[ 4966.444713] usb 3-1: Product: RNDIS/Ethernet Gadget
[ 4966.444718] usb 3-1: Manufacturer: Linux 3.4.39 with sunxi_usb_udc
[ 4966.444722] usb 3-1: SerialNumber: ch000001
[ 4966.615123] cdc_acm 3-1:2.0: This device cannot do calls on its own. It is not a modem.
[ 4966.615169] cdc_acm 3-1:2.0: ttyACM0: USB ACM device
[ 4966.615800] usbcore: registered new interface driver cdc_acm
[ 4966.615802] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 4966.618621] usb-storage 3-1:2.2: USB Mass Storage device detected
[ 4966.618795] scsi6 : usb-storage 3-1:2.2
[ 4966.618891] usbcore: registered new interface driver usb-storage
[ 4971.629404] scsi 6:0:0:0: Direct-Access                               0000 PQ: 0 ANSI: 2
[ 4971.629670] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 4971.630115] sd 6:0:0:0: [sdb] 4194304 512-byte logical blocks: (2.14 GB/2.00 GiB)
[ 4971.630264] sd 6:0:0:0: [sdb] Write Protect is off
[ 4971.630266] sd 6:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[ 4971.630405] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 4971.631847]  sdb:
[ 4971.632512] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 4973.119396] FAT-fs (sdb): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

When we put a payload into Attack Mode STORAGE, the drive presents a 2G drive to the system.  This looks just like the drive that gets presented when plugging the Bash Bunny in via Arming Mode.

This is useful for some attacks, such as what the TwinDuck firmware the USB Rubber Ducky provides, where we use both STORAGE and HID Attack Modes, then use Ducky commands to bring up a command prompt of some sort, type some commands to figure out where our drive is at, and drop files to that location.  This kind of attack is becoming less useful with corporate policies that prevent the use of USB thumb drives, these days, but the Bunny has another way to do this same kind of thing.  We’ll look at that next week when we introduce the networked attack modes.

The Lab – Gearcheck – Hak5 Bash Bunny – Ducky Mode

The Bash Bunny is a versatile USB tool.  It comes with several “Attack Modes” which actually are instructions to enable certain devices it should present to the “victim” machine.

The “Attack Modes” are SERIAL, ECM_ETHERNET, RNDIS_ETHERNET, STORAGE, and HID.  Today, we’re going to look specifically at the “HID” type.

Since the Bash Bunny expects a payload in order to perform its duties, we need to create a payload file.  This will be a file actually named “payload.txt” located in one of the switch directories under the payloads directory of the device.

In order to play with this, we’ll present two different payload files that do essentially the same thing, but will identify which switch folder the payload came from.  This will let us validate that the switch positions labeled by the documentation match the “switch” folder name on the device itself.

Our first payload will be located under the “switch1” folder, and our second under the “switch2” folder.  The payloads are below.

#Payload1 = switch1/payload.txt
ATTACKMODE HID
QUACK STRING I am on switch one!

#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK STRING I am on switch two
!

After saving both of these, we can unplug the Bash Bunny, click the switch one notch (to the documented “switch2” position,) bring up a notepad or other scratch space typing field, and plug it back in.  We wait a few seconds for the Bunny to initialize/boot, and then we see “I am on switch two!” as we expect to see.

Unplug, click the switch one more notch (to the documented “switch1” position,) and do the same wait for boot, and finally we get “I am on switch one!” as we expected.

If we have a more elaborate DUCKY script we would like to use, we can put that into a file to itself, and change our “QUACK” command to call that file.

#Ducky Script1 = switch1/ducky_payload.txt
#Payload1 = switch1/payload.txt
ATTACKMODE HID
QUACK ducky_payload.txt

#Ducky Script2 = switch2/ducky_payload.txt
#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK switch2/ducky_payload.txt

In the examples above, the first payload does not work, but the second payload, does.  This means the “switch#/<filename>” format is necessary in order to load that DUCKY script file.  These are things that need to be considered when working with the Bunny payloads.

These example payloads just mimic the USB Rubber Ducky at this point.  The LED wasn’t manipulated in these examples.  There is no feedback other than the keyboard, and we didn’t utilize any other devices.  The wait time to boot makes this a poor choice when speed is of the essence, so this definitely does not replace the USB Rubber Ducky for straight up HID attacks.  It does, however, provide the ability to produce more feedback (by way of blinking/solid/different colors on the LED) as well as the ability to carry two different payloads without having to “reload” the device by updating the “inject.bin” file in between.  It is easier to use, since the DUCKY script doesn’t have to be converted into an “inject.bin” to begin with.  Once we throw in some other Attack Modes, we’ll be able to do some more elaborate payloads to carry out our needs.

It also has some flexibility in that you can use  “QUACK STRING” followed by a “bash” variable, or a command, in order to see output from such.  You could use this functionality to use a network based attack mode to generate a “loot” file, then follow it up with a HID attack mode to pull up a text editor, and type the contents of the “loot” file for immediate display, if you so desired.

#Ducky Script2 = switch2/ducky_payload.txt
#Payload2 = switch2/payload.txt
ATTACKMODE HID
QUACK STRING $( ls /root/udisk )

One caveat with this is that using “QUACK” with any combination of “switch” followed by “.txt” (no matter what the characters are in between) causes it to NOT display that string.  It seems like a bug, since “QUACK STRING” shouldn’t care what comes after it, but “QUACK switch1/<filename.txt>” matters for loading from a file.  I think it should do a “QUACK STRING” check before it does any decision making on whether to try to load a file, and if it’s not “STRING” then consider the file name from there, but I haven’t looked at the code (if it’s available) to see if there’s an easy fix to offer.

Next week, we’ll look at the STORAGE Attack Mode.

The Lab – Gearcheck – Hak5 Bash Bunny

Anyone who has hung around this blog for a while should know by now that I’m a fan of the Hak5 gear.  The newest gadget gizmo of “gosh, did I do that” to be released is the Bash Bunny.  This is a USB device that offers more sophisticated attacks than the hard coded USB Rubber Ducky, but also acts as storage like the TwinDuck firmware, as well as behaving as a network device like the LAN Turtle.  You can choose multiple “attack modes” to define your payload, and bring home the loot.

bash-bunny

The Bunny is slightly larger (wider) than a typical USB thumb drive, and doesn’t look like a generic drive.  It also runs a full blown Debian Linux installation under the hood, so it takes a few seconds to boot.  And at twice the price of a USB rubber ducky (and then some,) it definitely doesn’t wedge the Ducky out completely.  The Ducky still works much faster upon plugin, and has that “I’m just a drive, you can TRUST me” look to it that the Bunny may never have.

The Bunny’s network capabilities are also are just a facade to allow for a few network type attacks against the victim computer.  In order for the Bunny to reach the internet, it has to trick the victim computer into letting it piggy back.  The LAN Turtle doesn’t rely on the “victim” host in order to do stuff on the rest of the network, so it also is not squeezed out of its niche.

Where the Bunny shines, though, is being able to coordinate multiple “attack modes” to gain trust as a HID or as a New Network, and then use combined “bunny script” and full blown Bash logic to determine what steps to take.  It suddenly provides flexibility in how to react to an initial command.

For example, you could have it do an “nmap” against the victim computer, then process the results to do multiple other attempts at gaining information/drop a shell/whatever based on the results.

How does this work?  There is a switch on the side that has three positions.  The one closest to the USB plug is switch 3 (“arming” mode,) which loads the Bunny as a storage device, so you can upload files to the payloads directories as needed.  The other two are “switch 1” and “switch 2” so that you can have more than one payload option at hand without having to re-arm between payload attempts.  If you built a “Windows” payload on “switch 1” and a “Linux” payload on “switch 2” you just set it to the appropriate switch before plugging in and exfiltrating … I mean “running an involuntary backup” on the data.

The LED is also multi-color, and you can program it to display the color as well as hold solid or blink based on where you’re at in your payload.  This gives you immediate visual feedback, and that makes it easy to tell what step you’re at when you suddenly find you need to snatch the device and leave because unexpected visitors just showed up while you were “helping their data along.”

In all seriousness, though, as a legitimate admin tool, this ranks above the Ducky as far as being able to drop customized long HID scripts onto a virtual machine console that doesn’t take “copy/paste.”  With the Ducky, you would have to code in pauses like little “sleep” statements, and just trust that the next step is going to be what you expect it to be.  With this, you have Bash to let you do some logic before deciding on what to do next.  It’s not the same as an old fashioned Expect script, but it gives some of the same power.

At least, in my head it does.  I haven’t really had any opportunity to play with it more than to make sure it works since I got it.  My dream is that I can code in some input detection so that something like the “hit caps lock 4 times” on my TwinDuck firmware could be used to trigger “the next step” of the payload without it just moving on on its own.  I’m going to do some payload testing and post the examples here in later Gearcheck posts.

 

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.

Hak5 Field Kit 1
Hak5 Field Kit 1

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.

Hak5 Field Kit 2
Hak5 Field Kit 2

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.