View source for 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>{{Cite news|url=http://robert-louis-stevenson.org/lamplit-vicious-fairy-land/|title=Lamplit Vicious Fairy Land - Robert Louis Stevenson|newspaper=Robert Louis Stevenson|language=en-GB|access-date=2016-11-12}}</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:
<code>dd bs=4M if=2017-09-07-raspbian-stretch-lite.img of/dev/mmcblk0p1 conv=fsync</code>

=== GadgetFS ===


<syntaxhighlight lang="bash">
echo "dtoverlay=dwc2" | sudo tee -a /boot/config.txt
echo "dwc2" | sudo tee -a /etc/modules
</syntaxhighlight>



==== Gadget erstellen ====

<syntaxhighlight lang="bash">
#!/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
</syntaxhighlight>


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

<code>mkdosfs mass_storage</code>

== 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

<code>mkdir ~/mount_usb</code>

<code>mount -o loop,rw mass_storage ~/mount_usb</code>

<code>cd ~/mount_usb</code>

<code>yes 0 | dd of=test_file1.text bs=1M count=4000</code>

<code>yes 1 | dd of=test_file1.text bs=1M count=4000</code>

=== 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:
<syntaxhighlight lang="bash">
dd if=/dev/zero of=/home/pi/usbdisk.img bs=64k count=8192
mkdosfs /home/pi/usbdisk.img
</syntaxhighlight>
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


[[File:wireshark0.png|1000px|center|thumb|Screenshot von Wireshark mit Datei die Random Input enthält]]

[[File:wireshark1.png|1000px|center|thumb|Screenshot von Wireshark mit Datei die Random Input enthält]]

Demo:
1. raspberry pi:
* create one images
<code>dd if=/dev/zero of=image.img bs=1M count=4000</code>

<code>msdosfs image.img</code>

<code>sudo mount -o loop,rw image.img usbdisk.d</code>

<code>sudo umount usbdisk.d</code>

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

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

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

3. robbys rechner:
<code>sudo mount -o loop,rw usbdisk.img usbdisk.d</code>

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

<code>sudo umount usbdisk.d</code>

4. ninas rechner

<code>cat four_gb.txt > /dev/null</code>
 --> wireshark zeigen
 

datei erstellt 0000
pi mount verändert unmount
datei anders

== Fazit ==

== Quellen ==