Eine App-Sicherung für alle Fälle

Wie aber können Developer die Sicherheit von mobilen Anwendungen verbessern? Ein bewährtes Mittel ist es, einen Mix aus innovativen Technologien, bewährten Methoden und effizienten Werkzeugen zu verwenden, die schon frühzeitig im Entwicklungsprozess eingesetzt werden sollten. Nicht trotz, sondern gerade durch agile Entwicklungsmethoden wird das Thema Sicherheit zu einem ständigen Begleiter, vom ersten Konzept bis zum Release. Doch worauf sollte der Developer achten? Eine bewährte Handreichung ist eine zehn Punkte umfassende Liste mit häufigen Risiken, die OWASP Mobile Top 10, die wir hier näher vorstellen. Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation, die das Ziel verfolgt, die Sicherheit von mobilen und Web-basierten Anwendungen und Diensten zu verbessern.

Dazu noch eine Anmerkung: Die hier beschriebene Aufstellung stammt zwar aus dem Jahr 2016, jedoch sind die genannten Aspekte auch heute noch relevant, um eine sichere mobile Anwendung zu entwickeln. Vor allem ist es wichtig zu verstehen, dass bei einem Smartphone grundsätzlich andere Risiken bestehen als bei einem Laptop oder PC.

Der kleine Unterschied

Eigentlich ist ein Smartphone nichts anderes als ein kleiner Laptop, richtig? Leider falsch. Zunächst fallen Telefone nochmals deutlich kleiner aus. Dann nutzen sie andere Sicherheitskonzepte und gehen anders mit Berechtigungen um. Weiterhin kommt die mobile Welt generell mit anderen Gefahren daher.

Beispielsweise könnte ein „Denial of Service“-Angriff dazu genutzt werden, die Funktion zum Absetzen eines Notrufs auf dem Handy zu blockieren. Jedoch ist in vielen Ländern – auch Deutschland – gesetzlich geregelt, dass ein Notruf nicht absichtlich gestört werden darf. Das zielt zwar mehr auf den Einsatz von Störsendern ab; wird jedoch per Software diese Funktion blockiert, kann dies sogar rechtliche Auswirkungen für den Hersteller haben, wenn er diese Angriffsmuster nicht verhindert.

Deutlich häufiger beklagen Anwendende auch den Verlust ihres Gerätes. Ein Handy rutscht schneller aus der Tasche als ein Laptop. Weiterhin haben Angreifende bei der Manipulation der Geräte mehr Möglichkeiten, einfach weil ein Smartphone über sehr viele Kanäle und Technologien kommunizieren kann. Technisch versierte Nutzende verschaffen sich manchmal Administratorrechte auf Smartphones durch einen Jailbreak (Apple-Geräte) bzw. Rooten (Android-Geräte), um beliebige Software auf dem Gerät zu verwenden. Damit wird jedoch aus dem Rechtekonzept des Telefons ausgebrochen und Nutzende (und Angreifende) können Funktionen in einer Art verwenden, die so gar nicht vom Hersteller vorgesehen war. Zwei letzte Beispiele: Das kleinere Display erleichtert das Spoofing, wenn wichtige Informationen außerhalb des sichtbaren Bereichs dargestellt oder vom Angreifenden mit fremden Inhalten überdeckt werden. Ein weiteres Beispiel ist ein überklebter QR-Code, der nun zu einer bösartigen Webseite führt, die Schadcode nachlädt. Solch ein Vorgehen eines Angreifenden dürfte bei einem Laptop-Nutzer eher selten zum Erfolg führen. Daher sollten Developer eine solide Vorstellung für die mobile Bedrohungslage besitzen und den grundsätzlichen Aufbau der Sicherheitsarchitektur von mobilen Endgeräten kennen.

So funktioniert Handy-Sicherheit

Die Sicherheit von Daten und Apps wird auf Smartphones und Tablets über vier Schichten realisiert: Hardware, Betriebssystem (OS), API und Apps. Auf der Hardware-Ebene sorgen eine Gerätevollverschlüsselung sowie ein geschützter Bootloader dafür, dass nur valide Software beim Gerätestart geladen wird. Das OS stellt eine Sandbox bereit, in der Apps isoliert und geschützt ablaufen, also keine Manipulation des Gesamtsystems vornehmen können. Weitere Sicherheits-Features auf OS-Ebene sind Funktionen zur sicheren Kommunikation mit verschiedenen Netzen oder die Benutzeridentifizierung per PIN oder Gesichtserkennung.

