Nach meinem Artikel zur Architekturschwäche von Android und der - in meinen Augen nicht wirklich effizienten - Verschlüsselung von Android Systemen nun eine Erläuterung zum Android-for-Work-Bereich.

Zunächst zur Begriffserklärung: "Android for Work", eingeführt mit Android Version 5 (Lollipop), wurde mit Blick auf die enorme Nachfrage, persönliche Geräte im Geschäftsumfeld zu nutzen (ByoD), entwickelt. Daneben gibt es für Geräte mit den Android-Versionen Ice Cream Sandwich (Android 4.0) bis Kitkat (Android 4.4) noch die Möglichkeit, Android for Work als eigenständige App zu installieren. Die Lösung ist jedoch wegen der eingeschränkten Möglichkeiten nur bedingt praxistauglich und auch nicht Gegenstand dieses Artikels.

Google hat Ende letzten Jahres Android for Work einen neuen Namen spendiert. Da die meisten APIs im Android-Betriebssystem integriert wurden, heißen Android for Work und Google Play for Work nur noch Android und Google Play. Daneben hat Google auch Google for Work in Google Cloud und die Google Apps in G Suite umbenannt. Da in vielen Gesprächen der Terminus "Android for Work" nach wie vor verwendet wird, habe ich ihn für diesen Artikel ebenfalls verwendet.

Container soll Berufliches von Privatem trennen

Die Grundidee hinter "Android for Work" ist es, ein separates Profil auf dem Gerät zu schaffen, welches geschäftsbezogene Kontrollen beinhaltet, während das ursprüngliche, persönliche Profil offen und "unmanaged" bleibt.

"Android for Work" bietet eine zusätzliche Sandbox, in der Apps außerhalb der Sandbox nicht auf Daten innerhalb der Sandbox zugreifen können. Dies sorgt für die angebliche saubere Trennung. In anderen Worten, keine Applikation, die innerhalb des persönlichen Profils auf dem Gerät installiert ist, sollte Zugriff auf den Ablauf oder den Inhalt im Arbeitsprofil haben.

Alle Geschäftsanwendungen, Emails und Dokumente werden innerhalb des Geschäftsprofils abgesichert und verwaltet, während alles auf der persönlichen Seite unberührt und unbeschränkt bleibt. Auf diese Weise erhalten Anwender ihre vollen Freiheitsgrade und ihre Privatsphäre bleibt gewahrt, da Administratoren keinen Einblick in diesen Bereich haben. Dies soll die Koexistenz von Produktivität und Privatsphäre ohne Sicherheitskonzessionen ermöglichen.

Neben dem Trennen von geschäftlichen und privaten Daten und dem Umsetzen von erweiterten Richtlinien unterstützt Android for Work auch den Schutz von geschäftlichen Daten beim Ausscheiden von Anwendern aus dem Unternehmen. Im letzteren Fall lassen sich die Firmendaten remote löschen, ohne die privaten Daten zu beeinträchtigen.

Unter der Haube basiert die Datentrennung aber lediglich auf einem anderen Unix-User mit eigenem Home-Verzeichnis und das ist auch der Grund für die folgenden Herausforderungen, die erstmalig von Skycure aufgebracht wurden.

Angriff auf die Benachrichtigungen

Mobile Benachrichtigungen sind mittlerweile Standard und ein essentieller Bestandteil mobiler Betriebssysteme. Die "Android for Work" Benachrichtigungen werden parallel zu den persönlichen Benachrichtigungen, im gleichen Interface, dargestellt. Dies ist nicht nur optisch der Fall. Auch für die interne API wird zwischen den verschiedenen Bereichen nicht unterschieden.

Seitdem der Zugriff auf Benachrichtigungen eine Erlaubnis auf Geräteebene ist, kann eine bösartige App im persönlichen Profil gezielt die Berechtigung erlangen, alleBenachrichtigungen inklusive der Arbeitsbenachrichtigungen zu sehen und in Aktion treten.

Sensible Informationen, wie Kalender-Meetings, Emails und andere Informationen erscheinen in diesen Benachrichtigungen, welche damit automatisch auch für eine "persönliche" bösartige App sichtbar sind.

Um einen Zugang zu Informationen im Arbeitsprofil zu bekommen, muss der Anwender so beeinflusst werden, dass er den Zugriff auf die Benachrichtigungen freigibt. Dies ist, wenn man die Qualität heutiger professioneller Spam-Angriffe anschaut, sicherlich nicht schwer. Auch ist für den Anwender das Gefahrenpotential nicht ersichtlich, da er sich ja in seiner "privaten" Umgebung frei bewegen darf/kann.

Ein Angreifer kann in der Lage sein, diese Methode für einen weiteren Zugang zu sensiblen Arbeitsinformationen zu nutzen, indem er einen "Passwort vergessen" Prozess auf einem Unternehmenssystem initiiert und die anschließende On-Device-Benachrichtigung stiehlt, um sich einen vollständigen Zugang zum Unternehmen zu ermöglichen, sogar außerhalb des Kontextes des mobilen Gerätes. Beispiele dafür sind etwa PIN/TAN Verfahren zum Anmelden an Finanzsystemen oder die Ermittlung von Zwei-Faktor-Anmeldedaten.

