Jump to content

How to defend against the Bunny?


FurtleMcGurtle

Recommended Posts

Hi there,

I've got a presentation/demo of Bash Bunny coming up for some customers.  I'm excited to show some of the payloads such as document slurping and wifi password-stealing, but also interested in talking about how to defend against these kinds of attacks.

I'm thinking the following recommendations make sense:

* Disabling USB ports that aren't needed.

* Implementing screen locks to minimize/eliminate damage from some payloads

* Log Powershell events (I need to research this more as I'd like to understand exactly what / how this is done)

Am I on the right track here?  Any other defensive measures to consider?

Brian

Link to comment
Share on other sites

I think you are on the right track. :ph34r:

1.  Don't make users an admin without requesting it first and even then, limited time.  This makes the user always a user and eliminates any style of attack from running as a local admin since the current logged in user isn't going to be one.

2.  Disable USB for anything but charging.  Even the USB Rubber Ducky, while the script appears to run, it can't write back to the storage card as Mass Storage is blocked.  The keyboard function works but there is effectively no way to offload that payload.  No Email, no FTP, no websites defined as Online Storage are allowed so you are stuck.

3.  Screen locks after X minutes does help.  Sure somebody could scope out your station as you walk away but it helps for the casual observer or whomever is roaming around.  Like a car, they see a locked screen, easier to continue to the next workstation vs messing with that situation.

4.  No Open Wifi and if you do allow it, route clients thru an authentication screen and make it a VPN

5.  Enforce password policy and regular password changes.  Even if somebody got credentials or your Wifi password, changing it on a regular basis helps and keeps any info stolen, useless in 90 days or less.

Link to comment
Share on other sites

Like anything security there isn't one silver bullet to prevent it, you have to layer several controls.

A few possible items:

Controlling physical access is the best approach.  Depending on the office environment require all guests to check in at the front desk, and be escorted at all times.

Its not fool proof since you can spoof it, but blocking the default device IDs.  Whitelist known USB peripherals if and block everything else is a good approach if you can pull it off.

Configure the firewall to treat all new networks as untrusted. I'm not sure how easy it is to do that on Windows Firewall, but most 3rd party AV/firewalls have the ability to go into a protected mode on new networks.

Enable an AV scan when a new USB device is plugged in, scan network drives as well.

Implement 802.1X on your wireless with network access control, so if people get your wifi credentials they still cant join the wifi.

Restrict unsigned powershell scripts.

Link to comment
Share on other sites

11 hours ago, mda1125 said:

I think you are on the right track. :ph34r:

1.  Don't make users an admin without requesting it first and even then, limited time.  This makes the user always a user and eliminates any style of attack from running as a local admin since the current logged in user isn't going to be one.

2.  Disable USB for anything but charging.  Even the USB Rubber Ducky, while the script appears to run, it can't write back to the storage card as Mass Storage is blocked.  The keyboard function works but there is effectively no way to offload that payload.  No Email, no FTP, no websites defined as Online Storage are allowed so you are stuck.

3.  Screen locks after X minutes does help.  Sure somebody could scope out your station as you walk away but it helps for the casual observer or whomever is roaming around.  Like a car, they see a locked screen, easier to continue to the next workstation vs messing with that situation.

4.  No Open Wifi and if you do allow it, route clients thru an authentication screen and make it a VPN

5.  Enforce password policy and regular password changes.  Even if somebody got credentials or your Wifi password, changing it on a regular basis helps and keeps any info stolen, useless in 90 days or less.

Part 2 will only work against payloads using the Mass Storage. I can easily create a server that can store the files without showing the file system (offline storage) or I can shoot them over a webserver across the internet using the computer's internet.

Part 1 is good, if you have a main admin account with every other user piggybacking off of that (even if all the users know the admin password) it will still be more secure because any HID attacks will not be able to pass it unless they know the password (ALT+Y will just cause a password incorrect error).

Part 3 is also good, self-explanatory.

Part 4 I don't think will change a huge amount, as (more than likely) the user will already be connected and the BashBunny can run a server that uses the client's internet (e.g. any requests made by the BashBunny actually force the client to request for the information, which means the client is requesting using it's internet - clever I know).

Part 5 is good, and should be done anyway, really.

Link to comment
Share on other sites

14 hours ago, LowValueTarget said:

Fill the USB ports with cement. :)

This is the best way to go.

Realistically, a combination of the noted approaches can be taken to lessen the impact of a malicious USB device, however a targeted attack will bypass many of these, so part of your defence in depth strategy should ensure that compromise of a single host has a limited impact on your network.

Disabling USB ports is one way to go, but often impractical in the real world. Ensuring that screens are locked when users are absent from their devices is generally good practice and could help defend against a drive-by payload from an attacker who hasn't done recon. However, if you're targeting an organisation who religiously follow this practice, I imagine your payload would wait until it detects user activity before kicking in, or focus on any available network vectors which may not require an unlocked workstation. Ensuring users are operating in the least privileged context they can (while remaining functional) is also just good practice that would lessen the impact of their compromise.

Generally presuming an attacker is going to try to open PowerShell is probably a pretty safe bet as a place to add barriers.

Consider NCSC's guidelines with regards to password expiry policies.

While generally skeptical of security software vendors, I'm interested in the developing area of behaviour-based USB protection, or protections based on analysing the USB traffic of the device and comparing it to known good or known bad samples. Could be worth investigating whether you gain anything meaningful by uninstalling drivers you know will not be used in your environment. While it doesn't do any clever analysis, approaches like USBGuard on Linux require the device to have a whitelisted PID/VID/product name (all spoofable) and also be plugged into the same USB port every time, so they have to replace a legitimate device (more likely to disrupt user activity and be detected).

Link to comment
Share on other sites

On 4/12/2017 at 5:57 PM, LowValueTarget said:

Fill the USB ports with cement. :)

Fill the users with cement ...

 

On a more serious note : having your users being aware of the potential dangers and acting accordingly is a lot of work; However this is the first line of defense against any randomly dropped USB stick.

 

Like one previously said : its quite easy to have a listening device on the network that does not show anywhere but is quite capable of storing information. 

This could be a website with an upload function; an ftp site or a combination of the two.

 

 

Main problem with this situation is maintaining the highest level of security whilst still making it possible for your end-users to perform their work.

 

 

Would be interested to see (parts) of your presentation and moreover: the reaction of the people you are giving the presentation to.

Link to comment
Share on other sites

  • 2 weeks later...

I liked Qubes when I tried when it was at 3.1 with a separate HD on my laptop, I just had difficulties setting up things.  Like hooking up a USB drive was difficult.  Never got my external Alpha to work right nor my internal Broadcom wireless.  Broadcoms always have issues though until in recent years with linux.  I run Kali/Parrot and it was hard to setup an internal test environment or even use it though I was making way figuring out the firewall settings.  Okay for the advanced but for any noob to use there should be a network tool to handle firewalling all the way through like if I want to expose a certain port on a app VM then I should say expose and it will handle the firewall ruling for me.  Needs something like that for wifi too so when I attach it, it can be install in the host (which I know is Xenserver) so it can be attached to the firewall VM and then picked up by app to be used as network without having to install firmwares and doing lsusb and all the other stuff..

I do agree, with it doing compartmentalization, Qubes is extremely secure and can block almost any attack if the person doesn't have time at the keyboard to set it up.

 

Link to comment
Share on other sites

  • 7 months later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...