Evil Mass Storage

21 Sep, 21
Tags:
142 views

 Development Details 

All the source code its available in my github: https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2

Demo video (in Spanish): https://youtu.be/-K6MMVyKEv0?t=346

Steps to reproduce an attack:

  1. The victim connects the USB device.
  2. To make forensic work more difficult the device can randomize the VID/PID, serial disk and all relevant forensic-USB-data in each connection (the uploaded POC only changes this info in some stages):
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Descriptors.c#L112
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SCSI.c#L88
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SDCardManager.c#L150
  3. The USB device is a USB composite device (not a USB HUB, again... read the books!!). Windows will detect it as a new keyboard and a new mass storage device.
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Descriptors.c#L193
  4. The keyboard-device opens a run window (WIN + R) and starts to brute-force the assigned letter for mass storage in order to execute the stored .exe in our mass storage. This exe is not the malware, its the first stage. It retrieves useful information like the user name and writes it into the mass storage.
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/MassStorageKeyboard.c#L342
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/stage1/stage1/main.c#L90
  5. The microcontroller gets the SCSI command and if the info is correct it resets the USB connection, and at this moment the malware is at the mass storage. This malware is decrypted (the POC uploaded is only a crap-XOR) using the information written in the mass storage... if evil mass storage is not connected to the target computer, malware won't be in it. 
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/MassStorageKeyboard.c#L317
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SDCardManager.c#L381
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SCSI.c#L370
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SDCardManager.c#L587
  6. The malware is executed and the microcontroller removes all sectors of the malware from the SD.
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SDCardManager.c#L163
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/MassStorageKeyboard.c#L125
  7. From this moment, the USB device will only work as a regular USB mass storage (keyboard part is removed). The VID-PID + other USB info gets changed again.
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Descriptors.c#L97
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Descriptors.c#L288
  8. The malware exfiltrates data writing to the mass storage device and the microcontroller resends the information via rf 433MHz ASK (helped by a atmega328p). It also supports exfiltration via the SD card (encrypting the information first).
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilmass/evilmass/Lib/SDCardManager.c#L438
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/evilard/evilard.ino#L176
    https://github.com/David-Reguera-Garcia-Dreg/evilmass_at90usbkey2/blob/master/stage2/stage2/main.c#L183

NOTE: This attack is only useful to steal a little info because SPI uses slow, RF 433MHz bandwidth…

I'm working on a new version. Currently experimenting with two ARM Cortex-M4 32 bit boards: FRDM-K66F MK66FN2M0VMD18 and Teensy 3.6 MK66FX1M0VMD18 (Paul J Stoffregen + an awesome community pjrc + a lot of code).

What I am looking for:

  • Fast microcontroller ARM Cortex-M4 at 180 MHz
  • A real SDIO interface (fast SD access)
  • Cryptographic Acceleration & Random Number Generator (I want to use AES to encrypt/decrypt sectors...).

NOTE: ARM Cortex-M4 is very, very complex compared to AVR-8 bit, you should read this (hard) book:

  • The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors Third Edition by Joseph Yiu. ARM Ltd., Cambridge, UK. https://amzn.to/3tMbfzC

Teensy 3.6 ARM Cortex-M4 (NXP Kinetis MK66FX1M0VMD18) 180MHz:

  • ARM Cortex-M4 at 180 MHz
  • Float point math unit, 32 bits only
  • 1024 Flash, 256K RAM, 4K EEPROM
  • USB device 12 Mbit/sec, USB host 480 Mbit/sec
  • 64 digital input/output pins, 22 PWM output pins
  • 25 analog input pins, 2 analog output pins, 11 capacitive sense pins
  • 6 serial, 3 SPI, 4 I2C ports
  • 1 I2S/TDM digital audio port
  • 2 CAN bus
  • 1 SDIO (4 bit) native SD Card port
  • 32 general purpose DMA channels
  • Cryptographic Acceleration & Random Number Generator
  • RTC for date/time

https://www.pjrc.com/store/teensy36.html

 

teensy

FRDM-K66F (NXP Kinetis MK66FN2M0VMD18):

Performance

  • Up to 180 MHz ARM Cortex-M4 based core with DSP instructions and Single Precision Floating Point unit

System and Clocks

  • Multiple low-power modes to provide power optimization based on application requirements
  • Memory protection unit with multi-master protection
  • 3 to 32 MHz main crystal oscillator
  • 32 kHz low power crystal oscillator
  • 48 MHz internal reference

Security

  • Hardware random-number generator
  • Supports DES, AES, SHA accelerator (CAU)
  • Multiple levels of embedded flash security

Timers

  • Four Periodic interrupt timers
  • 16-bit low-power timer
  • Two 16-bit low-power timer PWM modules
  • Two 8-channel motor control/general purpose/PWM timers
  • Two 2-ch quad decoder/general purpose timers
  • Real-time clock

Human-machine interface

  • Low-power hardware touch sensor interface (TSI)
  • General-purpose input/output

Memories and memory expansion

  • Up to 2 MB program flash memory on nonFlexMemory devices with 256 KB RAM
  • Up to 1 MB program flash memory and 256 KB of FlexNVM on FlexMemory devices
  • 4 KB FlexRAM on FlexMemory devices
  • FlexBus external bus interface and SDRAM controller

Analog modules

  • Two 16-bit SAR ADCs and two 12-bit DAC
  • Four analog comparators (CMP) containing a 6-bit DAC and programmable reference input
  • Voltage reference 1.2V

Communication interfaces

  • Ethernet controller with MII and RMII interface to external PHY and hardware IEEE 1588 capability
  • USB high-/full-/low-speed On-the-Go with on-chip high speed transceiver
  • USB full-/low-speed OTG with on-chip transceiver
  • Two CAN, three SPI and four I2C modules
  • Low Power Universal Asynchronous Receiver/ Transmitter 0 (LPUART0) and five standard UARTs
  • Secure Digital Host Controller (SDHC)
  • I2S module

https://www.nxp.com/docs/en/data-sheet/K66P144M180SF5V2.pdf

https://www.nxp.com/design/development-boards/freedom-development-boards/mcu-boards/freedom-development-platform-for-kinetis-k66-k65-and-k26-mcus:FRDM-K66F

FRDM-K66F

My pull request adding new ClassDriver MassStorageSDKeyboard Demo for LUFA - the Lightweight USB Framework for AVRs:

My talk in english (translated by who knows):

Just my own adaptation for mass storage sd card and keyboard for AT90USBKEY2:

Presentation: 

FatFS + TTL UART + MICRO SD + ATMEL ICE JTAG DEBUGGING:

jtag_and_uart

NOTE: I have no plans to make/sell more roapt v1 boards. I don't want to spend money on this xD.

ARM POC version is coming