Як працює контейнеризований Android у різних операційних системах

:::info Автори:

(1) Daniele Capone, SecSI srl, Неаполь, Італія (daniele.capone@secsi.io);

(2) Francesco Caturano, Кафедра електротехніки та інформаційних технологій, Університет Неаполя Федеріко II, Неаполь, Італія (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, Неаполь, Італія (angelo.delicato@secsi.io);

(4) Gaetano Perrone, Кафедра електротехніки та інформаційних технологій, Університет Неаполя Федеріко II, Неаполь, Італія (gaetano.perrone@unina.it)

(5) Simon Pietro Romano, Кафедра електротехніки та інформаційних технологій, Університет Неаполя Федеріко II, Неаполь, Італія (spromano@unina.it).

:::

Таблиця посилань

Анотація та I. Вступ

II. Пов'язані роботи

III. Dockerized Android: Дизайн

IV. Архітектура Dockerized Android

V. Оцінка

VI. Висновок та майбутні розробки, та посилання

V. ОЦІНКА

Цей розділ оцінює платформу Dockerized Android, розглядаючи кілька аспектів. По-перше, ми підкреслюємо відмінності між компонентами Core для емулятора та Core для реального пристрою з точки зору функцій та висвітлюємо сумісність з трьома найбільш використовуваними операційними системами. Потім ми надаємо практичні приклади використання Dockerized Android та обговорюємо покриття вимог, визначених у розділі III.

\

\ A. Відмінності між Core для емулятора та Core для реального пристрою

\ Навіть якщо було докладено значних зусиль для створення системи, яка має однакові функції для обох типів пристроїв, існують обмеження при використанні емуляції:

\ • Функція відправки/отримання SMS через ADB: в емульованих пристроях можливо автоматизувати відправку та отримання SMS-повідомлень через програмне забезпечення ADB. Очевидно, це неможливо нативно для реальних пристроїв. Тому користувач повинен вручну відправляти та отримувати SMS-повідомлення для реалізації сценаріїв атак через SMS. Рішенням цієї проблеми може бути створення спеціального застосунку для Android, який можна встановити на реальний пристрій і який можна налаштувати для автоматичного відправлення та отримання повідомлень.

\ • Мережа: мережа досить відрізняється між версіями для емулятора та реального пристрою. У версії для емулятора AVD створюється всередині Docker-контейнера, і тому він використовує IP-адресу контейнера. Натомість реальний пристрій фізично підключений до машини, яка запускає контейнер, і зберігає власну IP-адресу.

\ • Апаратна віртуалізація: для апаратних компонентів ситуація також досить відрізняється: деякі апаратні пристрої, такі як GPS та мікрофон, можуть бути емульовані. Зокрема, місцезнаходження GPS пристрою можна встановити через ADB, а мікрофон хост-машини можна спільно використовувати з емулятором. Є інші апаратні компоненти, які наразі не можуть бути емульовані, наприклад, Bluetooth.

\ B. Оцінка хоста для кросплатформної сумісності

\ Нефункціональна вимога NF04 (Кросплатформна сумісність) вказує, що отримана система повинна бути придатною для використання з будь-якої хост-ОС. Це стосується ОС машини, яка запускає Docker-контейнери. Таблиця III надає огляд сумісності з Linux, Windows та OS X.

\

\ Проблема з Windows полягає в тому, що наразі найкращий спосіб використання Docker - через фреймворк Windows Subsystem for Linux (WSL). На жаль, WSL ще не підтримує вкладену віртуалізацію, а ця функція необхідна для запуску емулятора Android всередині Docker-контейнера. Однак ця функція буде доступна в майбутніх випусках WSL. Можливо, запустити Core для емулятора на Windows, використовуючи віртуальну машину, хоча це призведе до втрати всіх переваг продуктивності, пов'язаних з контейнеризацією. Подібна проблема існує з OS X, з якою наразі немає способу запустити Core для емулятора. Крім того, OS X не дозволяє спільно використовувати USB-пристрій з Docker-контейнером. З цієї причини єдиними способами використання Core для реального пристрою є або запуск ADB через Wi-Fi, або підключення до хост-ADB з Docker-контейнера.

\ У решті цього розділу ми показуємо ефективність Dockerized Android у відтворенні ланцюгів атак безпеки, використовуючи як Core для емулятора, так і Core для реального пристрою.

\ C. Відтворення атаки безпеки на емуляторі

\ Тут ми зосереджуємося на прикладі сценарію вразливості, пов'язаному з CVE-2018-7661[1]. Ця CVE пов'язана з безкоштовною версією застосунку "Wi-Fi Baby Monitor". Цей застосунок має бути встановлений на двох пристроях, щоб діяти як так званий дитячий монітор (радіосистема, яка використовується для віддаленого прослуховування звуків, що видаються немовлям). Як повідомляється в Національній базі даних вразливостей, "Wi-Fi Baby Monitor Free & Lite" до версії 2.02.2 дозволяє віддаленим зловмисникам отримувати аудіодані через певні специфічні запити до TCP-портів 8258 та 8257".

\

\ Преміум-версія цього застосунку пропонує користувачам можливість вказати пароль для використання в процесі з'єднання. Спостерігаючи за мережевим трафіком, можна помітити, що:

\ • початкове з'єднання відбувається на порту 8257;

\ • для початку процесу з'єднання завжди надсилається одна й та сама послідовність;

\ • наприкінці процесу з'єднання на порту 8258 починається нове з'єднання. Цей порт використовується для передачі аудіоданих;

\ • після підключення до порту 8258 інше з'єднання на порту 8257 залишається відкритим і використовується як heartbeat для сесії;

\ • на з'єднанні heartbeat клієнт періодично надсилає шістнадцятковий байт 0x01 (приблизно раз на секунду);

\ Доказ концепції, який дозволяє зловмиснику отримати аудіодані, наведено в [21]. Цей Proof of Concept (PoC) легко відтворюється на Dockerized Android через реалізацію інфраструктури, що складається з трьох сервісів:

\ • core-emulator: екземпляр компонента Core з попередньо встановленим застосунком Baby Monitor, що діє як відправник;

\ • ui: компонент UI для контролю того, що відбувається;

\ • attacker: налаштована версія Kali Linux, яка автоматично встановлює всі залежності, необхідні для виконання PoC.

\ Це також ідеальний приклад для демонстрації функції Port Forwarding, яка використовується для забезпечення комунікацій.

\ D. Відтворення атаки безпеки на реальному пристрої

\ З реальним пристроєм ми розглядаємо ще одну вразливість, відому як BlueBorne. Термін "BlueBorne" відноситься до кількох вразливостей безпеки, пов'язаних з реалізацією Bluetooth. Ці вразливості були виявлені групою дослідників з Armis Security, компанії з безпеки IoT, у вересні 2017 року. За даними Armis, на момент виявлення близько 8,2 мільярда пристроїв потенційно були вразливі до вектора атаки BlueBorne, який впливає на реалізації Bluetooth в Android, iOS, Microsoft та Linux, тим самим впливаючи майже на всі типи пристроїв Bluetooth, такі як смартфони, ноутбуки та смарт-годинники. BlueBorne був детально проаналізований у статті, опублікованій 12 вересня 2017 року Беном Сері та Грегором Вішнепольським [22]. Вісім різних вразливостей можуть бути використані як частина вектора атаки.

\ Щодо Android, всі пристрої та версії (тобто версії старші за Android Oreo, який був випущений у грудні 2017 року) вразливі до вищезгаданих вразливостей, за винятком пристроїв, які підтримують BLE (Bluetooth Low Energy). Загалом, для експлуатації вразливості повинні бути виконані дві вимоги: (i) цільовий пристрій повинен мати увімкнений Bluetooth; (ii) зловмисник повинен бути достатньо близько до цільового пристрою. Оскільки функція Bluetooth недоступна в Core Emulator, ланцюг атаки може бути відтворений лише на реальних пристроях.

\ 1) Повне відтворення BlueBorne на Dockerized Android: Щоб показати ефективність Dockerized Android, ми розробили ланцюг атаки, який використовує дві вразливості віддаленого виконання коду (RCE), що впливають на Android, а саме CVE-2017-0781 та CVE-2017-0782. Ці вразливості входять до набору вразливостей Bluetooth, визначеного як "BlueBorne" і виявленого групою дослідників безпеки з Armis Security [23].

\ Діаграма на рис. 4 дає огляд розробленого ланцюга атаки:

\

1. Зловмисник створює фішинговий електронний лист через Gophish, програмне забезпечення для генерації фішингу.

\ 2) Фішинговий електронний лист надсилається на поштову скриньку жертви.

\ 3) Жертва читає фішинговий електронний лист і помилково натискає на шкідливе посилання, що міститься в тілі листа.

\ 4) Шкідливе посилання дозволяє зловмиснику запустити атаку, яка завантажує та встановлює підроблений застосунок на мобільний пристрій жертви.

\ 5) Шкідлива інформація надсилає відповідну інформацію про мобільний пристрій зловмиснику. Ця інформація необхідна для експлуатації двох вразливостей.

\ 6) Зловмисник створює шкідливе навантаження для експлуатації вразливостей.

\ 7) Зловмисник надсилає атаку, використовуючи вразливості компонента Bluetooth, і отримує віддалений доступ до пристрою жертви.

\