Die Abbildung zeigt die vier Layer des Security-Modells, die bei der Entwicklung für mobile Endgeräte zu berücksichtigen sind.

Über die APIs wird eine Laufzeitumgebung für Anwendungen bereitgestellt. Mithilfe dieser Plattform erfolgt beispielsweise die Kommunikation der Apps untereinander. Auch werden hier Rechte, Berechtigungen und der Datenschutz umgesetzt, also welche Apps dürfen auf welche Komponenten des Smartphones zugreifen. Wichtig zu wissen, dass auf dieser Ebene auch die Zwischenablage realisiert ist.

Die vierte Schicht umfasst die eigentlichen Anwendungen, die Apps. Diese verarbeiten Nutzerdaten, Passwörter und andere Zugänge, erzeugen Log-Files und regeln die persönlichen Datenschutzeinstellungen wie z. B. das Erfassen von Nutzungsstatistiken. Die Nutzung von Cloud-Diensten erfolgt ebenfalls auf dieser Ebene. Wichtig für das Sicherheitskonzept ist zu erkennen, dass heute viele Hersteller ihre eigene Cloud für das Smartphone mitbringen und Apps diese nutzen, entweder direkt über APIs oder indirekt, beispielsweise durch Backups.

Diese Pyramide zeigt, dass es notwendig ist, dass sich Apps auf die Sicherheit aller darunter liegenden Schichten verlassen können. Je weiter unten eine Schwachstelle gefunden wird, desto verheerender ist sie meist. Eine Schwachstelle im Bootloader zum Beispiel kann das gesamte Gerät gefährden. Ein solches Problem betraf vor einigen Jahren tatsächlich einen der größten Hersteller, der in einem seiner Chips eine Security-Lücke hatte, sodass Anwendende über Jahre hinweg einen Jailbreak durchführen und potenziell gefährliche Software laden konnten. Behoben wurde das Problem erst durch eine neue Gerätegeneration.

Zehn potenzielle Fehlerquellen

Aus den Fehlern anderer zu lernen, ist eine effiziente Methode, um die App-Sicherheit zu steigern. Eine Liste der häufigsten Risiken hat die bereits erwähnte OWASP zusammengetragen. Dies ist keine vollständige Aufstellung aller Risiken, jedoch eine wertvolle Hilfe, um darauf aufbauend sein eigenes Security-Konzept umzusetzen. Auch die Reihenfolge sollte nicht zur Priorisierung verwendet werden – alle genannten Aspekte sollten bei der App-Entwicklung berücksichtigt werden.

Zurückgelassene Funktionen

Steigen wir ein mit dem Punkt M10: Extraneous Functionality. Gemeint sind damit Funktionen im Programmcode, die nur in der Entwicklungsphase genutzt wurden und deren Entfernung vor der Fertigstellung vergessen wurde. Dies können beispielsweise versteckte Admin-Schnittstellen sein, aber auch Funktionen für Software-Testende, um eine Zwei-Faktor-Authentisierung zu deaktivieren, wodurch sich das Testen vereinfacht. Werden solche Artefakte in eine Produktivversion übernommen, kann dies die Sicherheit der App oder serverseitiger Dienste gefährden.

Unter die Haube schauen

Die Punkte M9 (Reverse Engineering) und M8 (Code Tampering) gehören im Grunde zusammen. Bei M9, der Rekonstruktion eines Quellcodes, geht es um Informationsgewinnung. Durch detailliertes Verständnis der Funktionsweise lassen sich mögliche Schwachstellen in der Programmierung oder Fehler der Developer entdecken. Als im Jahr 2016 das Smartphone-Spiel Pokémon Go populär war, haben Nutzende rekonstruiert, wie die App mit ihren Servern kommuniziert und konnten dadurch falsche GPS-Koordinaten einschleusen und so dem Spiel einen anderen Standort vorgaukeln. Dies war deshalb relevant, weil sich beispielsweise im Central Park von New York die besten Monster finden ließen. Generell geht es hier aber auch um den Diebstahl geistigen Eigentums.

Hat ein Hacker erstmal verstanden, wie das Original funktioniert, ist es auch möglich, den Code zu verändern (Code Tampering). Die Veränderungen werden meist binär auf Codeebene durchgeführt, um das Verhalten einer App zu modifizieren oder neue Funktionen zu integrieren. Damit lassen sich Schadcode nachladen, Nutzerdaten auslesen oder Lizenzprüfungen umgehen. Auch hier liefert die Spieleindustrie passende Beispiele. Die Entfernung eines Kopierschutzes bei Spielen – umgangssprachlich Cracking genannt – bedient sich dieser Vorgehensweise.

