Android-Berechtigungen umgehen

Originalartikel von Yinfeng Qiu, Mobile Threat Analyst

Die Berechtigungen auf Android-Geräten sollen gewährleisten, dass Apps ohne explizite Rechte keinerlei schädliche Aktionen auf dem Mobilgerät ausführen können. Oder können sie doch?

Funktionsweise

Eine Android-App hat nur zu begrenzten Systemressourcen Zugang. Um auf ein kritisches API zuzugreifen, muss sie explizite Berechtigungen haben, die in der AndroidManiflest.XM-Datei gespeichert sind. Zu dieser Art von API gehören Kamerafunktionen, Standortdaten (GPS), Bluetooth- und Telefoniefunktionen, SMS/MMAS sowie Netzwerk/Daten-Verbindungen.

Nach der Installation einer App zeigt der App Installer dem Anwender diese geforderten Berechtigungen, und der kann sie akzeptieren oder verweigern.

Abbildung 1: Screenshot mit App-Berechtigungen

Gewährt der Nutzer die Berechtigungen, so werden sie so lange auf die App angewendet, bis diese vom Gerät wieder entfernt wird. Während der Laufzeit benachrichtigt das System den Nutzer nicht mehr, wenn auf ein sicherheitskritisches API zugegriffen wird. Verweigert der Anwender die Berechtigungen, so bricht die Installation ab.

Sollte eine App versuchen, auf eine geschützte Funktion zuzugreifen, ohne die dafür erforderliche Berechtigung explizit eingeholt zu haben, so gibt das Laufzeitsystem eine Sicherheitswarnung aus und beendet die App.

Abbildung 2: Sicherheitswarnung für eine App ohne Berechtigung

Aufgrund dieser Funktionsweise sollte man davon ausgehen, dass die Möglichkeiten, eine Berechtigung zu umgehen, sehr gering sind. Dem ist leider nicht so, denn findige Entwickler können die Berechtigungen mit mehreren Methoden umgehen.

Standard-Browser zum Hochladen von Informationen missbrauchen

In Android kann eine App eine Komponente einer anderen App starten, indem sie eine abstrakte Datenstruktur (Intent) nutzt, die die auszuführende Aktion beschreibt. Jeder Intent besteht aus einer Aktion (zu auszuführen ist) und den Daten, die für die Durchführung benötigt werden. Sendet eine App einen Intent aus, so wählt das mobile Betriebssystem die dafür geeignete App.

