•  

AppGefahren

Auch in Deutschland ist der Markt für mobile Apps ein Wachstumsmarkt. Laut Bitkom wurde mit dem Verkauf von mobile Apps für Smartphones und Tablets in Deutschland 2018 etwa dreimal so viel Umsatz erzielt als im Jahr 2013, nämlich 1,6 Milliarden Euro [1]. Das ist nicht weiter verwunderlich, ersetzt doch zunehmend das Smartphone den heimischen PC oder Laptop, wenn es um die Erledigung von so alltäglichen Dingen wie das Online-Banking, das Melden von Stromverbrauchswerten oder die Verwaltung der eigenen Versichertendaten einer Krankenversicherung geht. Doch wie ist es um die Sicherheit der mobilen Apps bestellt? Was können Unternehmen tun, um in Zeiten von DSGVO und Hacker-Angriffen die Daten ihrer Kunden zu schützen und den Datenschutzanforderungen gerecht zu werden? Was bei Webapplikationen schon länger üblich ist, gilt in gleichem Maße für mobile Apps: Bereits im Entwicklungsprozess sollte die Einhaltung der gestellten Sicherheitsanforderungen durch geeignete Tests verifiziert werden. Dies umfasst sowohl die mobile App, das Front- bzw. Backend und den Kommunikationskanal. Worauf bei Sicherheitstests für mobile Apps alles geachtet werden muss, zeigt der folgende Artikel.

Mit Methode

Die bekannten Ausprägungen von Sicherheitstests im Sinne ihres Prüfungsansatzes lassen sich natürlich auch in die Welt der mobilen Apps übertragen.  

So werden beim White-Box-Ansatz alle Information dem Prüfer offengelegt. Darunter versteht sich im Kontext der mobilen Apps die Bereitstellung des Quellcodes der App, der Dokumentation und der Zugangsdaten mit allen Berechtigungsebenen. Hinzu kommen die Information zu Abläufen in der App und die Kommunikationsweise, sowie die genutzten Endpunkte auf Serverseite in Form von Komponenten- und Sequenzdiagrammen. Vorhandene Sicherheitsmaßnahmen werden folglich offengelegt. Durch die gegebene Transparenz kann ein Auditor viel effizienter Testen und deutlich komplexere Testfälle abdecken.

Im Gegensatz zum White-Box Ansatz werden beim Black-Box-Ansatz keine Informationen außer die zu prüfende App bereitgestellt. Der Hauptzweck dieses Tests besteht darin, dem Tester zu ermöglichen, sich wie ein echter Angreifer zu verhalten. Die so aufgedeckten Schwachstellen sind somit diskussionsfrei auch von anderen zu finden, jedoch ist der Aufwand der Analyse bei gleichem Ergebnisanspruch um ein vielfaches höher als im ersten Ansatz.

Das Prinzip einer Grey-Box-Prüfung liegt als Mittelstück zwischen den beiden zuvor genannten. Wobei sich die bereitgestellten Informationen unterscheiden können. Meist sind es Zugangsdaten und/oder Beschreibungen zu Abläufen in der Anwendung. Alternativ kann Quellcode ohne Zugangsdaten auch in diesen Bereich fallen.

Wurde über den zu verfolgenden Ansatz entschieden, so bestimmen die gegebenen Information den Ablauf der Analyse-Phase. Die Analyse wird in zwei Bereiche, nämlich statische und dynamische Analyse, unterteilt, wobei diese je nach bereitgestellten Informationen sequenziell oder parallel erfolgen würde.

Statische und Dynamische Analyse

Beim statischen Application Security Testing (SAST) werden die Komponenten einer Anwendung untersucht, ohne sie auszuführen, indem der Quellcode entweder manuell oder automatisch analysiert wird.  Wohingegen das dynamische Application Security Testing (DAST) die Applikation zur Laufzeit untersucht. Das Interactive Application Security Testing (IAST) kombiniert beide Ansätze.

