Schlagwort-Archive: App

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.

Mobile Apps bedürfen der gleichen Sicherheit wie Browser

Originalartikel von David Sancho, Senior Threat Researcher

Im Grunde genommen sind mobile Anwendungen “Browser in einer Box”. Für diese Behauptung spricht einiges: Öffnet der Anwender eine App, so ist die Wahrscheinlichkeit hoch, dass sie versucht, auf eine bestimmte Webseite zuzugreifen und die Ergebnisse in irgendeiner Art und Weise darstellt. Nicht nur Anwendungen wie Amazon oder eBay verhalten sich wie Browser (die solche Anfragen auf ihre eigenen Server einschränken), sondern auch Apps wie Flipboard, das „Soziale Nachrichtenmagazin“ für iPad und iPhone, greifen im Prinzip lediglich auf Facebook und Twitter zu, um die Ergebnisse auf eine sehr hübsche Weise darzustellen.

Macht dies Apps angreifbarer für Verhaltensweisen, die reguläre Browser von den Nutzern erwarten? Führt beispielsweise eine App eingeschränkte Anfragen an eine einzelne Site aus, so könnte doch ein Angreifer dieses Verhalten für die Kompromittierung der App oder Site missbrauchen.

Mithilfe einer Testumgebung, die den an- und ausgehenden Verkehr von mobilen Anwendungen – sowohl Android als auch iPhone/iPad – überwachte, wollte der Autor herausfinden, ob Apps tatsächlich wie Browser abzusichern sind. Die Suche nach ausnutzbaren Mechanismen oder Lücken war erfolgreich. Unter anderem gibt es ein Spiel, das immer wieder Kennwörter vergibt und ändert, um den Spielern den Zugang zu neuen Ressourcen zu öffnen. Diese Kennwörter aber werden als unverschlüsseltes http angefordert und gesendet. Einen Angriff auf die involvierten Server zu fingieren war ein Kinderspiel! Die klare Schlussfolgerung: unverschlüsselte, vorgefertigte http-Übertragungen sind nicht vertrauenswürdig. Auch weitere Probleme mit verschiedenen Anwendungen traten zutage: Eine App, die regelmäßig XML-Dateien mit Links zu Bildern und Audio-Dateien verschickt, tat dies ebenfalls in reinem Text über unverschlüsseltes http.

Die entdeckten Probleme waren jedoch so vielfältig, dass es schwierig wurde, dieses Projekt von jedem anderen Webanwendungs-Penetrationstest abzugrenzen. Das heißt, die Clients sind mobile Anwendungen, doch eigentlich bezogen sich die Nachforschungen auf den unsicheren Webcode eines Entwicklers.

Fazit: Die Anfangsthese stimmt: Alle mobilen Apps sind Webclients und daher genauso so unsicher wie ein Browser – und wie ein Browser müssen sie auch gesichert sein.