Как поймать «Триангуляцию»

В начале 2023 года благодаря SIEM-системе Kaspersky Unified Monitoring and Analysis Platform (KUMA) мы обратили внимание на подозрительную сетевую активность, которая оказалась частью атаки на iPhone и iPad наших коллег. Как только мы поняли, что в подключениях прослеживается четкая закономерность и что устройства могут быть заражены, мы инициировали стандартный протокол мероприятий по цифровой криминалистике и реагированию на инциденты (DFIR) — прошлись по офису, собрали устройства и изучили их содержимое. Нашей конечной целью было обнаружить и извлечь зловред, найти точку входа (если повезет, это будет уязвимость нулевого дня) и разработать метод сканирования устройств Apple на предмет активного заражения. Этот процесс растянулся на несколько месяцев, и в данной статье мы хотели бы описать его целиком.

Первые шаги

Как мы уже упоминали в самой первой статье цикла «Операция Триангуляция», зараженные устройства, о которых нам было первоначально известно, принадлежали сотрудникам центрального офиса «Лаборатории Касперского» в Москве. Все эти устройства были подключены к корпоративной сети Wi-Fi, что позволило нам регистрировать и анализировать сетевой трафик. В результате анализа, проведенного с помощью Wireshark, мы обнаружили следующее.

• Перед тем как начать вести себя подозрительно, устройства подключались к серверам iMessage, отвечающим за получение сообщений и загрузку вложений.
• После загрузки нескольких килобайтов данных, которые могли быть вложением, устройства устанавливали соединение с сервером backuprabbit[.]com и меньше минуты обменивались с ним данными.
• Далее устройства устанавливали более длительное соединение с одним из следующих серверов:
  • cloudsponcer[.]com
  • snoweeanalytics[.]com
  • topographyupdates[.]com
  • unlimitedteacup[.]com
  • virtuallaughing[.]com
• После перезагрузки устройства вся подозрительная активность прекращалась.

К нашему сожалению, все соединения с указанными серверами осуществлялись по протоколу HTTPS, поэтому мы не смогли извлечь из трафика никаких дополнительных сведений.

Создание образов устройств

Поскольку все устройства находились от нас буквально на расстоянии вытянутой руки, мы решили изучить все их содержимое. К сожалению, этот путь оказался тупиковым: доступные на тот момент утилиты для сбора криминалистических данных основывались на checkra1n и аналогичных эксплойтах, несовместимых с современными процессорами под управлением iOS 15 и 16.

Изучение резервных копий

Вместо полных образов устройств мы решили воспользоваться резервными копиями iTunes. Их нужно было получить незаметно, чтобы не спугнуть атакующих, чьих возможностей мы на тот момент наверняка не знали, поэтому исходили из того, что злоумышленники могли прослушивать микрофоны устройств и читать сообщения в мессенджерах и электронной почте. Для конспирации мы проводили очные встречи, предварительно переведя телефоны в авиарежим или поместив в экранирующие пакеты Фарадея. В получении резервных копий нам помог отличный инструментарий libimobiledevice. Когда они были готовы, мы проанализировали данные и восстановили хронологию событий с помощью Mobile Verification Toolkit.

Полученная хронология объединяла записи, извлеченные из различных системных баз данных с временными метками файловой системы. Мы сосредоточили свое внимание на директориях iMessage, ведь именно там в 2021 году исследователи Citizen Lab обнаружили печально известный эксплойт FORCEDENTRY. Мы надеялись, что наш анализ окажется столь же плодотворным, однако злоумышленники, стоящие за «Операцией Триангуляция», оказались весьма скрытными и не оставили никаких признаков эксплойтов в резервной копии. Мы также проверили ее на наличие исполняемых файлов вредоносного ПО, однако и их не нашли.

Оставались временные метки подозрительной сетевой активности. Мы принялись искать повторяющиеся события, произошедшие примерно в это время. В результате мы обнаружили то, что очень напоминало новый индикатор компрометации: записи об использовании данных, связанные с системным процессом BackupAgent, — этот файл устарел еще много лет назад и вообще не должен был запускаться.

