In meinem letzten Post habe ich euch gezeigt wie ihr euren Raspberry Pi als Tor WiFi Hotspot zum anonymen surfen verwenden könnt und gleichzeitig auf die Damit verbundenen Gefahren aufmerksam gemacht. In diesem Beitrag möchte ich das anhand eines Experiments verdeutlichen und zeigen ich euch wie ihr euren Raspberry Pi als Tor Exit Node Sniffer (Tor Exit Node Attack) zum schnüffeln verwenden könnt.
Viele andere Tutorials, zum Beispiel das von Jan oder von Werner, gehen nicht auf diese Problematik ein. Ein Spezialist für diese Themen bin ich auch nicht, möchte aber dennoch an diesem Beispiel gezielt aufzeigen wie gefährlich solche Nachlässigkeiten sein können.
Achtung! Das hier aufgezeigte Beispiel dient nur zur wissenschaftlichen zwecken und darf unter keinen Umständen zum Datendiebstahl o.ä. missbraucht werden. Falls euch das Tor Projekt gefällt unterstützt die Community mit einem eigenen Node, seit euch aber der Gefahren und Probleme stets bewusst. Vor allem der Betrieb einer Exit Node kann problematisch sein, euer Provider wird nicht sehr erfreut sein wenn euer Anschluss zum File Sharing etc. verwendet wird, unproblematischer ist der Betrieb einer Tor Relay Node.
In diesem Experiment möchte ich euch noch vorführen wie ihr euren Raspberry Pi als Tor Exit Knoten, also quasi das Ende der Tor-Kette, einrichtet. Wir verwenden ein ähnliches Setup wie im vorangehenden Projekt.
-
Einen Raspberry Pi
- Mit SD-Karte für das Betriebssystem (mindestens 4GB) - Für alle Modelle geeignet
- Ein Netzteil mit mindestens 1200mA und MicroUSB Anschluss
- Ein SD-Kartenleser um eure SD-Karte mit dem Betriebssystem zu bespielen (für Micro SD Adapter benötigt)
- Ein Gehäuse für den Raspberry Pi (B+) - Optional
- Ein Ethernet Kabel um euren RasPi mit eurem DSL-Router zu verbinden
Wir installieren nach dem üblichen Procedere zum aktualisieren unseres Betriebssystems und dem Ändern des Kennworts für den Pi Benutzer erst die Tor-Software und Tor-Arm (anonymizing relay monitor).
Während die Tor Software auf dem RasPi installiert wird müssen wir, da sich euer Raspberry Pi vermutlich hinter einem Router befindet, noch die Ports vom Router an euren RasPi weiterleiten. Das ist notwendig da der Tor Datenverkehr nicht bis zum Raspberry Pi durch kommt sondern von eurem Router blockiert wird. Filesharer, Gamer und erfahrene Raspberry Pi Benutzer werden mit diesem Vorgehen bereits vertraut sein.
Wir müssen also an unserem Internet Router den TCP-Port 9001 an die interne IP-Adresse unseres Raspberry Pi weiterleiten. Die Einrichtung einer Port Weiterleitung (Port Forwarding) ist von eurem Internet Router abhängig. Das Vorgehen zum Port Forwarding mit einer Fritz Box habe ich bereits in meinen Einsteiger Guides ausführlich erklärt und gehe hier nicht mehr gesondert darauf ein. Folgende Weiterleitungen habe ich eingerichtet.
Wir editieren nun die Tor Konfiguration um unseren Exit Node zu erstellen. Fügt die untern aufgeführten Zeilen ans Ende der Datei an, eventuell müsst ihr die IP-Adressen ersetzen.
Die Konfiguration unserer Tor Node ist recht simpel, über den ORPort 9001 empfängt Tor Anfragen aus dem Tor-Netzwerk. Mit AviodDiskWrites schonen wir noch unsere SD-Karte, um via Tor-Arm Statistik-Daten abfragen zu können setzen wir noch DisableDebuggerAttachment. Die Optionen Nickname und ContactInfo könnt ihr frei wählen, solltet aber keine direkten Rückschlüsse auf eure Identität zulassen. Da ich zwecks Asynchroner DSL Leitung nur begrenze Upload-Kapazität besitze begrenze ich in der Konfiguration die Geschwindigkeit für Tor auf 100/200KB (entspricht 800 kbit/s Upload, mein DSL 16000 hat max. 1.024 kbit/s Upload) .Den Control Port benötigen wir um lokal Statistiken abzufragen.
Die Zeile "ExitPolicy accept *:*" gibt an das wir unseren Tor Server als Exit Node betreiben möchten, eure ExitPolicy solltet ihr unter Umständen anpassen sodass kein Filesharing Traffic über euren Exit Node läuft (z.B. ExitPolicy accept *:80,accept *:110,accept *:6660-6667,accept *:6697,reject *:*).
Eine detaillierte Übersicht der Parameter findet ihr beim Torproject.
Nun können wir direkt unseren Tor Server starten
Über das ARM Tool können wir uns auch direkt ansehen ob und welcher Traffic über unsere Exit Node läuft.
Die Tor Knoten müssen sich über einige Tage im Netzwerk "profilieren" bevor wirklich Daten über den Exit laufen, die ersten Tage werden dazu verwendet die Bandbreite über interne Tor Prozesse zu messen, erst dann kommt merklich Traffic. Ich hatte meinen Node 24h laufen und konnte erst dann die ein oder andere Connection erkennen.
Jetzt gibt es diverse Optionen und Angriffsvektoren, die einfachsten und populärsten sind den HTTP/HTTPS Traffic mitzulesen und nach verwertbarem Ausschau zu halten. Ein prominentes Beispiel ist das stehlen von Session Cookies mit welchen man sich ohne weiteres z.B. an Facebook als anderer Benutzer anmelden kann ohne seine Login Daten zu kennen. Alternativ kann via "man in the middle" Attack auch wirklich brisantes zu Tage befördert werden wenn der Benutzer unachtsam eingeschleuste Zertifikate akzeptiert.
HTTP Traffic mitlesen
Um nun den normalen unverschlüsselten Traffic, der das Tor Netzwerk an unserem Knoten verlässt, mitlesen zu können installieren wir den Sniffer TShark
Ein ganz einfaches Beispiel für Traffic auf Port 80 ist:
Allen HTTP-Traffic könnt ihr so ausgeben (schwer lesbar).
Alle anderen Filter und Möglichkeiten überlasse ich eurer Fantasie!
Verschlüsselten HTTPs Traffic splitten
Die wohl einfachste Methode ist allen Traffic nach HTTPS URLs zu untersuchen und dann in HTTP umzuwandeln, das versetzt uns in die Lage ohne Aufwand mitlesen zu können. Viele bemerken das nicht und z.B. Login Seiten sind oftmals auch via HTTP erreichbar. Da das Tool uns nicht direkt am RasPi eingreifen lässt müssen wir einen weiteren kleinen Rechner zwischen schalten (als weiterer Router zwischen RasPi und Internet Router). Dann könnt ihr recht einfach auf dem zweiten System alles mitlesen:
Wir verwenden hierzu SSLSplit
Dann starten wir SSL und lauschen auf Port 8080 auf Traffic.
Jetzt müssen wir nur noch den HTTP Traffic der an unseren zweiten Raspberry Pi auf Port 80 ankommt an sslstrip weiterleiten, das macht IPTables ganz komfortabel für uns.
Weitere Details möchte ich hier nicht zeigen.
