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.