Android implementiert ein Berechtigungsmanagement, um Apps den Zugriff auf sensiblen Nutzerdaten und System-Ressourcen zu verwehren. Doch...
Smartphone Betriebssysteme implementieren ein Berechtigungsmanagement, um Apps den Zugriff auf sensiblen Nutzerdaten und System-Ressourcen zu verwehren. Dennoch ist es einigen Apps unter Android gelungen das Berechtigungsmanagement zu umgehen. Damit können sie sich den Zugang zu den sensiblen Nutzerdaten verschaffen. Wir erläutern in diesem ersten Teil, wie das funktioniert.
Hierfür nutzten sie sogenannte „covert channel“ und „side channel“. Side channels ermöglichen es Apps, ohne Berechtigung auf geschützte Daten und Systemressourcen zuzugreifen, wohingegen covert channels die Kommunikation zwischen zwei zusammenarbeitenden Apps ermöglicht. Der eigentliche Clou in covert channels ist, dass die Apps ihre Berechtigungen teilen können. So kann App 1 das Mikrofon durch App 2 nutzen, obwohl es nicht einmal die Berechtigung dafür besitzt. Beide channels sind eine Gefahr für die Privatsphäre der Nutzer.
Daten müssen vor einem nicht autorisierendem Zugriff geschützt werden
Durch die Nutzung des Android Smartphones sammeln sich im Laufe der Zeit auch private Daten an wie z.B. Notizen, Adressbücher, Bilder, Browserverläufe, Videos etc. Des Weiteren ist es dadurch einigen Apps erlaubt, auf Sensoren, Kameras oder auf das Mikrofon zuzugreifen. Apps könnten auch auf die Daten des Endnutzers (e.g. E-Mail-Adressen, Kontaktlisten), sowie auf eindeutige persistente Daten (e.g. IMEI) zugreifen. Es ist sehr wichtig diese Daten vor einem unautorisierenden Zugriff zu schützen.
Androids Berechtigungsmanagement
Android implementiert seit der Version 6.0 ein Berechtigungssystem, dass den Zugang zu sensiblen System-Ressourcen von Third-Party Apps regelt. In diesem Modell, muss der App-Entwickler explizit die Berechtigungen für System-Ressourcen anfragen. Dieses Modell sieht vor, dass der Nutzer selbst entscheidet welche Apps Zugang zu Ressourcen und Daten haben und welche nicht.
Android isoliert Apps voneinander
Das Android-Betriebssystem isoliert Nutzer-Anwendungen, um zu verhindern, dass diese mit anderen laufenden Anwendungen interagieren. Dies geschieht, indem es jeder App zur Laufzeit eine separate User-ID zuweist und weitere Zugriffskontrollen mit SELinux implementiert. Jeder laufende Prozess einer App wird durch den geschriebenen Code selbst ausgeführt oder durch SDK-Bibliotheken (Software Development Kit), die in der App implementiert sind.
Diese SDKs können von Android selbst kommen oder von Drittanbietern. App-Entwickler integrieren Bibliotheken für Zwecke wie Absturzmeldungen, Entwicklersupport, Google Analytics Services, Werbung oder für soziale Netzwerke. Nach dem designten Berechtigungsmanagement von Android hat jede Drittanbieter-Bibliothek dieselben Zugriffsrechte wie die App, die sie implementiert. Anders ausgedrückt: Wenn eine App den Standort kennt, dann auch ihre Drittanbieter-Bibliotheken.
Sicherheitsmechanismen können umgangen werden
In der Praxis können solche Sicherheitsmechanismen oft umgangen werden. Wie anfangs schon erwähnt, geschieht dies durch side channels und covert channels. Diese beiden Methoden treten auf, wenn es unter Android einen alternativen Zugang zu den geschützten Ressourcen gibt, der vom Sicherheitsmechanismus nicht überprüft wird. Dadurch bleiben die Ressourcen ungeschützt.
Ein side channel zeigt einen Pfad zu einer System-Ressource auf, welche außerhalb des Sicherheitsmechanismus liegt. Dies kann ein Designfehler des Sicherheitsmechanismus oder ein Fehler durch die Implementation sein. Ein klassisches Beispiel für einen side channel ist, dass der Stromverbrauch der Hardware bei der Durchführung kryptographischer Operationen Teile eines geheimen Schlüssels leaken kann. Covert channels sind, anders als side channels, bewusst designt worden.
Hierbei stellt App X der App Y Daten und Zugänge zur Verfügung, die App Y über die App X nutzen kann und das ohne gegen den Sicherheitsmechanismus zu verstoßen. Beispielsweise wenn AliceApp die IMEI legitim liest und sie dann an BobApp weitergibt, obwohl es BobApp verweigert wurde, wenn er sie über die entsprechenden zugriffsgeschützten Android-APIs anfordert.
Fortsetzung der Serie: Wie bei Android manche Apps alle Sicherheitsmechanismen umgehen.
Beitragsbild von Pathum Danthanarayana, thx!
Tarnkappe.info
