USB: Dr. Jekyll und Mr. Hyde: Difference between revisions
m (→Software) |
|||
(21 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
== Einleitung == |
== 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. |
|||
== Dr. Jekyll und Mr. Hyde == |
|||
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> |
|||
⚫ | |||
⚫ | |||
=== Hardware === |
=== 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. |
|||
Entscheidung zu Raspberry Pi |
|||
wichtig USB on the Go (OTG) |
|||
=== Software === |
=== 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: |
|||
Raspberry Pi Zero einrichten |
|||
<code>dd bs=4M if=2017-09-07-raspbian-stretch-lite.img of/dev/mmcblk0p1 conv=fsync</code> |
<code>dd bs=4M if=2017-09-07-raspbian-stretch-lite.img of/dev/mmcblk0p1 conv=fsync</code> |
||
weiterhin muss das wlan eingerichtet werden |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
=== GadgetFS === |
=== GadgetFS === |
||
Line 71: | Line 50: | ||
ls /sys/class/udc > UDC |
ls /sys/class/udc > UDC |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
⚫ | |||
⚫ | |||
== Szenarien == |
== Szenarien == |
||
Line 114: | Line 98: | ||
- nicht erkennbar für den Pi ob er gemountet ist oder nicht |
- 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 |
- dadurch kann nicht automatisch nach unmounten des Sticks das Skript ausgeführt werden |
||
---> Skript manuell ausführen nach unmounten |
---> Skript manuell ausführen nach unmounten |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
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 |
dee |
||
Line 163: | Line 171: | ||
[[File:wireshark0.png| |
[[File:wireshark0.png|1000px|center|thumb|Screenshot von Wireshark mit Datei die Random Input enthält]] |
||
[[File:wireshark1.png| |
[[File:wireshark1.png|1000px|center|thumb|Screenshot von Wireshark mit Datei die Random Input enthält]] |
||
Demo: |
Demo: |
||
1. raspberry pi: |
1. raspberry pi: |
||
* create one images |
* create one images |
||
<code>dd if=/dev/zero of=image.img bs=1M count=4000</code> |
|||
- msdosfs image.img |
|||
<code>msdosfs image.img</code> |
|||
⚫ | |||
<code>sudo mount -o loop,rw image.img usbdisk.d</code> |
|||
⚫ | |||
⚫ | |||
⚫ | |||
- - - - - schon erledigt - - - - - - - - - |
- - - - - schon erledigt - - - - - - - - - |
||
Line 184: | Line 197: | ||
3. robbys rechner: |
3. robbys rechner: |
||
sudo mount -o loop,rw usbdisk.img usbdisk.d |
<code>sudo mount -o loop,rw usbdisk.img usbdisk.d</code> |
||
sudo dd if=/dev/urandom of=four_gb.txt bs=1M count=4000 conv=notrunc status=progress |
<code>sudo dd if=/dev/urandom of=four_gb.txt bs=1M count=4000 conv=notrunc status=progress</code> |
||
⚫ | |||
⚫ | |||
4. ninas rechner |
4. ninas rechner |
||
cat four_gb.txt > /dev/null |
<code>cat four_gb.txt > /dev/null</code> |
||
--> wireshark zeigen |
--> wireshark zeigen |
||
Line 199: | Line 214: | ||
== Fazit == |
== Fazit == |
||
== Quellen == |
Latest revision as of 09:42, 25 October 2017
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
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