Wie sicher ist meine App?

Die wenigsten mobilen Apps kommen mit statischem Content aus. Meist werden für das Laden von dynamischem Content http-basierte Protokolle verwendet. Dieser Artikel beschreibt, was bei der Sicherung einer http Verbindung mittels SSL beachtet werden sollte und wie man man-in-the-middle Attacken verhindern kann.

codefluegel-app-security

Die Client-Server Verbindung einer App ist meist von großer sicherheitstechnischer Relevanz. Oft werden hier Username und Passwort eines Benutzers, oder aber auch rechtlich geschützte Medien übertragen. Nehmen wir an, unsere App lädt ein Video von unserem Server, das sie dann abspielt. Das Video ist beispielsweise unter folgendem Link erreichbar:

http://my-app.codefluegel.com/5a6d5732-5178-46d1-9b36-49541ce9a183/secret_video.mp4

Nun sollte dieser Link möglichst nicht öffentlich bekannt werden. Generell sollte man den Link auch nicht erraten können. Das würde jede Sicherheitsvorkehrung ad absurdum führen. Dies wird hier durch einen langen (hier 128 bit) Unterordnernamen erreicht. Diese Vorgehensweise wird relativ häufig verwendet (z.B.  bei der Share Link Funktion von Dropbox).

Probleme und Lösungsansätze für App Sicherheit

Ein Angreifer wird hier nicht nur versuchen, die URL zu erraten, sondern diese bei der Übertragung festzumachen. Ohne Verschlüsselung kann die URL ganz einfach abgehört werden. Vom Benutzer der App kann dies zum Beispiel am WLAN Router, an dem das Smartphone mit der App hängt, erfolgen. Für so einen Angriff sind zwar Netzwerkkenntnisse notwendig, ein Experte in Sachen Netzwerkadministration muss man allerdings nicht sein. Auch kann jeder, der Zugriff auf die Netzwerkknotenpunkte zwischen dem Gerät und dem Server hat, die URL auslesen.

Der erste offensichtliche, und auch erforderliche Schritt um die App Sicherheit zu gewährleisten, ist hier die Sicherung der Verbindung per SSL. Der Link würde dann wie folgt aussehen:

https://my-app.codefluegel.com/5a6d5732-5178-46d1-9b36-49541ce9a183/secret_video.mp4

Hier lässt sich dann mit der oben genannten Abhörmethode nur noch die Server-IP und (in den meisten Fällen) der Hostname (my-app.codefluegel.com) herausfinden. Dies stellt erst mal eine große Verbesserung der Verbindungssicherheit dar. Mit etwas mehr Wissen kann ein Angreifer den Link aber trotzdem ohne allzu großem Aufwand auslesen. Dies ist mit einer sogenannten Man-in-the-middle Attacke möglich.

Die Man-in-the-middle (MITM) Attacke

Https Verbindungen gewährleisten End-to-End Verschlüsselung. Das heißt, nur die beiden Endpunkte können die Kommunikationsdaten im Klartext sehen. Im folgenden Diagramm ist diese Verbindung grün gestrichelt eingezeichnet:

client-server-connection-de

Bei einer MITM Attacke wird diese sichere Kommunikation dadurch ausgehebelt, dass unbemerkt von Server und der Client App zwei https Verbindungen aufgebaut werden. Die Erste zwischen dem Client und einem dritten Teilnehmer im Lokalen Netzwerk (hier „Angreifer“ genannt), und eine weitere vom Angreiferrechner zum Server. Ein gefälschtes SSL Zertifikat und ein DNS Eintrag im lokalen Netzwerk, das den Hostnamen my-app.codefluegel.com  mit der lokalen IP des Angreiferrechners verknüpft, reichen aus, um den Client glauben zu lassen, der Angreiferrechner sei der Server. Dieser wiederum baut eine https Verbindung zum „echten“ Server auf und gibt sich diesem gegenüber als Client aus. Somit entschlüsselt der Angreifer die Kommunikationsdaten des Clients und verschlüsselt diese dann wieder über die zweite https Verbindung zum Server. Dadurch kann er die gesamte Kommunikation mitlesen, und sogar veränderte Daten weiterleiten.

Eine solche Attacke ist relativ schnell implementiert, und man kann das benötigte Setup für beliebige Apps und Webseiten wiederverwenden.

Vermeidung von MITM Attacken

Um dieses Sicherheitsproblem in den Griff zu bekommen, muss die App mit einem Client-Zertifikat ausgeliefert werden. Der Server kann dann beim Aufbau der Verbindung überprüfen, ob der Client das mitgelieferte Zertifikat verwendet. Fast alle gängigen Webserver beherrschen diese Checks. Eine Beispielkonfiguration für nginx findet sich hier. Nun akzeptiert der Server das gefälschte SSL Zertifikat des Angreifers nicht  mehr, und die oben beschriebene Attacke kann nicht länger durchgeführt werden. Auch der Client kann das Server Zertifikat gegenchecken.  Um zu verhindern, dass der Download eines Tages nicht mehr funktioniert, ist zu beachten, dass das Ablaufdatum des Clientzertifikates weit genug in der Zukunft liegen sollte.

Limitierungen

Mit der oben genannten Methode kann ein großer Teil der der MITM Attacken verhindert werden. Perfekte Sicherheit kann man aber nie erreichen. Zu möglichen Sicherheitsrisiken zählen:

– Implementierungsfehler im eigenen Code oder in der SSL Library (siehe Heartbleed Bug)
– Auslesen des Client Zertifikates und des Zertifikatschlüssels aus dem App Package (.ipa oder .apk)
– Bekanntwerden des Serverseitigen SSL Schlüssels (meist wegen sorglosen Umgangs)
– Sicherheitskritische Fehler in den verwendeten Algorithmen oder im SSL Protokoll

Manche dieser Risiken können mit viel Aufwand minimiert, aber nie ganz ausgeschlossen werden.

Zusammenfassung von App Sicherheit

Perfekte Sicherheit gibt es bei der Datenübertragung nicht. Das Abhörrisiko kann jedoch durch die Verwendung von SSL und das Gegenchecken der Zertifikate erheblich gemindert werden.

Für weitere Details und Fragen stehen wir gerne zur Verfügung!