Bedrohungsanalyse von Android. Die Ausnutzung von Stagefright

Inhaltsverzeichnis

Abstrakt

1 Prolog
1.1 Motivation
1.2 Aufbau der Arbeit

2 Abhandlung
2.1 Android (Betriebssystem)
2.1.1 Interfaces und Architektur
2.1.2 Mediaframework
2.1.3 Versionen
2.1.4 Marktanteil und Verbreitung
2.2 Terminus „Stagefright“
2.2.1 Stagefright
2.2.2 Stagefright 2.0

3 Schwachstellen in Stagefright
3.1 Grundlagen: Integer Under- and Overflow
3.2 MP4 Atom Integer Overflow
3.2.1 Sample-to-Chunk (’stsc’)
3.2.2 Composition Offset (’ctts’)
3.2.3 Time-to-Sample (’stts’)
3.2.4 Sync Sample (’stss’)
3.2.5 Text Metadata (’tx3g’)
3.2.6 Album cover artwork (’covr’)
3.3 MP4 Atom Integer Underflow
3.3.1 Elementary Stream Descriptor (’esds’)
3.3.2 Album cover artwork (’covr’)
3.3.3 3rd Generation Partnership Project (3GPP)
3.3.4 Text Metadata (’tx3g’)
3.4 Metadata Buffer Overread
3.5 libstagefright Integer Overflow
3.5.1 findFrame.
3.5.2 size_t overflow in base64 decoding
3.6 libutils Integer Overflow

4 Angriffsvektoren
4.1 Proof of Concept bestätigte Szenarien.
4.1.1 MP4
4.1.2 Firefox for Android
4.1.3 MKV-Datei
4.2 Offene Szenarien.

5 Schutzmaßnahmen
5.1 MMS Umleitung.
5.2 Updates.
5.3 Stagefright Detector App
5.4 Address Space Layout Randomization (ASLR)

6 Resonanzen
6.1 Arbeitsumfeld.
6.2 Privater Umkreis

7 Exploit Demo

8 Fazit

Abbildungsverzeichnis

Literaturverzeichnis

Abstrakt

Das Android-Betriebssystem von Google findet weltweit vielseitigen Einsatz, angefangen bei Smartphones, über Tablet-Computer und mittlerweile sogar Smartwatches oder Android TV. Diese Arbeit beschränkt sich jedoch auf die Ausnutzung der libstagefright Bibliothek auf Smartphones, die das Android-Betriebssystem nutzen. Smartphones werden im heutigen, schnelllebigen Computerzeitalter immer billiger und damit erschwinglich für die breite Masse an potenziellen Nutzern. Dies führt dazu, dass im Jahr 2015 bereits knapp 2 Milliarden Smartphones weltweit genutzt werden. Auf jedem zweiten Gerät läuft das Betriebssystem von Android. Seit Version 2.2 verwendet Android neben dem alten Multimedia-Framework OpenCore, ein Framework namens Stagefright, dieses birgt jedoch einige Schwachstellen bezüglich der Speicherverwaltung in sich.

Wie an zahlreichen, in dieser Arbeit beschriebenen Lücken zu sehen sein wird, bietet das Stagefright-Framework eine große Anzahl an Angriffsvektoren für potenziellen Missbrauch.

Kapitel 1 Prolog

1.1 Motivation

Stagefright ist zur Zeit das Thema in der Android-Welt, seit Bekanntmachung der Sicherheitslücken durch Joshua J. Drake auf der Black Hat Konferenz in Las Vegas im August diesen Jahres. Joshua J. Drake ist als Sicherheitsforscher bei Zimperium zLabs tätig und Hauptautor des "Android Hacker’s Handbuch". Nahezu 1 Milliarde Android-Geräte wären seinen Aussagen zufolge durch potenzielle Übergriffe bedroht. Da zu diesem Thema viel Aufklärungsbedarf besteht, soll diese Arbeit einen grundlegenden Überblick zu den gefundenen Sicherheitslücken geben und deren Behebungen, sowie mögliche Schutzmaßnahmen darstellen.

1.2 Aufbau der Arbeit