Ein Intent mit der Aktion Intent.ACTION_VIEW und den Daten Uri.parse(“http://www.google.com”) beispielsweise, zeigt an, dass die App die Google-Webseite sehen will. In diesem Fall wird das Betriebssystem das Starten des Browsers als beste Wahl ansehen.

Mit diesem Wissen im Hinterkopf kann ein Entwickler eine App mit dem Intent erstellen, einen Browser zu öffnen und jede Art von gestohlenen Daten auf den gewünschten Server hochzuladen. Soll eine App die Geräte-ID auf den Server http://example.com laden, so kann der Entwickler sie darauf zuschneiden.

Abbildung 3: Beispiel für verdächtigen App-Intent

Da der Browser die URL öffnet, muss die App die android.permission.INTERNET nicht angeben, da der Browser diese Berechtigung bereits hat.

Abbildung 4: Google-Browser-App beim Öffnen einer Site

Logcat: viel mächtiger als angenommen

Eine weitere Methode, Berechtigungen zu missbrauchen, läuft über Logcat. Dies ist ein vom Android-Framework zur Verfügung gestelltes Logging-System, das die Debug-Logs des Outputs von System- und App-Debug-Logs sammelt, anzeigt und filtert. Auch gibt es eine Reihe von APIs für Anwendungsentwickler, über die sie die Debug-Logs in den Buffer schreiben können. Zum Lesen der Logs muss eine App lediglich die android.permission.READ_LOG anfragen, die für den normalen Nutzer harmlos erscheint.

Entwickler können jegliche Information, in den meisten Fällen Debug bezogene,  in Logcat schreiben. Viele dieser Daten sind sensibel (etwa Login-Daten, Kreditkartennummern), und es kann vorkommen, dass Entwickler vergessen, diese Infos zu entfernen, bevor sie ihre Produkte veröffentlichen. Das Problem dabei: Bösartige Apps können die Infos aus dem Log-Nachrichtenüberblick lesen und sie dann in ihrem nächsten Angriff nutzen. Auch loggt das Betriebssystem bestimmte Informationen, die ein potenzieller Angreifer für seine Zwecke nutzen kann.

Beispielsweise loggt Logcat in bestimmten Android-Versionen die URL, wenn das Betriebssystem eine Webseite im Standard-Browser öffnet. Das klingt zwar harmlos, doch kann eine Schad-App den Log überwachen, um die URLs abzugreifen und damit die Vorlieben des Nutzers festzustellen. Mit diesem Wissen hat ein Angreifer die Möglichkeit, für sein Opfer eine Phishing-Version für die am häufigsten besuchte Seite zu wählen. Sollte der Nutzer diese Seite wieder besuchen, könnte die App die ladende Seite stoppen und stattdessen den Browser anweisen, die Phishing-Version zu laden.

GPS ist ein weiteres Beispiel. Wird der vom System angebotene GPS-Service genutzt, kann eine App die aktuellen GPS-Daten mitschneiden. Eine Schad-App wäre in der Lage, über einen Audit des Logs die aktualisierten Standortinformationen zu holen, um die Spur des Nutzers zu verfolgen.

Nicht geschützte Komponenten missbrauchen

Android-Apps bestehen üblicherweise aus vier Komponenten: Aktivität, Service, Content Provider und Funkempfänger (BroadcastReceiver). Aufgrund dieser Komponenten kann eine Anwendung über mehrere Eintrittspunkte aufgerufen werden. Das Berechtigungssystem soll verhindern, dass die Komponenten von willkürlichen Apps angesprochen werden können.

Das System liefert Kontaktinformationen über einen Content Provider, und um die Daten erfolgreich abfragen zu können, benötigt die anfragende App die Berechtigung android.permission.READ_CONTACTS. Ebenso braucht sie für die Installation einer weiteren App die Berechtigung android.permission.INSTALL_PACKAGES. Außer den vom System vordefinierten Berechtigungen können Apps auch ihre eigenen Rechte registrieren. Welches Recht auch immer eine App angibt, die anfragende App muss diese Berechtigung erhalten, um die gewünschte App aufrufen zu können.

Doch sind immer noch zu viele Apps vorhanden, die keine Berechtigungen erfordern. Dies ist üblicherweise für Komponenten der Fall, die innerhalb einer App genutzt werden. Manche Entwickler mögen davon ausgehen, dass keine andere App von dem Vorhandensein dieser Komponenten weiß, da sie nur „privat“ zum Einsatz kommen.

Damit erhalten leider böswillige App-Schreiber ihre Chance. Ein Entwickler könnte nach allen versteckten und privaten Komponenten suchen, um diese aufzurufen, indem er die anvisierte App dekompiliert. Handelt sich dabei um eine System-App, ist dies ein schwerwiegendes Problem, denn diese vorinstallierten Apps haben meist sehr mächtige Fähigkeiten wie etwa Installieren von Apps, das Lesen sensibler Informationen oder gar das Entfernen von allen Daten auf dem Gerät. Auch können Nutzer System-Apps nicht vom System nehmen, es sei denn, die Geräte sind gerootet.

Der Sicherheitsforscher Andre Moulu hat bei vielen vorinstallierten Apps auf dem Samsung Galaxy S3 schwere Lücken in den Funktionen gefunden. Ein Dienst etwa hat die Fähigkeit APK-Dateien aus einem bestimmten Ordner zu installieren (wiederherzustellen), setzt aber keine Berechtigungen durch und prüft auch die Autorisierung des Aufrufenden nicht. Moulu fand des weiteren einen Dienst, der APK-Dateien in einen bestimmten Ordner auf der SD-Karte kopiert, und dabei dieselben Mängel aufweist, wie oben beschrieben. Nutzt eine schädliche App diese beiden Lücken aus, kann sie ihre Payload ablegen und diese Dienste dazu nutzen, um die APK-Datei in ein bestimmtes Verzeichnis zu kopieren und zu installieren – ohne dass der Nutzer etwas bemerkt.

Weitere Informationen zu Berechtigungen und der Sicherung von mobilen Geräten enthält der E-Guide When Android Apps Want More Than They Need.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>