Этот фрагмент логов устройства с необычной активностью процесса BackupAgent мы уже показывали в первой статье цикла «Операция Триангуляция»

На основе этой аномалии мы написали первую версию нашей утилиты triangle_check. Она позволила нам быстро проверять резервные копии устройств на наличие следов потенциальной компрометации.

Попытка перехвата вредоносного сообщения iMessage

При более детальном изучении хронологии событий мы обнаружили второй слабый индикатор компрометации: запись об одной или нескольких модификациях пустой директории SMS-вложений перед записью об использовании данных процессом BackupAgent. Если в измененной директории нет никаких файлов, как правило, это означает, что последней операцией было удаление файла: поступило сообщение с вложением, затем оно было удалено, а через несколько секунд процесс BackupAgent инициировал подозрительную сетевую активность.

Так как злоумышленники, стоящие за «Операцией Триангуляция», действовали предусмотрительно и удаляли вредоносные вложения с зараженных устройств, мы решили попробовать перехватить входящее сообщение в процессе доставки iMessage. В поисках способа перехвата сообщений iMessage мы наткнулись на этот скрипт Frida, разработанный командой Google Project Zero. Он был предназначен для компьютеров Mac, поэтому мы воспользовались имеющимся у нас Mac mini и установили Frida на него. Затем мы попросили нескольких зараженных коллег войти в систему на этом Mac mini под своими идентификаторами Apple ID. Таким образом мы получили возможность отслеживать и перехватывать получаемые ими сообщения iMessage. Теперь оставалось только ждать, когда злоумышленники в очередной раз заразят устройство одного из них.

В то же время мы активно отслеживали логи SIEM на предмет подозрительной активности. Довольно скоро мы обнаружили знакомые сетевые подключения, свидетельствующие об успешной компрометации телефона с «клонированной» учетной записью iMessage. Однако при проверке логов перехвата iMessage на Mac mini мы не обнаружили следов сообщений в момент заражения. Таким образом, нашей системе не удалось перехватить сообщение с эксплойтом (мы до сих пор не знаем, почему это не сработало), и мы стали искать другие способы перехвата вредоносного ПО.

Старая добрая атака MITM

После того как план перехвата сообщений iMessage с помощью устройства Mac провалился, мы решили попробовать расшифровать обмен данными с командными серверами по протоколу HTTPS, выявленными ранее в результате анализа трафика.

Для этого мы:

• настроили сервер под управлением Linux и установили на него mitmproxy, инструмент для перехвата трафика HTTPS;
• установили корневой сертификат SSL (предварительно сгенерированный нами с помощью mitmproxy) на несколько ранее скомпрометированных iOS-устройств;
• установили на эти устройства VPN-клиент Wireguard, указав в качестве VPN-сервера наш экземпляр mitmproxy.

Мы также написали бот для Telegram, который уведомлял о заражении одного из контролируемых устройств:

К сожалению, этим методом мы не смогли перехватить HTTPS-трафик сервисов Apple (в том числе iMessage), поскольку в iOS на этот случай предусмотрен механизм закрепления сертификата SSL (SSL pinning). Как следствие, нам не удалось расшифровать трафик iMessage, проходивший через VPN.

Обнаружение JavaScript-валидатора

Как только злоумышленники повторно заразили одну из жертв, мы заглянули в логи mitmproxy и заметили, что тому удалось расшифровать трафик с командного сервера:

Мы полагали, что перехваченная нами полезная нагрузка будет эксплойтом для iOS. Однако это был JavaScript-валидатор, который просто собирал информацию о браузере жертвы и отправлял ее на командный сервер.

Мы заметили, что зараженное устройство получило полезную нагрузку в ответ на информацию о проверке, отправленную на командный сервер. Однако перехваченный HTTPS-трафик расшифровать не удалось. Дело в том, что JS-валидатор имеет собственный слой шифрования для обмена данными с командным сервером, основанный на библиотеке NaCl. При этом используется криптографический алгоритм с открытым ключом. В частности, для связи с командным сервером JS-валидатор:

• генерирует случайную пару ключей (состоящую из закрытого и открытого ключей);
• формирует общий ключ на основе сгенерированного закрытого ключа и открытого ключа командного сервера;
• использует этот общий ключ для шифрования сообщений, отправляемых на командный сервер, и расшифровки сообщений, полученных от него.

Генерация ключей

Для расшифровки сообщений командного сервера необходимо знать закрытый ключ, сгенерированный случайным образом JS-валидатором. Однако этот ключ хранится в памяти и не передается на командный сервер. Поэтому нам пришлось проделать дополнительную работу по расшифровке трафика валидатора.

Как видно из скриншота выше, JS-валидатор генерирует случайную пару ключей, вызывая метод nacl.box.keyPair(). Для расшифровки трафика мы решили скомпрометировать этот процесс. Мы написали небольшое дополнение к mitmproxy, которое обнаруживает вызовы метода nacl.box.keyPair() и заменяет их другим методом, nacl.box.keyPair.fromSecretKey(), инициализирующим пару ключей на основе предоставленного закрытого ключа.

Как видно из скриншота выше, мы прописали закрытый ключ в аргументах этого метода, тем самым создав бэкдор в схеме шифрования валидатора. После выполнения на зараженном устройстве валидатора с бэкдором у нас появилась возможность расшифровать все операции обмена данными JS-валидатора.

Бинарный валидатор и подсказка о вложении

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

Как мы уже рассказывали в статье, посвященной скрытности кампании «Операция Триангуляция», бинарный валидатор содержит функцию, удаляющую следы вредоносного сообщения iMessage. Мы обнаружили, что эта функция выполняет следующий SQL-запрос к базе данных SMS.db:

Условие uti == «com.apple.watchface» дало нам еще одну подсказку: теперь стало ясно, что вредоносное вложение представляет собой файл .watchface. Вооружившись этими новыми знаниями, мы спланировали и осуществили следующую попытку получения этого вложения.

Изучение iMessage

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

1. Отправитель генерирует случайный ключ AES и шифрует им вложение.
2. Зашифрованное вложение выгружается в iCloud.
3. Ссылка iCloud на зашифрованное вложение отправляется получателю вместе с ключом AES, который дополнительно шифруется с помощью открытого RSA-ключа устройства.

Таким образом, для получения файла вредоносного вложения нам потребовалось извлечь два компонента:

• зашифрованный текст вложения;
• ключ AES, используемый для шифрования.

Получить зашифрованный текст вложения оказалось несложно — достаточно было перехватить трафик к серверам iCloud через mitmproxy. Выше мы писали о том, что iOS не позволяет расшифровывать HTTPS-трафик сервисов Apple. Однако ссылки на вложения в iCloud оказались исключением из этого правила.

При этом процесс получения ключа AES оказался довольно сложным. Ключ отправляется по протоколу iMessage и поэтому не может быть перехвачен через mitmproxy. Но мы нашли способ восстановить вложение и извлечь этот ключ, имея физический доступ к атакуемому устройству: мы помешали iMessage успешно загрузить вложение по ссылке iCloud, чтобы эксплойт не смог отработать и затем удалить вложение, при этом ключ шифрования AES сохранился в базе данных SMS.db.

Чтобы достичь этого результата, мы изменили несколько байт в зашифрованном тексте вложения с помощью нашего дополнения для mitmproxy. Тем самым мы нарушили процесс загрузки зашифрованного текста вложения, тогда как ключ сохранился в базе данных SMS.db. Затем мы загрузили резервную копию iTunes с зараженного устройства и извлекли ключ из содержащейся в ней базы данных. В результате мы смогли получить вредоносное вложение .watchface, отправленное злоумышленниками, — оно и было началом цепочки эксплойтов, призванных скомпрометировать устройства.

Получение импланта

После получения эксплойтов злоумышленников нам оставалось только раздобыть сам имплант. За скачивание импланта с командного сервера и его активацию отвечает бинарный валидатор, при этом для обмена данными используется комбинация алгоритмов шифрования RSA и AES. Опять же, применение RSA означает, что невозможно расшифровать полезную нагрузку, располагая только зашифрованным трафиком.