In Kapitel (2 Abhandlung) werden zunächst die nötigen Informationen zu Android bereit- gestellt, um zu verstehen, wo genau im Android-Betriebssystem diese Lücken auftreten. Dazu werden wichtige Systemkomponenten von Android erklärt, die grundlegend für das Verständnis der Funktionsweise von Android und dessen Stagefright-Framework sind. Außerdem wird Stagefright als Begriff selbst erklärt und zudem zwischen den ersten entdeckten Lücken und den nachfolgenden, die als Stagefright 2.0 bezeichnet wurden, unterschieden.

Anschließend werden die gefundenen Lücken in Kapitel (3 Schwachstellen in Stagefright) dargelegt und erklärt. In den letzten Kapiteln werden zudem noch Schutzmaßnahmen - zu finden in Kapitel (5 Schutzmaßnahmen) - vorgestellt sowie einige Resonanzen - zu finden in Kapitel (6 Resonanzen) - zum Thema Stagefright. Abgerundet wird diese Arbeit durch eine kurze Demonstration eines Exploits in Kapitel (7 Exploit Demo).

Kapitel 2 Abhandlung

2.1 Android (Betriebssystem)

Google’s Android ist ein Open-Source-Betriebssystem, d.h. es kann beliebig verändert und den eigenen Wünschen angepasst werden. Als Basis dient ein Linux-Kernel, der von Google speziell für die Bedürfnisse eines mobilen Betriebssystems abgeändert wurde. Android wurde von Google 2005 unter Android Inc. entwickelt und später von der Open Handset Alliance (OHA)¹ weiterentwickelt. Die OHA wurde von Google gegründet und wird neben zahlreichen anderen Firmen auch von Google geführt. Diese Organisation hat das Ziel offene Standards für mobile Geräte zu entwickeln.

Die erste beta Version des Android Software Development Kit (SDK) wurde 2007 von Google mit der Apache Lizenz veröffentlicht, die erste kommerzielle Version Android 1.0 im September 2008. Alle verfügbaren Apps für Android befinden sich entweder im App Store, Google Play genannt, oder können von Drittanbietern bezogen werden.^{2 3}

Die in (Abbildung 2.1) gezeigte Grafik macht die Vorzüge von Android deutlich, zu denen unter anderem die großzügige Entwicklungsumgebung zählt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Why Android?

http://www.tutorialspoint.com/android/android_overview.htm

2.1.1 Interfaces und Architektur

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Android-Architektur

https://source.android.com/devices/index.html

Die Android-Architektur, zu sehen in (Abbildung 2.2) kann man als eine in fünf Schichten aufgeteilte Grafik betrachten.

Als unterste Schicht ist der Linux-Kernel zu sehen, der die Grundfunktionalitäten bereit- stellt. Zu diesen zählen hauptsächlich das Bereitstellen der Treiber für die verwendete Hardware, sowie das Prozessmanagement, die Speicherverwaltung, Sicherheit usw. Die nächste Schicht, der hardware abstraction layer (HAL) enthält Methoden zur Ver- bindung der Plattform und der Hardware, wie beispielsweise Kamera, Audio, Bluetooth, GPS, WiFi usw.

Darüber befinden sich die Systemdienste, die den Medienserver und auch den System- server enthalten. Dieser Medienserver nimmt zum Thema Stagefright die entscheidende Rolle ein, da dieser ständig im Hintergrund aktiv ist und jegliche Art von eingehender Datei durch diesen verarbeitet wird.

Die vierte Schicht wird durch die Binder IPC Proxies dargestellt. IPC steht hier für Inter-Process Communication und ermöglicht der letzteren Schicht, dem Applikations- Framework, die Kommunikation über Prozessgrenzen hinaus. Die letzte Schicht, das Applikations-Framework wird von Programmierern zur Entwicklung von Applikationen benutzt. Dazu werden die in (2.1) erwähnten SDK’s genutzt.^{4 5 6}

2.1.2 Mediaframework

Abb. 2.3: Mediaframework

Abbildung in dieser Leseprobe nicht enthalten

https://source.android.com/devices/media/images/ape_fwk_ media.png

