Blocking the Lan Turtle / Poison Tap / Bash Bunny and other cruft

I've been doing this for a long time.  So I've researched, discovered, implemented, and forgotten a ton of stuff.  I should probably start up a blog just for stuff that I've forgotten ;-)

So I first thought about it when the HAK5 turtle showed up (link here: https://lanturtle.com/) ....  I thought to myself  "oh yeah, I totally know how to stop that, I aught to write up a blog post about it..." and then life happened....  then Mubix posted something that at the time about using  a USB armory to do similar stuff (link here: https://room362.com/post/2016/snagging-creds-from-locked-machines/) .... and the lightbulb went on then went out again...  Then I read about the poisontap (link here: https://samy.pl/poisontap/) , and I was like oh yeah... I really aught to do that blog post.... then life... etc...

So I then I saw the new Bash Bunny (https://hakshop.com/products/bash-bunny) and figured I aught to get off my ass...

I originally found this while researching how to prevent the tool 'inception' from working...  (link here: http://www.breaknenter.org/projects/inception/) The TLDR for this attack is that firewire and thunderbolt both allow direct memory access (DMA) when prodded the right way.  This is a Bad Thing (tm) for people like me to be able to do ;-)  There is a way with GPO to block the loading of the drivers that make it work, which is documented on the MS site.

Microsoft was kind enough to put a page up describing what needs to be done.  (Link here: https://support.microsoft.com/en-us/kb/2516445) 

I'm going to demonstrate a general method for preventing these sorts of attacks and my thinking behind it.  The usual caveat applies, always test in a lab environment before deploying anything like this.  It could have disastrous consequences if not used properly.  However, I believe the impact should be minimal the way I'm suggesting you address the problem.  This method is Windows specific as I feel that is the largest attack surface...

Quick Background

Devices like the Beaglebone, the Pi, or the USB armory take advantage of a feature in the Linux kernel called a USB gadget (link: http://www.linux-usb.org/gadget/).  Essentially the gadgets allow the Linux device to emulate several different common USB devices, such as a network adapter, USB keyboard, USB mass storage drive, and sometimes several at the same time .  In this case, the Linux device emulates a USB network adapter.  Windows has built-in drivers for the type of device presented, so they will automatically load.  The name of the device as it appears on Windows is a "RNDIS/Ethernet Gadget".

*Note* The Lan Turtle actually presents as a different network card which has Windows driver support directly.  The Bash Bunny is new (March 1, 2017) and I haven't seen or played with one, so I don't know how it presents, however, I know the most likely candidate is going to be the USB Multi Gadget...

Getting Started

Both of these methods use a Group Policy Object (GPO) to prevent the driver from being loaded.  This also works on computers that are not attached to a domain by using the local 'gpedit.msc' panel.

Starting 'gpedit.msc' from a command prompt brings up the following window.  I have highlighted the path we are looking for:

Underneath "Device Installation Restrictions" we have the following items.  The ones we are interested in are primarily "Prevent installation of devices using drivers that match these device setup classes" and  "Prevent installation of devices that match any of these device ID's".

A brief overview of the two options:

• "Prevent installation of devices using drivers that match these device setup classes"
• This is a more general option suited to stop entire classes from loading IE network cards
• This is the option I'm recommending
• "Prevent installation of devices that match any of these device ID's"
• This option is more specific
• I *suspect* (unproven) that this could be worked around
• Would need multiple items for each specific device
• Not the way I'm recommending solving it

How to Break the Devices

The way the Poisontap and the Bash Bunny (informed speculation) work is that they present as a high speed network device with drivers that are built into Windows.  By default, when a Windows box gets a new network interface up, it tries to use DHCP to acquire an IP address.  Since these devices have a DHCP server, the device gets an IP address and is considered fit for duty by Windows.  By stating to Windows the device is high speed, that forces the Windows TCP/IP stack to assign it the highest priority when sending out network traffic, which allows all sorts of interesting MITM attacks, such as leveraging responder for creds...

The easiest way to break this is to simply prevent the device from getting a driver.  This is actually fairly straight forward using the "Prevent installation of devices using drivers that match these device setup classes" option above.  If we combine this with the generic network device GUID, this means that no NEW network devices can be added to the system.

There is an option to make this apply to devices that are already installed.  DO NOT CHECK THIS BOX! Only death and misery follow if you pushed out a network wide GPO with that checkbox enabled!

I think, if applied correctly, (unless somebody can prove me wrong) that this is a fairly low risk enhancement to the security posture. 

The risk (as I see it) comes from whenever you add a 'network device' to the system.  How often does this happen given the average business class hardware?  Most systems I have seen in use in a corporate environment have wired / wireless built in.  I have, on occasion, seen an external wireless adapter, but those are mostly exceptions to the rule. 

Existing network connections will not be affected (as long as you don't hit the checkbox I warned about above), so presumably since it can connect to the domain everything is working... it would only be if you needed to add a device or possibly change a device, which shouldn't be an everyday event...

The only occasions I see this being a problem would be if something like VMWare Workstation was added to the system, but then you could temporarily disable the setting, install the software, and then reapply the GPO.  It is also possible that some VPN software could also trip this up, but I *suspect* that if you started the VPN once while the GPO was disabled it would still work, however that would require further testing.

How to actually do it

From here (link: https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426(v=vs.85).aspx) the specific class GUID for network adapters is "{4d36e972-e325-11ce-bfc1-08002be10318}"

So to prevent new adapters from being installed, select "Prevent installation of devices using drivers that match these device setup classes"

Worth mentioning again:

There is an option to make this apply to devices that are already installed.  DO NOT CHECK THIS BOX! Only death and misery follow if you pushed out a network wide GPO with that checkbox enabled!

Hitting the 'Show' Button brings up this dialog box:

Simply copy and paste the GUID from above into the box and hit OK.  In this example I have already done this.  Hit Ok, then Apply and boom.

Whenever a new network device gets plugged in it will fail!

Final Caveat

I suspect there will be ways around this, like any mitigation.  However my feelings are that if you can force the bad guys to up their game and screw over the skiddies who don't what they are doing, both of those are a net win.  There will always be a window one could use to bypass a door... 

Password Maths Hurt the Brains

Every now and again I find myself figuring out the answers to some math questions related to passwords.  The answer usually revolves around me writing the equation on a napkin and then punching the numbers into my cell phone calculator and then moving on with my life.  I finally got around to making a generic spreadsheet that does all the heavy lifting for me, more on this later.

One of the fundamental tenets of cryptography is that the strength of the cryptography needs to outlive the usefulness of the data being encrypted.  For example, transactional data that has a useful lifetime of a few minutes or less doesn't need to be encrypted at the same strength that something that needs to remain secret for 20+ years.  We are specifically talking about hashed passwords that are used for a variety of things from logging into a system to protecting documents.

Most of the questions revolve around cracking passwords with the latest technology.  These numbers tend to move around quite a bit, but there have been some benchmarks posted with hashcat and multi-gpu rigs.  This gist has numbers from a rig of 8 NVIDIA GTX 1080 cards from Sagitta (https://sagitta.pw/) running benchmarks for Hashcat Beta 3.0. Mucho Kudos for posting those numbers, as I'm using this as the basis for my calculations... more on that later on... first some math...

Password Calculation Basics

UPDATE - I like to be as technically correct as I can when it comes to stuff I put out.  I want to thank @scoobzt for correcting me here on something I overlooked.  Keyspace = CharacterSetLength ^ PasswordLength.  So in all of the following, the word 'Keyspace' is used incorrectly and should be substituted with CharacterSetLength.  At some point in the future I will get around to updating the images below...

It all starts with a basic equation, shown below.

In this equation, there are 4 variables we can solve for, Hashrate, Time, Keyspace, or Password Length.  Now, we know the values for Hashrate (from the gist posted above for the various hashing algorithms) so in reality we are solving for one of the remaining three values.

Solving for Password Length

Since Password Length is an exponent of Keyspace, we need to use logarithms to get the answer.  

It is worth noting that the base of the logarithm is immaterial, so we will use the typical 10 as the base.  You could use natural logarithms and the numbers will be the same.  Yay math!

Solving for Password Length yields:

Solving for Keyspace

Solving for Keyspace size (in characters) involves solving for the Password Length root of the left side of the equation as shown below.

Solving for Time

Solving for Time is the most straightforward of the bunch since it is simple division of the original equation

Let's talk about hashing algorithms

Various hashing algorithms perform differently based on a number of different factors from the age of the algorithm to salting to brute-force cracking resistance (increasing the rounds of encryption required or making the algorithm require a lot of memory to run, etc)...  A discussion of these topics are beyond the scope of this post.

The benchmark mode for Hashcat provides a hash calculation rate for only a single hash, so cracking multiple hashes will naturally degrade the performance.  However, for the numbers I am using, I took the aggregate numbers from the gist and averaged it by 8, namely the number of cards provided.  I also added 10% to assume some measure of overclocking or some other sort of efficiency.

Ok, so what?

So why is this at all interesting?  

First, I often field questions from customers relating to passwords and how often then should change them.  There is a lot of numbers thrown around, but not a ton of explanation as to why those values are chosen.  Doing the math makes some of these discussions easier.

Secondly, when developers have to choose a hashing algorithm, once again, there is often a lot of noise regarding what they should choose.  Providing some real numbers can help guide the decisions appropriately.

Thirdly, sometimes you just want a napkin calculation regarding how quickly you can brute force some password for whatever reason...  

The moment you have all been waiting for...

Here is the link to a google spreadsheet which does the math for you.  You will need to make a copy of it to be able to edit it. Notes:

• Generally speaking, both the 'password hash type' and the 'keyspace' are selectable values from a list on the second page (except when keyspace is being solved for).  
• The values in the green cells are what are being solved for
• Hashrate gets looked up based on the hash value
• Yes, symbols have 33 values, don't forget the 'space' character...
• No, I didn't use anything other than plain US ASCII characters
• These numbers should be considered highly optimistic, YMMV
• You can generally edit the following values unless they are being solved for: number of GPUs, length of time (days), length of password

The link:  Password Cracking Google Spreadsheet

Thanks to Andrew for helping make the spreadsheet pretty...