Як Android 17 перебудовує модель загроз навколо AccessibilityService

В Android 17 режим Advanced Protection кардинально змінює правила гри: доступ до AccessibilityService отримують лише перевірені застосунки, позначені як Accessibility Tools, а всі інші — блокуються, що перекриває один із ключових каналів банківських троянів і шпигунських програм, але водночас створює ризики сумісності для легітимних застосунків, які використовують Accessibility не за прямим призначенням; організаціям і досвідченим користувачам доведеться заздалегідь провести інвентаризацію таких застосунків і протестувати роботу в новому режимі.

Технічні деталі змін в Android 17

За даними офіційного блогу безпеки Google, в Android 17 за ввімкненого Advanced Protection доступ до AccessibilityService автоматично обмежується лише застосунками, які Google класифікував як Accessibility Tools. Усі інші програми втратять можливість використовувати цей інтерфейс, навіть якщо раніше користувач вручну надавав їм відповідні дозволи.

AccessibilityService API — це потужний фреймворк, який дає змогу застосунку:

• працювати у фоні;
• перехоплювати події інтерфейсу користувача;
• взаємодіяти з іншими застосунками від імені користувача.

Його призначення — допомога людям з інвалідністю (зчитування з екрана, голосове керування тощо), що описано в офіційній документації по AccessibilityService API. Однак той самий рівень привілеїв дає шкідливому ПЗ змогу глибоко спостерігати за системою та керувати нею без прав root.

Попередні кроки захисту навколо Accessibility

Нові обмеження в Android 17 доповнюють уже реалізовані заходи Google проти зловживань Accessibility:

• блокування увімкнення Accessibility для застосунків, установлених в обхід офіційного магазину (sideloading);
• захист під час дзвінків, який не дозволяє зловмиснику вмовити користувача телефоном вимкнути Google Play Protect, установити ПЗ з невідомих джерел або надати небезпечні Accessibility-дозволи;
• флаг accessibilityDataSensitive, який розробники можуть виставляти на елементах інтерфейсу з конфіденційними даними, щоб потенційно шкідливі застосунки не могли читати вміст і емулювати дії на цих елементах — механізм описаний у технічному матеріалі Google про захист від витоків даних через Accessibility;
• режим Android Advanced Protection Mode (AAPM), який уже обмежував використання Accessibility для деяких типів застосунків.

Нововведення Android 17 фактично перевертає модель за замовчуванням: замість «дозволено всім, окрім явно заборонених» запроваджується схема «заборонено всім, окрім явно допущених Google Accessibility Tools» — але лише для пристроїв із увімкненим Advanced Protection.

Додаткові функції безпеки в Android 17

Окрім захисту Accessibility, Android 17 з Advanced Protection додає ще кілька елементів посиленої оборони (Google Security Blog):

• Intrusion Logging — постійне, але зорієнтоване на конфіденційність журналювання для розслідування складних шпигунських атак; вмикається вручну в налаштуваннях Advanced Protection.
• USB Protection — захист від несанкціонованого доступу до пристрою через фізичне USB‑підключення.
• Disable WebGPU — можливість вимкнути WebGPU в браузері, щоб зменшити поверхню атак через складні веб‑експлойти.
• Failed Authentication Lock — повне блокування пристрою після серії невдалих спроб автентифікації, що ускладнює брутфорс і фізичний перебір.
• View Supporting Apps — інтерфейс, який дає змогу користувачу бачити, які встановлені застосунки перевіряли статус Advanced Protection.

Розробники застосунків можуть отримувати сповіщення про ввімкнення Advanced Protection і автоматично активувати додаткові захисні функції або змінювати поведінку застосунку для цієї категорії користувачів (офіційний опис механізму).

Контекст загроз: чому саме Accessibility під ударом

Доступ до AccessibilityService уже давно став пріоритетною ціллю мобільного шкідливого ПЗ. Згідно з описом Google, після того як користувача вмовляють увімкнути Accessibility під приводом «розширеної функції» або «прискорення роботи», шкідливий застосунок отримує можливість:

• програмно ініціювати шахрайські перекази коштів з установлених фінансових застосунків;
• перехоплювати натискання клавіш і введені дані;
• створювати підроблені екрани входу поверх легітимних застосунків;
• надавати собі додаткові чутливі дозволи;
• читати конфіденційні дані безпосередньо з екрана;
• установлювати інше шкідливе ПЗ або блокувати власне видалення.

Визначальний момент: усе це відбувається без необхідності експлуатувати вразливість ядра або отримувати root — malware спирається на легітимний, але надто потужний системний інтерфейс. Тому переведення доступу до Accessibility в модель «лише верифіковані Accessibility Tools за ввімкненої Advanced Protection» підрізає цілий клас атак, що спиралися виключно на соціальну інженерію та подальше зловживання API.

