«Лаборатория Касперского» опубликовала новый отчет о малвари, которая использовалась в рамках кампании «Операция Триангуляция» (Operation Triangulation). На этот раз исследователи уделили внимание скрытности и инструментам, с помощью которых хакеры ее достигали, а также разобрали активность импланта после компрометации.
Предыстория
Напомним, что в начале июня текущего года ФСБ и ФСО России сообщили о «разведывательной акции американских спецслужб, проведенной с использованием мобильных устройств фирмы Apple». Вскоре после этого «Лаборатория Касперского» опубликовала развернутый отчет о целевых атаках, направленных на устройства, работающие под управлением iOS.
Эта кампания получила название «Операция Триангуляция» (Operation Triangulation) и, по данным исследователей, целью выявленных атак было «незаметное внедрение шпионского модуля в iPhone сотрудников компании — как топ-менеджмента, так и руководителей среднего звена». В компании сообщали, что эти атаки начались еще в 2019 году.
Вскоре после этого эксперты опубликовали бесплатную утилиту triangle_check, которая позволяет найти следы заражения в резервной копии устройства Apple. Затем они обнародовали и детальный отчет о малвари TriangleDB, написанной на Objective-C, и рассказали, что имплант загружался на устройства после того, как атакующие получали root-права в результате успешной эксплуатации уязвимости в ядре iOS.
После этого компания Apple выпустила патчи для двух уязвимостей нулевого дня (CVE-2023-32434 и CVE-2023-32435), которые использовались для атак на пользователей iOS. Баги, позволяли атаковать iPhone с помощью zero-click эксплоитов для iMessage.
Затем появились новые исправления, связанные с этой вредоносной кампанией. В частности, в WebKit была устранена уязвимость CVE-2023-37450 и еще одна 0-day проблема, CVE-2023-38606, которая представляла собой уязвимость ядра и использовалась в атаках, нацеленных на устройства с более старыми версиями iOS на борту.
Новый анализ
В предыдущих постах исследователи описали цепочку заражения «Операции Триангуляция»: на устройство приходит вредоносное сообщение iMessage, которое запускает выполнение цепочки эксплоитов, в конечном итоге приводящее к загрузке вредоноса TriangleDB. Более наглядно эта цепочка показана на схеме ниже.
Помимо эксплоитов и компонентов TriangleDB в цепочку входят два «валидатора», а именно, валидатор, написанный на JavaScript, и бинарный валидатор. Они собирают и отправляют на управляющий сервер различную информацию об устройстве жертвы, которая затем используется в том числе для того, чтобы убедиться, что iPhone или iPad, на который собираются загрузить TriangleDB, не является исследовательским устройством. Это помогает злоумышленникам не выдать свои эксплоиты и имплант.
JavaScript-валидатор проводит множество различных проверок на устройстве жертвы, в том числе записывает результаты арифметических операций, таких как Math.log(-1) или Math.sqrt(-1), и проверяет доступность таких компонентов, как Media Source API, WebAssembly и так далее.
Также этот валидатор собирает данные об устройстве при помощи технологии Canvas Fingerprinting: рисует желтый треугольник при помощи WebGL и вычисляет его контрольную сумму. Именно из-за этого треугольника эксперты и назвали всю кампанию «Триангуляцией».
После завершения всех проверок, валидатор шифрует собранную информацию и отправляет ее на уникальный адрес на домене backuprabbit[.]com, чтобы в ответ получить (или не получить) следующую стадию цепочки заражения.
Бинарный валидатор запускается непосредственно перед загрузкой TriangleDB. Если JavaScript-валидатор — это скрипт, то этот валидатор представляет собой бинарный файл Mach-O. После запуска он расшифровывает конфигурацию (файл plist) при помощи алгоритма AES.
Файл конфигурации содержит список действий (например, DeleteLogs, DeleteArtifacts), которые должен выполнить валидатор. В частности, он:
- удаляет из директории /private/var/mobile/Library/Logs/CrashReporter записи о сбоях, появившиеся в процессе эксплуатации;
- ищет следы вредоносного сообщения iMessage в различных базах данных, таких как ids-pub-id.db и knowledgeC.db, и удаляет их. Для этого в конфигурации валидатора содержатся 40 MD5-хэшей различных Apple ID, которые использовались для отправки iMessage. Эксперты смогли взломать большую часть этих хэшей и получить список email-адресов Apple ID, используемых злоумышленниками;
- получает список запущенных на устройстве процессов и сетевых интерфейсов;
- проверяет устройство на наличие джейлбрейка. В валидаторе предусмотрены проверки на использование большого списка инструментов для джейлбрейка, в том числе Pangu, xCon, Evasion7, Electra, unc0ver, checkra1n и других;
- включает отслеживание персонализированной рекламы;
- собирает множество данных о жертве, таких как имя пользователя, номер телефона, IMEI и Apple ID;
- извлекает список установленных приложений.
При этом все перечисленные действия в валидаторе прописаны как для iOS, так и для macOS.
Также в этом валидаторе было обнаружено неиспользуемое действие, которое злоумышленники назвали PSPDetect. Это действие извлекает список файлов из конфигурации валидатора (в проанализированных конфигурациях он был пустым), проверяет их присутствие в файловой системе и составляет список обнаруженных файлов.
Сокращение PSP в данном случае может означать personal security product («персональный защитный продукт») или, проще, «защитное решение». Соответственно, предполагается, это действие используется для обнаружения установленных защитных решений на устройствах с macOS.
После выполнения всех действий бинарный валидатор шифрует собранные данные (список процессов, информацию о пользователе и прочее) и отправляет их на управляющий сервер. В ответ сервер возвращает вредонос TriangleDB.
Аналитики пишут, что за скрытность в этой операции отвечали не только валидаторы. Также экспертов заинтересовали команды, которые атакующие отправляют на зараженное устройство через имплант.
Так, после успешного выполнения всех эксплоитов и запуска TriangleDB, вредонос отправляет командному серверу сигнальное сообщение. После установления связи он получает несколько команд CRXShowTables и CRXFetchRecord. Они связаны с поиском логов, в которых могут оставаться следы цепочки заражения и (или) самой малвари. В частности, извлекаются следующие файлы:
- файлы журнала сбоев (например, из папки /var/mobile/Library/Logs/CrashReporter);
- файлы баз данных (например, /private/var/mobile/Library/IdentityServices/ids-gossip.db), связанные со входящими сообщениями iMessages.
Заполучив эти файлы, злоумышленники удаляют их с устройства, чтобы жертва не могла найти в них потенциальные следы компрометации.
Что касается модулей малвари, один из самых опасных исследователи называют модуль записи с микрофона под названием msu3h (предполагается, что 3h означает три часа — продолжительность записи по умолчанию). После запуска он расшифровывает свою конфигурацию с помощью кастомного алгоритма (вариация хэширования из GTA IV), но дальнейшие операции выполняются только при заряде батареи не менее 10%.
Помимо ожидаемых параметров, таких как длительность записи и AES-ключ для шифрования записей, файл конфигурации содержит настройки более изощренных функций, например:
- suspendOnDeviceInUse — определяет, будет ли останавливаться запись при включении экрана устройства;
- syslogRelayOverride — определяет, нужно ли записывать звук при захвате системных логов.
Звуковые фрагменты записываются с помощью API Audio Queue и сжимаются кодеком Speex, а затем подвергаются AES-шифрованию.
Также в отчете компании приведен анализ модулей для кражи данных SQLite, эксфильтрации Keychain и мониторинга местоположения жертвы.
В заключение специалисты отмечают, что хакеры, стоящие за «Операцией Триангуляция», продемонстрировали глубокое понимание внутренних особенностей iOS, использовали недокументированные приватные API в ходе атаки и реализовали в некоторых модулях поддержку версий iOS, предшествующих 8.0. То есть модули могли использоваться очень давно.
По словам экспертов, компоненты цепочки заражения содержат код, который может указывать на то, что атаки нацелены не только на iOS, но и на macOS, хотя на момент публикации следов этой малвари на устройствах под управлением macOS пока обнаружено не было.