Während der statischen Analyse wird der Quellcode der mobilen App auf die sichere Implementierung der Funktionalitäten hin untersucht. Ist der Quellcode dem Prüfer nicht vorliegend, so muss zuerst mittels Reverse Engineering versucht werden, den ursprünglichen Quellcode wieder zu berechnen. Ansonsten kann auch der kompilierte Programmcode statisch analysiert werden, was im manuellen Prozess jedoch erheblich aufwendiger ist als der Weg mit Quellcode.

In der statischen Analyse kommen automatisierte Tools zum Einsatz, welche den Quellcode auf bekannte Schwachstellen und Fehlkonfigurationen untersuchen. Leider ist dieser Prozess durch fehlendes Verständnis für die Logik der App oft durch viele falsche Feststellungen geprägt, was für einen Auditor bedeutet, dass die Schwachstellen zwingen verifiziert werden müssen.

In der manuellen Prüfung wird der Quellcode betrachtet, um ein Verständnis für die Architektur und die Bestandteile zu gewinnen, welche dann in der weiterführenden Analyse von vermeintlich kritischen Funktionen zur Gewinnung von Schwachstellen führen soll. Somit können mit diesem Verfahren besonders gut Fehler in der Business Logik und im Design aufgedeckt werden.

In der dynamischen Analyse werden Schwachstellen in Echtzeit, also während der Ausführung identifiziert. Neben den Abläufen in der App wird auch die Kommunikationssicherheit zu den Endpunkten betrachtet. Erfolgt diese nach Stand der Technik verschlüsselt? Welche Daten werden übertragen und sind diese durch entsprechende Authentisierung und Autorisierung geschützt? Aber auch die Datenhaltung auf den Geräten kann betrachtet werden.

Die Analyse der Applikation zur Laufzeit kann durch die Ausführung in virtuellen Maschinen oder auf echten Geräten erfolgen. Virtuelle Maschinen erlauben sofort die Analyse des Arbeitsspeichers, wohingegen echte Geräte hierfür vorbereitet werden müssen.

Eine Analysemethode zur Laufzeit, die inzwischen sehr große Bedeutung gewonnen hat, ist das dynamische Instrumentieren. Hierbei wird ein Gerät oder die App so verändert, dass sie durch Analysefunktionalität das Mitlesen und Manipulieren von Methoden-Aufrufen zur Laufzeit erlaubt. Dies werden wir in zwei Beispielen weiter unten vorführen.

Die Top Ten

Einer der wichtigsten Prüfungsrichtlinien im Bereich der mobile App Sicherheit ist der OWASP mobile Security Testing Guide [2] und die dazugehörige Liste der häufigsten Sicherheitsrisiken im mobile App Bereich, die OWASP mobile Top 10 2016 [3]. Die Relevanz dieser Auflistung von unterschiedlichen Arten von Schwachstellen ist auch heute noch aktuell. Die folgende Tabelle listet diese Schwachstellenkategorien auf und führt Beispiele an, um diese für den Leser praxisnah verständlich zu machen.

 

[4] [5]

Um das Ganze zu illustrieren, wollen wir zeigen, wie ein Penetrationstest im Bereich der mobilen Apps durchgeführt wird und anhand einiger Beispiele etwas tiefer ins Detail gehen.

Planung ist unverzichtbar

Das wichtigste in der Vorbereitungsphase ist, wie in jedem Penetrationstest, die präzise Definition des Prüfumfangs. Im Kontext von mobile Apps gilt es unter anderem zu bewerten,

  • ob und in welcher Tiefe (netzwerkseitige Analyse / Konfigurationsprüfung) auch die zugrundliegende Server-Infrastruktur untersucht werden soll,
  • welche APIs des Front- bzw. Backends prüfungsgegenständlich sein sollen,
  • wie Schnittstellen zu Dritten behandelt werden sollen,
  • ob und von welchen Komponenten der Quell-Code geprüft werden soll und
  • in welchen Nutzerrollen / Berechtigungsstufen die Tests ausgeführt werden sollen.

Zentrale Fragestellung ist zudem auch, ob für die Prüfungen eine uneingeschränkt prüfbare Testumgebung bereitgestellt werden kann oder Einschränkungen berücksichtigt werden müssen.

