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.

Sudo Policy Fixes and Fails – The Host_Alias

Last week we looked at the User_Alias label.  This week, we’re going to look at the Host_Alias label.  Within a policy line, the “Host_Alias” is the next section of that policy.  This dictates on which systems/servers this policy will be allowed to run.

When the policy is unique to each server, is not maintained as a centralized monolithic structure that gets shared out to all end points, or isn’t stored in a database such as LDAP, the usual default is the “ALL” entry.  This simplifies figuring out which items to put here for a given server.  It may seem like that answer is simple, but in reality, it’s not, due to the way sudo checks the host when called to execute a policy request.

What do I mean by that?  The below snippet from the sudoers man page addresses this better than my own words ever could.

A Host_List is made up of one or more host names, IP addresses, network numbers, netgroups (prefixed with ‘+’) and other aliases.

If you do not specify a netmask along with the network number, sudo will query each of the local host's network interfaces and, if the network number corresponds to one of the hosts's network interfaces, the corresponding netmask will be used.  The netmask may be specified either in standard IP address notation (e.g. or ffff:ffff:ffff:ffff::), or CIDR notation (number of bits, e.g. 24 or 64).  A host name may include shell-style wildcards (see the Wildcards section below), but unless the host name command on your machine returns the fully qualified host name, you'll need to use the fqdn option for wildcards to be useful.  Note that sudo only inspects actual network interfaces; this means that IP address (localhost) will never match.  Also, the host name “localhost” will only match if that is the actual host name, which is usually only the case for non-networked systems.

As you can see, there is some reliance upon what the “host name” command returns, whether an IP is ever checked based on the actual network interfaces configured, and so on.  The loopback interface is never checked.  It is recommended to create a test policy with different Host_Alias entries that LOOK like they should work before making any assumptions about how your policy will actually behave once installed.  If you frequently change the IP address(es) of your systems, a host name is preferred.  If you change the name frequently, such as during a migration or similar, setting policy by IP might be better for your environment.  Or maybe the name is better, and you include the name change inside your distributed monolithic policy file, or LDAP entry, or what have you.  In the end, you need to figure out what will work best for your environment and be consistent with how you handle things.  It doesn’t hurt to use both host name and IP in a policy, so you can set your alias label for either, or both.

Also, you can do negation with this just as you can with User_Alias entries.  You could say “ALL, !” to make this apply to any system that isn’t “” (for example.)

The Host_Alias label is less important to change from the almighty “ALL” if you aren’t doing some kind of distributed shared policy, but if you get to more than a few end point servers that are not identical use case machines, you will eventually want to consider such a move.  This is why it is important to learn how the Host_Alias actually behaves for policy on each machine, and test your policy to be sure it does what you expect.

Next week we’ll cover Runas_Alias, as it is the next section of a policy line.

Thanks for reading!