Wie Android 17 das Bedrohungsmodell rund um den AccessibilityService neu aufstellt

In Android 17 ändert der Modus Advanced Protection die Spielregeln grundlegend: Zugriff auf den AccessibilityService erhalten nur noch überprüfte Apps, die als Accessibility Tools gekennzeichnet sind, alle anderen werden blockiert. Damit wird einer der wichtigsten Angriffswege von Banktrojanern und Spionage-Software abgeschnitten, zugleich entstehen aber Kompatibilitätsrisiken für legitime Anwendungen, die Accessibility zweckentfremden; Organisationen und Power-User müssen solche Apps im Vorfeld erfassen und den Betrieb im neuen Modus testen.

Technische Details der Änderungen in Android 17

Laut dem offiziellen Sicherheitsblog von Google wird in Android 17 bei aktiviertem Advanced Protection der Zugriff auf den AccessibilityService automatisch auf Apps beschränkt, die Google als Accessibility Tools klassifiziert hat. Alle anderen Programme verlieren die Möglichkeit, dieses Interface zu nutzen – selbst dann, wenn der Nutzer ihnen zuvor manuell die entsprechenden Berechtigungen erteilt hat.

Die AccessibilityService API ist ein mächtiges Framework, das einer App erlaubt:

• im Hintergrund zu laufen;
• UI-Ereignisse abzufangen;
• mit anderen Apps im Namen des Nutzers zu interagieren.

Ihr Zweck ist die Unterstützung von Menschen mit Behinderungen (Screenreader, Sprachsteuerung usw.), wie es in der offiziellen Dokumentation zur AccessibilityService API beschrieben ist. Derselbe Privilegienumfang ermöglicht es Malware jedoch, das System ohne Root-Rechte tiefgehend zu beobachten und zu steuern.

Frühere Schutzmaßnahmen rund um Accessibility

Die neuen Einschränkungen in Android 17 ergänzen bereits umgesetzte Maßnahmen von Google gegen den Missbrauch von Accessibility:

• Blockierung der Aktivierung von Accessibility für Apps, die unter Umgehung des offiziellen Stores installiert wurden (Sideloading);
• Schutz während Telefonaten, der verhindert, dass ein Angreifer den Nutzer am Telefon dazu überredet, Google Play Protect zu deaktivieren, Software aus unbekannten Quellen zu installieren oder gefährliche Accessibility-Berechtigungen zu erteilen;
• das Flag accessibilityDataSensitive, das Entwickler auf UI-Elemente mit vertraulichen Daten setzen können, damit potenziell schädliche Apps deren Inhalt nicht auslesen und keine Aktionen auf diesen Elementen emulieren können – dieser Mechanismus wird im technischen Material von Google zum Schutz vor Datenabfluss über Accessibility beschrieben;
• den Modus Android Advanced Protection Mode (AAPM), der die Nutzung von Accessibility bereits für bestimmte App-Typen eingeschränkt hat.

Die Neuerung in Android 17 stellt das bisherige Standardmodell faktisch auf den Kopf: Statt „für alle erlaubt, außer ausdrücklich verbotenen“ gilt nun „für alle verboten, außer den von Google ausdrücklich zugelassenen Accessibility Tools“ – allerdings nur für Geräte mit aktiviertem Advanced Protection.

Zusätzliche Sicherheitsfunktionen in Android 17

Neben dem Schutz rund um Accessibility bringt Android 17 mit Advanced Protection noch einige weitere Elemente verstärkter Abwehr (Google Security Blog):

• Intrusion Logging – eine permanente, aber auf den Datenschutz ausgerichtete Protokollierung zur Untersuchung komplexer Spionageangriffe; wird manuell in den Advanced-Protection-Einstellungen aktiviert.
• USB Protection – Schutz vor unbefugtem Zugriff auf das Gerät über eine physische USB-Verbindung.
• Disable WebGPU – Möglichkeit, WebGPU im Browser zu deaktivieren, um die Angriffsfläche für komplexe Web-Exploits zu verringern.
• Failed Authentication Lock – vollständige Sperrung des Geräts nach einer Reihe fehlgeschlagener Authentifizierungsversuche, was Brute-Force-Angriffe und physisches Durchprobieren erschwert.
• View Supporting Apps – ein Interface, das dem Nutzer anzeigt, welche installierten Apps den Status von Advanced Protection abgefragt haben.

