Zum Hauptinhalt Zur Navigation Zur Suche

Protokollanalyse: Mogeln im Quizduell

Entwickler verlassen sich zu sehr auf HTTPS und verzichten auf grundlegende Sicherheitsmaßnahmen. Über eine Man-in-the-Middle-Attacke konnten Security-Forscher in den Datenverkehr zwischen App-Server und Apps hineinsehen – und entdeckten Sonderbares.
/ Jörg Thoma
41 Kommentare News folgen (öffnet im neuen Fenster)
Peter Frühwirt und Sebastian Schrittwieser zeigen, dass Entwickler sich kaum um die Sicherheit ihrer Apps kümmern. (Bild: Jörg Thoma/Golem.de)
Peter Frühwirt und Sebastian Schrittwieser zeigen, dass Entwickler sich kaum um die Sicherheit ihrer Apps kümmern. Bild: Jörg Thoma/Golem.de

Die Angriffsmethode ist seit langem bekannt, aber sie wird immer noch von zahlreichen Entwicklern ignoriert: Über einen Man-in-the-Middle-Angriff haben sich die beiden Sicherheitsforscher Peter Frühwirt und Sebastian Schrittwieser aus Österreich in den Datenverkehr zwischen App-Server und Smartphones eingeklinkt und teils sonderbare Schwachstellen entdeckt. Ihr Fazit: Die Entwickler vertrauen noch zu sehr darauf, dass HTTPS ausreichend Schutz vor Protokollanalyse bietet.

Spätestens seit Bekanntwerden der Goto-Lücke unter iOS und Mac OS X sowie in Linux-Anwendungen müssten Entwickler gewarnt sein. Mit einem gefälschten Zertifikat auf einem Client sind viele HTTPS-Verbindungen nicht mehr sicher. Denn nach dem Chain-of-Trust-Prinzip muss für viele Server lediglich ein vertrauenswürdiges Root-Zertifikat vorliegen.

Teils lustig, teils beängstigend

Was sich offenbart, wenn sich der HTTPS-Datenverkehr mitschneiden lässt, präsentierten(öffnet im neuen Fenster) Frühwirt von dem Sicherheitsunternehmen SBA Research(öffnet im neuen Fenster) und Schrittwieser von der Fachhochschule St. Pölten(öffnet im neuen Fenster) auf der Sicherheitskonferenz Troopers 14 in Heidelberg(öffnet im neuen Fenster). Dabei zeigten sie auch merkwürdige und lustige Fehler. Aber selbst der Datentausch zwischen Clients und einigen Banken sei durch Man-in-the-Middle-Angriffe verwundbar, warnen die Forscher.

Für ihre Analyse verwendeten Frühwirt und Schrittwieser den Proxy-Web-Debugger Charles(öffnet im neuen Fenster). Dessen Root-Zertifikat installierten sie zu Demonstrationszwecken auf einem iPhone. Der Proxy leitete dann Daten von dem Smartphone zum App-Server und zurück. Wegen des aus dem Web übernommenen Chain-of-Trust-Prinzips wunderte sich der jeweilige Applikationsserver nicht über die neu zertifizierte Verbindung. Schließlich vertraute der Client ja bereits dem Charles-Zertifikat.

Antworten mitgeliefert

Jetzt offenbarte sich Frühwirt und Schrittwieser, welche Daten Apps und Server sich hin- und herschicken. Quizduell zum Beispiel: Dort lässt sich großartig mogeln. Denn vom Server werden die korrekten Antworten im Klartext direkt auf das Smartphone übermittelt bevor der Nutzer antwortet und nicht mit dem Server per Token abgeglichen.

Dass solche Einblicke in das Protokoll selbstverständlich auch die Privatsphäre verletzen können, zeigt ein anderes Beispiel. Frühwirt und Schrittwieser konnten anhand der Nummerierung in einer Fototausch-App ein bestimmtes Muster erkennen. Sie luden daraufhin die ersten Fotos herunter, die mit der App gemacht wurden. Sie waren höchstwahrscheinlich von dem Entwickler selbst, von seinem Laptop, von seinen Füßen und von seinem Auto. In einem anderen Fototauschdienst filterten die beiden nach Fotos von über 18-Jährigen und fanden fast ausschließlich männliche Nackt-Selfies.

Gegenmaßnahmen

Eine Maßnahme gegen falsche Zertifikate wäre das sogenannte Zertifikat-Pinning. Dabei akzeptiert der Server nur sein eigenes Zertifikat, das dann allerdings mit der App ausgeliefert werden muss. Unter Android wäre es möglicherweise ein Leichtes, das Zertifikat-Pinning zu umgehen. Auch unter iOS habe es bereits Probleme damit(öffnet im neuen Fenster) gegeben, geben die beiden Forscher zu bedenken. Ohnehin verwendet lediglich einer von vier Entwicklern der von den beiden untersuchten Apps die zusätzliche Sicherheitsmaßnahme. Selbst viele Banken verzichten darauf.

Eine weitere Möglichkeit wäre die Verifizierung der Daten über einen sicheren Seitenkanal. Am Beispiel der öffentlichen Verkehrsgesellschaft Wiener Linien erklären Frühwirt und Schrittwieser, dass auch das nicht immer konsequent umgesetzt werde. Trotz ausreichend fälschungssicherem 2D-Barcode hätten die meisten Kontrolleure gar keinen geeigneten Scanner dabei.

Der Rat der beiden Forscher: Entwickler sollten niemals dem Client vertrauen. Jede Anfrage des Clients sollte vom Server auf seine Gültigkeit überprüft werden.


Relevante Themen