SHARE THE PERSPECTIVE
Спеціальні можливості необхідні користувачам; ризик виникає через необґрунтоване надання доступу та зловживання ним.

Шкідливому програмному забезпеченню не завжди потрібно ламати шифрування повідомлень. Якщо воно отримує доступ до даних, які пристрій обробляє для відображення або введення, то може побачити вміст до шифрування або після розшифрування. Зловживання спеціальними можливостями та вікна-накладки — два приклади, але їхні механізми різні.

Крім того, не кожен застосунок з Accessibility або плаваючим вікном є шкідливим. Програми читання з екрана й допоміжні інструменти необхідні багатьом користувачам. Мета — усвідомлено надавати доступ і зменшувати зловживання, а не усувати спеціальні можливості.

Три загрози, які не слід плутати

Метод Що робить нападник? Чого не слід припускати?
Підроблене вікно або форма Спонукає користувача вводити інформацію в інтерфейс, схожий на справжній застосунок Не кожна накладка Overlay автоматично читає текст нижнього вікна
Викрадення натискань, або Tapjacking Обманом змушує користувача торкнутися іншого елемента керування Наявність прозорого шару не означає запису всіх клавіш
Зловживання службою Accessibility Використовує дозволені можливості служби для спостереження чи дій Доступ до всіх подань неоднаковий у всіх версіях

Офіційний посібник із Tapjacking розрізняє повне й часткове перекриття інтерфейсу. На результат впливають тип вікна, версія Android і налаштування застосунку.

Як Accessibility може отримати доступ до чутливих даних?

Служба спеціальних можливостей у межах своїх можливостей може отримувати інформацію інтерфейсу або виконувати дії за користувача. Шкідлива служба може цим зловживати. Тому ввімкнення такої служби для застосунку без зрозумілої причини — не малозначне рішення.

Проте твердження «кожна служба може прочитати весь текст будь-якого застосунку» надто категоричне. Важливі структура подань, спосіб надання даних та обмеження операційної системи. Для чутливих подань Android має такі можливості, як accessibilityDataSensitive; їх використання й поведінку слід перевіряти на цільовій версії. Пояснення Google щодо захисту даних від шкідливих служб.

Що робить і чого не робить FLAG_SECURE?

FLAG_SECURE використовується для обмеження знімків екрана й відображення вмісту на незахищених виходах. Сам по собі цей прапорець не контролює контракт спеціальних можливостей, підроблені форми або всі способи видобування тексту. Фотографування екрана іншим пристроєм — також окрема проблема.

Android надає застосункам й інші інструменти, наприклад HIDE_OVERLAY_WINDOWS, для зменшення кількості вікон-накладок. Жоден із них не слід представляти як «кнопку проти шпигунства» без перевірки сумісності, обмежень версій і впливу на користувачів, яким потрібні спеціальні можливості. Посібник із захисту чутливих дій.

Список перевірки дозволів для користувача

  1. У налаштуваннях пристрою окремо перегляньте застосунки зі спеціальними можливостями, відображенням поверх інших застосунків і доступом до сповіщень. Назви шляхів відрізняються залежно від виробника й версії.
  2. Для кожного запитайте, якій конкретній функції потрібен цей доступ. Доступ довіреної програми читання з екрана й невідомого застосунку-ліхтарика — не одне й те саме.
  3. Термінове прохання ввімкнути доступ після встановлення невідомого файлу вважайте ознакою потреби в додатковій перевірці; сам запит дозволу не доводить шкідливості.
  4. Якщо екран входу виглядає підозріло, не вводьте чутливу інформацію. Відкрийте застосунок звичним способом і перевірте адресу або джерело встановлення.
  5. Після відкликання непотрібного доступу перевірте роботу необхідних вам допоміжних інструментів. Безпека не має робити пристрій непридатним для його власника.

Якщо ви припускаєте, що пароль або сеанс уже було розкрито, одного відкликання дозволу недостатньо. З довіреного пристрою перевірте активні сеанси та способи відновлення облікового запису й змініть паролі, що опинилися під загрозою.

Що має перевірити розробник?

Окремо оцініть екрани входу, підтвердження операцій і відображення чутливих відомостей. Перевірте дотики під перекриттям і часткове перекриття: лише перевірки знімків екрана недостатньо. Потім перевірте той самий шлях зі справжньою програмою читання з екрана й допоміжним інструментом, щоб захист не порушував законного доступу.

У звіті про перевірку вкажіть версії Android і застосунку, тип служби, дозволи та дані, які справді були видимі. З обмеженого тесту не можна робити висновки про всі пристрої.

Межа шифрування месенджера

Модель загроз Livara виключає заражені або розблоковані пристрої з гарантії захисту вмісту. Тому назва алгоритму чи постквантовий обмін ключами не є захистом від усіх зловживань користувацьким інтерфейсом. Розглядайте захист шляху повідомлень, цілісність пристрою та контроль дозволів як три окремі перевірки.

Переглянути Proof Lab Livara
CONTINUE THE THREADAndroid & device security ↗
YOU’VE REACHED THE ENDBack to the reading room ↗