Auf Seiten des Prüfers schlagen sich die Besonderheiten im Rahmen der Prüfung von mobile Apps auch im Aufbau einer geeigneten Prüfumgebung nieder. Diese sollte folgende Elemente umfassen.

  • iPhones und iPad, idealerweise mindestens ein Gerät mit Jailbreak
  • Apple Computer, welcher xCode (ggf. in unterschiedlichen Versionen) und die notwendigen Software Tools installiert hat (dazu später mehr)
  • Android Geräte, welche ein möglichst breites Spektrum an unterschiedlichen Android Versionen abdecken
  • Rechner, an welchen die Android Geräte angeschlossen werden können und auf denen die zum Testen notwendigen Tools laufen

Software-seitig gilt es zu beachten, dass die Welt der mobilen Apps schnelllebig ist. Dasselbe gilt auch für die Werkzeuge, die einem Pentester zur Verfügung stehen. Manche Tools, die gestern noch aktuell waren, funktionieren auf der nächsten Version des Betriebssystems schon gar nicht mehr. Man muss also ständig am Ball bleiben und die gegenwärtigen Entwicklungen verfolgen. Eine Auflistung aller verfügbaren Tools ist also weder zielführend, noch kann sie jemals wirklich vollständig sein. Aber einige Tools, welche sich über die Jahre gehalten haben und sowohl für iOS als auch für Android relevant sind, seien hier erwähnt:

  • Burpsuite [6]
  • Frida[7]
  • Objection [8]
  • Mob-SF [9]

Informationsbeschaffung und Mapping

Für die spätere Risikobewertung der Feststellungen ist essentiell, die Kritikalität der in der mobilen App verarbeiteten Daten aus Informationssicherheitssicht und Datenschutzsicht zu kennen. So sollten die im Rahmen der Entwicklung oder in der Betriebsumgebung umgesetzten Schutzmaßnahmen risikoorientiert ausgewählt worden sein. Bei einer Verarbeitung von personenbezogenen Daten ist eine nach Stand der Technik wirksame Transportverschlüsselung und verschlüsselte Speicherung in der Regel unumgänglich.

Aufgabe des Prüfers ist es, die Wirksamkeit dieser Maßnahmen explizit zu verifizieren – und zwar für alle unterstützten Plattformen, da je nach Architektur unterschiedliche Schwachstellen bestehen können. So ist z.B. unten beschriebenes Method Swizzling ein Feature der Sprachen Objective-C und Swift. Somit ist dieses Feature als Angriffsvektor im Java-basiertem Android nicht vorhanden.

Weiter sollten, analog zu einer Webapplikation, alle in der jeweiligen App angebotenen Funktionen und abbildbaren Use-Cases ausprobiert und auf ihre jeweilige Implementation hin geprüft werden. Lassen sich etwa Authentifizierungsmechanismen umgehen, wenn der Anwender vom dafür vorgesehenen Use-Case abweicht?

Man-in-the-Middle Angriffe

Obwohl in den meisten Applikationen, die bei uns im Hause geprüft wurden, SSL/TLS zum Verschlüsseln der Kommunikation zum Einsatz kommt, gab es immer wieder Fälle, in denen die Kommunikation teilweise mit Klartextprotokollen erfolgte.

Aber auch die richtige Implementation von SSL/TLS spielt eine wichtige Rolle. Eine wirksame Maßnahme stellt das sogenannte Certificate Pinning dar. Dies ist ein Schutzmechanismus, bei dem die mobile App, idealerweise schon vor der Auslieferung ein von einer vertrauenswürdigen Certificate Authority (CA) signiertes X.509 Zertifikat (oder Public Key) beinhaltet, mit dem der Backend-Server eindeutig als dieser identifiziert werden kann. Damit soll erreicht werden, dass sich die mobile App nur mit dem designierten Backend-Server verbindet und sonst alle anderen Verbindungen verwirft.

Dies ist insofern wichtig, als dass bei einem Man-in-the-Middle (MITM) Angriff, der mobile App eine sichere Verbindung zu einem Backendserver vorgegaukelt werden kann, wenn kein Certificate Pinning  implementiert ist.