Developer sind diesen Angriffen nicht hilflos ausgeliefert. So haben manche Apps eine Root- oder Jailbreak-Erkennung und lassen sich auf modifizierten Geräten nicht starten. Dies ist häufig bei Banking-Apps der Fall. Für Android-Geräte gibt es von Google dafür die SafetyNet API, eine Sicherheitsfunktion der Google Play-Dienste, die mithilfe einer API ein Gerät auf Integrität überprüft. Eine vollständige Sicherheit gegen Code-Veränderungen gibt es allerdings nicht.

Aus Nachbars Garten klauen

Der Aspekt „Client Code Quality“ (M7) mag zunächst einmal nicht nach einem Sicherheitsproblem klingen. Der Hintergrund ist aber, dass es bei fehlerhafter Programmierung möglich wird, in einem fremden Adressraum Code zu starten und damit Daten auszulesen. Zu schlechter Codequalität kann die Verwendung von Drittsoftware wie Frameworks und Bibliotheken mit mangelhafter Qualität führen. Aber auch der Einsatz von Programmiersprachen, die anfällig sind für Speicherkorruptionsfehler, sorgt oft für Schwachstellen.

Von einer der meistgenutzten Messenger-Apps ist bekannt, dass Teile in einer solchen Sprache programmiert wurden, um die Wiederverwendung von Funktionen zu vereinfachen. Ein Hersteller für Überwachungstechnologie aus Israel nutzte eine Schwachstelle in solchem Code aus und verteilte so eine Spyware. Es reichte schon ein externer Anruf auf dem installierten Messenger, um unbemerkt im Hintergrund eine Spionage-Software nachzuladen, die dann eine volle Kontrolle über das Endgerät ermöglichte.

Wer bin ich?

Die Risiken Insecure Authorization (M6) und Insecure Authentication (M4) stehen zwar nicht hintereinander, hängen aber ebenfalls zusammen. Bei der Autorisierung geht es um die Erlaubnis, ob der Nutzende auf Daten oder Funktionen überhaupt zugreifen darf, während die Authentifizierung über eine Nutzeranmeldung prüft, wer der Anwendende ist. Eine Schwachstelle bei diesen beiden ist oftmals gar nicht das Problem einer App, sondern eines API-Endpunkts, also beispielsweise eines Servers, mit dem die App kommuniziert. Bei M6 gelingt es einem Angreifenden, ohne die notwendige Berechtigung auf Funktionen zuzugreifen. So wurden in der Vergangenheit Daten aus Corona-Testzentren über nicht korrekt konfigurierte APIs abgegriffen. Bei M4 können Angreifende der App oder dem API-Endpunkt eine falsche Identität vorspiegeln, indem zum Beispiel eine Prüflogik für Identitätsinformationen ausgetrickst wird.

Die Angriffstechniken umfassen die bekannten Probleme, wie zu schwache Kennwörter und PINs, den Diebstahl von Kennungen, aber auch das Monitoring und die Manipulation von Netzwerkverkehr. Für Developer ist es wichtig zu wissen, dass auf den Einsatz von TLS (Transport Layer Security) nicht verzichtet werden darf. TLS ist trotzdem kein Allheilmittel. Bei der Anmeldung mit Single Sign-On wurden schon öfter Schwachstellen entdeckt, die TLS nicht verhindern konnte. Darüber hinaus ist beispielsweise für Angreifende, die den Netzverkehr beobachten, trotz TLS sichtbar, mit welcher Zieladresse Anwendende eine Verbindung herstellen.

Offene Geheimnisse

In die Kategorie Unzureichende Kryptographie (M5 - Insufficient Cryptography) fallen Sicherheitslücken, die durch nicht korrekt genutzte kryptographische Verfahren durch Developer entstehen. Ursache sind oft veraltete und damit potenziell unsichere Algorithmen oder eine Erwartungshaltung an ein Verfahren stimmt nicht mit der benötigten Sicherheitseigenschaft überein. Angreifende können beispielsweise den Code einer App auf fehlerhaft implementierte Verfahren analysieren und bekannte Schwachstellen nutzen. Da Kryptographie ein unglaublich komplexes Thema sein kann, an dieser Stelle die Empfehlung an Developer, keine eigenen kryptografischen Routinen zu erfinden. Es ist sicherer, auf geprüfte und vorhandene Verfahren zurückzugreifen. Untermauert wird diese Aussage durch eine Analyse von rund 10.000 Apps im Jahr 2018, bei der sich gezeigt hat, dass rund 95 Prozent der Anwendungen keine vollständig korrekte Nutzung von kryptografischen Schnittstellen aufwiesen.