App-Entwickler können benachrichtigt werden, wenn Advanced Protection aktiviert wird, und für diese Nutzergruppe automatisch zusätzliche Schutzfunktionen aktivieren oder das Verhalten der App anpassen (offizielle Beschreibung des Mechanismus).

Bedrohungskontext: Warum gerade Accessibility im Fokus steht

Der Zugriff auf den AccessibilityService ist seit Langem ein vorrangiges Ziel mobiler Malware. Nach Googles Darstellung erhält eine bösartige App, sobald der Nutzer über Vorwände wie „erweiterte Funktion“ oder „Leistungsbeschleunigung“ zur Aktivierung von Accessibility überredet wurde, die Möglichkeit:

• betrügerische Überweisungen aus installierten Finanz-Apps programmatisch auszulösen;
• Tastendrücke und eingegebene Daten abzufangen;
• gefälschte Login-Bildschirme über legitimen Anwendungen anzuzeigen;
• sich selbst zusätzliche sensible Berechtigungen zu erteilen;
• vertrauliche Daten direkt vom Bildschirm auszulesen;
• weitere Schadsoftware zu installieren oder die eigene Deinstallation zu blockieren.

Der entscheidende Punkt: All dies geschieht, ohne dass eine Kernel-Schwachstelle ausgenutzt oder Root erlangt werden muss – die Malware stützt sich auf ein legitimes, aber übermächtig ausgestattetes Systeminterface. Die Umstellung des Zugriffs auf Accessibility auf das Modell „nur verifizierte Accessibility Tools bei aktivierter Advanced Protection“ schneidet daher eine ganze Klasse von Angriffen ab, die sich ausschließlich auf Social Engineering und den anschließenden Missbrauch der API stützten.

Auswirkungsanalyse für Organisationen und Nutzer

Von den Änderungen betroffen sind:

• Nutzer von Geräten mit Android 17, die Advanced Protection aktivieren;
• Entwickler beliebiger Apps, die den AccessibilityService nutzen;
• Sicherheits- und Forensik-Teams, die gezielte mobile Angriffe untersuchen.

Positiver Effekt: Für Geräte mit Advanced Protection sinkt das Risiko einer Kompromittierung durch Social Engineering und das Aufdrängen von Apps, die Accessibility zu Betrugszwecken nutzen, deutlich. Selbst wenn der Nutzer eine bösartige App installiert und ihr Accessibility-Zugriff gewähren möchte, lässt das System in Android 17 dies nicht zu, sofern die App nicht zu den verifizierten Accessibility Tools gehört.

Kehrseite: Alle legitimen Apps, die den AccessibilityService derzeit für atypische Aufgaben nutzen (Automatisierung, Overlays mit Zusatzfunktionen über anderen Apps, unterstützende Shells usw.), aber von Google nicht als Accessibility Tools klassifiziert sind, werden bei aktivierter Advanced Protection auf Android 17:

• den Zugriff auf den AccessibilityService verlieren;
• ihre Funktionalität teilweise oder vollständig einbüßen;
• sich auf Geräten mit und ohne Advanced Protection unterschiedlich verhalten, was den Support erschwert.

Für Unternehmensumgebungen bedeutet dies, dass die Nutzungsprofile von Android-Geräten überarbeitet werden müssen: Geräte von Mitarbeitern mit erhöhten Schutzanforderungen (z. B. Führungskräfte, Mitarbeiter mit Zugriff auf sensible Daten) können bei aktivierter Advanced Protection auf den ersten Blick nicht kritische, aber dennoch störende Ausfälle gewohnter Funktionen von Drittanbieter-Apps erleben.

