Wie bereits in dem Vorgängerartikel beschrieben, gibt es ähnlich wie die OWASP Top 10 für Web-Applikationen eine Top 10 spezifisch für mobile Applikationen vom Application Security Project. Diese Wissenssammlung beschäftigt sich mit den häufigsten und kritischsten Schwachstellen bei Applikationen für Mobile Systeme.
Hierbei wird eine Vielfalt von Plattformen in Betracht gezogen, wie z. B. Android oder iOS.
Das Ziel dieses Blog-Artikels ist es, Entwickler über die wichtigsten Fallstricke bei der Entwicklung mobiler Apps aufzuklären. Wir orientieren uns bei unseren Mobile Application Penetration Tests unter anderem an diesem Dokument, um möglichst gründliche Überprüfungen zu garantieren.
Die aktuelle Version der OWASP Mobile Top 10 ist von 2016. Die genaue Zuordnung einer Schwachstelle zu einer der folgenden Themenbereiche ist oftmals schwer und die Beschreibungen überlappen sich gelegentlich.
Zusammen sollten diese Kategorien alle gängigen Schwachstellen von mobilen Applikationen abdecken. Dieser Blogartikel soll Ihnen kurz alle Kategorien näher bringen, um das Bewusstsein für Sicherheit im Bereich der Mobilen Applikationen zu steigern.
Unpassende Benutzung der Plattform (M1 – Improper Platform Usage)
Diese sehr breit gefächerte Kategorie umfasst alle Schwachstellen, die auftreten, wenn plattformspezifische Sicherheitsempfehlungen nicht umgesetzt werden. Sowohl für Android als auch für iOS gibt es umfassende Dokumente für die sichere Entwicklung auf den jeweiligen Systemen.
Für Android gibt es hier beispielsweise offizielle Dokumentationen zu Android Security Allgemein und Android Security speziell für Entwickler.
Der Leitfaden behandelt unter anderem Themen wie die sichere Speicherung und Verifikation von Daten, Intents, Rechte sowie sichere Kommunikation.
Apple befasst sich mit der sicheren Verwendung der TouchID, Durchführung und Prüfung von Inter Process Communication (IPC) und dem sicheren Design von Hintergrundprozessen. Hierfür wird eine Onlinedokumentation für sichere Programmierung geboten sowie eine Dokumentation für allgemeine iOS Sicherheit bereitgestellt.
Diese Kategorie überschneidet sich mit vielen der nachfolgenden, da alle folgenden Themen in solchen Leitfäden behandelt werden können, demnach werden auch die meisten Fallstricke in den plattformspezifischen Hilfswerken behandelt.
Das macht sie zu unumgänglichen Hilfswerken für die sichere Programmierung von mobilen Applikationen.
Unsichere Datenspeicherung (M2 – Insecure Data Storage)
Verlust von persönlichen oder anderweitig vertraulichen Daten ist leider ein bekanntes Thema, von dem man immer wieder in den Nachrichten hört.
Hier gibt es zwei Angriffspunkte bei mobilen Apps: durch andere Apps auf dem Gerät oder durch physischen Zugriff. Je nach Art der gespeicherten Daten entsteht hierdurch eine Gefahr für die Privacy des Benutzers oder auch die Integrität der App.
Datenspeicherung betrifft in diesem Fall nicht nur das bewusste Ablegen von Datensätzen auf dem Endgerät, wie z. B. in Datenbanken oder Textdateien, sondern auch das Zwischenspeichern in verschiedenen Caches.
Vertrauliche Daten müssen deswegen verschlüsselt gespeichert werden. Logs über das System sollten nicht als geheim angesehen werden und die plattformspezifischen Keystorages müssen korrekt verwendet werden.
Ein Beispiel für eine iOS App mit unsicherer Datenspeicherung ist iGoat. Die exemplarische App präsentiert eine Vielzahl von Schwachstellen, unter anderem die unsichere Speicherung von Daten auf dem Endgerät.
Die iGoat App speichert vertrauliche Daten in einer lokalen SQLite-Datenbank unverschlüsselt ab, somit sind die Zugangsdaten der App für jeden lesbar, der diese lokalen Dateien auslesen kann.
Unsichere Kommunikation (M3 – Insecure Communication)
Der Themenbereich unsichere Kommunikation umfasst nicht nur die klassische Kommunikation zu Webservices über das unverschlüsselte HTTP oder andere gängige Protokolle. Auch Datenübertragungen über Bluetooth oder NFC müssen beachtet werden.
Unzureichende verschlüsselte Kommunikation zu verschiedenen Webservices wie REST-Schnittstellen finden wir immer wieder bei unseren Audits. Transport Layer Security (TLS) mit einer vernünftigen Konfiguration, wie in unserem Blogartikel beschrieben, deckt diesen Themenbereich für die meisten Kommunikationen ab.
Zusätzlich sollte die App Serverzertifikate verifizieren, um Man in the Middle (MitM)-Angriffe zu erkennen.
Sollte eine App an sicherer Kommunikation scheitern, bedeutet das den kompletten Verlust der Integrität und der Vertraulichkeit von jeglichen Daten, die übertragen wurden.
Unsichere Authentifizierung (M4 – Insecure Authentication)
Authentifizierung ist ein kritischer Themenbereich, der bei allen Arten von Applikationen beachtet werden muss. Hier unterscheidet sich eine App für mobile Systeme nur im Detail, wie beispielsweise bei der Verwendung von TouchID für die Authentifizierung.
In diese Kategorie fallen zusätzlich auch jegliche Probleme mit dem Sitzungsmanagement.
Klassische Probleme, die wir bei Audits finden, sind z. B. die lokale Prüfung von Anmeldedaten oder auch die inkonsistente Verifikation der Sitzung.
Oftmals kommt es vor, dass auch nach einer sicher gestalteten Anmeldung bestimmte Aufrufe zum Backend die Sitzung nicht mehr validieren. Jegliche Aufrufe der App müssen auf eine gültige Sitzung geprüft werden. Die Anmeldeinformationen müssen immer auf dem Server geprüft werden.
Schwache Passwörter, wie die bei Apps gerne verwendete 4-Ziffern-PINs, sollten unbedingt vermieden werden.
Unzureichende Kryptografie (M5 – Insufficient Cryptography)
Der Einsatz von Kryptografie ist oftmals unumgänglich und unsichere Handhabung hat weitreichende Auswirkungen. Von unzureichender Kryptografie sind beispielsweise lokale, verschlüsselte Daten betroffen oder auch die Integritätsprüfung mittles veralteter Hashingfunktionen (z. B. RC2, MD4, MD5, SHA1, …).
Selbst entwickelte Verschlüsselungsmethoden müssen auf jeden Fall vermieden werden. Die Empfehlung der jeweiligen Plattform sollte beachtet werden (siehe „Unpassende Benutzung der Plattform“), da diese Vorgehen für sichere Verschlüsselung beschreiben.
Auch die sichere Handhabung von Schlüsseln kommt hier zum Tragen, nachdem auch der sicherste Verschlüsselungsalgorithmus keinen Schutz bietet, wenn der passende Schlüssel im Klartext verfügbar ist. Jegliche Art von Schlüssel sollte keinesfalls statisch in den Code eingepflegt (engl. hardcoded) werden.
Unsichere Autorisierung (M6 – Insecure Authorization)
Diese Kategorie ist wieder auf alle Arten von Anwendungen zutreffend. Wenn eine Applikation ein Rollen- und Rechtesystem verwendet, muss dieses durchgehend geprüft werden. Häufig werden Objekte direkt referenziert und fälschlicherweise wird angenommen, dass ein Benutzer nur über Schaltflächen in der Applikation auf diese Objekte gelangt. Wenn Dokumente oder andere Objekte direkt über eine ID (z. B. „https://www.example.com/beispiel/doc/42“) aufgerufen werden, muss unbedingt geprüft werden, ob der aufrufende Benutzer effektiv Zugriff haben sollte oder nicht. Eine lokale Überprüfung auf entsprechende Rechte für Funktionen oder Zugriff auf Daten ist nicht ausreichend – diese muss zwingend serverseitig erfolgen.
Unzureichende Autorisierung ist eine der häufigsten Schwachstellen, die wir bei Audits finden und hat gravierende Auswirkungen, die im schlimmsten Fall zur kompletten Übernahme der Applikation führen kann.
Mangelhafte Code Qualität (M7 – Client Code Quality)
Schwachstellen, die durch Programmierfehler der App, nicht die der Server-Komponente, entstehen, werden dieser Kategorie zugeordnet. Ein ganz klassisches Beispiel hierfür ist der Buffer Overflow, also wenn ein Zwischenspeicher einer bestimmten Größe erstellt wird, dieser aber durch fehlende Überprüfungen potentiell überfüllt werden kann.
Im Vergleich zu M1 „Unpassende Benutzung der Plattform“ identifiziert diese Kategorie nicht Schwachstellen aufgrund missachteter Leitfäden der Plattform, sondern der verwendeten Programmiersprache.
Die Auswirkungen solcher Schwachstellen ist von Fall zu Fall unterschiedlich, aber können bis zu kompletten Übernahme der Applikation bzw. des mobilen Endgerätes führen.
Hierbei sind allgemein gültige Programmierstandards und Richtlinien für die verwendete Programmiersprache zu beachten. Diese sind nicht unbedingt spezifisch für das jeweilige mobile System.
Code Manipulation (M8: Code Tampering)
Mobile Applikationen sind grundsätzlich anfällig für Code Manipulation, da die Applikation und die Plattform unter der Kontrolle des Benutzers sind.
Ein klassisches Ziel für Code Manipulation sind kostenpflichtige Zusatzfunktionen. Wenn eine Applikation kostenpflichtige Funktionen bereitstellt und erst nach einer Überprüfung für den Benutzer freischaltet, kann diese auch so angepasst werden, dass sie ohne Zusatzkosten aktiviert wird.
Als Gegenmaßnahme kann versucht werden, Manipulationen zu erkennen und deren Funktionalität zu unterbinden. Ebenso kann überprüft werden, ob die darunterliegende Plattform gerootet oder jailbroken ist – also ob der Benutzer auf dem System über administrative Rechte verfügt.
Hierbei sollte ein Entwickler sich damit beschäftigen, welche Auswirkung willkürliche Manipulation der Applikation hat und inwiefern prekäre Funktionen ausgelagert werden könnten.
Reverse Engineering (M9 – Reverse Engineering)
Ebenso wie bei „Code Manipulation“ gibt es kaum etwas, das effektiv gegen Reverse Engineering, das Nachkonstruieren der genauen Verhaltensweise der fertigen Applikation, schützt.
Codeverschleierung (engl. Obfuscation) wird oftmals als Lösung gegen Reverse Engineering angepriesen, jedoch bringt das im Idealfall lediglich einen Zeitgewinn. Ein motivierter Angreifer kann gegen Code Obfuscation einen etablierten De-Obfuscator verwenden oder kann manuell auf die genaue Verhaltensweise rückschließen. Die Verschleierung des Codes ist nicht komplett unnütz, aber sollte nicht als wirksamer Schutzmechanismus gesehen werden.
Es ist wichtig zu verstehen, dass es einem entschlossenen Angreifer durchaus möglich ist, auf die gesamte lokale Programmlogik zurückzuschließen.
Irrelevante Funktionalität (M10 – Extraneous Functionality)
Die letzte Kategorie beschäftigt sich mit jeglichen Funktionen, die nicht für die geplante Verwendung der Applikation relevant sind.
Es kommt häufig vor, dass Funktionen aus verschiedenen Entwicklungsstadien auch in der veröffentlichten Version der Applikation verfügbar sind. Ein klassisches Beispiel hierfür ist ein versteckter debugging oder administrativer Modus.
Deaktivierte oder für den Benutzer ausgeblendete Funktionen vergrößern die Angriffsfläche der Applikation und können zu Schwachstellen führen.
Zusammenfassend bieten die OWASP Mobile Top 10 ein weitreichendes Dokument sowohl für Entwickler als auch für Sicherheitsexperten, um Schwachstellen zu finden und zu vermeiden.
Wenn alle relevanten Punkte der Wissenssammlung beachtet werden, wird die Gesamtsicherheit der Applikation deutlich gesteigert.
Für praktische Beispiele von gewollt anfälligen mobilen Applikationen bieten sich die von OWASP entwickelten Apps iGoat (iOS) und GoatDroid (Android) an.