Netzverkehr richtig sichern

Die unsichere Kommunikation (M3 - Insecure Communication) beschreibt das Risiko, dass Developer den Netzwerk-Datenverkehr nicht oder nicht korrekt über TLS bzw. HTTPS absichern. Netzwerke sollten grundsätzlich als nicht vertrauenswürdig betrachtet werden. Durch passives Belauschen eines WLANs, das Abgreifen des Datenverkehrs direkt am Router oder durch Umleiten der Daten kommen Angreifende an die Rohdaten. TLS kann dies verhindern; in der Praxis finden sich jedoch immer wieder Beispiele, bei denen die notwendigen Schlüssel und Zertifikate nicht korrekt vom Developer-Team verwendet oder geprüft wurden. Auch sollten Developer beachten, dass Handys über viele weitere Schnittstellen Daten austauschen, wie Bluetooth, SMS, E Mail, USB, NFC, Kamera sowie Spracheingabe.

Passend hierzu gibt es das unterhaltsame Beispiel aus dem Jahr 2017, als ein Radiomoderator über das Kommando „Hallo Alexa“ bei seinen Hörern eine Massenbestellung über den Sprachassistenten Amazon Echo auslösen konnte.

Unsicherer Datenspeicher

Das Risiko Insecure Data Storage (M2) gewinnt kontinuierlich an Bedeutung, da die Speicherkapazität bei Smartphones weiter zunimmt. Developer sollten davon ausgehen, dass ein Zugriff auf das Dateisystem von Mobilgeräten durch Dritte durchaus möglich ist. Angreifende könnten das Gerät unter ihre Kontrolle bringen, sei es z. B. durch Diebstahl, während eines Security-Checks am Flughafen oder bei einer Grenzkontrolle. Dabei können Angreifende dann Schwachstellen im OS ausnutzen und Malware installieren, um auch künftig Daten auslesen zu können.

Eine Gerätevollverschlüsselung sollte nicht als Freifahrtschein für höchste Sicherheit gesehen werden. Diese Verschlüsselung ist für Software(-Angriffe) nicht sichtbar und schützt damit nur, wenn das Gerät komplett ausgeschaltet ist – der Flugmodus zählt nicht dazu.

Unschöne Dinge tun

Das letzte Risiko (M1 – Improper Platform Usage) bezieht sich auf die nicht korrekte Nutzung der Plattform und beschreibt eine Vielzahl von möglichen Sicherheitsproblemen. Ein typisches Beispiel ist die Vergabe von zu vielen Berechtigungen für eine App. Wenn eine Taschenlampen-App Zugriff auf das Adressbuch, die Fotos oder den Standort von Nutzenden verlangt, kann dies schon als Angriff auf persönliche Daten verstanden werden. Ein weiteres Beispiel ist die Kategorie der Injection-Angriffe, bei denen die App oder der Server Daten von Angreifenden als Code fehlinterpretiert und Angreifende so die Kontrolle erlangen. In einem zweiten Schritt wird dann beim sogenannten UI Redressing den Nutzenden eine gefälschte Oberfläche untergeschoben, um dadurch zum Beispiel teure Sonderrufnummern anzurufen. Oder den Nutzenden wird versprochen, durch Auflegen des Daumens auf den Fingerabdruck-Scanner könne der Puls gemessen werden. Der dann initiierte teure In-App-Kauf wird so direkt authorisiert.

Ein Tipp an Developer: Bei der Integration der virtuellen Tastatur sollte darauf geachtet werden, dass sicherheitsrelevante Eingaben der Anwendenden nicht in das Wörterbuch aufgenommen werden und somit nicht als Vorschlag in der Liste der Autovervollständigung auftauchen.

So bleibt abschließend noch der Hinweis, dass App Developer sich ein ganz eigenes Security-Mindset zulegen sollten. Ein Smartphone ist ständig mit dem Netz verbunden und während der gesamten Nutzung ganz unterschiedlichen Gefahren ausgesetzt. Man muss nicht paranoid werden, aber es hilft, die eigenen Sinne zu schärfen und ein ganz klein wenig wie ein Hacker zu denken.