Separat zu betrachten ist die Wirkung von Intrusion Logging und USB Protection. Erstere Funktion erhöht die Chancen auf eine erfolgreiche Untersuchung komplexer Spionageangriffe, erfordert aber ein bewusstes Aktivieren und etablierte Prozesse für den Umgang mit den Protokollen. USB Protection verringert das Risiko von Angriffen bei physischem Zugriff auf das Gerät über USB, was bei Bedrohungen durch Geräte-Diebstahl oder Versuche einer Analyse auf Seiten des Angreifers besonders kritisch ist.

Praktische Empfehlungen

Für Organisationen und Sicherheitsteams

• Apps mit Nutzung von AccessibilityService inventarisieren auf verwalteten Android-Geräten. Separat kennzeichnen, welche davon für Geschäftsprozesse kritisch sind.
• Pilotbetrieb von Android 17 mit aktiviertem Advanced Protection in einer begrenzten Nutzergruppe durchführen, die solche Apps verwendet. Dokumentieren, welche Funktionen ausfallen.
• Geräteprofile trennen: dort, wo Advanced Protection verpflichtend aktiviert wird (Geräte mit erhöhtem Risiko), und dort, wo sie aufgrund der Abhängigkeit von Apps mit Accessibility-Nutzung optional bleibt.
• In Richtlinien zur Incident Response die Möglichkeit der Nutzung von Intrusion Logging berücksichtigen: festlegen, wer es unter welchen Umständen in den Advanced-Protection-Einstellungen aktiviert, wie Protokolle ausgelesen und analysiert werden.
• USB Protection auf allen Geräten aktivieren, auf denen Einschränkungen bei USB-Verbindungen vertretbar sind, und Anweisungen für Mitarbeiter aktualisieren, die regulär sichere Verbindungen zu PCs benötigen.
• Den Bedarf zur Deaktivierung von WebGPU bewerten auf Geräten mit Zugriff auf kritische Web-Ressourcen, um das Risiko komplexer Browser-Angriffe zu minimieren.

Für Entwickler von Android-Apps

• Die Notwendigkeit der Nutzung von AccessibilityService überprüfen. Wenn Ihr Produkt kein unterstützendes Werkzeug für Menschen mit Behinderungen ist, kann die Nutzung von Accessibility dazu führen, dass ein Teil Ihrer Nutzer mit Advanced Protection zentrale Funktionen verliert.
• Die Richtlinie zur Nutzung von AccessibilityService studieren und einhalten, wie sie im Google-Play-Entwicklerleitfaden beschrieben ist, und sich bei Bedarf als Accessibility Tool verifizieren lassen.
• Sensible UI-Elemente mit dem Flag accessibilityDataSensitive kennzeichnen, wie im Google-Material zum Schutz von Daten vor Auslesen über Accessibility beschrieben, um das Risiko eines Abflusses vertraulicher Informationen über bösartige Services zu verringern.
• Eine verzweigte Logik für Nutzer mit aktiviertem Advanced Protection implementieren, indem Sie den Mechanismus zur Benachrichtigung über dessen Aktivierung nutzen (Beschreibung im Sicherheitsblog von Google), und bei Bedarf Funktionen deaktivieren oder ersetzen, die vom AccessibilityService abhängen.
• Einen Test-Stack auf Android 17 aufbauen und Prüfungen mit aktiviertem Advanced Protection in das Regressionstesten aufnehmen, insbesondere wenn das Produkt mit Finanztransaktionen oder sensiblen Daten arbeitet.

Die zentrale Erkenntnis: Android 17 mit Advanced Protection verlagert den Schutz vor Missbrauch des AccessibilityService aus der Sphäre „den Nutzer davon abhalten, zu viel anzuklicken“ in die Sphäre des systemseitigen Verbots. Deshalb ist es sinnvoll, schon jetzt: 1) alle Apps zu erfassen, die in Ihrer Umgebung den AccessibilityService nutzen, 2) auf einer Testgruppe von Geräten mit Android 17 Advanced Protection zu aktivieren und sämtliche Funktionsstörungen zu dokumentieren, 3) basierend auf den Testergebnissen problematische Apps entweder zu ersetzen oder im Vorfeld Ausnahmen und separate Geräteprofile vorzubereiten.