Как работает Android в Docker на разных операционных системах

:::info Авторы:

(1) Daniele Capone, SecSI srl, Неаполь, Италия ([email protected]);

(2) Francesco Caturano, Кафедра электротехники и информационных технологий, Университет Неаполя Федерико II, Неаполь, Италия ([email protected])

(3) Angelo Delicato, SecSI srl, Неаполь, Италия ([email protected]);

(4) Gaetano Perrone, Кафедра электротехники и информационных технологий, Университет Неаполя Федерико II, Неаполь, Италия ([email protected])

(5) Simon Pietro Romano, Кафедра электротехники и информационных технологий, Университет Неаполя Федерико II, Неаполь, Италия ([email protected]).

:::

Таблица ссылок

Аннотация и 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]. Это доказательство концепции (PoC) легко воспроизводится на Dockerized Android путем реализации инфраструктуры, состоящей из трех сервисов:

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

\ • 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, и получает удаленный доступ к устройству жертвы.

\

\ Сложный сценарий охватывает несколько угро