Um einen solcher Angriff geheim zu halten, kann die bösartige App mit Hilfe der Notifications API von Android, die Benachrichtigung sofort entfernen und die Wiederherstellungs-Mail "archivieren". So merkt das Opfer nicht einmal, dass es gehackt wurde.

Wenn die bösartige App dazu bestimmt ist, die gesehene Information in den Benachrichtigungen an einen "command and control server" zu übermitteln, dann ist die Information in den Benachrichtigungen nicht länger sicher und kann auch im großen Stil, sogar über mehrere Geräte hinweg, zentral abgegriffen und ausgewertet werden.

Rich-Notifications erschweren den Datenabfluss zusätzlich. Dabei werden, im Gegensatz zu jetzt, nicht mehr nur schnöde Text-Informationen eingeblendet, sondern auch Bilder von Kontakten und Ähnliches kann angezeigt werden.

Angriff über Bedienungshilfen

Schon in Android 1.6 beziehungsweise mit API-Level 4 wurden Accessibility-APIs in Android eingeführt. Android bietet mit dem "Accessibility Service" Erweiterungen der Nutzeroberflächen an, um diese auch für Anwender mit Einschränkungen zugänglich zur machen. Dies beinhaltet Features wie beispielsweise die akustische Wiedergabe vom Bildschirmtext für sehbeeinträchtigte Anwender.

Accessibility Services bieten auch Drittherstellern die Möglichkeit, die Zugänglichkeit aller installierten App zu erhöhen. So steht den Apps mit dieser Berechtigung der komplette Bildschirminhalt zur Interaktion zur Verfügung. Apps können dieser Schnittstelle Zusatzdienste z.B. für selektierte Texte anbieten (z.B. markierten Text auf Wikipedia nachschlagen). Bereits das Öffnen einer App gibt die Inhalte preis.

Eine Applikation im persönlichen Profil, die eine Zugangserlaubnis erwirbt, so kann einen Zugang zu allen Applikationen erhalten. Nicht nur zu den privaten, sondern auch zu den in dem geschäftlichen Profil hinterlegten Apps. Damit sind unkontrollierte Datenabflüsse möglich.

Aktuell schutzlos ausgeliefert

Das persönliche Profil kann vom Arbeitsprofil aus nicht angesehen oder kontrolliert werden. Selbst dann, wenn IT Administratoren versuchen, die Sicherheit auf dem Arbeitsprofil durchzusetzen (z.B. indem sie die Profileinstellungen einschränken oder nur "Whitelist-Apps" erlauben), wird es nicht möglich sein, eine Darstellung von sensiblen Informationen ausfindig zu machen, die der "Accessibility Service" nutzt, da sie nicht auf das persönliche Profil zugreifen können. Um eine solche Attacke durchzuführen, muss ein Hacker eine bösartige Applikation als ein "Accessibility Service" registrieren, sie dann mit einem harmlosen Label präsentieren und anschließend den Anwender manipulieren, damit dieser den Zugriff gewährt.

Gedankenspiele

Bisher war das Thema Datenabfluss aus dem Geschäftsbereich thematisiert. Aber es sind auch andere Datenabflüsse möglich. Der Zugriff auf Online-Banking TAN-Nummern (iTan per SMS) ist ebenso möglich. Der Datenabzug kann aber auch durch eine Firmen-App erfolgen. So wäre es theoretisch denkbar, eine App im dienstlichen Bereich zu installieren und mir ihr Art, Umfang und Inhalt der persönlichen Kommunikation (während der Arbeitszeit) zu überwachen und auszuspionieren. Der Vertrauensverlust, in diese Plattform, ist für mich persönlich, damit enorm.

Fazit

Für alles Beschriebene gilt: Die Sandbox von "Android for Work" funktioniert genau so, wie sie konzipiert und bestimmt ist. Leider hilft das den Unternehmensdaten wenig.

Dies alles sind ernsthafte Bedrohungen für die Nutzung von Android for Work. Zwar sichert Android die Daten in einer gesonderten Sandbox, stellt aber gleichzeitig API und Mechanismen zur Verfügung, die für ein Unternehmen völlig unsichtbar ablaufen und auch durch EMM (Enterprise Mobility Management) -Systeme nicht abzuwiegeln sind.

Ich habe keine persönlichen Ressentiments gegenüber dem Android-System, zusammen mit den Erkenntnissen aus den anderen Artikeln muss ich aber anmerken, dass mir persönlich immer klarer wird, wie umfangreich und komplex eine ganzheitliche Betrachtung des Android-Betriebssystems in einer modernen Unternehmensumgebung ist. Ihre Meinung in den Kommentaren würde mich sehr interessieren! (mb)