Android Security: Cloak & Dagger

Im letzten Jahr ist Android 8 mit dem Codenamen Oreo erschienen und bis zur Konferenz sicherlich auf vielen neuen Geräten verfügbar. Dieser Vortrag betrachtet die in den vergangenen Jahren eingeführten Sicherheitsfunktionen eines Android Telefons. Hierbei werden die in den verschiedenen Android Versionen eingeführten Sicherheitsfunktionen erläutert und begründet. Der Vortrag schließt mit den in der aktuellen Version 8.0 Oreo eingeführten Sicherheitsfunktionen von Android 8.0 Oreo. Eine Demonstration basiernd auf der Cloak & Dagger Sicherheitslücke (siehe http://cloak-and-dagger.org/) zeigt wie wichtig diese Funktionen sind. Sämtliche älteren Versionen sind aktuell anfällig für diesen Angriff.

Das Android Sicherheitsmodell basiert zu großen Teilen auf der Application Sandbox. Jede Applikation wird in einer eigenen Sandbox ausgeführt. Vor Android 4.3 wurde diese Sandbox durch einen App-spezifischen unprivilegierten Linux Benutzer realisiert. Die Applikation wurde mit den Rechten des unprivilegierten Benutzers ausgeführt und durch das Linux Rechtekonzept eingeschränkt. Ab Android 4.3 hat Google SELinux eingeführt und genutzt, um die Sandbox zusätzlich abzuschotten. Während in 4.3 SELinux noch im Permissive Modus genutzt wurde, wurden in 4.4 SELinux teilweise erzwungen. Mit der Version 5.0 wird es vollständig erzwungen. Android nutzt SELinux um eine Mandatory Access Control (MAC) für alle Prozesse (auch root-Prozesse) umzusetzen. Auch privilegierte Prozesse werden überwacht.  Für die von dem Benutzer installierten Applikationen erzeugt Android automatisch entsprechende SELinux Richtlinien.

Zusätzlich hat Android 5 die Möglichkeit einer Full-Disk-Encryption realisiert. Das gesamte Gerät kann verschlüsselt werden und so im ausgeschalteten Zustand der Zugriff auf die Daten verhindert werden. Eingeschaltet schützt ein Pin-Code oder eine Passphrase das Gerät. Gleichzeitig wurde auch der Multi-User-Modus für Smartphones eingeführt. Tablet verfügten über diesen Modus bereits früher. Im Multi-User-Modus kann jeder Benutzer seine eigenen Einstellungen vornehmen und eigene Apps installieren. Diese stehen nur für den Benutzer zur Verfügung. Dies verbessert die Privatsphäre.

Ab Android 6 wurde der Verified Boot eingeführt. Hierbei kann das Smartphone mit Hilfe von kryptographischen Hashes die Integrität der System-Boot-Partition prüfen. Rootkits können so erkannt werden. Des Weiteren wird ab der Version 6 eine verbundene USB-Schnittstelle per Default nur zum Laden verwendet. Eine Freigabe des Speichers erfolgt nur nach Konfiguration durch den Benutzer. Eine Einstellung, auf die die Anwender keinen Einfluss haben, die jedoch von den Entwicklern genutzt werden kann, ist die Clear-Text-Traffic Einstellung. Diese Einstellung stellt sicher, dass eine App nur noch verschlüsselt kommuniziert. HTTP-Links werden zum Beispiel nicht verfolgt.

Eine weitere Verbesserung die Einfluss auf das Nutzerverhalten hat, ist die Abfrage der Berechtigungen zur Laufzeit. Die Berechtigungen werden nicht mehr zum Installationszeitpunkt, sondern erst bei Anforderung dem Benutzer zur Freigabe präsentiert. Dies erlaubt einfachere Installationen und die Möglichkeit auch Berechtigungen, wie den Zugriff auf den Standort während der Laufzeit, zu verweigern. Die Apps werden in den meisten Fällen dennoch funktionieren. Auch ist die Unterstützung von Fingerabdrücken für die Freischaltung des Telefons in der Version 6 aufgenommen worden.

In Version 7 wurden der Verified Boot und SELinux verbessert. Gleichzeitig wurde eine dateibasierte Verschlüsselung eingeführt. Hierbei stehen nun zwei Speicherbereiche zur Verfügung: Device Encrypted Storage. Dieser ist nach Eingabe des Boot-Kennwortes verfügbar. Credential Encrypted Storage. Dieser ist nach einer weiteren Eingabe des Benutzerkennwortes verfügbar. So können direkt nach dem Boot bestimmte Funktionen bereits zur Verfügung stehen. Dies wird als Direct Boot bezeichnet. Hierbei kann es sich um die Uhr, Wecker oder Telefoniefunktionen handeln. Weitere Funktionen, wie Kalender oder E-Mail, stehen nur nach Eingabe des benutzerspezifischen Kennworts bereit. Auch Multi-User-Setups werden hierdurch verschlüsselt möglich.

Um Man-in-the-middle Angriffe zu verhindern, vertrauen Apps ab API-Level 24 (7.0) nur noch den ausgelieferten CAs. Zertifikatsautoritäten, die durch die Nutzer oder Administratoren hinzugefügt wurden, werden nicht akzeptiert. Hierzu müssen die Apps spezifisch diesen CAs vertrauen.

In Android 8 wurde die Unterstützung für SSLv3 entfernt. Im Rahmen von Google Play Protect scannt Google die Apps im Playstore. Nun werden die Apps auch auf dem Gerät geprüft. Dies betrifft auch Apps die nicht aus dem Playstore kommen. Gleichzeitig wird das Nachladen von Code nicht mehr erlaubt und verlangt die Einwilligung des Nutzers.

Die wichtigste Errungenschaft ist jedoch der Schutz der SystemUI vor Clickjacking Angriffen. Bei diesem Angriff benötigt die Malware lediglich zwei Berechtigungen. Bei einer Installation über den Appstore wird der Benutzer nicht aufgefordert, diese Berechtigungen zu erlauben oder auf sie hingewiesen. Bei dem Angriff versieht die Malware den Bildschirm mit Overlays. Über diese Overlays können im Hintergrund Berechtigungsdialoge verdeckt werden. Der Anwender klickt vermeintlich OK für eine Einstellung in der App und weist ihr dabei zusätzliche Berechtigungen zu. Auch können Tastatureingaben abgefangen oder mit Hilfe der zusätzlich erlangten Berechtigungen getätigt werden. Auch kann das Gerät entsperrt oder Zwei-Faktor-Token erbeutet werden. Erst September 2017 wurden diese Angriffsvektoren durch Google gepatcht. Wir werden dies mit Hilfe eines älteren Android 7 Systems demonstrieren. Dies zeigt, wie wichtig die Bereitstellung und Installation von Firmware Updates auf Android Geräten ist.