USB: Dr. Jekyll und Mr. Hyde

Einleitung

Das Universal Serial Bus (USB) Protokoll wird zur Kommunikation zwischen einem Computer und externer Hardware wie Tastaturen und Massenspeichergeräten verwendet. Hierbei nimmt ein Kommunikationspartner die Rolle des Hosts, von dem die Kommunikation ausgeht, ein. Der andere Kommunikationspartner übernimmt die Rolle des Slave, der auf die Anfragen des Hosts antwortet. Im Allgemeinen kann der Host in diesem Modell davon ausgehen, als einziges Gerät auf den Slave zugreifen zu können.

In unserem Projekt haben wir uns zum Ziel gesetzt, einen USB-Stick zu emulieren, der sich im laufenden Betrieb, also ohne dass er vom Host-Computer abgesteckt wird, verändern kann. Der Projektname, "Dr. Jekyll und Mr. Hyde", bezieht sich hier auf die Novelle "Strange Case of Dr Jekyll and Mr Hyde" von Robert Louis Stevenson, in der sich Dr. Jekyll durch Einnahme eines Trankes in den bösen Teil seiner Seele, Mr. Hyde, verwandeln kann. Wie Dr. Jekyll ist auch unser emulierter Stick in der Lage sein Verhalten zu ändern.

Wir haben uns im Rahmen des Projekts mit drei Szenarien für einen "sich selbst verändernden" USB-Stick beschäftigt und diese jeweils auf unserem Hardware- und Software-Setup implementiert.<ref>Template:Cite news</ref>

Setup

Hardware

Zur Emulation des USB-Sticks wurde ein Raspberry PI Zero W verwendet. Dieser unterstützt, ebenso wie eine Reihe von Android Smartphones, die USB On-the-Go (OTG) Erweiterung. OTG wurde 2001 spezifiziert und ermöglicht es Geräten, sowohl als Host als auch als Slave aufzutreten, was für unser Projekt eine Voraussetzung war. Andere Single Board Computer wie der "Raspberry Pi Model B" unterstützen diese Erweiterung nicht.

Abgesehen von der OTG-Unterstützung ist auch der Formfaktor des Raspberry Pi Zero W zu erwähnen, der dem eines USB Sticks schon relativ nahe kommt. Eine über dieses Projekt hinausgehende Herausforderung ist eine Hardware zu designen, die glaubwürdig als USB-Stick getarnt ist und gleichzeitig die für den Betrieb notwendige Stromversorgung sicherstellt.

Software

Als Betriebssystem wurde die Linux-Distribution Raspbian verwendet. Der bei Raspbian mitgelieferte Kernel wurde mit USB-Gadget-Unterstützung kompiliert. Das Betriebssystem-Image wurde wie folgt auf eine microSDHC-Speicherkarte aufgespielt: dd bs=4M if=2017-09-07-raspbian-stretch-lite.img of/dev/mmcblk0p1 conv=fsync

GadgetFS

echo "dtoverlay=dwc2" | sudo tee -a /boot/config.txt
echo "dwc2" | sudo tee -a /etc/modules

Gadget erstellen

#!/bin/bash
cd /sys/kernel/config/usb_gadget/
mkdir -p isticktoit
cd isticktoit
echo 0x1d6b > idVendor # Linux Foundation
echo 0x0104 > idProduct # Multifunction Composite Gadget
echo 0x0100 > bcdDevice # v1.0.0
echo 0x0200 > bcdUSB # USB2
mkdir -p strings/0x409
echo "fedcba9876543210" > strings/0x409/serialnumber
echo "Tobias Girstmair" > strings/0x409/manufacturer
echo "iSticktoit.net USB Device" > strings/0x409/product
mkdir -p configs/c.1/strings/0x409
echo "Config 1: ECM network" > configs/c.1/strings/0x409/configuration
echo 250 > configs/c.1/MaxPower
# Add functions here
# see gadget configurations below
# End functions
ls /sys/class/udc > UDC

dd if=/dev/zer of=mass_storage bs=1M seek=1024 count=16000

mkdosfs mass_storage

Szenarien

Hidden Volume

was - usb hat 2 partitionen, sind auf dem raspberry pi 2 images, - je nach User wird eine oder beide Partionen sichtbar - beispielsweise hier loesungen der klausur und passwörter

wie , sind auf dem raspberry pi 2 images, eine partition wird default angezeigt als massenspeicher - außerdem emuliert gadgetfs eine serielle schnittstelle, wenn auf der seriellen schnittstelle daten rein kommen, soll die geheime partition angezeigt werden

resultat/probleme

- Der Pi erkennt nicht an welchem PC er angeschlossen wird, demnach nicht möglich so zu entscheiden wieviele Partionen gezeigt werden --> wir nutzten die serielle Schnittstelle als zusätzlichen Kanal, wenn Daten auf der seriellen Schnittstelle auf dem Pi ankommen, mountet er die hidden Partition

- Functions können nicht später (d.h. im gemounteten Zustand) hinzugefügt werden --> Lösung: um zwei Partionen statt einer zu erkennen, muss der Pi neu gestartet werden

Passive Attack

