zaterdag 3 december 2016


Overview of BADUSB

BADUSB

USB drives are considered unmalicious by Windows.   automatically trusts the content of a USB drive to be safe and secure. The USB protocol also allows devices to self-dictate or manipulate what they do – for example, a USB drive communicates to the operating system, when plugged in, that it is a USB storage device. This is how the USB port can appear universal – USB devices have surely become the universal port and plug of choice for our time, ranging from flight simulators to mice and keyboards to storage devices.

BadUSB has the ability to infect other USB 3.0 Flash Drives with the Phison 2303 (again pretty hard to obtain).
Adam Caudill (spublished on his GitHub from his BadUSB talk

At this moment BADUSB only works on an USB 3.0 flash drive with a Phison 2303 (2251-03) Controller. Those sticks are hard to get. A list of USB types that have this controller can be found on : https://github.com/brandonlw/Psychson/wiki/known-supported-devices.

A tool to verify if you happen to have a phison USB is  Flash Drive Information Extractor 

A good explanation on how to create a BADUSB can be found here:
http://null-byte.wonderhowto.com/how-to/make-your-own-bad-usb-0165419/


Rubber Ducky

A commercial tool  to test the BADUSB vulnerability created for pen testers.

Teensy

An other method is using  a Teensy USB Development Board from PJRC for an inexpensive price of $19.80
First described by  Samy Kamkar’s (SkyJack) USBDriveBy,
Paensy
Payloads are inserted with arduino to the teensy device.

Payloads

The danger of BADUSB comes from the payload, this is the software / malicious code that is places in the firmware of the USB stick. Examples of payloads are: 
  • Add Admin User (adds a pre-programmed user with a programmatically-defined password)
  • Download and Execute (downloads and executes a file of your choosing)
  • Facebook Post (posts a Facebook status to the victim’s Facebook page)
  • Hide Window (a proof-of-concept showing how to hide the current window)
  • Lock Your Computer (opens up notepad and scolds the user on their inability to lock their computer) 
  •  
  •  https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads

links 

teensy and BADUSB    https://github.com/Ozuru/Paensy

USB - Linux


  1. # cat /sys/kernel/debug/usb/devices

    The software strace is not an option for me because it only shows the syscalls to ioctl.

  2. Find USB port 
  3. Output of dmesg:
    [16975.000221] usb 7-1: new full-speed USB device number 5 using  uhci_hcd
    [16975.193543] usb 7-1: New USB device found, idVendor=0403, idProduct=6001
    [16975.193548] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [16975.193552] usb 7-1: Product: FT232R USB UART
    [16975.193555] usb 7-1: Manufacturer: FTDI
    [16975.193558] usb 7-1: SerialNumber: A400BJII
    [16975.200550] ftdi_sio 7-1:1.0: FTDI USB Serial Device converter detected
    [16975.200599] usb 7-1: Detected FT232RL
    [16975.202604] usb 7-1: FTDI USB Serial Device converter now attached to ttyUSB0 
    However I tried moserial to do this and the command "echo foobar > /dev/ttyUSB0" to verify, if it works. Also my software doesn't create an output to moserial.want to monitor (sniff) the traffic of my /dev/ttyUSB0 which is created by FTDI USB Serial Converter. I've written my own application in Windows and now I try to port it to linux and use /dev/tty/USB0. I want to debug the communication that actually happens.
  4. Setup usbmon

    modprobe usbmon

    1.1 With Linux kernels prior to 2.6.23, you will also need to run this command

    modprobe -t debugfs none /sys/kernel/debug

  5. usbmon0 will monitor any traffic from all usbmon0 to usbmonX 2.1. Find the correct usb device

    cat /sys/kernel/debug/usb/devices|grep FTDI -A 7 -B 4

    T:  Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=12   MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
    P:  Vendor=0403 ProdID=6001 Rev= 6.00
    S:  Manufacturer=FTDI
    S:  Product=FT232R USB UART
    S:  SerialNumber=A400BJII
    C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 90mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
    E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    
    2.2. Note Bus number of the port (Bus=07), so usbmon to monitor will be usbmon7
    2.3. Use wireshark to capture the usbmon7 interface or use following command to get output to the console (stdout) ... replace the number with bus-id

    cat /sys/kernel/debug/usb/usbmon/7u

    Two formats are supported currently: the original, or '1t' format, and the '1u' format. The '1t' format is deprecated in kernel 2.6.21. The '1u' format adds a few fields, such as ISO frame descriptors, interval, etc. It produces slightly longer lines, but otherwise is a perfect superset of '1t' format.