Kategorie-Archiv: Consumerization

Beschwerde beim FTC über fehlende Android-Updates

Hinterlassen Sie eine Antwort

Originalartikel von Jonathan Leopando, Technical Communications

Letzte Woche ging eine interessante Beschwerde bei der US-Bundeshandelskommission (Federal Trade Commission, FTC) ein. In einem 16 Seiten langen Brief beschwert sich die American Civil Liberties Union über das Fehlen von Updates für viele Android-Geräte und bezeichnet diesen Mangel als „unfaire und betrügerische Geschäftspraktik“. Das Papier fordert des Weiteren die vier größten US-Funkanbieter auf, Kunden mit nicht aktualisierten (und angreifbaren) Geräten vorzeitig aus den Verträgen zu entlassen.
Weiterlesen →

Gezielte Angriffe verstehen: Wogegen müssen wir uns tatsächlich wehren?

Hinterlassen Sie eine Antwort

Originalartikel von Martin Roesler, Director for Threat Research

Das meiste, was die Sicherheitsindustrie über gezielte Angriffe weiß, hat sie auf die harte Tour gelernt – nämlich über die Analyse erfolgreicher Angriffe. Dabei mussten die Branchenvertreter feststellen, wie wenig sie über die Hintergründe und derzeitigen Methoden der Angreifer wissen. Das fehlende Verständnis aber führt auch dazu, dass der Umgang mit den Attacken schwierig ist. Haben also die Angreifer die Oberhand? Die Antwort lautet leider ja.
Weiterlesen →

Android-Berechtigungen umgehen

Hinterlassen Sie eine Antwort

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.

US-Präsidentschaftskandidaten als Köder in Android-Apps

Hinterlassen Sie eine Antwort

Originalartikel von Paul Pajares, Fraud Analyst

Die Sicherheitsforscher von Trend Micro haben vier Android-Apps in Google Play und weiteren App Stores gefunden, die nach ihrer Installation Werbenachrichten pushen und sich Zugang zu bestimmten Geräteinformationen verschaffen. Die kostenlosen Apps nutzen die bevorstehenden Präsidentschaftswahlen in den USA und deren Kandidaten Mitt Romney und Barack Obama als Köder. Eine dieser Apps ist zwar aus Google Play entfernt worden, doch gibt es sie noch in anderen App Stores.

Die App “Obama vs Romney” enthält eine ANDROIDOS_AIRPUSH Variante und nimmt Verbindung zu airpush.com auf, einer mobilen Werbe-Site. Die Seite mit der App-Beschreibung weist auch darauf hin, dass sie Werbenachrichten enthalten könne. Diese App wurde bislang mehr als 300 Mal aus unterschiedlichen App Stores heruntergeladen und etwa 500 bis 1000 Mal aus Google Play.

Die App ist als Umfragedienst aufgesetzt, und die Nutzer können zwischen den beiden Präsidentschaftskandidaten wählen. Das Gesamtergebnis wird sofort gezeigt. Die App machte sich durch die folgende Meldung verdächtig: „Sie wollen wahrscheinlich so schnell wie möglich klicken.“ Verbindungen zu airpush.com oder zu der bestimmten URL mit der Werbung der Cyberkriminellen bedeutet einen Klick, und damit verdienen die Autoren dann Geld. Über ACCESS_COARSE_LOCATION kann auf Informationen wie die GPS-Ortung des Geräts zugegriffen warden.

Eine weitere App “Captain America Barack Obama 1.0” (ANDROIDOS_ADWLEADBOLT-Variante) installiert einen Barack Obama 3D-Hintergrund und die amerikanische Flagge auf dem Gerät. Auch diese App ist aus Google Play entfernt worden, doch nicht aus weiteren App Stores. Ähnlich der ersten umfasst auch diese App ACCESS_FINE_LOCATION und ACCESS_COARSE_LOCATION und hat Zugriff auf die GPS-Ortung, Cell ID und den WiFi-Standort. Nach der Installation erzeugt sie einen Shortcut auf dem Home-Bildschirm des Geräts. Sie wurde bereits 720 Mal aus verschiedenen App Stores heruntergeladen.

Die anderen beiden Apps schließlich, “Barack Obama Campaign LWP 1” und “Mitt Romney Live Wallpaper 1” (beides ANDROIDOS_ADWLEADBOLT-Varianten) stellen auch Werbung auf das Gerät. Die Nutzer können die Werbung unterdrücken, indem sie eine bestimmte URL anklicken und Informationen wie ihre International Mobile Equipment Identity (IMEI) und Gerätetypus dort angeben. Beide Apps enthalten auch ACCESS_FINE_LOCATION und ACCESS_COARSE_LOCATION.