Android stellt, wie schon erwähnt, seit Version 2.2 ein Framework namens Stagefright zur Medienverarbeitung bereit. Dieses enthält Codecs, um verschiedene Medienforma- te, wie z.B. MPEG4, .3gp, .3g2 usw. abspielen zu können. Stagefright unterstützt Audio- und Videoverarbeitung mit OpenMAX Codecs, Sitzungsverwaltung, Zeitsynchro- nisierung, Transportüberwachung und digitale Rechteverwaltung. OpenMax ist eine lizenzfreie, betriebssystemübergreifende API, die umfassende Codecs zur Medienverarbeitung bereitstellt.⁷

Im ersten Schritt veranlasst eine Applikation android.media API’s zur Kommunikation mit der Multimedia Hardware. Anschließend ermöglichen die Binder IPC Proxies die Kommunikation der einzelnen Prozesse untereinander. Diese befinden sich in frameworks/av/media/libmedia. Auf dem untersten Level bietet Android ein Multimediaframework, das der Stagefrightumgebung Audio- und Videoaufnahmen, sowie deren Wiedergabe ermöglicht. Stagefright beinhaltet eine Standardliste mit allen unterstützten Software Codecs und es besteht auch die Möglichkeit eigene Hardware Codecs mit Hilfe der OpenMAX Integrationsschicht zu implementieren. Media Player und Stagefright Komponenten befinden sich in frameworks/av/media.⁸

Die nachfolgende Grafik (Abbildung 2.4) gibt einen detaillierten Einblick in die Klasse StagefrightPlayer, die als Client für die Klasse AwesomePlayer fungiert. Die Klasse StagefrightPlayer befindet sich in frameworks/av/media/libstagefright und beinhaltet die algorithmische Logik. Diese Grafik macht deutlich, welche Auswirkungen die Lücken in libstagefright haben. Ausgehend von der Klasse MPEG4Extractor kann über Media- Extractor und AwesomePlayer die Klasse StagefrightPlayer erreicht werden und da diese innerhalb des Mediaservers läuft, der Systemrechte hat, kann ein Angreifer hier viel Schaden anrichten. Aber dazu mehr im Kapitel (3 Schwachstellen in Stagefright).⁹

Abb. 2.4: Stagefright-Player

Abbildung in dieser Leseprobe nicht enthalten

https://quandarypeak.com/wp-content/uploads/android- stagefright-architecture.png

Stagefright kommt, wie zu sehen, jedes Mal zum Einsatz, wenn etwas auf einem Gerät, das Android nutzt verarbeitet werden muss. Dafür verwendet Stagefright den Medien Scanner, der heruntergeladene oder neu erstellte Mediendateien an den Medien Scanner Service weiterreicht. Der Medien Scanner Service liest anschließend die Metadaten der Datei und weist sie zu. Dazu zählen Bilder, die in der Galerie abgelegt werden, Musik, die jederzeit zum Abhören bereit sein muss oder Videos usw.¹⁰

In der nachfolgenden Grafik (Abbildung 2.5) ist die Architektur des frameworks MediaPlayer zu sehen. Mit Hilfe des media players kann man Audio- und Videodateien wiedergeben. Wie zu sehen, ist der MediaPlayer in Java geschrieben und nutzt das JNI (Java Native Interface) um Methoden des in C++ geschriebenen Native MediaPlayers aufrufen zu können. Da diese beiden Klassen sich in der Applikationsebene befinden, kommt wie in (2.1.1 Interfaces und Architektur) schon erwähnt, der Binder zum Einsatz, um mit den Klassen in der Media service-Ebene kommunizieren zu können.¹¹

Abb. 2.5: Media Player Architektur

Abbildung in dieser Leseprobe nicht enthalten

http://elinux.org/images/9/9d/Android_media_framework--van- dam_and_kallere.pdf

2.1.3 Versionen

Abb. 2.6: Android-Versionen

Abbildung in dieser Leseprobe nicht enthalten

http://media2.giga.de/2015/08/android-versionen-vergleich. png