Для связи с командным сервером бинарный валидатор:

• генерирует случайный ключ AES;
• шифрует сгенерированный AES-ключ открытым ключом RSA сервера, указанным в конфигурации валидатора;
• шифрует сообщение, отправляемое на командный сервер, с помощью сгенерированного ключа AES;
• отправляет зашифрованное сообщение на командный сервер и получает от него ответ;
• расшифровывает ответ тем же ключом AES, которым было зашифровано отправленное сообщение.

Валидатор шифрует все пакеты с помощью следующих инструкций ARM:

В этом коде сначала выполняется функция serialized_plist, которая подготавливает данные к отправке. После ее выполнения в регистр X0 помещается указатель на данные, готовые к отправке на сервер.

Затем вызывается функция encryptData. Она принимает два аргумента: в регистр X0 передается указатель на шифруемые данные, а регистр X1 содержит plist с конфигурационными данными, включая параметры шифрования. После выполнения этой функции в регистр X0 помещается указатель на зашифрованный текст.

Для перехвата данных с зараженного устройства нам вновь потребовалось вмешаться в процесс шифрования. Мы решили заменить вызов функции encryptData инструкцией NOP (1f 20 03 d5). В этом случае значение регистра X0 не будет перезаписано указателем на зашифрованные данные, и валидатор будет отправлять на наш VPN-сервер данные в чистом виде.

Как и в случае с JavaScript-валидатором, мы правили код на лету, предварительно доработав наше дополнение для mitmproxy:

Фрагмент кода дополнения для mitmproxy, который подменяет вызов функции encryptData на NOP

Когда незашифрованные данные поступили на наш VPN-сервер, мы (опять же с помощью дополнения для mitmproxy) имитировали обмен ключами и шифрование данных и получили возможность контролировать значение ключа шифрования. В результате мы успешно расшифровали данные, отправленные командным сервером, и извлекли тело импланта.

Получение модулей

Анализ импланта TriangleDB показал, что тот способен загружать дополнительные модули. И нам очень захотелось заполучить бинарные файлы этих модулей. В статье про имплант мы писали, что исполняемые файлы модулей передаются зловреду посредством команд CRXUpdateRecord и CRXUpdateRunRecord. Таким образом, для получения этих исполняемых файлов нужно было расшифровать все команды, отправленные на командный сервер.

Алгоритм шифрования и в этом случае был основан на RSA, поэтому мы предприняли те же действия, что и при получении бинарных файлов импланта.

Однако на этот раз мы решили:

• сгенерировать собственную пару ключей RSA;
• заменить открытый ключ RSA из конфигурации импланта на сгенерированный нами.

Для этого мы добавили следующий код в наше дополнение для mitmproxy:

Когда трафик импланта достиг нашего VPN-сервера, мы:

• расшифровали его с помощью сгенерированного нами закрытого ключа RSA;
• сохранили расшифрованный трафик;
• повторно зашифровали трафик с помощью открытого ключа, использованного злоумышленниками.

Это позволило нам прослушивать все соединения, осуществляемые имплантом, а также получить бинарные файлы модулей.

Заключение

Наше расследование кампании «Операция Триангуляция» заняло несколько месяцев. Несмотря на то, что не все наши действия имели успех, нам удалось выявить все стадии этой атаки, в том числе: четыре эксплойта нулевого дня, о которых мы доложили компании Apple; два валидатора; имплант и его модули.

Попутно мы изучили внутреннее устройство iOS и освоили множество интересных приемов, например технику извлечения вложений iMessage.

Большинство проблем в нашем расследовании было вызвано шифрованием с открытым ключом, которое использовалось практически на всех этапах цепочки заражения. Для обхода шифрования пришлось написать дополнение для mitmproxy, которое на лету вносило исправления во вредоносный код и компрометировало исходные алгоритмы. Код первого варианта нашей утилиты насчитывал всего 30 строк. Когда мы закончили извлекать модули, в нем уже было около 400 строк. В начале нашей работы мы совершенно не предполагали, что код дополнения настолько разрастется!