was - Alice speichert ein Dateien auf einem USB Stick und gibt diesem Bob - bevor Bob den Stick ansteckt, werden die Dateien auf dem Stick verändert. - Bob guckt sich modifizierte Daten an

wie - Dateien werden verändert nach dem unmounten des USB Sticks - Demo: Beispielsweise: Skript sucht auf dem Stick nach Bild Dateien und rotiert diese - weitere Ideen: veränderung der IBAN oder Geldbeträge, weitere kompromittierte Dateien hinzufügen

resultat/problem - nicht erkennbar für den Pi ob er gemountet ist oder nicht - dadurch kann nicht automatisch nach unmounten des Sticks das Skript ausgeführt werden ---> Skript manuell ausführen nach unmounten

das Image muss dann gemountet werden

mkdir ~/mount_usb

mount -o loop,rw mass_storage ~/mount_usb

cd ~/mount_usb

yes 0 | dd of=test_file1.text bs=1M count=4000

yes 1 | dd of=test_file1.text bs=1M count=4000

Aktive Attacke

Wie bereits oben erwähnt, kann der Host in einer USB-Verbindung davon ausgehen, alleinigen Zugang zum Slave-Device zu haben. Beispielsweise sollten Änderungen an einer Partition auf einem USB-Massenspeichergerät also genau dann auftreten, wenn der Host diese vornimmt - andernfalls kann von einem Defekt des Datenträgers ausgegangen werden. Unsere Installation ermöglicht es uns, zu einem beliebigen Zeitpunkt gezielt Änderungen an einer vom Host gemounteten Partition vorzunehmen. Das konkrete Ziel dieses Szenarios war zu beobachten, wie das Host-System mit unerwarteten Änderungen an der Partition umgeht. Von besonderem Interesse war zu beobachten, ob sich auf diese Weise die auf dem Host-System installierte Anti-Malware-Software "austricksen" ließe.

Zur Implementation dieses Szenarios wurde auf dem Raspberry Pi ein Datenträger-Image angelegt und als FAT32-Dateisystem formatiert. FAT32 wurde aus zweierlei Gründen ausgewählt: Zum einen ist dieses Dateisystem auf allen populären Desktop-Betriebssystemen mit Lese- und Schreibunterstützung implementiert. Zum anderen sind für FAT32 keine Dateisystem-eigenen Integritätssicherungsmechanismen vorgesehen, wie diese zum Beispiel in ZFS existieren. Das Image wurde wie folgt vorbereitet:

dd if=/dev/zero of=/home/pi/usbdisk.img bs=64k count=8192
mkdosfs /home/pi/usbdisk.img

Das Script zum Erstellen des entsprechenden Gadgets mit Massenspeicher-Funktionalität sieht wie folgt aus: TODO: hier nidaro-Script einfügen (liegt auf dem Pi)

dee virenscanner scannt dateien, sagt alles virenfrei schadcode im gemounteten Zustand einfügen

was - der Stick wird angesteckt, eine Datei wird geladen angeguckt wieder geschlossen, und während der Stick gemountet ist, wird die Datei vom pi geändert bsp. mit schadcode - danach wird die datei wieder geöffnet und ist verändert

wie

- kleine dateien verändern 00 zu 11 - keine veränderunng: gecacht oder gehasht fehlermeldung bei windows und linux korruptes filesystem

-versuch mit sehr großen dateien bsp. 4 gb bei 4 gb ram linux - swap deaktiviert veränderung wird gesehen - siehe demo

- versuche auf windows teilweise speicher volllaufen auf glück? veränderung gesehen einmal gesehen

- verschiedene Ansätze / Versuche - OS: Windows und Linux reagieren unterschiedlich

- text file erstellt, vom pi sollte dann dieser string eingefüght werden X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

https://en.wikipedia.org/wiki/EICAR_test_file

resultat/problem

- OS nimmt an totale Kontrolle über das File System zu haben - Dateien werden vermutkich im RAM gecacht (I/O Buffer)

   Linux: wie in Demo, wird gezwungen File neu zu öffnen

   Windows: caching verhalten nicht so vorhersehbar

   unser Windows system hatte 8gb ram, dass linux system nur 4gb

Screenshot von Wireshark mit Datei die Random Input enthält

Screenshot von Wireshark mit Datei die Random Input enthält

Demo: 1. raspberry pi:

• create one images

dd if=/dev/zero of=image.img bs=1M count=4000

msdosfs image.img

sudo mount -o loop,rw image.img usbdisk.d

sudo umount usbdisk.d

yes 0 | sudo dd of=four_gb.txt bs=1M count=4000 iflag=fullblock

- - - - - schon erledigt - - - - - - - - -

2. ninas rechner: sudo modprobe usbmon sudo wireshark cat four_gb.txt > /dev/null wireshark zeigen

3. robbys rechner: sudo mount -o loop,rw usbdisk.img usbdisk.d

sudo dd if=/dev/urandom of=four_gb.txt bs=1M count=4000 conv=notrunc status=progress

sudo umount usbdisk.d

4. ninas rechner

cat four_gb.txt > /dev/null

--> wireshark zeigen

datei erstellt 0000 pi mount verändert unmount datei anders