Alle Versionen von Android tragen den Namen einer Süßspeise, dessen Anfangsbuchstabe der Bezeichnung jeweils im Alphabet aufsteigend ist.¹² Die folgende Auflistung soll dazu einen kurzen Überblick geben.

- Android 1.0 - 2.0, in diesen Versionen wurde noch das OpenCore media frame work genutzt.
- Android 2.2.0 Froyo, eingeführt am 20. Mai 2010. Zu diesem Zeitpunkt wurde das damals neue media framework Stagefright eingeführt
- Android 2.3.0 Gingerbread, eingeführt am 6. Dezember 2010
- Android 3.0 Honeycomb, eingeführt am 23. Februar 2011
- Android 4.0 Ice Cream Sandwich, eingeführt am 19. November 2011
- Android 4.1, 4.2, 4.3 Jelly Bean, eingeführt ab 27. Juni 2012
- Android 4.4 KitKat, eingeführt am 31. Oktober 2013
- Android 5.0 Lollipop, eingeführt am 3. November 2014
- Android 6.0 Marshmallow, eingeführt am 28. Mai 2015

2.1.4 Marktanteil und Verbreitung

Die in (Abbildung 2.7) zu sehende Grafik zeigt, wie sich Android im Vergleich zu iOS und anderen Betriebssystemen bis Ende 2016 entwickeln wird. Diese Angaben sind prognostiziert und können natürlich etwas abweichen. Android läuft inzwischen auf fast jedem zweiten verkauften Gerät. Ein ausschlaggebender Punkt ist hierbei wohl der geringere Preis von Android-Geräten gegenüber den Konkurrenzprodukten von Apple. Dadurch ergibt sich ein Marktanteil von 59% für Android in 2015. Die restlichen 40% teilen sich Windows (14%) iOS und OS X (11%) und kleinere Betriebssysteme (15%). Dieser hohe Marktanteil von Android-Geräten zeigt, wie viele Nutzer von den Sicherheitslücken potenziell betroffen sind.¹³

Abb. 2.7: Android Marktanteil

Abbildung in dieser Leseprobe nicht enthalten

http://www.itopnews.de/wp-content/uploads/2015/01/ Marktanteil-Android-bis-2016.jpg

2.2 Terminus „Stagefright“

2.2.1 Stagefright

Stagefright benennt sowohl die Anfang 2015 entdeckten Sicherheitslücken, als auch die Verarbeitungseinheit für Audio- und Videodateien auf Betriebssystemebene namens libstagefright. Diese ist seit Android 2.2 (Froyo) bis zur aktuellsten Version 6.0.1 (Marshmallow) vorhanden. Das Framework ist mit seinen Parsern und Decodern, die zahlreiche Audio- und Videoformate unterstützen, dafür verantwortlich Bitströme in hörbare Töne umzuwandeln, die auf dem Smartphone abgespielt werden können, sowie Videos die man ansehen kann.¹⁴

Der Mediaserver-Prozess, der ständig im Hintergrund auf Android-Geräten läuft, nutzt diese Stagefright-Bibliothek. Er besitzt dabei Rechte der Systemebene, diese liegt nur eine Ebene oberhalb der Root-Rechte und dies ermöglicht ihm beliebige Manipulationen am Gerät.

Stagefright wird auch als "Mutter aller Android-Schwachstellen"¹⁵ bezeichnet und nimmt weite Ausmaße an. So sind rund 95% aller auf dem Markt befindlichen AndroidGeräte davon betroffen, da die meisten Geräte derzeit auf einer Android-Version zwischen 2.2 und 5.1.1 laufen und wie schon erwähnt, die Stagefright-Bibliothek seit 2.2 auf allen Geräten vorhanden ist. Wegen zahlreicher Schwachstellen lassen sich somit betroffene Geräte attackieren und sogar übernehmen, ohne dass der Nutzer im schlimmsten Fall etwas davon bemerkt.

Die wichtigste Rolle zu diesem Thema übernimmt hierbei Joshua J. Drake von Zimperium zLabs, der diese gravierenden Sicherheitslücken Anfang diesen Jahres entdeckt hat.¹⁶