Paradoxerweise muss genau dieses Sicherheitsfeature in der Testumgebung ausgehebelt werden, um ein möglichst genaues Bild vom Verhalten der Applikation in der dynamischen Analyse zu erzielen. Je nach Art des Tests, (Grey-/Whitebox-Test) kann zusätzlich auch eine spezielle Version der mobilen App mitgeliefert werden, welche das Certificate Pinning schon von sich aus deaktiviert hat. Weiter kann es auch Bestandteil des Pentests selbst sein, herauszufinden, wie leicht, oder wie schwer es ist, das Certificate Pinning auszuhebeln.

Aber bleiben wir beim gesetzten Fall, dass die Applikation, in unserem Beispiel eine iOS App, im Auslieferungszustand untersucht werden soll. Es gibt einige Tools, welche uns es auf einem Gerät mit Jailbreak erlauben, Certificate Pinning [10] per Knopfdruck abzuschalten. So gibt es für iOS Geräte mit Jailbreak etwa „SSL Kill Switch 2“, welches oft verwendete high-level API Aufrufe kennt und umgeht.

Falls das Certificate Pinning hingegen in einer maßgeschneiderten SSL/TLS Implementierung verwirklicht wurde, kann diese Aufgabe sehr zeitaufwendig sein. 

Im folgenden Beispiel zeigen wir, wie man sich mit Hilfe von „Burpsuite“ und „SSL Kill Switch 2“ als Proxy, also als „Man-in-the-Middle“ in eine HTTPS Verbindung einer Applikation einschleifen kann. Dazu sendet unsere Test Applikation DVIAv2 eine HTTPS Anfrage an den example.com Server auf Port 443.

Unser iPhone Testgerät ist über WLAN mit dem Internet verbunden und hat den Server des Auditors, auf dem Burpsuite läuft, als Proxy gesetzt. Weiter wurde das Burp Client Certificate im Testgerät installiert.

Das Interface der Test Applikation bietet die Möglichkeit, einen Satz von Testdaten via HTTPS zu verschicken.

Diese wollen wir nun im Burpsuite Proxy abgreifen, jedoch kann der Client (also die App) die Anfrage nach einer SSL Verbindung nicht vollenden und im Burpsuite Proxy wird folgende Fehlermeldung ausgegeben.

 

Hier hilft das Pentesting Tool „SSL Kill Switch 2“, welches das Certificate Pinning auf der Seite des Clients unterbricht, und somit es dem Client erlaubt, eine SSL Verbindung ohne Certificate Pinning aufzubauen. Das Tool benötigt ein iOS Testgerät mit Jailbreak und kann dann durch einfaches Umlegen eines Schalters das Certificate Pinning unterbinden.

 

Somit lässt sich jetzt durch den Pentester die Kommunikation zu den Endpunkten auf den Backendservern der App untersuchen. Auch illustriert dieser Punkt, wie wichtig es ist, dass die mobile Apps Certificate Pinning aktiviert haben. So könnte ein Angreifer in einem öffentlichen WLAN [11] , den Verkehr einfach umleiten und über seinen eigenen Proxy (analog zu Burpsuite) abgreifen. Dies wäre, wie hier gezeigt, mit aktiviertem Certificate Pinning nicht möglich.

 

Abschalten der Jailbreak-Detection zur Laufzeit auf iOS (Method Swizzling)

Ein Angriffsvektor welcher nur für Apple iOS relevant ist, ist das sogenannte Method Swizzling. Damit ist nichts anderes als das Verändern von Methoden zu deren Laufzeit gemeint. Das ist dadurch möglich, das in Objective-C und auch in Swift jede Implementation einer Methode einen bestimmten Key zugeordnet bekommen hat, anhand dessen bestimmt wird, welche Methode intern (vom Program-Kernel) aufgerufen wird. Diese Verbindung von Key und Implementation wird in einer Tabelle festgehalten, welche mit Tools wie etwa Frida zur Laufzeit des Programmes geändert kann.

Method Swizzling ermöglicht somit, dass bestehende Methoden durch eigene Methoden ausgetauscht werden können (die ursprüngliche Methode wird als Kopie im Speicher gehalten). So kann man etwa die Jailbreak Detection mancher Apps dadurch umgehen, dass man die Methode, welche den Jailbreak erkennt, dahingehend ändert, dass diese immer den Wert „False“ zurückgibt. Die App nimmt also somit immer an, sie würde in einer sicheren Umgebung laufen.

