Ungesicherte Einsichten

Seite 2: Testaufbau

Inhaltsverzeichnis

Selbst in verschlüsselten WLANs kann ein Angreifer unter Umständen mit ARP-Vergiftung die Datenpakete zwischen Mobiltelefon und Router über sich umleiten. Schlampt eine Mobil-App bei der Zertifikatsprüfung, kann er sogar SSL-Verbindungen abfangen.

Zum Test der insgesamt 20 Android- und 15 iPhone-Apps und -Systemkomponenten haben wir ein Setup aus gängigen, frei verfügbaren Angriffs- und Analysetools aufgebaut. Zwischen einen WLAN-Router mit WPA2-Verschlüsselung und seine Internetverbindung haben wir einen Rechner mit zwei Netzwerkkarten geschleift, auf dem die auf Sicherheits-Audits ausgelegte Linux-Distribution BackTrack 4 lief. Auf dem BackTrack-System setzten wir das Schnüffeltool ettercap ein, das diverse Protokolle wie HTTP, IMAP und SMTP interpretieren und gezielt nach Zugangsdaten durchsuchen kann. Auf einem Notebook im WLAN des Routers war ettercap auch in der Lage, den Netzwerkverkehr der beiden Smartphones per ARP-Poisoning und DHCP-Spoofing über sich umzuleiten.

Etwas trickreicher mussten wir beim Knacken der SSL-Verbindung vorgehen. Dafür verwendeten wir sslsniff, das sich mit gefälschten Zertifikaten in durchgehende Verbindungen einschleift, indem es eine eigene SSL-Verbindung zum Server aufbaut und dem Client ein gefälschtes Zertifikat schickt (siehe Bild). Dieser Angriff ist nur erfolgreich, wenn Clients (oder deren Nutzer) bei der Zertifikatsprüfung versagen.

Die Auswahl der Testkandidaten erfolgte anhand der vier Kategorien Systemdienste, E-Mail und Instant-Messenger, Soziale Netzwerke sowie Banking und Shopping. Hinzu kamen die wichtigsten Betriebssystemdienste wie Browser, Google Market und der AppStore. Auch den Dateisynchronisationsdienst Dropbox und das Web-basierte Notizbuch Evernote haben wir mitgetestet, da sie weit verbreitet sind. Die Tests erfolgten unter dem immer noch am weitesten verbreiteten Android 2.1 sowie unter iOS 4.0.3.

Oops, sslsniff hat ein Twitter-Passwort erwischt. Der Android-Client Twidroyd hat vergessen, das SSL-Zertifikat zu prüfen ...

Die Anwendungen lassen sich in drei Verschlüsselungskategorien einteilen. Ein Teil der Mobil-Apps verschlüsselt den kompletten Datenverkehr zu ihren Servern im Internet. Das ist unverzichtbar, wenn wie etwa bei einer Banking-Anwendung oder einem E-Mail-Programm ausschließlich schützenswerte Daten über die Leitung gehen.

... und ohne Murren unser gefälschtes akzeptiert.

Um den Rechenbedarf für Clients und Server kleinzuhalten, verschlüsseln andere Apps lediglich das Login und versenden die restlichen Anwendungsdaten im Klartext. So schlüpfen vielleicht doch mal schützenswerte Daten über die unverschlüsselte Verbindung – etwa die Notizbuchinhalte von Evernote. Außerdem kann ein Angreifer in der Regel den Inhalt der umgeleiteten Klartextpakete manipulieren und unter Umständen ist es sogar möglich, Sitzungsdaten für unautorisierte Zweitverbindungen zu missbrauchen.

Das dritte Konzept ist der völlige Verzicht auf Verschlüsselung – selbst für Logins. Dieses Verhalten mussten wir bei drei Android-Apps feststellen. Unverschlüsselte Logins enthüllen nicht unbedingt Nutzername und Passwort, weil sie sich beispielsweise mit Hash-Funktionen verschleiern lassen, aber unter Umständen sind Replay-Angriffe möglich, indem man die abgefangenen Logins noch einmal von einem anderen Gerät aus verschickt. Ob derartige Angriffe erfolgreich sind, hängt allerdings vom jeweiligen Dienst ab und erfordert eine tiefgehende Einzelfallanalyse, die über den Rahmen des Artikels hinausgeht.