Mobile Security PDF

Mario Kubek Mobile Security Fakultät für Mathematik und Informatik Das Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung und des Nachdrucks, bleiben, auch bei nur auszugsweiser Verwertung, vorbeh...

Mario Kubek Mobile Security Fakultät für Mathematik und Informatik Das Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung und des Nachdrucks, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (Druck, Fotokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung der FernUniversität reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Der Inhalt dieses Studienbriefs wird gedruckt auf Recyclingpapier (80 g/m2, weiß), hergestellt aus 100 % Altpapier. 3 Inhaltsverzeichnis Inhaltsverzeichnis 0 Vorwort 5 1 Einführung in Mobile Security 1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Allgemeine Bedrohungen . . . . . . . . . . . . . . . . . . . . . . 1.3 Riskantes Nutzerverhalten . . . . . . . . . . . . . . . . . . . . . 1.4 Allgemeine Sicherheitsmechanismen . . . . . . . . . . . . . . . . 1.5 Konkrete Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Weitere Maßnahmen zum Schutz mobiler Endgeräte und Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Sicherheitsbezogene Einstellungen und sichere Nutzung mobiler Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 2 Mobile Betriebssysteme und ihre Applikationen 3 Das Berechtigungskonzept von Android 3.1 Berechtigungskategorien . . . . . . . . . . . . . . . . . . . . . 3.2 Spezifizierung von Berechtigungen . . . . . . . . . . . . . . . . 3.3 Präsentation von Berechtigungsanfragen . . . . . . . . . . . . . 3.4 Sichere Interaktion von Apps und Schutz von App-Komponenten 3.5 Rechteausweitung . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12 12 19 20 25 . 31 . 35 . 39 41 . . . . . . . . . . . . 43 44 48 51 56 60 61 4 Analyse von Android-Applikationen 63 5 Analyse von iOS-Applikationen 65 6 Angriffe auf die Datenübertragung 67 7 Sicherheitsaspekte im geschäftlichen Umfeld 7.1 Nutzungsparadigmen mobiler Endgeräte . . . 7.2 Geräteverwaltung . . . . . . . . . . . . . . . 7.3 Managed Application Configurations . . . . . 7.4 Aspekte der Realisierung von Enterprise-Apps 7.5 Bedrohungs- und Risikoanalyse . . . . . . . 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 70 74 79 81 84 88 4 Inhaltsverzeichnis Fazit 91 Literaturverzeichnis 93 Version des Dokuments: 1.3 (13.08.2021) 5 Vorwort Vorwort Einleitende Informationen Herzlich willkommen zum Kurs 01864 Mobile Security! Die Modul- und Prüfungsnummer lautet 64313. Der Kurs besteht aus einem Basistext, welcher beschafft werden muss, einem Leittext und Übungsaufgaben. Als Basistext dient das Buch Michael Spreitzenbarth: Mobile Hacking: Ein kompakter Einstieg ins Penetration Testing mobiler Applikationen - iOS, Android und Windows Phone. dpunkt.verlag, 2017. Der Leittext (LT) besteht aus dem vorliegenden Dokument. Der Kurs gliedert sich in sieben Kurseinheiten (KE), die den Kapiteln dieses Leittextes und des Basistextes (BT) wie folgt entsprechen: KE Kapitel im LT Kapitel im BT Überschrift 1 1 – Einführung in Mobile Security 2 2 1, 2 Mobile Betriebssysteme und ihre Applikationen 3 3 – Das Berechtigungskonzept von Android 4 4 3, 4 Analyse von Android-Applikationen 5 5 5, 6 Analyse von iOS-Applikationen 6 6 9, 10 Angriffe auf die Datenübertragung 7 7 – Sicherheitsaspekte im geschäftlichen Umfeld Es gibt vier Übungsaufgabenserien (Einsendeaufgaben, EA), die den obigen Kurseinheiten wie folgt zugeordnet sind: EA KE 1 1 und 2 2 3 und 4 3 5 4 6 und 7 6 Vorwort Die Lösungen der Übungsaufgaben sind im Online-Übungssystem des Kurses einzusenden. Die Übungsaufgaben können von dort, im Virtuellen Studienplatz und in Moodle abgerufen werden. Individuelle Lösungshinweise und Musterlösungen werden bereitgestellt. Nähere Informationen zu den Einsendeterminen und den Kurs-Link zum Online-Übungssystem finden Sie im Informationsschreiben (X-Schreiben). Zu jeder Kurseinheit werden im Leittext eingangs die Lernziele sowie relevante Zusatzinformationen angegeben. Hierzu sind folgende wichtige Hinweise zu beachten: • Die im Basistext enthaltenen Kapitel 7 und 8 sowie die Abschnitte 1.3 und 1.6.3 zu Windows 10 Mobile sind aufgrund des geringen Marktanteils dieses Betriebssystems nicht Gegenstand dieses Kurses. • Die im Basistext beschriebenen Analysen unter iOS setzen teilweise spezielle Hardware wie Rechner mit Mac OS X sowie jailbroken iOS-Endgeräte voraus. Es ist nicht beabsichtigt, dass Sie sich solche Hardware zur Durchführung dieses Kurses besorgen, oder gar selbst einen Jailbreak an Ihrem privaten Gerät vornehmen. Trotzdem sollten Sie die Kurseinheit 5 zu iOS gründlich durcharbeiten, um ein Gefühl und das nötige Hintergrundwissen für die technische Analyse von iOS-Applikationen und die dabei einzusetzenden Werkzeuge zu gewinnen. • Die praktischen Übungsaufgaben werden mit Hilfe eines Android-Emulators (die Installation der SDK-Tools von https://developer.android. com/studio im Bereich “Command line tools only” und die Konfiguration eines Emulators mit Hilfe dieser Tools ist hierfür ausreichend; die komplette Entwicklungsumgebung Android Studio wird nicht benötigt) und anderer frei verfügbarer Werkzeuge wie Burp Suite Community Edition von https:// portswigger.net/burp/communitydownload zu lösen sein. Auch wird hierfür kein Android-Endgerät (weder gerootet noch ungerootet) benötigt. Es wird auch empfohlen, sich die Seite des Kurses in Moodle und im Virtuellen Studienplatz anzusehen. Dort finden Sie alle Arbeitsmaterialien wie Kurstexte, Übungsaufgaben, Musterlösungen, Programmpakete sowie Links zu weiteren relevanten Inhalten und Werkzeugen externer Quellen. Es ist dabei möglich, dass sich im Verlauf des Kurses Aktualisierungen und Erweiterungen der Materialien ergeben. Vorwort Informationen zur Durchführung des Kurses finden Sie im Informationsschreiben (X-Schreiben), welches ebenfalls im Virtuellen Studienplatz und in Moodle abrufbar ist. Der Kurs setzt Kenntnisse zu den Inhalten der Kurse „Sicherheit im Internet I“ (01866) und „Sicherheit im Internet – Ergänzungskurs“ (01868) voraus. Weiterhin sind zum Verständnis des Kurses und zur Bearbeitung der Übungsaufgaben grundlegende Programmierkenntnisse sowie zur Shell-Nutzung hilfreich. Informationen zu den jeweiligen Prüfungsmodalitäten Ihres Studienganges finden Sie in den Prüfungsinformationen der Fakultät für Mathematik und Informatik. Kursinhalte Dieser Kurs führt in die Sicherheitskonzepte und -mechanismen mobiler Endgeräte wie Smartphones und Tablets sowie der auf ihnen laufenden Betriebssysteme und Applikationen ein. Der Fokus dieser Betrachtungen liegt dabei auf der technischen Analyse mobiler Applikationen, die für die gängigen Plattformen Android und iOS erstellt wurden. Die Sicherheitsmechanismen von Android sowie die Detektion von Sicherheitslücken in Android-Applikationen werden besonders hervorgehoben. Konkret befasst sich der Kurs zunächst in Kurseinheit 1 mit den allgemeinen Bedrohungen und Angriffsszenarien in diesem Kontext sowie den Sicherheitsarchitekturen obiger Plattformen und ihren Prinzipien als Gegenmaßnahmen. Weitere Maßnahmen zum Schutz mobiler Endgeräte und Applikationen sowie zur Detektion schädlicher Aktivitäten und zur Schadensminderung im mobilen Kontext runden die Kurseinheit ab. In Kurseinheit 2 werden die Architekturmerkmale der genannten mobilen Plattformen vertieft. Weiterhin wird ausgeführt, wie mobile Applikationen aufgebaut sind und aus welchen Software-Komponenten sie bestehen. Auch werden spezielle Sicherheitsmechanismen unter iOS eingeführt. Der zweite Schwerpunkt dieser Kurseinheit ist der Einführung in das Gebiet der technischen Analyse mobiler Applikationen gewidmet. Hierbei werden die Techniken der statischen und dynamischen Analyse vorgestellt und voneinander abgegrenzt. Diese Techniken stellen den Hauptschwerpunkt dieses Kurses dar, da durch sie die Sicherheit mobiler Applikationen selbst, mit denen wir als Nutzer im Alltag direkt und zunehmend interagieren, überprüft werden kann. Das Berechtigungskonzept von Android und insbesondere der darauf laufenden Apps wird in Kurseinheit 3 eingeführt. Es wird hierzu dargelegt, welche Kategorien von App-Berechtigungen es gibt und wie diese eingesetzt und angefordert werden. Hierbei wird auch darauf eingegangen, wie App-Komponenten vor Zugriffen anderer Apps geschützt werden können, um unter anderem dem Problem der horizonta- 7 8 Vorwort len Rechteausweitung zu begegnen. In Kurseinheit 4 wird die gängige Vorgehensweise beim Reversing (Rekonstruktion des Quelltextes) von Android-Applikationen erklärt, wobei zu diesem Zweck auf ihre Beschaffung, Analyse und die dafür nötigen technischen Umgebungen und Werkzeuge eingegangen wird. Weiterhin werden die wichtigsten Schwachstellen im Code solcher Applikationen und deren Erkennung sowie die Detektion von Schadcode und gängige Schutzmaßnahmen behandelt. Kurseinheit 5 folgt der Gliederung der vorigen Kurseinheit, stellt also zunächst die wichtigsten Werkzeuge zur Analyse von iOS-Applikationen im Kontext der dazu nötigen Vorgehensweise vor. Weiterhin wird beschrieben, wie iOSApplikationen zur Laufzeit analysiert und manipuliert werden können. Ebenfalls werden in Kurseinheit 4 und Kurseinheit 5 verschiedene Ansätze forensischer Untersuchungen unter Android und iOS besprochen. Die Kurseinheit 6 gibt einen Überblick über eine Reihe von Angriffen auf die mobile Datenübertragung und das für ihre Durchführung passende Vorgehen. Ebenso wird besprochen, wie dabei mitgeschnittener Netzwerkverkehr analysiert und interpretiert werden kann. Die abschließende Kurseinheit 7 widmet sich den Sicherheitsaspekten mobiler Endgeräte und Applikationen im geschäftlichen Umfeld. Die dabei relevanten Nutzungsparadigmen dieser Geräte werden beschrieben und es wird erörtert, wie Enterprise-Apps sicherheitsorientiert entwickelt und konfiguriert werden können. Wie bereits erwähnt, gibt es Übungsaufgaben bzw. Einsendeaufgaben, zu denen individuelle Lösungshinweise und Musterlösungen bereitgestellt werden. Es wird empfohlen, diese – oftmals praktisch ausgerichteten – Aufgaben anzugehen. Das Verständnis der Materie wächst, wenn man sich mit dem Stoff aktiv auseinandersetzt, was insbesondere für diesen Kurs gilt. Literatur Die im Folgenden genannten Fachbücher, Kapitel, White Paper und Zeitschriftenartikel sind als weitere Informationsquelle empfehlenswert. Diese behandeln einzelne thematische Aspekte dieses Kurses genauer bzw. auf eine andere Weise. • Das Fachbuch M. Kofler et al.: Hacking & Security: Das umfassende Handbuch. 2., aktualisierte und erweiterte Auflage, Rheinwerk Computing, 2020 geht in Kapitel 20 auf die Sicherheitsgrundlagen von Android und iOS ein, widmet sich der technischen Analyse mobiler Applikationen und bietet auch einen Einblick in Lösungen zur Verwaltung mobiler Endgeräte in Unternehmen und Organisationen. Vorwort • Kapitel 13 des Lehrbuches E. Glatz: Betriebssysteme: Grundlagen, Konzepte, Systemprogrammierung. 4. Auflage, dpunkt.verlag, 2019 ist der kurzen Einführung in mobile Betriebssysteme gewidmet. • Das Lehrbuch D. Westhoff: Mobile Security. 1. Auflage, Springer Vieweg, 2020 bietet in Teil III eine tiefgehende Einführung in das mobile Betriebssystem Android, bespricht die Umsetzung sicherheitskritischer mobiler Anwendungen und stellt Techniken des Zertifikat-Pinnings sowie der Obfuskierung und Deobfuskierung bei mobilen Applikationen vor. • Das englischsprachige Fachbuch R. Tamma et al.: Practical Mobile Forensics: Forensically investigate and analyze iOS, Android, and Windows 10 devices. 4th Edition, Packt Publishing, 2020 deckt ebenfalls die in diesem Kurs behandelten Themen ab, bespricht jedoch die einzelnen Schritte forensischer Analysen mobiler Endgeräte und Applikationen tiefgehender und systematischer. • Das von Apple selbst bereitgestellte White Paper Sicherheit der ApplePlattformen, Mai 2021 [1] gibt eine Einführung in die Sicherheitsmechanismen der Apple-Plattformen. Relevant für diesen Kurs sind insbesondere die Ausführungen zur Systemsicherheit, Datensicherheit und Applikationssicherheit unter iOS. Das Kapitel zur Netzwerksicherheit ist eine sinnvolle Ergänzung zu den in diesem Kurs behandelten Aspekten sicherer Datenübertragung. Sie finden dieses Dokument in den Zusatzmaterialien dieses Kurses. Eine englischsprachige Version ist auch bei Apple herunterladbar. Weiterhin wurden in den letzten Jahren eine Reihe von für diesen Kurs relevanten Artikeln u. a. in den deutschsprachigen Computerzeitschriften c’t und iX veröffentlicht. Diese Artikel fokussieren etwa – genau wie dieser Kurs – die technische Analyse mobiler Applikationen und des durch diese erzeugten Datenverkehrs. Die Links zu diesen Artikeln werden im Virtuellen Studienplatz und in Moodle aufgelistet. Teilweise (insbesondere die Artikel des Magazins c’t) können Sie die Artikel von wiso-net über die Universitätsbibliothek des FernUni und Ihren FernUni-Zugang kostenfrei beziehen. Der Zugang zu diesem Angebot ist nur von Rechnern möglich, die sich im Hochschulnetz der FernUni befinden (z. B. via VPN). Unter https://www.ub.fernuni-hagen. de/datenbankenlieferdienste/showdatabase.html?id=539 finden Sie weiterführende Informationen. 9 10 Vorwort 11 Kurseinheit 1 Einführung in Mobile Security Diese Kurseinheit führt in die allgemeinen Sicherheitskonzepte und -mechanismen mobiler Endgeräte wie Smartphones und Tablets sowie der auf ihnen laufenden Betriebssysteme und Applikationen ein. Zuvor wird zu ihrer Motivation auf die Bedrohungen, denen solche Geräte und ihre Nutzer ausgesetzt sind, eingegangen. Hierbei werden die Inhalte des Abschnittes zu Smartphone-Sicherheit des Kurses „Sicherheit im Internet – Ergänzungskurs“ (01868) aufgegriffen sowie deutlich aktualisiert und erweitert. Lernziele Die Lernziele dieser Kurseinheit sind: • die Ursachen mannigfaltiger Bedrohungen für mobile Endgeräte und die bei ihrer Nutzung beteiligten Parteien kennenzulernen, • Verhaltensweisen von Nutzern zu kennen, die die Sicherheit von Endgeräten und der darauf gespeicherten Informationen gefährden können, • die allgemeinen Sicherheitsmechanismen mobiler Plattformen nennen und erklären zu können, • die Kernaspekte der Sicherheitsarchitekturen der populären Betriebssysteme Android und iOS verstanden zu haben und • weitere Maßnahmen zum Schutz mobiler Endgeräte und Applikationen sowie zur Detektion schädlicher Aktivitäten und zur Schadensminderung im mobilen Kontext benennen zu können. Kurseinheit 1 12 1.1 Einführung in Mobile Security Einleitung In den letzten Jahren haben sich Smartphones sehr stark verbreitet. Es handelt sich hierbei um eine Kombination aus Mobiltelefon und Computer. Man kann damit mobil telefonieren, aber auch Programme (engl. application) installieren und laufen lassen. Diese Programme werden kurz App genannt. Mit Hilfe dieser Programme lässt sich komfortabler kommunizieren. Eine kleine Kontaktdatenbank enthält die Namen, Telefonnummern und weitere Kontaktdaten von Familie, Freunden, Kollegen, usw. Statt umständlich lange Telefonnummern eintippen zu müssen, kann man jetzt bequem einen Eintrag der Kontaktliste auswählen und diesen direkt anrufen. Über das Mobilfunknetz oder ein WLAN kann ein Smartphone ständig mit dem Internet verbunden sein. Es kann Webanwendungen benutzen und Daten aus dem Internet laden, aber natürlich auch Daten ins Internet senden. Weiterhin sind moderne Smartphones auch mit einem GPS-Empfänger ausgestattet. Mit Hilfe dieses Empfängers ist der jeweilige Standort des Smartphones bekannt. Weiterhin können Smartphones auch beliebige andere Programme ausführen. Hierzu gehören Spiele oder auch Anwendungen, die vom aktuellen Standort des Smartphones abhängen1 , ebenso wie Büroanwendungen. Asokan et al. [2] charakterisieren Smartphones anhand dieser drei Eigenschaften: 1. Sie können ihre Funktionalität erweitern, indem neue Software-Komponenten installiert werden. 2. Sie können auf das Internet zugreifen und man kann aus dem Internet auf das Smartphone zugreifen. 3. Auf einem Smartphone liegen private und vertrauliche Daten. Smartphones werden nicht nur privat benutzt, sondern auf ihnen werden immer mehr dienstliche Anwendungen installiert. Daraus ergeben sich eine Reihe von Sicherheitsproblemen. Sie werden in Abschnitt 1.2 besprochen. Danach werden in Abschnitt 1.4 einige allgemeine Sicherheitstechniken vorgestellt, um den Bedrohungen begegnen zu können. Den Abschluss dieses Kursteils bildet Abschnitt 1.5. Dort werden zu den aktuell verbreitetsten Betriebssystemen von Smartphones die dort implementierten Sicherheitsmechanismen vorgestellt. 1.2 Allgemeine Bedrohungen In diesem Abschnitt sollen allgemeine Bedrohungen im mobilen Kontext besprochen werden, denen Smartphones und vergleichbare mobile Endgeräte sowie ihre Nutzer unterliegen. 1 Beispielsweise Restaurants in der Nähe finden. 1.2 Allgemeine Bedrohungen Verlust des Endgerätes und seine Folgen: Die erste und nächstliegende Bedrohung bei so kleinen und handlichen Geräten besteht im Verlust des Smartphones. Normalerweise führt man sein Smartphone immer mit und somit gibt es auch viele Gelegenheiten, bei denen das Smartphone vergessen und liegen gelassen werden kann. Aber auch bei Dieben sind Smartphones begehrt und so werden sie häufig gestohlen. Ein unredlicher Finder oder ein Dieb soll das Gerät aber nicht benutzen und damit dann auf Kosten des legitimen Eigentümers kommunizieren können. Um das zu erschweren wird der PIN-Mechanismus benutzt, der immer schon bei der Mobilfunktechnik eingesetzt wurde. Der Dieb soll aber natürlich auch keine Gelegenheit bekommen, die (vertraulichen) Daten auf dem Gerät auslesen zu können. Häufig ist der Speicherplatz auf Smartphones knapp, so dass alle Systeme auch die Speicherung von Benutzerdaten im Internet ermöglichen. Diese Dienste nennt man auch Cloud Services. Da das Smartphone ständig im Netz ist, kann es die Benutzerdaten auch jederzeit aus der Cloud des Benutzers laden und dann verarbeiten. Damit kann man beispielsweise seinen Kalender einfach zwischen PC und Smartphone synchronisieren. Aber auch Dokumente und Fotos werden gerne in der Cloud gespeichert. Natürlich möchte man nicht, dass andere diese Daten mitlesen können. Die Daten müssen also bei der Übertragung verschlüsselt werden und die Cloud muss einen guten und sicheren Mechanismus zur Benutzerauthentifizierung einsetzen. Hier kommen heute überwiegend passwortbasierte Verfahren zum Einsatz. Ist so ein Passwort auf dem Smartphone gespeichert – vielen Benutzern ist es zu unbequem, das Passwort immer wieder einzugeben – dann kann ein Dieb möglicherweise mit dem Smartphone alle Daten des Benutzers mitlesen. Sind in der Cloud jetzt noch die Benutzerpasswörter bei den vielen Internetdiensten (Online-Händler, Banking, eBay, Foren, usw.) gespeichert, so kennt der Dieb alle Informationen, um im Internet an die Stelle desjenigen zu treten, der das Smartphone verloren hat. Damit könnte der Dieb das Konto des Opfers plündern, seinen Ruf ruinieren und andere schlimme Dinge tun. Spionierende Anwendungen: Durch das GPS-Modul im Smartphone können die dort installierten Programme den Aufenthaltsort des Besitzers verfolgen. Voraussetzung ist, dass dem jeweiligen Programm der Zugriff auf das GPS-Modul erlaubt ist. Für alle location based services ist das auch erforderlich. Was ein Programm dann mit diesen Daten macht, bleibt häufig unklar. Gerade kostenlos vertriebene Programme sind oft so programmiert, dass sie diese Daten irgendwie kommerziell verwerten. Das Recht hierzu bekommen sie vom Benutzer bei der Installation oder Laufzeit des Programms erteilt. In den Lizenzbedingungen des Programms 13 14 Kurseinheit 1 Einführung in Mobile Security bekommt der Benutzer das Recht, das Programm installieren und benutzen zu dürfen und im Gegenzug gewähren die Benutzer dem Programmautor oft das Recht, die gewonnenen Daten zu verwerten. Neben diesen Aufenthaltsdaten gibt es viele weitere Daten, die kommerziell interessant sind. Wie oben schon erwähnt, gibt es die persönliche Kontaktliste des Benutzers. Sie enthält die Namen und Kontaktdaten von Familie, Freunden, Kollegen, usw. Mit diesen Daten kann man Beziehungsnetze erstellen, aus denen hervorgeht, wer wen kennt. Diese Daten lassen sich gut für Marketingzwecke einsetzen. Wenn viele Ihrer Kontakte als Tennisspieler bekannt sind, dann sind Sie vermutlich auch empfänglicher für Werbung für Tenniszubehör als der Durchschnittsmensch. Spezielle Programme wie z. B. WhatsApp, die einfache Kommunikationsmöglichkeiten ähnlich zur SMS anbieten, können bessere und bequemere Dienste anbieten, wenn der Benutzer ihnen den Zugriff auf die Kontaktliste gewährt. Diese Kontaktinformationen werden dann auf den Servern des Programmanbieters (also WhatsApp) gespeichert. Auch wenn Sie selbst kein WhatsApp-Benutzer sind, so können Ihre Kontaktdaten dort auf den Servern gespeichert sein. Dazu muss nur einer Ihrer Freunde, Familienmitglieder, Kollegen, usw. Ihre Daten in seiner Kontaktliste stehen haben und Benutzer von WhatsApp sein. Stehen die Server des Programmanbieters dann nicht in der EU und unterliegen den europäischen Vorschriften zum Datenschutz, so kann man nicht wissen, wer alles Zugriff auf diese Daten hat. Manipulierte Anwendungen: Neue Programme werden auf einem Smartphone normalerweise installiert, indem sie aus dem Internet geladen und dann installiert werden. Die früher üblichen Installationsmedien wie DVDs lassen sich bei Smartphones nicht mehr einsetzen. Woran kann ein Benutzer aber erkennen, dass ein Programm beim Herunterladen nicht unbemerkt manipuliert wurde? Für die verbreiteten Systeme Android und iOS gibt es sogenannte App Stores. Dort kann im Prinzip jeder Entwickler seine Programme anbieten. Die Verteilung des Programms und die Abrechnung des Kaufpreises übernimmt der Betreiber des App Stores. Entwickler müssen sich dort zwar registrieren, aber man kann als Käufer nicht sicher davon ausgehen, welche Person oder Firma denn ein Programm dort eingestellt hat. Obwohl die Plattform-Anbieter in ihren App Stores Schutzmechanismen einbauen, die schädliches Verhalten der von ihnen verteilten Apps aufdecken sollen und dies auch den Endnutzern kundtun (was ein falsches Sicherheitsgefühl hervorruft), muss man trotzdem davon ausgehen, dass Programme aus den App Stores möglicherweise von Hackern erstellt wurden und neben ihrer angepriesenen Funktion auch weitere unbekannte Funktionen enthalten. Man nennt solche Programme 1.2 Allgemeine Bedrohungen trojanisches Pferd. Damit ein trojanisches Pferd die anderen laufenden Programme nicht beeinträchtigen kann, bieten alle modernen Betriebssysteme für mobile Geräte spezielle Abschottungsmechanismen zwischen den Programmen an. Social Engineering: Die Gutgläubigkeit oder das Wohlwollen von Personen wird ausgenutzt, um sie dazu zu bringen, unabsichtlich Schadcode zu installieren und auszuführen. Dieser kann in vermeintlich harmlosen Apps versteckt worden sein oder auch nachträglich über einen Update-Mechanismus einer App seinen Weg auf das Smartphone finden. Auch durch den Besuch speziell präparierter Webseiten kann automatisch schadhafter Code heruntergeladen werden. Generell sind aber auch persönliche und sensible Informationen auf den Endgeräten bedroht. Zum Beispiel ist die unverschlüsselte Speicherung persönlicher Bilder in der StandardGalerie-App als gefährlich anzusehen. Ein Angreifer, welcher Zugang zum Gerät hat, kann diese auf einfache Art und Weise extrahieren und zum Zwecke des eigenen finanziellen Vorteils nutzen, indem sie verkauft oder gar zum Erpressen von Lösegeld genutzt werden. Durch aktivierte Ortsdienste und das Senden des persönlichen Aufenthaltsortes in sozialen Netzwerken setzen sich Nutzer auch bewusst Angreifern aus, die ihnen physisch schaden oder die Tatsache ausnutzen wollen, dass sie sich an einem speziellen Ort aufhalten (Einbruch, Raub, Diebstahl). Drahtlose Datenübertragung: Mobile Endgeräte verbinden sich i. d. R. drahtlos mit dem Internet. Dabei wird entweder WLAN oder ein Mobilfunknetz (GSM, UMTS, LTE, 5G, . . . ) benutzt. Durch Funk übertragene Daten lassen sich einfacher abhören oder manipulieren als bei kabelgebundener Übertragung. Ihr eigenes WLAN zu Hause können Sie durch den Einsatz von WPA3 einfach vor Abhören schützen. Aber über die vielen anderen, freien WLANs haben Sie keine Kontrolle. Häufig benutzen diese WLANs keine oder nur schwache Verschlüsselung. Sie müssen also davon ausgehen, dass andere im WLAN Ihren Datenverkehr mitlesen können. Ein Smartphone ist ständig im Netz, man kann nicht am herausgezogenen Kabel erkennen, dass es gerade offline ist. Auch fehlt eine dedizierte Firewall zwischen dem Smartphone und dem Internet. Zu Hause haben Sie i. d. R. eine Firewall, die die Kommunikation Ihrer Heimrechner mit Rechnern im Internet kontrolliert. Ein Smartphone kann ständig „angefunkt“ werden und muss sich selbst darum kümmern, dass nur die vom Benutzer erlaubte Kommunikation stattfinden kann. Auch über Kommunikationswege wie SMS/MMS, Bluetooth und neuerdings auch Near-field Communication (NFC) sind mobile Geräte Bedrohungen ausgesetzt. Designfehler in der SMS-Architektur können ausgenutzt werden, um Schadcode beim Opfer-System einzuschleusen. Auch ist es möglich, über so genannte 15 16 Kurseinheit 1 Einführung in Mobile Security „stille SMS“ den ungefähren Aufenthaltsort des angefragten Gerätes zu bestimmen oder zu herauszufinden, ob das Gerät überhaupt eingeschaltet ist. Dies passiert, ohne dass der Nutzer davon in Kenntnis gesetzt wird. Auch über Bluetooth kann schadhafter Code zwischen Geräten übertragen werden. Ein kompromittiertes Gerät kann sich selbst mit anderen Geräten mittels Standard-Passwörtern paaren und dann Kopien des Codes an das Zielgerät senden. Mittels so genannter Drive-by-Angriffe über NFC können Smartphones dazu gebracht werden, Webseiten aufzurufen, die Schadcode auf dem Gerät ausführen. Malware, die die NFC-Funktion des Smartphones nutzt, kann aber auch mit (entsprechend ausgerüsteten) Zahlungskarten in der näheren Umgebung kontaktlos interagieren und unerwünschte Transaktionen auslösen, ggf. sogar unbemerkt. Finanzielle Schäden: In Telefonnetzen werden seit längerem sogenannte Mehrwert-Dienste angeboten. Sie sind unter speziellen Rufnummern erreichbar und kosten den Anrufer mehr als ein „normaler“ Anruf. Diese Rufnummern werden von den heute üblichen Flatrates i. d. R. nicht abgedeckt. Ein Programm auf dem Smartphone, das im Hintergrund ständig solche Nummern anruft, kann den Besitzer des Smartphones sehr teuer zu stehen kommen. Beim Internet-Banking bieten einige Banken das MTAN-Verfahren an. Möchte der Benutzer eine Überweisung tätigen, so erzeugt der Server der Bank eine neue Transaktionsnummer (TAN) und sendet diese per SMS an die hinterlegte Mobiltelefonnummer des Kontoinhabers. Der Inhaber tippt diese Nummer dann ab und autorisiert damit die Überweisung. Ein Angreifer muss also (1) den PC des Benutzers erfolgreich angreifen, um an an die PIN zu kommen und (2) irgendwie an die SMS mit der TAN kommen. Hierzu kann man ein Programm schreiben, das, wenn es auf dem Smartphone des Kontoinhabers installiert ist, die SMS der Bank im Hintergrund abfängt und an einen Anschluss des Angreifers umleitet. Sollte der Benutzer seine PIN auch auf dem Smartphone gespeichert haben, dann fällt Schritt (1) für den Angreifer weg und die Anwendung auf dem Smartphone kann auch die PIN ausspionieren und dem Angreifer verraten. Benutzer eines Smartphones haben i. d. R. ihre Bezahlinformationen oder ein Guthaben (pre paid) beim App Store hinterlegt und können so einfach und bequem neue Programme kaufen, direkt herunterladen und installieren. Diese Funktion kann auch von Programmen ausgenutzt werden. Beispielsweise kann ein Benutzer nach dem Kauf eines Programms aus diesem Programm heraus weitere Komponenten „nachkaufen“. Spieleprogrammierer können so neue Levels erstellen und Spieler können diese dann aus dem Spiel heraus nachkaufen. Man nennt das auch In-AppKäufe. 1.2 Allgemeine Bedrohungen Eine bösartige App könnte ihre Benutzer nun durch In-App-Käufe dazu bringen, ihr Guthaben/Geld für nutzlose Dienste auszugeben. Neben dem Programmierer der bösartigen App profitieren auch die Betreiber der App Stores hiervon, sie bekommen ja eine Provision bei allen Käufen. Für Benutzer muss es also immer eindeutig und klar erkennbar sein, ob ein Klick auf einen Button in einer App einen kostenpflichtigen Einkauf auslöst oder nicht. Beteiligte Parteien: Beim Einsatz von Smartphones gibt es verschiedene beteiligte Parteien (engl. stakeholder) mit unterschiedlichen Interessen und Sicherheitsanforderungen [2]. Benutzer: Da ist als erstes der Benutzer des Smartphones. Sein Hauptinteresse liegt darin, dass seine Daten auf dem Smartphone sicher sind und dass das Gerät keinen „Unsinn“ macht. Außerdem möchte der Benutzer die völlige Freiheit mit dem Gerät haben, also beliebige Software installieren können. Ein sicheres Smartphone bedeutet in diesem Kontext und aus Nutzersicht, dass es der Nutzer zwanglos verwenden kann und sich somit die persönliche Nutzererfahrung verbessert. Das Smartphone ist primär durch einen externen Angreifer gefährdet, der entweder direkten Zugriff auf das Gerät erlangt oder über das Netz das Smartphone angreift. Aber auch die Hersteller wollen manchmal verhindern, dass Benutzer bestimmte Änderungen am Smartphone vornehmen. Hardware-Hersteller: Jedes Smartphone hat einen Hersteller. Er ist dafür verantwortlich, dass beispielsweise die elektromagnetische Strahlung im vorgesehenen Rahmen bleibt. Außerdem muss er sicher stellen, dass die weltweit eindeutige Gerätenummer International Mobile Equipment Identifier (IMEI) beispielsweise von einem Dieb nicht nachträglich verändert werden kann. Diese Daten müssen also in einem speziell geschützten Speicherbereich des Gerätes abgelegt sein. Weiterhin muss sich der Hardware-Hersteller um die Abwicklung von Garantieansprüchen kümmern und sollte Firmware-Updates für seine zumindest aktuellen Endgeräte bereitstellen. Hierbei hat der Hersteller nicht nur ein Interesse daran, Sicherheitslücken zu beseitigen, sondern auch neue Sicherheitsfunktionen und -optionen einzuführen, die die Konkurrenz (noch) nicht anbietet und somit neue Kunden zu gewinnen. Die Schutzziele des Herstellers sind primär durch den Besitzer des Gerätes (der legitime oder ein Dieb) gefährdet. Netzbetreiber: Die Betreiber von Mobilfunknetzen haben auch oft spezielle Interessen an Smartphones, die beispielsweise subventioniert an Kunden abgegeben werden. Solche Geräte sollen nur im Netz dieses Betreibers einge- 17 18 Kurseinheit 1 Einführung in Mobile Security setzt werden. Auch könnte das Geschäftsmodell des Betreibers dazu führen, dass bestimmte Programme, wie beispielsweise Voice over IP Anwendungen, nicht vom Benutzer installiert werden sollen. Statt dessen soll der Benutzer die kostenpflichtigen Dienste des Netzbetreibers benutzen. Software-Entwickler und Dienstanbieter: Sie möchten gerne beliebige Anwendungen installieren können und den kompletten Funktionsumfang des Smartphones in der Anwendung einsetzen können. Allerdings möchten sie nicht, dass die Benutzer des Smartphones beispielsweise die Anwendung beliebig kopieren können oder auf die Daten der Anwendung / des Dienstes zugreifen. Hierbei könnte es sich um kopiergeschütztes Material (Musik oder Filme) handeln. Der Benutzer soll diese Daten nur auf dem Gerät einsetzen können, für das er diese Daten gekauft hat. Plattform-Anbieter: Zum Smartphone gehört auch der Anbieter des Betriebssystems. Dieser ist für die Implementierung, Bereitstellung, Pflege und Support des jeweiligen Betriebssystems verantwortlich und muss hierzu auch regelmäßige Updates bereitstellen, um das Vertrauen seiner Nutzer und Kunden nicht zu verlieren. Er bietet meist auch die Entwicklungsumgebung für Anwendungsentwickler und einige „Basis-Anwendungen“ des Systems an. Der Plattform-Anbieter legt auch die Regeln fest, wie zusätzliche Software auf das Smartphone kommen soll. Das führt zum nächsten Beteiligten. Marktplatzbetreiber: Programme für Smartphones werden i. d. R. über einen Marktplatz vertrieben. Er wird oft auch App Store genannt. Sein Betreiber hat ein Geschäftsmodell und verdient am Verkauf der Software für die Smartphones. An diesen Erlösen werden die Software-Entwickler normalerweise beteiligt. Unlautere Software-Entwickler oder unlautere Smartphonebesitzer können die Interessen der Marktplatzbetreiber gefährden. Neben offiziellen App Stores, die von den Plattform-Anbietern betrieben werden, gibt es auch alternative App Stores von Drittanbietern und firmenbezogene App Stores (Corporate oder Enterprise App Stores), die oftmals ein App-Angebot mit einer speziellen Ausrichtung (z. B. freie und Open-Source-Software) bereitstellen. Administratoren: Immer wenn Smartphones von Arbeitgebern gestellt werden und von den Angestellten auch privat benutzt werden, haben die Administratoren des Arbeitgebers Sorgen. Sie möchten gerne sicherstellen, dass vertrauliche Firmendaten nicht durch die private Nutzung des Smartphones gefährdet werden. Neben den ohnehin vorhandenen Gefährdungen führen privat 1.3 Riskantes Nutzerverhalten installierte Apps zusätzliche (und meist größere) Gefährdungen hinzu. Unvorsichtige Smartphonebenutzer sind hier die größte Gefährdung. 1.3 Riskantes Nutzerverhalten Viele Nutzer setzen durch ihr eigenes Verhalten im Umgang mit Smartphones diese selbst und ihre (persönlichen) Informationen einer erhöhten Gefahr aus. Diese Geräte sind – wie oben angesprochen – oftmals dauerhaft in Betrieb und mit dem Internet verbunden. Dieses als “Always-on” bekannte Paradigma ist den (technisch weniger versierten) Nutzern oftmals wichtiger als der Sicherheitsstatus der WLANNetzwerke, mit denen Sie sich verbinden. Auch ist die leichtsinnige und ungeprüfte Installation von Apps (auch aus bekannten App Stores) in diesem Kontext bedenklich. Die folgende, keinesfalls als abschließend zu betrachtende Liste führt weitere nutzerbedingte Ursachen auf, die die Sicherheit von Endgeräten und die darauf gespeicherten Informationen gefährden: • Nutzer sind sich oft über Gefahren im Hinblick auf die Sicherheit ihrer Geräte und den Schutz ihrer Informationen nicht bewusst. • Nutzer haben auch meist geringes Wissen über die Vermeidung von Sicherheitsproblemen und über Mechanismen zum Schutz ihrer Informationen auf ihren Geräten. • Anfragen von Apps, ihnen Berechtigungen zu geben, werden oft bedenkenlos bewilligt, auch wenn der Zweck solch einer Anfrage wenig Sinn macht (falls er überhaupt erklärt wird). • Apps aus externen (unbekannten) Quellen werden insbesondere unter Android trotz eingeblendeter Warnungen des Systems installiert und entsprechende Risiken in Kauf genommen. Die betreffende Option muss sogar erst aktiv eingeschaltet werden (siehe Abbildung 1.1). • Wichtige oder sensible Daten auf den Endgeräten werden zumeist nicht verschlüsselt abgelegt. Wie oben dargelegt, ist es so für Angreifer leicht, an persönliche Informationen zu gelangen. • Geräteeigene Dienste, z. B. zur Erfassung der Position, werden bedenkenlos genutzt oder Zugriffe darauf bereitwillig gewährt. Aufgrund der hohen Verbundenheit der Nutzer mit ihren Geräten, müssen Firmen, in denen der Einsatz privater Smartphones erlaubt wird, Maßnahmen ergreifen und darauf hinwirken, solche Einstellungen und Verhaltensweisen zu ändern, um 19 Kurseinheit 1 20 Einführung in Mobile Security Abbildung 1.1: Installationswarnung für Apps aus unbekannten Quellen Sicherheitsrisiken zu minimieren. Ein bedeutsames Informationsleck kann etwa zu enormen Kosten bei der Regulierung des Schadens führen. Weiterhin können solche Vorfälle (sofern sie nach außen bekannt gemacht werden) das Ansehen des Unternehmens schmälern und Kunden zur Abwanderung bewegen, was Umsatz- und Gewinneinbußen zur Folge hat. Darum ist es in solchen Umgebungen angeraten, Sicherheitsfunktionen in mobilen Endgeräten standardmäßig zu aktivieren sowie die Angestellten in sicherheitsbezogenen Praktiken und Denkweisen zu schulen, in diesem Zuge aber auch die Security-Awareness im privaten und betrieblichen Umfeld zu erhöhen. 1.4 Allgemeine Sicherheitsmechanismen Schichtenarchitektur: Für alle Smartphones gibt es eine gemeinsame in Schichten angeordnete Systemstruktur, siehe Abbildung 1.2. Die Basis der Struktur ist die Hardware des Smartphones. Sie muss nicht nur die Programme ausführen, sondern auch bestimmte Sicherheitsfunktionen bereitstellen. Darüber befindet sich ein Betriebssystem, dessen Kern sich u. a. um die Steuerung der Hardware kümmern muss. Weiterhin bietet das Betriebssystem auch die Schnittstelle zu den Anwendungsprogrammen. Sie besteht aus den System-Diensten und den System-Bibliotheken. Darauf bauen die Anwendungsprogramme auf. Anwendungsprogramme können „klassische“ Programme mit einer Benutzerschnittstelle (engl. user interface) sein oder ein Dienst (engl. service) ohne eigene Benutzerschnittstelle. 1.4 Allgemeine Sicherheitsmechanismen Abbildung 1.2: Architekturübersicht von mobilen Plattformen aus [2] Das Betriebssystem muss auch eine Reihe von Sicherheitsfunktionen anbieten. Abbildung 1.3 zeigt, wie man sich eine nächste Detaillierungsstufe vorstellen kann. Die Platform Security Architecture ist eine Menge von Software-Komponenten, die einerseits die zugrunde liegende Hardware ansprechen und andererseits von den darüber liegenden Anwendungen und Diensten benutzt werden. Die PlatformSecurity-Architecture-Komponenten sind in den grau hinterlegten Rechtecken dargestellt. Sie werden vom Hersteller des Smartphones typischerweise mitgeliefert. Rechtecke mit weißem Hintergrund stellen die von Dritten bereitgestellten Programme oder Dienste dar. In Ovalen sind die o. g. Beteiligten am Gesamtsystem dargestellt. Sie benutzen bestimmte Komponenten der Security Architecture. Grundprinzipien: Ausgehend von der Architektur aus Abbildung 1.3 erfüllt jede Plattform dieselben drei Prinzipien [2]: 1. Isolierung der Programme: Jedes Programm (engl. application) läuft in seiner eigenen Laufzeitumgebung und hat seine eigene persistente Speicherumgebung. Man nennt das oft auch Sandkasten (engl. sandbox). Ein Programm agiert nur in seiner Sandbox und kann nicht mit anderen Programmen, bzw. deren Sandbox, interagieren. Eine spezielle Komponente der Security Architecture, die in Abbildung 1.3 IPC (Inter-Process Communication) genannt wird, ist die einzige Möglichkeit, über die verschiedene Programme miteinander interagieren. 21 22 Kurseinheit 1 Einführung in Mobile Security Abbildung 1.3: Modell einer Mobile Platform Security Architecture aus [2] 2. Zugriffskontrollmodell: Damit der Benutzer die Kontrolle behält, welche Programme auf Daten welcher anderen Programme zugreifen können, arbeitet die IPC-Komponente sehr eng mit einem sogenannten Reference Monitor zusammen. Nur wenn entsprechende Berechtigungen eingetragen sind, wird die Kommunikation über die IPC-Komponente erlaubt. 3. Digital signierte Programme: Bei der Zugriffskontrolle müssen Subjekte eindeutig authentisiert werden. Dazu werden Programme digital signiert. Dadurch wird nicht nur sichergestellt, wer das Programm geschrieben hat, sondern auch, dass das Programm unverändert vorliegt. Software-Verteilung: Die Softwareverteilung erfolgt i. d. R. über das Internet. Auf einem Marktplatz werden Programme angeboten und die Benutzer können die Programme über den Marktplatz erwerben und herunterladen. Im Prinzip kann jeder Anbieter auf diesem Marktplatz sein. Ein Benutzer kann nicht ohne weiteres erkennen, ob es sich um einen seriösen Anbieter oder einen Hacker handelt. Einige Marktplatzbetreiber versuchen den Zugang zu ihrem Marktplatz zu kontrollieren. So müssen sich Programmierer beispielsweise namentlich registrieren. Trotzdem bleibt das Problem, dass niemand weiß ob der Entwickler „Meier, Kurt aus Saarbrücken“ zu den seriösen Anbietern oder den Hackern gehört. Also werden meist auch die Programme selbst überprüft. Aber auch das ist sehr schwierig, denn man kann nicht automatisch herausfinden, ob ein Programm etwas „böses“ macht oder nicht. Das vergleichsweise viel einfachere Halteproblem ist ja schon nicht entscheidbar. Daher müssen Menschen die Programme prüfen, bevor sie auf 1.4 Allgemeine Sicherheitsmechanismen dem Marktplatz angeboten werden. Hat man ein passendes Programm im Marktplatz gefunden und möchte es installieren, dann ergibt sich das nächste Problem. Der Benutzer muss kontrollieren können, welche Berechtigungen das Programm denn bekommen soll. Letztlich konfiguriert der Benutzer hierbei den Reference Monitor. Das Programm muss dem Benutzer mitteilen, welche Berechtigungen es gerne haben möchte und der Benutzer muss hierüber entscheiden. Die konkreten, evtl. sehr detaillierten Berechtigungen überfordern häufig den normalen Benutzer. Das System muss also eine vereinfachte Abstraktion des Berechtigungsmodells anbieten, so dass der Benutzer sich nicht mit den vielen Details beschäftigen muss. Das MS Windows Dateisystem bietet auch eine solche Abstraktion. Hinter dem „abstrakten“ Recht Vollzugriff verbergen sich die vielen einzelnen Rechte wie Lesen, Schreiben, Ändern, Rechte vergeben, usw. Wichtig ist hierbei, dass dem Benutzer nur Abstraktionen angeboten werden, die (1) für den Benutzer verständlich sind und (2) hinter denen sich tatsächlich auch nur die detaillierten Berechtigungen verbergen, die man normalerweise dort auch erwarten würde. Das abstrakte Recht Kontaktdaten lesen dürfen darf daher nicht auch den Zugriff auf das GPS-Modul erlauben oder Zugriff auf andere vertrauliche Daten ermöglichen. Außerdem ist es wichtig, dass die Benutzerentscheidungen so gespeichert werden, dass sie nicht nachträglich von der Anwendung verändert werden können. Also darf nur ein spezielles Installationsprogramm diese Informationen erheben und speichern. Trotzdem sollte der Benutzer seine Entscheidungen auch nach der Installation eines Programms noch einmal ändern können. Laufzeitumgebungen: Das Betriebssystem auf dem Smartphone sollte eine Benutzerverwaltung realisieren. Sie ist die Basis für die Implementierung des Reference Monitors. Alle Zugriffe von Programmen auf kritische Ressourcen müssen vom Reference Monitor vorab überprüft werden. Hat der Benutzer bei der Installation des Programms die Berechtigung erteilt, dann darf das Programm den Zugriff ausführen. Fehlt die Berechtigung, dann wird dem Benutzer häufig eine Dialogbox angezeigt. Dort steht, dass das Programm xy auf die Ressource z zugreifen will und die Berechtigung fehlt. Das wird mit der Frage an den Benutzer verbunden, ob er die Berechtigung jetzt erteilen mag. Weiterhin müssen Laufzeitumgebungen verhindern, dass Anwendungen das Berechtigungssystem umgehen oder auf den Adressraum einer anderen Anwendung zugreifen kann. Die Konzepte hierfür sind bekannt und sie werden bei Betriebssystemen schon seit Jahren angewendet. Das Konzept der virtuellen Maschinen trennt 23 24 Kurseinheit 1 Einführung in Mobile Security nicht nur einzelne Prozesse, sondern komplette virtuelle Computer voneinander. Sie werden daher auch in den Betriebssystemen von Smartphones oft eingesetzt. Persistent gespeicherte Daten, z. B. auf Speicherkarten, müssen verschlüsselt sein, damit die Vertraulichkeit der Daten auch nach Verlust der Speicherkarte gewahrt bleibt. Es ist besser, wenn sich nicht jedes Programm selbst um die Verschlüsselung der Daten kümmern muss. Statt dessen sollen die Programme so wie immer geschrieben werden. Die Laufzeitumgebung muss nun transparent für den Programmierer sicherstellen, dass alle Systemaufrufe zur Speicherung von Daten erst die erforderliche Verschlüsselung durchführen und danach die Daten auf das Speichermedium schreiben. In den Systemaufrufen zum Lesen muss dann natürlich eine entsprechende Entschlüsselung vorgesehen werden. Da Smartphones oft in „unsicheren“ WLANs eingesetzt werden müssen die Netzverbindungen immer verschlüsselt werden. Die Smartphone-Betriebssysteme unterstützen daher alle die Verschlüsselungsprotokolle SSL bzw. TLS. Surft man mit dem Smartphone im Internet, kann man damit vertrauliche und authentische Verbindungen zu Web-Servern realisieren. Auch der Abruf von E-Mails von einem Server kann hiermit geschützt werden. Auch Virtual Private Network (VPN)Software gehört zu einem Smartphone-Betriebssystem. Management: Dieser Problembereich ist mehr organisatorischer als technischer Natur. Statt eines Firmen-Smartphones und eines privaten Smartphones möchten die meisten Menschen nur ein (vornehmlich ihr eigenes) Smartphone mit sich herum tragen und dieses mit IT-Systemen des Arbeitgebers verbinden. Das in diesem Kontext allgegenwärtige Paradigma “Bring Your Own Device” (BYOD) kann durch unterschiedliche Strategien umgesetzt werden. Generell sollen auf dem Smartphone die geschäftlichen und die privaten Anwendungen oder Daten gemeinsam gespeichert und verwaltet werden. Sinnvollerweise möchte man eine Trennung dieser beiden Bereiche vornehmen. Auch sollen für diese möglicherweise unterschiedliche Security-Policies gelten. Aus diesen Gründen betreiben Firmen oftmals spezielle Lösungen für Enterprise Mobility Management, EMM, über die es möglich ist, eine Vielzahl mobiler Geräte ihrer Angestellten zu administrieren. Hierbei werden über Profile die betreuten oder administrierten Geräte feingranular gesteuert. Unter anderem kann so festgelegt werden, ob der Nutzer bestimmte Aktionen wie die Installation und Löschung von Apps auf dem Gerät ausführen darf. Weiterhin unterstützen diese Lösungen eine weitgehende Verwaltung von Nutzerrollen und Berechtigungen, Gerätefunktionen, Systemeinstellungen, App Stores und Apps sowie das Tracking verwalteter Geräte. Obwohl der letzte Aspekt dazu dienen soll, verloren gegangene Geräte wiederzufinden, lässt sich darüber aber auch ein Bewegungsprofil des Nutzers leicht erheben (ungeachtet geltender Datenschutzregelungen). Aber 1.5 Konkrete Systeme auch auf Plattform-Ebene wird üblicherweise eine Trennung von Privat- und Geschäftsbereich durch Profilisolation unterstützt. Zum Beispiel wird ab Android 5.0 die Lösung Android Enterprise, ehem. Android for Work angeboten, die von gängigen EMM-Systemen administriert werden kann. Trotzdem kann es dabei Konflikte geben: Während Firmen daran interessiert sind, dass alle Systemaktualisierungen rechtzeitig installiert werden, möchte ein „normaler“ Anwender vielleicht lieber noch weiter mit einer älteren Version des Systems arbeiten. 1.5 Konkrete Systeme In diesem Abschnitt werden zwei populäre Betriebssysteme für Smartphones etwas genauer betrachtet. Neben ihrer Funktionsweise soll insbesondere darauf eingegangen werden, wie die Systeme aufgebaut und wie die Sicherheitsmechanismen dort umgesetzt sind. Android: Die Firma Google hat auf der Basis des Betriebssystems Linux das Smartphone-Betriebssysteme Android entwickelt. Wie Linux ist auch Android im Quelltext frei verfügbar (engl. open source) und verschiedene Hersteller vom Smartphones passen Android für ihre Geräte an und erweitern es auch falls erforderlich. Der Google Play Store ist der zentrale Verteilmechanismus für AndroidProgramme. Neben diesen Programmen werden dort auch andere digitale Produkte vertrieben, z. B. Nachrichten, Musik, Filme oder Bücher. Google behält sich vor, bestimmte Programme/Inhalte im Play Store nicht zuzulassen. Außerdem werden alle Programme automatisch von einem Antivirus-Programm geprüft, bevor sie im Play Store akzeptiert werden. Leider garantiert das nicht, dass „schädliche“ Programme nicht in den Play Store gelangen. Benutzer müssen die Programme für ein Android-Smartphone allerdings nicht über den Google Play Store erwerben und installieren. Man kann auch Programme direkt von der Website eines Entwicklers laden und installieren. Dazu muss der Entwickler ein sogenannten Android Package erstellen. Das ist eine digital signierte Archivdatei, deren Name auf .apk endet. Auch können andere Betreiber von Shop-Systemen für Android auftreten. Über den Google Play Store vertriebene Apps müssen seit August 2021 als Android App Bundle (AAB) veröffentlicht werden. In einem solchen Bundle befinden sich der kompilierte Code und alle App-Ressourcen. Der Store nutzt nun dieses Veröffentlichungsformat zur eigenständigen Generierung von optimierten .apk-Dateien, zu deren Signierung und Auslieferung. Die optimierten .apk-Dateien enthalten nur noch auf den Nutzer/Endgerät zugeschnittene Sprachdateien und Ressourcendateien für die spezifische Displaygröße. Auf diese Weise fallen die App-Downloads etwa 15 Prozent 25 26 Kurseinheit 1 Einführung in Mobile Security kleiner aus. Weitere Information zu dem neuen Veröffentlichungsformat sind unter https://developer.android.com/guide/app-bundle zu finden. Bevor ein Programm geladen und installiert wird bzw. wenn eine bestimmte, ggf. gefährliche Funktion genutzt werden soll, werden die vom Programm angeforderten Berechtigungen angezeigt. Der Benutzer muss nun entscheiden, ob diese Berechtigungen erteilt werden sollen (dann kann das Programm installiert bzw. die Funktion ausgeführt werden) oder nicht (dann wird das Programm nicht installiert bzw. die Funktion nicht ausgeführt). Eine Manifestdatei AndroidManifest.xml aus dem Android Package beschreibt (1) die Komponenten, aus denen die App besteht, (2) welche Hardwareeigenschaften zur Ausführung erforderlich sind (z. B. eine Kamera für Apps, die Fotos machen können) sowie (3) die Berechtigungen, die für die Ausführung benötigt werden. Abbildung 1.4: Übersicht über den Softwarestack von Android [3] Abbildung 1.4 zeigt den Softwarestack von Android. Die Basis ist ein LinuxKernel. Er sorgt für die Ansteuerung der Hardware und bietet bereits die im Betriebssystem angebotenen Sicherheitstechniken. Darüber liegt ein Hardware Abstraction Layer (HAL). Auf einer dritten Ebene befinden sich die Bibliotheken (engl. libraries) sowie die Laufzeitumgebung. Programme für Android werden i. d. R. in der Programmiersprache Java (neuerdings auch in Kotlin) entwickelt. Ausgeführt werden sie dann in einer Java Virtual Machine (JVM). Jede App wird in einer eigenen JVM gestartet, die ihrerseits ein 1.5 Konkrete Systeme eigener Prozess im zugrundeliegenden Linux-System ist. Jede App bekommt eine eigene UNIX user id, unter der sie läuft. Die Dateizugriffsberechtigungen des Linux-Basissystems basieren auf ihnen. Dadurch wird sichergestellt, dass eine App nicht auf die Dateien einer anderen App zugreifen kann. Die Laufzeitumgebung hieß früher Dalvik VM (siehe Abbildung 1.4), aktuell heisst sie Android Runtime (ART). Sicherheitskritische Funktionen aus den Bibliotheken sind so implementiert, dass sie zunächst die user id der aufrufenden App nehmen und die zu dieser id vorliegenden Berechtigungen überprüfen. Nur wenn die passende Berechtigung gewährt und eingetragen wurde, wird die eigentliche Bibliotheksfunktion ausgeführt. Die Abschottung zwischen den Anwendungen wird vom Linux-Kernel implementiert. Da jede Virtual Machine und damit jede Anwendung unter einer eigenen, festen und entwicklerspezifischen Benutzerkennung (engl. user id, UID) in einem eigenen Prozess läuft, können über passende Zugriffsrechte (nur der Benutzer selbst darf lesen, schreiben, ausführen und andere Prozesse haben keine Berechtigungen) die betriebssystemeigenen Discretionary Access Controls (DAC) verhindern, dass eine Anwendung mit einer anderen Anwendung interagiert. Auf diese Weise werden Apps voneinander und auch gegenüber dem eigentlichen System isoliert. Apps, die mit dem gleichen Entwicklerschlüssel signiert wurden, erhalten die gleiche UID. Eine wichtige Erweiterung des Android-Sicherheitsmodells erfolgte ab Android 4.3 durch die Integration des Kernel-Moduls SELinux. Dieses unterstützt die Durchsetzung von systemweiten Richtlinien zur Kontrolle des Zugriffs von Subjekten (Prozesse) auf Objekte (Ressourcen) mit Hilfe von Mandatory Access Controls (MAC). Hierbei werden Informationsflüsse in Abhängigkeit der Vertrauenswürdigkeit (auf Basis von Sicherheitsmarkierungen) der Subjekte und Objekte sowie der sie involvierenden Operationen wie Lesen und Schreiben (Flussrichtung) geregelt, also gewährt oder unterbunden. Obwohl SELinux zwar nicht gegen Verwundbarkeiten im Kernel schützen kann, bietet es aber weitergehende Möglichkeiten, Apps voneinander zu trennen und (unerwünschte) Rechteausweitungen zu verhindern. Seit Android 4.4 ist die Sicherheitsfunktion “Verified Boot” verfügbar, welche die Integrität der Gerätesoftware bei jedem Start überprüft. Wenn das AndroidGerät startet, wird der Bootprozess durch das Kernel-Feature device-mapper-verity, kurz dm-verity verifiziert. Hierbei werden die durch den Gerätehersteller signierten Hashwerte von zum Betriebssystem gehörenden Speicherblöcken mittels SHA-256 berechnet und mit zuvor gespeicherten Hashwerten verglichen. Ihre Unversehrtheit wird durch die Verifikation der Boot-Partition mittels eines unveränderbaren, in der Gerätehardware gespeicherten Schlüssels sichergestellt. Auf diese Weise sollen Manipulationen durch Schadsoftware und Rootkits aufgedeckt werden. Im Falle einer festgestellten Manipulation der Boot-Partition wird das Gerät mit einer entsprechenden Fehlermeldung ausgeschaltet. Ist eine andere Partition betroffen, wird der Nut- 27 28 Kurseinheit 1 Einführung in Mobile Security zer möglicherweise darauf hingewiesen, dass das Gerät fehlerhaft ist, ihm darum nicht vertraut werden kann und es nicht ordnungsgemäß funktionieren könnte. Ein Start des Systems ist dann aber teilweise noch möglich. Somit stellt “Verified Boot” eine zuverlässige Basis für die übrigen Sicherheitsfunktionen dar. Ihr Einsatz ist seit Android 7.0 obligatorisch, um den Start kompromittierter Geräte zu verhindern. Zur Verschlüsselung der auf dem Android-Gerät befindlichen Daten wurde bis Android 6 nur Vollverschlüsselung unterstützt. Hierbei wird der gesamte FlashSpeicher auf Blockebene mit AES-128 mit Chiffrierblockverkettung (CBC) und ESSIV:SHA256 (Encrypted Salt-Sector Initialization Vector) verschlüsselt. Der Master-Key, der auch Disk Encryption Key (DEK) genannt wird und für die eigentliche Blockverschlüsselung verwendet wird, wird selbst wiederum über Aufrufe der OpenSSL-Bibliothek mit 128-Bit-AES oder höher verschlüsselt. Dieser wird aus einem Geheimnis des Nutzers wie Passwort, PIN und Entsperrmuster sowie einem Salt abgeleitet. Er war bis einschließlich Android 7 für den gesamten Datenträger gültig, also sowohl für das persönliche als auch das Arbeitsprofil. Ab Android 8.0 werden für solche Profile unterschiedliche Schlüssel verwendet. Trotzdem liegen bei diesem Ansatz die persönlichen Daten nach dem Gerätestart unverschlüsselt vor. Auch wird hier der kryptographische Schlüssel im Speicher gehalten solange das Gerät eingeschaltet ist. Seit Android 7.0 wird darum auch dateibasierte Verschlüsselung, also die Verschlüsselung von verschiedenen Dateien mit unterschiedlichen Schlüsseln, eingesetzt. Gleichfalls erfolgt die Entschlüsselung unabhängig voneinander. Auf dieser Basis wird die ebenfalls in Android 7.0 eingeführte Funktion “Direct Boot” realisiert, durch die es möglich ist, auch ohne Eingabe von Anmeldeinformationen nach einem Geräteneustart wichtige Systemdienste und anwendungen starten zu können, was unter Vollverschlüsselung nicht möglich war. Auf diese Weise können etwa Alarme ausgelöst und Anrufe entgegengenommen werden, wobei in diesem Kontext sensible Nutzerdaten weiterhin geschützt bleiben. Ab Android 10 ist die Nutzung dateibasierter Verschlüsselung verpflichtend. Seit Android 11 ist das Konzept des Scoped Storage verfügbar. Für Apps, die diese oder eine höhere Version adressieren, ist das Feature verpflichtend und standardmäßig aktiviert. Durch dieses haben Apps nur Zugriff auf die eigenen AppDateien (auch in einem Verzeichnis auf einem externen Speichermedium) und die durch sie erzeugten Multimedia-Dateien. Zu diesem Zweck wird in einer Datenbank die jeweilige Zuordnung von Apps als Eigentümer zu ihren Dateien vorgehalten. Apps können so leicht in den von ihnen erzeugten Dateien navigieren. Auch ist es so möglich, bei der Entfernung einer App die zu ihr gehörenden Dateien ebenfalls automatisch und ohne Zuhilfenahme einer weiteren Hilfs-App zu löschen. Der Media Store hilft zudem dabei, im Rahmen von indizierten Collections thematisch passende Inhalte wie Bilder und Downloads zu gruppieren und den Zugriff auf die darin 1.5 Konkrete Systeme enthaltenden Elemente zu vereinheitlichen. Durch diese Mechanismen soll verhindert werden, dass Apps z. B. im Kamera- oder Download-Ordner nach Belieben Dateien ablegen und diese Orte „verschmutzen“. Soll eine App dennoch auf von einer anderen App erzeugten Dateien zugreifen, so muss auf das Storage Access Framework zurückgegriffen werden. Für zusätzliche Informationen zu diesen Konzepten sei auf die Seite https://developer.android.com/training/datastorage verwiesen. Weitere Informationen zu Android und zur Sicherheit von Android-Apps finden Sie in den eingangs genannten neueren Fachbüchern, bei Gunasekera [4] oder im Internet unter: https://developer.android.com/index.html http://source.android.com/ iOS: Die Firma Apple hat auf das Basis von OS X für das eigene Smartphone iPhone das Betriebssystem iOS entwickelt. Es ist keine freie Software und läuft nur auf den Smartphones und Tablets der Firma Apple. Programme bzw. Apps können nur über den App Store von Apple auf ein iOSGerät geladen und installiert werden. Voraussetzungen sind, dass die Entwickler bei Apple registriert sind und dass die Programme digital signiert sind. Auch Apple behält sich vor, Programme vor der Aufnahme in den App Store zu überprüfen. Auch dieses Verfahren kann nicht garantieren, dass „schädliche“ Programme nicht in den App Store kommen. In Abbildung 1.5 findet sich eine Übersicht über die Sicherheitsarchitektur in Apple iPhones. Sie ist hierarchisch aufgebaut und basiert auf einer Hardware, die bereits bestimmte Sicherheitseigenschaften aufweist. Im Boot-ROM befindet sich neben dem Code zum Laden des Betriebssystems auch der öffentliche Schlüssel der Apple Wurzelzertifizierungsstelle (engl. root CA). Mit diesem Schlüssel kann man die digitalen Signaturen unter den anderen Apple-Zertifikaten prüfen und letztlich damit auch die digitalen Signaturen unter dem Betriebssystem-Code. Man kann das mit der chain of trust in einem Trusted Platform Module, TPM vergleichen. Nur Betriebssystem- oder Programm-Code mit einer gültigen digitalen Signatur wird auf dem Gerät ausgeführt. In der Hardware des Gerätes sind auch Komponenten zur Unterstützung von V