Accessibility-Missbrauch : Risiken durch Android-Bedienungshilfen-API

Von Kai Kunschke, Heilbronn

Um Menschen mit Behinderung die Verwendung von Android-Geräten zu vereinfachen beziehungsweise überhaupt erst zu ermöglichen, gibt es eine Bedienungshilfen-Schnittstelle (API). Apps erhalten dadurch Zugriff auf alternative Techniken zur Ein- und Ausgabe. So können Eingaben für andere Apps erzeugt werden, beispielsweise um eine Spracheingabe oder einen sogenannten Switch-Access zu implementieren. Andererseits können sämtliche textbasierten Ausgaben von Apps abgefangen werden, um diese dem Benutzer beispielsweise vorzulesen (Screenreader). Problematisch daran ist, dass die hierfür genutzten Verfahren das Sicherheitsmodell von Android an vielen Stellen aushebeln – dazu später mehr.

Zugriff auf die Bedienungshilfen-API erhält eine App erst, nachdem der Benutzer die Berechtigung BIND_ACCESSIBILITY_SERVICE erteilt hat. Android teilt Berechtigungen in mehrere Stufen ein – je nach Sensibilität des Eingriffs in das System. Die Berechtigungsstufe „normal“ sieht Google als unproblematisch an. Daher müssen solche Anforderungen nur im App-Manifest deklariert, aber nicht zusätzlich vom Benutzer bestätigt werden.

Berechtigungen der Stufe „dangerous“ muss der Benutzer jedoch abnicken – das ist zum Beispiel erforderlich, wenn eine App Zugriff auf das Telefonbuch verlangt. Seit Android 6 kann das auch zur Laufzeit geschehen, indem das System ein Dialogfenster einblendet, das den Benutzer zur Bestätigung der Berechtigung auffordert. Auf älteren Android-Versionen wurde dem Benutzer nur bei der Installation einer neuen App eine (möglicherweise lange) Liste der angeforderten Berechtigungen angezeigt.

Riskante Berechtigungen

Berechtigungen, die Google als besonders sensibel einstuft, gehören zum Level „signature“. Dies umfasst unter anderem die Device-Admin-Berechtigung, die MDM-Apps zur Geräteverwaltung verwenden, und auch die Bedienungshilfen-Berechtigung. Um diese Rechte zu vergeben, müssen Benutzer manuell mindestens drei Klicks machen:

• das zugehörige Menü in den Einstellungen aufrufen,
• die zu berechtigende App auswählen und
• den erscheinenden Hinweisdialog abnicken.

