So how is this any different from existing USB hardware implants like the Rubber Ducky, or keyloggers. Firstly, the devices I’ve seen can only achieve one or two attack classes such as eavesdropping or message fabrication. BadUSB2 can eavesdrop, replay, modify, fabricate, exfiltrate data and BadUSB in one device. Furthermore, when combining these attack classes really interesting attack scenarios begin to surface. Secondly, keyboard emulation devices register as an additional USB device making them easy to detect and block, i.e. why do I now have two keyboards attached!? Yes, such devices can be easily detected and blocked. The same can be said of BadUSB, it often needs to register as a secondary USB device to perform a malicious task. BadUSB2 is an INLINE hardware implant giving it the stealth of a hardware keylogger but far more capabilities as mentioned above. Finally, (law of 3’s), just cos…
x1 Linux build (tested on default install of Ubuntu 14.04)
x1 Windows XP/7 (our target)
x3 USB type A-male to USB Mini-B cables
x1 USB Keyboard (tested on HP & Genius brands)
Implemented Proof of Concept Attacks:
+ Eavesdrop. Once the keyboard has been registered to the target all keystrokes are captured to the ‘/tmp’ folder.
+ Modify. Weaponised code could use regular expressions to modify user keystrokes in order to defeat one-time-passwords. In this POC we simply annoy the user 🙂
+ Replay. The POC code will automatically detect ‘ctrl-alt-delete’ and assume it is a login session. It stops recording once the ‘enter’ key is pressed. Ay any time the ‘replay’ command can be given to automatically authenticate to the workstation.
+ Fabricate. Start/Run or generic commands can be issued to the target operating-system just as if you were at the keyboard.
+ Exfiltrate. I’ve implemented a PowerShell exfiltration POC that uses the ‘morse code’ technique (LEDs) to exfiltrate data. Using custom HID output reports is faster but MS Windows restricts read/write access from Win 2K. In short, this is a very rudimentary POC, and did I mention very slow!
BadUSB. I did not actually implement a POC for this. The Facedancer has plenty of example code that can be used to fake USB peripherals to the host, but it would be nice to implement some of the BadUSB “Kali Nethunter” type attacks here.
git clone https://github.com/withdk/badusb2-mitm-poc && cd badusb2-mitm-poc
The main requirement is the FTDI USB/Serial adapter (ftdi_sio modules) which "should" be installed by default on Ubuntu 14.04.
When connecting a Facedancer you should get:
-- snipped --
[ 1725.385252] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1725.385256] usb 1-4: Product: FT232R USB UART
[ 1725.385259] usb 1-4: Manufacturer: FTDI
[ 1725.385262] usb 1-4: SerialNumber: AI02BP4J
[ 1725.398297] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected
[ 1725.398351] usb 1-4: Detected FT232RL
[ 1725.403446] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
If this is the first time using the Facedancer's you will need to flash your devices so follow the goodfet tutorial found here:
You will need to repeat the above steps twice, one for each Facedancer.
When both Facedancers are attached to the MITM system you should now have two devices registered:
$ ls /dev/TTYUSB*
*** IMPORTANT NOTE ***
Before running the BadUSB2 m2p/m2h scripts ensure the Facedancer 2 peripheral is connected first so it registers on '/dev/ttyUSB0'.
To run it we need to terminals open:
# Run on the first terminal (run this first)
sudo ./m2p.py info
# Run on the second terminal
I've noticed on some Windows builds that you need to re-run the python scripts in order to get the operating-system to register the keyboard. I haven't looked into why this is.