"THIS HAPPENS EVEN BEFORE THE SOUND THAT YOU’VE RECEI- VED A MESSAGE HAS EVEN OCCURRED [...] THAT’S WHAT MAKES IT SO DANGEROUS. IT COULD BE ABSOLUTELY SILENT. YOU MAY NOT EVEN SEE ANYTHING.

I’VE DONE A LOT OF TESTING ON AN ICE CREAM SANDWICH GALAXY NEXUS... WHERE THE DEFAULT MMS IS THE MESSAGING APP, MESSENGER. THAT ONE DOES NOT TRIGGER AUTOMATICALLY BUT IF YOU LOOK AT THE MMS, IT TRIGGERS, YOU DON’T HAVE TO TRY TO PLAY THE MEDIA OR ANYTHING, YOU JUST HAVE TO LOOK AT IT."

(Joshua J. Drake, Black Hat USA, August 2015)

Insgesamt sind hierzu bereits 7 Lücken bekannt, die jeweils mit einer eigenen CVE- Nummer (Common Vulnerabilities and Exposures) festgehalten wurden. CVE’s werden für alle weltweit bekannten Sicherheitslücken in Computersystemen angelegt.¹⁷ Diese werden nachfolgend in Kapitel (3 Schwachstellen in Stagefright) erläutert.

2.2.2 Stagefright 2.0

Nach den ersten 7 entdeckten Lücken Anfang des Jahres, folgten im Oktober 2015 bereits 2 weitere Schwachstellen und auch hier ist die Stagefright-Bibliothek betroffen. Speziell geht es bei den beiden Lücken um präparierte MP3 Audiodateien und MP4 Videodateien. Die erste Lücke in libutils betrifft sogar alle Geräte bis Android 1.0, die zweite in libstagefright kann auf Geräten mit Android 5.0 und höher ausgenutzt werden. Bei der Schwachstelle in libutils sind vor allem ältere Geräte betroffen, falls die verwundbare Funktion (allocFromUTF8), zu sehen auf Seite 30, verwendet wird. Dies könnte der Fall sein bei Drittanbieter-Apps sowie Anbieter- oder Betreiberfunktionen, die vorinstalliert werden. Die Verwundbarkeit liegt in der Verarbeitung von Metadaten innerhalb der Dateien, so dass nur die Vorschau der Musik oder des Videos den Schadcode forciert. Ein Angreifer würde beispielsweise versuchen einen Nutzer durch Klicken eines Links, der auf eine durch den Angreifer kontrollierte Webseite weiterleitet, zu führen. Eine weitere Verwundbarkeit würde sich durch Drittanbieter-Apps ergeben, wenn diese die verwundbare Bibliothek libutils verwenden. Hierzu wird jedoch kein Proof of Concept der Öffentlichkeit zugänglich gemacht, lediglich verifizierte ZHA (Zimperium Handset Alliance) Mitglieder werden dies zu sehen bekommen. Die ZHA ist eine speziell gegründete Task-Force zur Bearbeitung der Sicherheitsprobleme in Android.^{18 19}

Kapitel 3
Schwachstellen in Stagefright

Im vorhergehenden Kapitel 2 war bereits die Rede von CVE’s (2.2.1 Stagefright), davon wurden im Juli 7 Einträge für die Lücken in Stagefright angelegt. Betroffen von diesen Lücken sind alle Android-Versionen von 2.2 bis 5.1.1.

Die nachfolgende Tabelle der CVE’s soll zeigen, mit welchen Lücken sich diese Arbeit beschäftigt. Außerdem zeigt sie um welche Art von Verwundbarkeit es sich handelt und über welchen Weg dies ausgenutzt werden kann.

Zur besseren Einschätzung der Bedrohung werden zudem ein Impact Score, ein Exploi- tability Subscore sowie die Angriffswege und deren Komplexität mit angegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.1: CVE’s 1.0

Im Oktober 2015 wurden zusätzlich folgende CVE’s für weitere entdeckte Sicherheits- lücken angelegt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.2: CVE’s 2.0

Weitere werden mit Sicherheit folgen!

[...]