Yanick Fratantonio und seine Mitstreiter haben allerdings 2017 mit Cloak & Dagger gezeigt, dass sich die Berechtigung SYSTEM_ALERT_WINDOW missbrauchen lässt, um einen Clickjacking-Angriff auf diese drei Klicks durchzuführen (vgl. http://cloak-and-dagger.org/ bzw. [1]). Benutzer können die Bedienungshilfen-Berechtigung also unbemerkt erteilen, wenn eine böswillige App die Dialogfenster überblendet. Kurioserweise erhalten Apps, die über den offiziellen Google Play Store installiert werden, die Berechtigung SYSTEM_ALERT_WINDOW automatisch zugewiesen, obwohl diese dem „signature“-Level angehört – Google hat durch diese willkürliche Entscheidung dem Angriff Tür und Tor geöffnet. In der Praxis ist er vermutlich trotzdem wenig relevant: Hier kommt Google die starke Fragmentierung des Android-Markts einmal zugute, da ein Clickjacking-Angriff auf die konkrete Display-Auflösung und eventuell weitere herstellerabhängige Modifikationen am Android-System angepasst werden muss.

Dennoch ist es sinnvoll, das Risiko-Potenzial der Bedienungshilfen-API näher zu untersuchen. Schon allein, weil die meisten Anwender trotz der Warnhinweise beim Aktivieren der Berechtigung deren reale Auswirkungen vermutlich unterschätzen.

Hinzu kommt, dass eine Bedienungshilfen-App die vermeintlichen Grenzen zwischen dem persönlichen Profil und dem Geschäfts-Container beim Einsatz von „Android for Work“ (vgl. [2]) wieder aufhebt: Denn eine Bedienungshilfen-App im persönlichen Profil kann Bildschirminhalte von Apps im Geschäftsprofil auslesen und Eingaben für diese erzeugen. Und auch die Nachrichteninhalte von Ende-zu-Ende-verschlüsselten Messengers wie Signal oder WhatsApp können durch Bedienungshilfen-Apps abfließen.

Funktionsweise der API

Bedienungshilfen-Apps implementieren einen Android-Service, der bestimmte sogenannte AccessibilityEvents abonniert. Davon gibt es grob gesagt zwei Arten: Eingabe- und Ausgabeevents. Das Android-System ruft nun immer, wenn eines der abonnierten Events auftritt, die Callback-Methode onAccessibilityEvent der Service-Komponente auf. Wurde beispielsweise der EventType TYPE_VIEW_CLICKED abonniert, so wird der Callback bei jedem Klick auf einen Button aufgerufen – auch Eingaben über die Bildschirmtastatur erzeugen diese Events. Wurde der EventType TYPE_VIEW_TEXT_CHANGED abonniert, dann wird der Callback bei jeder Änderung in einem EditText-Element aktiv. Apps können natürlich auch mehrere oder einfach alle Eventtypen abonnieren.

Offensichtlich ließen sich so recht einfach Keylogger implementieren, indem man TYPE_VIEW_CLICKED-Events abonniert. Doch Google hat vorgesorgt und verhindert, dass diese Events generiert werden, wenn die Eingabe in ein explizites Passwortfeld erfolgt. Android behandelt jedoch alle Eingabefelder als EditText-Elemente, egal ob es sich um Loginformulare in einer Webseite oder das Passworteingabefeld am Sperrbildschirm des Gerätes handelt. Daher werden regelmäßig Ausgabeevents vom Typ TYPE_VIEW_TEXT_CHANGED erzeugt, wann immer eine Eingabe erfolgt. Und über diesen Umweg lassen sich Passwörter dann doch abfangen, da Android standardmäßig das letzte eingegebene Zeichen im Klartext anzeigt – das dient an sich der Benutzerunterstützung, denn schließlich kommt es auf den kleinen Bildschirmtastaturen häufiger zu Vertippern. Um jedoch vollständig verhindern zu können, dass Passwörter über die genannte Methode abgefangen werden, sollte man die Systemeinstellung „Make passwords visible“ manuell deaktivieren.

Soviel zum Abfangen von Ein- und Ausgaben. Möchte man unter Verwendung der Bedienungshilfen selbst Eingaben erzeugen, ist grundsätzlich genauso vorzugehen: Der onAccessibilityEvent-Callback bekommt dazu vom Android-System ein Objekt des Typs AccessibilityEvent übergeben. Dieses Objekt enthält eine baumartige Repräsentation aller GUI-Elemente (Textfelder, Buttons etc.) des momentanen Bildschirminhalts. Diesen Baum kann man dann durchlaufen, um Eingaben in Textfeldern zu erzeugen, Buttons zu klicken oder Ähnliches zu bewirken.

Sandkasten-Schleuse

Um das strenge App-Sandboxing von Android an der einen oder anderen Stelle aufzuweichen, nutzen viele Apps die Bedienungshilfen-API auch für legitime Zwecke. So verwendet etwa der populäre Passwort-Manager LastPass diese Berechtigung, um eine Autofill-Funktion zu implementieren; dies ermöglicht es der App, Passwörter in Eingabefelder anderer Apps – beispielsweise im Browser – einzufügen, was an sich nicht nur der Benutzerfreundlichkeit, sondern auch der Sicherheit der Passwörter zugutekommt. Denn die alternative Lösung, Passwörter über die Zwischenablage zu kopieren, kann zum Abfließen des Passworts führen, da alle Apps hierauf zugreifen können. Inzwischen hat Google reagiert und mit Android 8 eine spezielle Autofill-API für Passwort-Manager eingeführt. Da Android 8 und 8.1 gegenwärtig jedoch nur auf eine Marktdurchdringung von gerade einmal 5,7 % kommen (Stand Mai 2018 – Quelle: https://developer.android.com/about/dashboards/), werden Passwort-Manager aber noch eine ganze Weile auf die Bedienungshilfen zurückgreifen müssen.

Bei der Untersuchung einiger Security- und Parental-Controls-Apps kamen darüber hinaus weitere kreative Anwendungsfälle der Bedienungshilfen-API zutage: So verwenden die Apps Bitdefender Mobile Security, Sophos Mobile Security, ESET Parental Control, Kaspersky Safe Kids und Symantec Norton Family diese API unter anderem, um Webfilter zu implementieren. Dazu extrahieren die genannten Anwendungen die aufgerufene URL aus der Adressleiste des Browsers und gleichen sie mit einer Blacklist ab, um Anwender vor Malware-Seiten und Kinder vor unpassenden Inhalten zu bewahren – befindet sich die aufgerufene URL auf der Blacklist, wird beispielsweise kurzerhand eine andere URL eingeschleust und geöffnet, die einen Warnhinweis anzeigt.

Einige der genannten Apps verwenden die API darüber hinaus, um sogenannte App-Locks zu implementieren. Diese beschränken die Ausführung bestimmter Anwendungen gänzlich, nach Ablauf eines Zeitkontingents oder innerhalb eines Zeitfensters. So kann Kindern beispielsweise die Ausführung eines bestimmten Spiels nur für einen gewissen Zeitraum gestattet werden.

Doch auch die Deinstallation einer App lässt sich mit dieser Technik verhindern – was bei Parental-Controls und Apps, die Anti-Diebstahl-Funktionen implementieren, durchaus sinnvoll ist, denn schließlich sollen Diebe oder Kinder die App ja nicht einfach entfernen können. Hierzu ist zusätzlich die Device-Admin-Berechtigung erforderlich: Apps mit dieser Berechtigung können erst deinstalliert werden, nachdem man die Berechtigung deaktiviert hat. Wenn die Einstellungen-App mit einer PIN geschützt ist, kann ein Unbefugter die Berechtigung nicht entziehen und damit die mit dem Lock geschützte App eigentlich nicht deinstallieren – wenn da nicht noch der „Safe Mode“ wäre: Denn im Android „Safe Mode“ werden nur die vom Gerätehersteller vorinstallierten Apps ausgeführt – ein nachträglich installiertes App-Lock wird also ausgehebelt und die Deinstallation der App wieder ermöglicht.

Gut oder böse?

Die Grenze zwischen kreativem Gebrauch (aka Hacks) und schädlichem Missbrauch der Bedienungshilfen-API verläuft fließend: So sehen einige Entwickler bei der Verhinderung der Deinstallation die Richtlinien des Google Play Store verletzt. Streng genommen handelt es sich sogar bei jeder Nutzung der Bedienungshilfen um einen Missbrauch, wenn diese nicht ausschließlich verwendet werden, um Menschen mit Behinderung zu unterstützen – so zumindest steht es in der Android-Dokumentation [3]. Google ist sich des Missbrauchspotenzials der API dabei durchaus bewusst und hat im November 2017 angedroht, alle Apps, die Bedienungshilfen für andere Zwecke verwenden, aus dem Play Store zu entfernen (vgl. [4]). Inzwischen ist Google aber wieder zurückgerudert und sieht über den Missbrauch der Bedienungshilfen hinweg, wenn dies „auf verantwortungsvolle Weise geschieht und dem guten Zweck dient“. Wie das überprüft werden soll, bleibt indessen unklar.

In der Tat sind die Anwendungsmöglichkeiten jenseits des guten Zweckes vielfältig: So wurden die Bedienungshilfen schon von verschiedenen Android-Malware-Familien missbraucht, um zum Beispiel weitere bösartige Apps vom Benutzer unbemerkt zu installieren. Hat eine Malware-App erst einmal die Bedienungshilfen-Berechtigung erlangt, kann sie sich selbst alle weiteren Berechtigungen verschaffen, indem sie die Android-Systemdialoge selbstständig bestätigt oder in die betreffenden Menüs zum Verleihen der „signature“-Berechtigungen navigiert. In vielen Fällen sieht der Benutzer nicht einmal das Aufflackern der entsprechenden Dialogfenster.

Fazit

Unter Verwendung der Bedienungshilfen können auch ohne Root-Exploit vielfältige Angriffe auf Android-Geräten durchgeführt werden und Unternehmensdaten, vertrauliche Nachrichteninhalte sowie Passwörter abfließen. In der Konsequenz sollten Unternehmen den Einsatz von Bedienungshilfen-Apps auf geschäftlich genutzten Geräten soweit wie möglich einschränken. Auf jeden Fall sollte jeder Android-Benutzer hinterfragen, ob das Vergeben dieser Berechtigung für den konkreten Anwendungsfall einer App wirklich notwendig ist. Vertrauenswürdige Apps klären den Benutzer darüber auf, für welche Funktionen sie die Berechtigung benötigen. Im Zweifel sollte man auf den Einsatz der App verzichten oder eine vertiefende Risikoanalyse durchführen.

Kai Kunschke ist Berater bei der cirosec GmbH in Heilbronn.

Literatur

[1] Yanick Fratantonio, Chenxiong Qian, Simon P. Chung, Wenke Lee Georgia Tech, Cloak and Dagger: From Two Permissions to Complete Control of the UI Feedback Loop, Mai 2017, www.s3.eurecom.fr/~yanick/publications/2017_oakland_cloakanddagger.pdf – erweiterte Version vom Juli 2017: www.s3.eurecom.fr/~yanick/publications/2017_blackhatusa_cloakanddaggerbhusa.pdf, Vortragsfolien und -videos via www.s3.eurecom.fr/~yanick/publications.html
[2] Mike Raggo, Android wird geschäftsfähig, <kes> 2015#3, S. 50
[3] Android Developer Documentation, Accessibility-Service, https://developer.android.com/reference/android/ accessibilityservice/AccessibilityService
[4] Fennifith, Is Google Play really going to suspend all apps using accessibility services for things other than
accessibility?, Kommentar auf dem Reddit Android-Channel, November 2017, https://www.reddit.com/r/Android/comments/7c4go5/