Hilft Jelly Bean der Sicherheit und BYOD?

1 Antwort

Originalartikel von Cesare Garlati, Vice President Mobile Security

Googles kürzlich angekündigte Version Android 4.1, Jelly Bean genannt, stellt eine Weiterentwicklung des mobilen Betriebssystems in Richtung Apple iOS dar und bietet vor allem Verbesserungen für die Verbraucher und die Benutzerfreundlichkeit. Aus Sicht des BYOD-Konzepts (Bring your own Device) hat sich nicht viel geändert. Im Gegenteil, es gibt weitere Gründe sich um die Sicherheit zu sorgen aufgrund von Funktionalität bezüglich der Wi-Fi-Verbindungen und des Datenaustausches. Dazu gehört Wi-Fi Direct, eine Technik, die es Apps erlaubt, direkt über breitbandige Peer-to-Peer-Verbindungen miteinander zu kommunizieren. Des weiteren geht es um Android Beam für den Bluetooth-Datenaustausch zwischen Geräten, etwa im Bereich NFC.

Doch werden sich IT-Manager über das neue Network Bandwidth Management API sowie die Smart App Update-Funktionalität freuen. Das überarbeitete Network Bandwidth Management könnte Unternehmen Kosten im Mobilbereich sparen, wenn ein Gerät mit einem kommerziellen Netzwerk verbunden ist. Apps können abfragen, ob das aktuelle Netzwerk kostenpflichtig ist, bevor sie einen größeren Download starten. Das neue API erfordert jedoch die Einbindung in ein Mobile Device Management-System und/oder Telecom Expense Management (TEM), um Netzwerkaktivitäten entsprechend verwalten zu können.

Die Smart App Update-Funktion verkleinert die Updates für Apps, sodass sie schneller und kostengünstiger herunterzuladen sind. Dies könnte auch der Sicherheit dienen, denn die Endanwender werden somit ihre Apps eher auf aktuellem Stand halten.

Zwei der neuen Funktionen haben einen direkten Einfluss auf die Sicherheit:

  • App Encryption: Diese Funktion wird mit der neuen Version in Google Play integriert und soll die dort zur Verfügung stehenden kostenpflichtigen Anwendungen schützen. Dafür werden diese mit einem gerätespezifischen Schlüssel verschlüsselt, bevor sie ausgeliefert und auf einem Gerät gespeichert werden. Allerdings dient dies eher dem Schutz der App-Entwickler vor illegalen Downloads als der Vorsorge vor Datenverlust durch Geräte, die sich mit Unternehmensnetzwerken verbinden. Die Verschlüsselung gilt lediglich dem Anwendungscode selbst und auch nur dann, wenn dieser aus dem offiziellen Google-Store heruntergeladen wird. Als Nebeneffekt könnte die neue Verschlüsselung sogar die Entwicklung und Ausführung von unabhängigen mobilen Reputationsdiensten erschweren – so etwa den von Trend Micro, der eine Vielfalt an Android-Stores scannt, die von Malware bedroht sind, einschließlich Google Play. Auf der anderen Seite mag es auch Hackern das Reverse Engineering von legitimen Apps, um Schädlinge einzuschleusen, erschweren.
  • PDK: Das Android Platform Developers Kit ist die Hardware-Variante der Software SDKs für App-Entwickler. SDKs werden üblicherweise schon Monate vor dem Lauch eines Produkts ausgegeben, weil Plattformanbieter den Entwicklern schon frühzeitig die Möglichkeit geben wollen, ihre Anwendungen fertigzustellen. Dies ist begrüßenswert, doch andererseits könnte es im Fall der PDKs zu einer größeren Android-Fragmentierung führen. Diese wird vor allem von Willen der OEMs getrieben, sich von Commodity-Produkten zu unterscheiden und weniger von technischen Motiven. Nicht zu vergessen, dass OEMs möglichst viele neue Geräte verkaufen und weniger Upgrades auf eine neue Betriebssystemversion anbringen wollen.

Fazit: Trotz einiger Sicherheits- und Managementfunktionalitäten auf Unternehmensebene, die allmählich in Android Eingang finden, bleibt für Googles Android der Verbraucher die Hauptzielgruppe. Und deshalb geht es vor allem um Eigenschaften im Design, den Formfaktor, coole Benutzerschnittstellen und weniger um Verschlüsselung, VPN- oder MDM-Unterstützung.