Home » Fachbeiträge » Cybersecurity » Smartphones unter Beschuss

Smartphones unter Beschuss

Mobile Apps speichern viele persönliche Informationen wie Fotos, Aufnahmen, Notizen, Zahlungs- und Kontodaten oder Standortdaten. Entsprechend wird erwartet, dass mobile Anwendungen und Dienste diese Informationen sicher aufbewahren, schützen und verantwortungsvoll verarbeiten. Doch welche Schutzmaßnahmen sollen oder müssen Entwickler für welche Risiken umsetzen? Orientierung dafür bietet eine zehn Punkte umfassende Liste mit häufigen Risiken, die OWASP (Open Web Application Security Project) Mobile Top 10.

6 Min. Lesezeit
Foto: ©AdobeStock/Konstantin Yuganov

Anwendungen und Dienste für Smartphones und Tablets stellen andere Sicherheitsanforderungen an die Entwickler als bei PCs – nicht nur, weil sie kleiner sind und leichter verloren gehen können. Diese Geräte nutzen andere Sicherheitskonzepte und gehen anders mit Berechtigungen um. Hinzu kommen die vielen Kanäle und Technologien, über die mobile Geräte kommunizieren wie Bluetooth, SMS, E-Mail, USB, NFC, Kamera und Spracheingabe. Ein solches Sicherheitskonzept für Daten und Apps betrachtet daher vier Schichten: die Hardware, das Betriebssystem (OS), die Plattform-API und die eigentlichen Apps, um deren Sicherheit es geht.

Angriffstechniken

Die Bauform und der hohe Grad an Konnektivität eines Smartphones verändert auch die Art und Weise der möglichen Angriffe und deren Folgen. Wird ein Smartphone über einen Denial-of-Service-Angriff daran gehindert, einen Notruf abzusetzen, kann gegebenenfalls der Hersteller des mobilen Geräts rechtlich haftbar gemacht werden. Mobile Geräte sind aufgrund des kleineren Displays für Spoofing anfälliger, wenn wichtige Inhalte vom Angreifer außerhalb des sichtbaren Bereichs dargestellt oder mit anderen Inhalten verdeckt werden. Per „überklebtem“ QR-Code sind schon mobile Nutzer zum Öffnen einer bösartigen Webseite verführt worden, welche anschließend Schadcode nachgeladen hat. Über einen Jailbreak bei Apple-Geräten beziehungsweise über Rooten bei Android-Geräten können sich technisch versierte Angreifer Administrationsrechte aneignen, um dann eine beliebige Software auszuführen und auf Daten zuzugreifen.

Vier Schichten müssen analysiert werden

Auf der Hardware-Ebene bieten alle modernen mobilen Geräte eine Vollverschlüsselung und einen geschützten Bootloader. Beide schützen vor Manipulation an der Hardware und an den Speicherinhalten, sodass nur ein unverfälschtes Betriebssystem beim Gerätestart geladen wird. Dieses Betriebssystem stellt eine Sandbox bereit, in der die Apps isoliert und geschützt ablaufen, um Manipulationen am Gesamtsystem entgegenzuwirken. Die weiteren Aufgaben des OS sind die sichere Kommunikation mit den verschiedenen Netzen sowie die Benutzererkennung mittels PIN oder Fingerabdruck oder Gesichtserkennung.

Zusammen mit dem OS stellt das Application Programing Interface (API) die Laufzeitumgebung für die Apps zur Verfügung. Auf dieser Ebene tauschen Apps Daten untereinander aus wie Bilder und Dokumente, aber auch Inhalte über die Zwischenablage. Über entsprechende Anrufe können Apps auf die Kamera und das Mikrofon zugreifen oder den Standort abfragen. Dabei werden in dieser Schicht die Rechte und Berechtigungen der mobilen Apps durchgesetzt und im Zweifel der Nutzer gefragt.

Die vierte Schicht beinhaltet die Apps und alles, was diese Apps verarbeiten: Nutzerdaten, Passwörter, andere Zugänge und generierte Logfiles. Diese Schicht steuert zudem die persönlichen Datenschutzeinstellungen bezüglich Reichweitenmessung oder Nutzerstatistiken und die Anbindung von Cloud-Diensten. Letzteres kann direkt über APIs der Cloud-Dienste oder indirekt, beispielsweise durch Backups in die Gerätehersteller-Cloud, erfolgen.

