Stagefright: Angriffe nicht nur über MMS

Originalbeitrag von Wish Wu (Mobile Threat Response Engineer)

Vor ein paar Tagen deckte Zimperium zLabs eine Android-Sicherheitslücke auf, die dazu genutzt werden könnte, um über eine einfache Multimedia Message (MMS) Schadsoftware auf einem Gerät zu installieren. Die Lücke, auch unter dem Namen Stagefright bekannt, wurde aufgrund der darüber möglichen Angriffe viel beachtet. Darüber könnte ein Angreifer beispielsweise eine Spyware-App mithilfe einer einfachen MMS auf einem Telefon installieren, ohne dass der Besitzer etwas mitbekommt. Betroffen sind alle Android-Versionen ab 4.0.1 bis 5.1.1 – und das sind 94,1% aller heute genutzten Android-Geräte. Trend Micros Sicherheitsforscher hatten die Lücke ebenfalls im Visier und zeigen nur zusätzliche Details dazu auf.

Analyse der Sicherheitslücke

Auch diese Lücke befindet sich wie die vorigen in der mediaserver-Komponente, die für das Handling von geöffneten Mediendateien zuständig ist. Die in den angreifbaren Versionen vorhandene mediaserver-Komponente kann mit einer “missgestalteten” MP4-Datei nicht korrekt umgehen und somit einen Heap Overflow anstoßen und die Daten im Heap überschreiben. Dadurch könnte Code ausgeführt werden und zum Download einer App auf das Gerät führen. Einzelheiten zur Ursache und zum Ablauf gibt es im Originalbeitrag.

Proof-of-Concept

Die Sicherheitsforscher testeten drei Szenarien, die für einen Angriff auf mediaserver genutzt werden können. Sie verwendeten den Befehl adb shell top | grep mediaserver für den Prozess. Es zeigte sich anhand der geänderten PID (Process Identification Number) des mediaservers, dass der Prozess abstürzte und wieder gestartet wurde.

Szenario #1: Angriff von einer Anwendung aus

Die speziell erzeugte MP4-Datei bewirkt, dass der Heap des mediaservers zerstört oder “missbraucht” wird. Beim Test stürzte er lediglich ab, doch kann ein Angreifer auch einen bestimmten Datenblock bauen, um den Heap zu füllen und die Kontrolle über den Ablauf der Ausführung zu erlangen.

Bild 1. Debugging Output der mediaserver-Abstürze

Szenario #2: Angriff von einer URL aus

Dafür betteten die Sicherheitsforscher dieselbe missgestaltete MP4-Datei (mp4.mp4) in eine HTML-Datei ein, die dann auf einen Webserver hochgeladen wurde. Beim Einsatz des eingebauten WebView in Android 5.1.1 (die auch Twitter nutzt) für den Zugang zur Website, ergeben sich dieselben Probleme wie im ersten Szenario.

Bild 2. HTML-Code zum Einbetten der MP4-Datei

Auch wenn der mobile Chrome-Browser das vorausgehende Laden und Autoplay von Videos, die mit dem <video>-Tag eingebettet sind, deaktiviert, so verursacht die missgestaltete Datei dennoch einen Heap Overflow.

Szenario #3: Angriff von MMS-Nachrichten aus

Über dieses Szenario wurde viel geschrieben. Die MP4-Datei kann an eine MMS angefügt werden und an das Telefon des Opfers geschickt werden. Auf dem Testgerät (Nexus 6 mit Android 5.1.1) stürzte der mediaserver-Prozess zweimal ab, sobald eine MMs ankam. Diese Methode ist besonders gefährlich, weil sie keine Nutzerinteraktion erfordert. Es reicht das Abschicken der Datei!

Bild 3. Anfügen der “missgestalteten” mp4-Datei an eine MMS-Nachricht

Die Sicherheitslücke ist deshalb so gefährlich, weil sie effektiv vom Angreifer kontrolliert werden kann. Das heißt, er entscheidet, wann er den Angriff startet und wann er ihn stoppt.

Der mediaserver kümmert sich um multimediabezogene Aufgaben, wie etwa das Öffnen und Lesen von MP4-Dateien, Codieren/Decodieren eines MPEG4-Streams, Fotografieren, Aufnahmen von Videos/Audios, Lesen/Schreiben von Bildern und Videos von und auf die SD-Karte usw. Der Angreifer könnte seinen Code mit denselben Berechtigungen laufen lassen wie der mediaserver für seine normalen Routinen.

Nutzer haben relativ geringe Möglichkeiten, mit dieser Bedrohung umzugehen. Zuweilen entdecken sie sie gar nicht, weil die ursprüngliche Kompromittierung (MMS-Nachricht) nicht bösartig zu sein scheint. Sie können die Funktion autofetch für MMS-Inhalte deaktivieren. Das bedeutet, dass der Nutzer die MMS-Nachricht öffnen muss, bevor ein Angriff stattfinden kann.

Google hat einen Patch veröffentlicht, doch wann dieser auf den Geräten ankommt, hängt vom OEM des Geräts ab. Außerdem sind auch angepasste Android-Versionen, die mediaserver nicht modifiziert haben, in Gefahr.

Es gibt bei Software unzählige Abhängigkeiten untereinander, zwischen Betriebssystem und Applikationen, zwischen Anwendungen untereinander etc. – nicht nur bei Android. So können etwa auch Adobe Flash-Lücken, die im Browser nicht mehr ausnutzbar sind, weiterhin missbraucht werden, wenn ein darauf zugeschnittener Exploit in einem Office-Dokument versteckt wird. Das hat unmittelbare Auswirkungen auf den Umgang mit dem Wissen um Sicherheitslücken.

Sicherheitslösungen wie Trend Micro Mobile Security fügen eine weitere Schutzschicht gegen diese Art von Gefahren hinzu.

 

Zeitschiene der Veröffentlichung

Trend Micro hat Google davon in Kenntnis gesetzt:

  1. Mai: Bericht an das Android Security Team mit einem Proof-of-Concept Angriff
  2. Ma: Android Security Team vergab der Lücke die Bezeichnung ANDROID-21336907 als ‘High Severity’.
  3. Mai: Android Security Team benannte die Lücke mit CVE-2015-3824
  4. Juli: Android Security Team bestätigt das Vorhandensein eines Fix.

 

Schreibe einen Kommentar

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

*