Sicherheit am Mobiltelefon

Ein keiner Testlauf im lokalen Netzwerk

Aus aktuellem Anlass ein kurzer Demolauf im lokalen Netzwerk für die neugierigen, lernwilligen Kollegen. Die Werkzeuge: ein Netzwerk 192.168.2.0/24, Kali Linux, Notebook mit Interface auf wlan0 und 192.168.2.89. Ziel: Das Handy eines Besuchers.

Als erstes mittels ifconfig den Namen des Netzwerkinterfaces nachschlagen und dann mittels arp-scan -l -I NAME auflisten, was sich denn so alles im Netzwerk tummelt.

Wir entscheiden uns beispielsweise für 192.168.2.129 (das Handy).

Nun sollten wir den Netzwerkverkehr umleiten, damit wir als Man-in-the-middle einen Blick in den Netzwerkverkehr werfen können. Hierzu teilen wir dem System erstmal mit, dass wir doch bitte alles weiterleiten wollen:
echo 1 > /proc/sys/net/ipv4/ip_forward

Als nächstes überzeugen wir die ARP Tabelle, dass wir als Gateway agieren. Den zu verändernden Standardgateway (die 192.168.2.1) erhalten wir logischerweise ebenfalls aus ifconfig. Der Parameter -t zeigt das Ziel an (kann auch weggelassen werden um das ganze Netz zu spoofen). Hinten gibt man den Host an, für den man sich ausgeben will – eben das Gateway.

arpspoof -i wlan0 -r -t 192.168.2.129 192.168.2.1

Voila… nun sollten sämtliche Pakete im Netzwerk – auch die unseres Ziels – über unseren Rechner purzeln. Dies können wir uns auch live anschauen mittels tcpdump, welches wir in einer neuen Konsole aufmachen während arpspoof weiterarbeitet. Wollen wir aufgrund der vielen Pakete nur unser Zielsystem (die 2.129) und dort auch nur den Webtraffic ansehen, so geben wir ein:

tcpdump -i wlan0 -A host 192.168.2.129 and port 80

Wem die Konsole zu unübersichtlich sein sollte – mittels Wireshark geht das auch. Starten, Interface (Capture/Interfaces -> wlan0) einstellen und dann starten. Per Filterung (z.b. ip.addr == 192.168.2.129) wird dann eingeschränkt. Somit kann praktisch jedes Paket und Protokoll im Detail betrachtet werden. Hilfreiches Stichwort: Follow TCP Stream.

Weiterführende Ideen:

Per urlsnarf -i wlan0 werden alle angesurften URLs aufgelistet.
Per driftnet -i wlan0 werden die Bilder angezeigt, die vom Ziel im Internet betrachtet werden. Putzig!

Mittels dsniff -i wlan0 lassen sich Passworte (ftp, http, smtp, imap…) mitlesen – sofern diese nicht verschlüsselt übertragen werden.
Tip: nebenher tcpdump laufen lassen!

Sollte das Ziel dennoch https verwenden – mittels SSLstrip können die https in http Statements verändert werden – und schon befindet sich das Opfer auf der „Fallback“ http Seite.

Mittels der Tools hamster und ferret können Sidejacking – Angriffe gemacht werden. Hierfür brauchen wir ein Wlaninterface im Monitoring mode -> airmon-ng start wlan0 wird das Interface mon0 erzeugt. Dies muss in hamster auf z.b. 127.0.0.1:1234 konfiguriert werden und los gehts: Durch die gestohlenen cookies (wiederrum mit der SSL Einschränkung) ist man automatisch auf der entsprechenden Seite eingeloggt und postet z.b. in einem fremden Facebookaccount.

Für Android gibt es übrigens Tools, die teilweise obige Funktionen direkt am Handy ermöglichen: dsploit ist eines davon. (Anmerkung: Nethunter ebenfalls)

Fazit:

• Man sollte sich bewusst sein, welche Daten z.b. von einem Handy – auch passiv im Hintergrund! –  übertragen werden. Man denke z.b. an die regelmäßigen Logins beim automatischen Emailcheck oder verschiedenen Synchronisierungsdiensten, Messengern etc.
• Das „kostenlose“ Wlan, dessen Betreiber und Struktur man nicht kennt sollte man sich besser 2x überlegen!
• Jeder Dienst – speziell auf einem mobilen Gerät – sollte  auf einen verschlüsselten Übertragungsweg eingestellt werden (SFTP, SSL, TLS etc.)
• Einen statischen ARP Eintrag am Router einrichten – damit wenigstens der nicht zum Ziel wird.
• Wirklich auf korrekte SSL Verbindungen / Zertifikate achten – nicht nur beim eBanking!
• Im Verdachtsfall hilft beispielsweise ein auflisten der ARP Tabelle (Windows z.b. arp -l). Finden sich 2 idente MAC Adressen, dann sollte man anfangen nachzudenken.

Anekdote:

Wer denkt, dass diese Spoofing /  MITM Geschichten seltene Einzelfälle sind: Im Betrieb X  (*keine* technisch begabten Mitarbeiter oder Kunden anwesend) spielte „das Internet“ verrückt. Langsam, Verbindungsabbrüche, Pings kommen nicht immer an…  Verschiedene Dinge durchgespielt – plötzlich geht wieder alles. Juhu! Am nächsten Tag wieder Probleme. Doh! Es gibt kein logisches Muster zwischen den Symptomen und den Massnahmen der Fehlerbehebung in Bezug auf „Geht“ oder „Geht nicht“.

Die ARP Tabelle zeigt plötzlich an, dass ein weiteres Gerät dieselbe MAC hat wie der Gateway. Komisch. Laut MAC ein Samsung Gerät. Seltsam.

Nach etwas Recherche wird der Accesspoint gefunden, wo sich das Samsung Gerät angemeldet hat – tatsächlich handelte es sich um das Handy eines Mitarbeiters (der glaubhaft keine Ahnung von dieser Materie hat).

Dieses Gerät spooft also unseren Gateway, sobald der Mitarbeiter im Hause war (doppelt gemein: nur Teilzeit bei unregelmäßigen Arbeitszeiten, was das inkonsistente Fehlerbild erklärt 🙂 )

Tatsächlich hat sich der Kollege einen mutmaßlichen Trojaner eingefangen, der bei WLAN Verbindung ein ARP-Spoofing gestartet hat  – und das sicher nicht ohne Grund.

Somit ist davon auszugehen, dass wegen eines einzelnen kompromittierten Handys sämtliche (Klartext)passworte, die über das Netzwerk abgesetzt wurden ausspioniert wurden. Firewall hin oder her.