Wir wollen das Ganze einmal anhand der absichtlich verwundbar gemachten iOS App DVIAv2 (Damn Vulnerable iOS App Version 2) [12]  praktisch darstellen.

Wir haben dafür eines unserer iOS Testgeräte mit Jailbreak genommen. Dort ist neben der DVIAv2 auch Frida installiert. Frida wiederum bietet die Basis für das Tool Objection, welches uns in diesem Fall helfen wird. Als erstes benutzen wir folgendes Kommando, um mit Objection die DVIAv2 zu öffnen:

Falls die App schon gestartet ist, wird sie jetzt erneut gestartet und wir erhalten das Kommandozeileninterface von Objection, welches uns eine Menge an unterschiedlichen Möglichkeiten zur Erforschung und Manipulation der verwundbaren DVIAv2 App gibt. DVIAv2 hat 5 verschieden Arten, um das Gerät auf Jailbreaks zu prüfen. In unserem Beispiel versuchen wir die zweite dieser Methoden „Jailbreak Detection 2“ zur Laufzeit zu beeinflussen. 

Als nächstes wollen wir nach Methoden suchen, welche für den Test der Jailbreak Funktionalität in Frage kommen. 

 

Wir sehen, einige der Methoden beschäftigen sich mit dem Thema Jailbreak, doch genau welche verwendet die Applikation im Hintergrund bei Drücken des Knopfes „Jailbreak Detection 2“?

 

Auch hier hat Objection bereits ein Kommando, mit dessen Hilfe wir Methoden hooken [13] können, um dadurch zu erkennen, ob und in welchem Kontext diese ausgeführt werden und welcher Wert dann zurückgeben wird. Wir müssen jetzt also so lange probieren, bis wir die Methode ausfindig gemacht haben, welche beim Drücken des Knopfes „Jailbreak Detection 2“ ausgeführt wird. Gleich die erste, im Screenshot markierte Methode, ist die Richtige.

Nun wir es interessant. Objection erlaubt uns auch noch den Rückgabewert dieser Methode durch besagtes „Method Swizzling“ zu verändern.

 

Das Ergebnis sieht gut aus. Der Jailbreak Mechanismus wurde gefunden und erfolgreich so manipuliert, dass das Programm nun annimmt, es würde auf einem iPhone ohne Jailbreak laufen. 

Fazit

Mit der zunehmenden Verbreitung von mobile Apps und der Abbildung von sicherheitskritischen und datenschutzrelevanten Prozessen rücken diese mehr und mehr in den Fokus von Angreifern. Ob nun Banking Trojaner, getarnt als die eigentliche Banking App auf Android, oder die dynamische Manipulation der originalen App zur Laufzeit, um Zugriff auf (vermeintlich) geschützte Daten in der Infrastruktur des App Betreibers zu erlangen, die Liste der Angriffe ist lang. Daher ist die Berücksichtigung von Informationssicherheits- und Datenschutzanforderungen im Entwicklungsprozess im Einklang mit einem umfassenden Testverfahren, welches die statischen und dynamischen Methoden sinnvoll kombiniert, entscheidend für die Entwicklung sicherer mobile Apps.
 

Autoren: Tobias Mayer, Manuel Weber, GAI NetConsult GmbH

www.gai-netconsult.de

Quellen:

https://www.bitkom.org
Opens external link in new windowhttps://github.com/OWASP/owasp-mstg
https://www.owasp.org
Opens external link in new windowhttps://medium.com/@c0nk3r
https://www.bsi.bund.de
https://support.portswigger.net
https://www.frida.re/docs/home/
Opens external link in new windowhttps://github.com/sensepost/objection
Opens external link in new window https://github.com/MobSF
10  https://www.guardsquare.com
11  https://www.heise.de
12  Opens external link in new windowhttps://github.com/prateek147
13  Ungefähr: Eigenen Code im Kontext des App Prozesses zur Ausführung bringen.

Autor: Tobias Mayer, Manuel Weber

Diesen Artikel empfehlen