Оцінка впливу на організації та користувачів

Кого стосуються зміни:

• користувачів пристроїв на Android 17, які вмикають Advanced Protection;
• розробників будь-яких застосунків, що використовують AccessibilityService;
• команди безпеки та цифрової криміналістики, які розслідують цільові мобільні атаки.

Позитивний ефект: для пристроїв із Advanced Protection різко зменшується ризик компрометації через соціальну інженерію та нав’язування застосунків, які використовують Accessibility для шахрайства. Навіть якщо користувач установить шкідливий застосунок і спробує надати йому доступ до Accessibility, система в Android 17 цього не дозволить, якщо застосунок не належить до верифікованих Accessibility Tools.

Зворотний бік: будь-які легітимні застосунки, які зараз використовують AccessibilityService для нестандартних завдань (автоматизація, додаткові функції поверх інших застосунків, допоміжні оболонки тощо), але не класифіковані Google як Accessibility Tools, за ввімкнення Advanced Protection на Android 17:

• втратять доступ до AccessibilityService;
• можуть частково або повністю втратити функціональність;
• почнуть поводитися по-різному на пристроях з Advanced Protection і без нього, що ускладнить підтримку.

Для корпоративного середовища це означає необхідність переробки профілів використання Android: пристрої співробітників із підвищеними вимогами до захисту (наприклад, керівники, співробітники, які працюють із чутливими даними) за ввімкнення Advanced Protection можуть зіткнутися з на перший погляд некритичними, але дратівливими відмовами звичних функцій сторонніх застосунків.

Окремо варто відзначити вплив Intrusion Logging і USB Protection. Перший інструмент підвищує шанси на успішне розслідування складних шпигунських атак, але потребує усвідомленого ввімкнення та вибудовування процесу роботи з журналами. Другий знижує ризик атак за фізичного доступу до пристрою через USB, що критично для загроз, пов’язаних із крадіжкою пристроїв або спробами їх аналізу з боку зловмисника.

Практичні рекомендації

Для організацій і команд безпеки

• Провести інвентаризацію застосунків, що використовують AccessibilityService на керованих Android‑пристроях. Окремо відмітити, які з них критичні для бізнес‑процесів.
• Провести пілотне тестування Android 17 з увімкненим Advanced Protection на обмеженій групі користувачів, у яких є такі застосунки. Зафіксувати, які функції перестають працювати.
• Розділити профілі пристроїв: де Advanced Protection вмикається обов’язково (пристрої з підвищеними ризиками), а де — опціонально через залежність від застосунків, що використовують Accessibility.
• У регламентах з реагування на інциденти врахувати можливість використання Intrusion Logging: визначити, хто і в яких випадках вмикає його в налаштуваннях Advanced Protection, як вилучаються та аналізуються журнали.
• Увімкнути USB Protection на всіх пристроях, де допустимі обмеження під час підключення по USB, та оновити інструкції для співробітників, яким потрібні регулярні безпечні підключення до ПК.
• Оцінити необхідність вимкнення WebGPU на пристроях для доступу до критичних веб‑ресурсів, щоб мінімізувати ризик складних браузерних атак.

Для розробників Android‑застосунків

• Переглянути обґрунтованість використання AccessibilityService. Якщо ваш продукт не є допоміжним інструментом для людей з інвалідністю, використання Accessibility може призвести до блокування функціональності в частини користувачів з Advanced Protection.
• Вивчити й дотримуватися політики використання AccessibilityService, викладеної в керівництві Google Play для розробників, і за потреби проходити верифікацію як Accessibility Tool.
• Позначити чутливі елементи інтерфейсу флагом accessibilityDataSensitive, як описано в матеріалі Google про захист даних від перегляду через Accessibility, щоб знизити ризик витоку конфіденційної інформації через шкідливі сервіси.
• Реалізувати розгалуження логіки для користувачів із увімкненим Advanced Protection, використовуючи механізм сповіщень про його активацію (опис у блозі безпеки Google), і за потреби вимикати або замінювати функції, що залежать від AccessibilityService.
• Побудувати тестовий контур на Android 17 і додати перевірки з увімкненим Advanced Protection у регресійне тестування, особливо якщо продукт працює з фінансовими операціями або чутливими даними.

Ключовий висновок: Android 17 з Advanced Protection переводить захист від зловживань AccessibilityService із площини «переконувати користувача нічого зайвого не натискати» у площину системної заборони, тому вже зараз має сенс: 1) зібрати список усіх застосунків, що використовують AccessibilityService у вашому середовищі, 2) на тестовій групі пристроїв з Android 17 увімкнути Advanced Protection і зафіксувати всі порушення роботи, 3) за результатами тестів або замінити проблемні застосунки, або заздалегідь підготувати винятки та окремі профілі пристроїв.