Je weiter unten in Richtung Hardware die Schwachstelle angesiedelt ist, umso verheerender ist meist die Auswirkung für den mobilen Nutzer und für alle Apps und Daten auf dem mobilen Gerät. So kann eine Schwachstelle im Bootloader schnell das gesamte Gerät gefährden, indem Angreifer beispielsweise auf dieser Schicht einen Jailbreak durchführen, um anschließend Schadsoftware zu installieren.

Top 10 der mobilen Risiken nach der OWASP-Liste

Die Anordnung dieser Top-10-Liste der Risiken ist durch eine Umfrage ermittelt worden. Aus der Reihenfolge sollte aber nicht auf die Relevanz einzelner Risiken geschlossen werden. Entwickler erhalten durch die Liste die Chance, aus den Fehlern anderer Entwickler zu lernen und über diesen Lernprozess das Gesamtniveau an Sicherheit und den Reifegrad des Security-Konzepts zu erhöhen.

Vergessene Funktionen als potenzielle Einfallstore

M10 für Extraneous Functionality adressiert Funktionen im Programmcode, die Entwickler vergessen haben, nach der Nutzung in der Entwicklungsphase zu entfernen. Typische Beispiele sind versteckte Administrations-Schnittstellen und Funktionen zur Vereinfachung von Softwaretests, beispielsweise für das Deaktivieren einer ansonsten verpflichtenden Zwei-Faktor-Anmeldung.

Reverse Engineering

M9 zur Rekonstruktion des Quellcodes zur Informationsgewinnung und M8 für böswillige Code-Veränderung sind eng verwandt. Im ersten Schritt analysieren Angreifer den Maschinencode einer App oder einer der anderen Schichten, um diesen Code nachvollziehen zu können. Im zweiten Schritt setzen Angreifer dieses Wissen für binäre Code-Veränderungen ein, um das Verhalten von Apps zu modifizieren oder zusätzliche Funktionen zu integrieren. Auf diese Weise können Angreifer Schadcode nachladen, Nutzerdaten auslesen und Lizenzprüfungen umgehen. Manche Apps verfügen über eine Root- (Android) beziehungsweise Jailbreak-Erkennung (Apple), was ihren Start auf derart modifizierten Geräten unterbinden soll. Für Android-Geräte offeriert Google die SafetyNet API als Teil der Google-Play-Dienste. Mit ihr können Apps die Integrität des Geräts prüfen. Aber weder eine Root- noch eine Jailbreak-Erkennung noch SafetyNet API können bösartige Code-Veränderungen vollständig unterbinden.

Mindere Codequalität als Manipulationsobjekt

M7 für Client Code Quality dreht sich um schlechte Programmierpraktiken oder Speicherkorruptionsfehler. Wenn Angreifer diese ausnutzen, können sie bösartigen Code einschleusen und so Daten auslesen oder Apps beziehungsweise das Betriebssystem unter ihre Kontrolle bringen. Diese Fehler lauern oft nicht nur im eigenen Code des Entwicklers, sondern auch in verwendeter Drittsoftware wie Frameworks oder Bibliotheken in minderer Qualität. Bestimmte Programmiersprachen, die anfällig für Speicherkorruptionsfehler sind, erhöhen zusätzlich die Gefahr für Entwickler, solch einen Fehler versehentlich einzubauen.

Falschen Nutzeranmeldungen und unberechtigten Zugriffen vorbeugen

M6 steht für Insecure Authorization und M4 für Insecure Authentication. Dabei meint Autorisierung die Vergabe einer Berechtigung und Authentisierung die Identifikation eines Nutzers. Beides kann unsicher umgesetzt sein, was aber meist weniger Apps, sondern vielmehr API-Endpunkte auf Servern betrifft. Ist die Autorisierungs-Prüflogik nicht genügend abgesichert, besteht die Gefahr, dass Angreifer ohne Berechtigung auf Funktionen und Daten zugreifen. Schwachstellen innerhalb der Authentisierungs-Prüflogik können Angreifer dafür verwenden, um Apps ebenso wie API-Endpunkten eine falsche Identität vorzutäuschen.

Transport Layer Security (TLS) kommt in diesem Zusammenhang eine wichtige Rolle zu. Es darf bei keiner Authentisierung und Autorisierung fehlen. Ein Allheilmittel ist TLS dennoch nicht, wie zahlreiche Angriffe auf Single-Sign-on-(SSO-)Protokolle beweisen. Außerdem verhindert TLS nicht, dass Angreifer Zugangsdaten über
Phishing erbeuten.

Offene Geheimnisse durch inkorrekt genutzte Kryptografie-Verfahren

Auch nicht korrekt genutzte Kryptografie-Verfahren, M5 Insufficient Cryptography, können gefährliche Einfallstore für Angreifer bilden. Sie entstehen durch den Einsatz veralteter und damit unsicherer Algorithmen, aber auch dadurch, dass die Eigenschaften von Algorithmen erwartet werden, für die diese nicht entwickelt worden sind. Mittels solcher Schwachstellen können Angreifer Daten einzusehen und abgreifen oder sich Zugänge verschaffen. Dass solche Schwachstellen in der Nutzung von Kryptografie eher die
Regel als die Ausnahme sind, verdeutlicht eine Analyse von rund 10.000 Apps im Jahr 2018. Danach wiesen 95 Prozent dieser Apps keine vollständig korrekte Nutzung von kryptografischen Schnittstellen auf.

Netzverbindungen über TLS beziehungsweise HTTPS nicht hinreichend abgesichert

M3 für Insecure Communication adressiert das Risiko, dass Entwickler den Netzwerk-Datenverkehr nicht oder unzureichend über TLS respektive HTTPS absichern. In diesen Fällen gelangen Angreifer durch passives Belauschen eines WLANs, durch Abgreifen des Datenverkehrs  direkt am Router oder durch Umleiten der Daten an ihre Adresse an die Rohdaten. TLS ist ressourcenschonend und die entsprechenden Zertifikate sind kostenlos erhältlich. Es gibt somit keine Rechtfertigung, auf TLS zu verzichten. Allerdings müssen die Zertifikate beim Verbindungsaufbau sorgfältig geprüft werden.

Unsichere Datenspeicher für Angreifer immer interessanter

Mit der stetigen Zunahme der Speicherkapazität in Smartphones und Tablets werden die darin gehaltenen Daten auch für die Angreifer immer interessanter. Das Risiko M2 für Insecure Data Storage gewinnt damit auch für Entwickler immer mehr an Bedeutung. Nach einem Diebstahl des Geräts oder während einer Sicherheitskontrolle am Flughafen soll der Nutzer sich keine Sorgen um seine Daten machen müssen. Die Plattform-APIs der mobilen Betriebssysteme bieten dafür ausgeklügelte Mechanismen, die die Daten verschlüsseln und zur Entschlüsselung die PIN oder den Fingerabdruck beziehungsweise einen Gesichtsscan erfordern.

Falsche Nutzung der Plattform befördert Sicherheitsprobleme

M1 für Improper Platform Usage, last but not least, beschreibt Sicherheitsprobleme, die sich aus Un- oder Missverständnis der Plattformfunktionen ergeben können. Die Bandbreite dieser Schwachstellen ist groß. Sie reicht von Apps mit zu vielen Berechtigungen über eine Bildschirmtastatur, die ungewollt Passwörter und Antworten auf Sicherheitsfragen lernt, bis hin zu Injection-Angriffen, mit denen Apps ferngesteuert werden. Manche Injection-Angriffe gehen so weit, dass über UI-Redressing den Nutzern gefälschte Oberflächen und Knöpfe unterschoben werden, die ungewollte Anrufe zu teuren Premium-Rufnummern auslösen.

Dr. Dennis Felsch, Senior Cyber Security Consultant bei Materna

Andere interessante Fachbeiträge

Energieanlage

IDS im Einsatz: Schutz für Energieanlagen

Die Cyberangriffe auf Energieversorger haben eine alarmierende Entwicklung gezeigt. Seit den Attacken auf das ukrainische Stromnetz bis zu den jüngsten Vorfällen in Dänemark ist kl...

Ritter in Rüstung

Der Weg zur kollektiven Cyberresilienz

Mit der Digitalisierung unserer Wirtschaft und Gesellschaft stehen Unternehmen weltweit vor der Herausforderung, ein komplexes Ökosystem aus Abhängigkeiten wie Internet of Things (...

Grafik Sichere Software

Mit DevSecOps zu sicherer Software

Traditionelle Sicherheitspraktiken sind in der modernen DevOps-Welt oft ineffizient. Denn Sicherheitsscans zu einem späten Zeitpunkt im Entwicklungszyklus bedeuten für die Entwickl...