Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
На прошлой неделе в Таиланде прошла конференция Security Analyst Summit, организованная «Лабораторией Касперского». Одной из главных тем конференции стало исследование атаки, которая получила название «Операция Триангуляция». О ней стало известно в июне, когда эксперты «Лаборатории Касперского» сообщили об обнаружении сложной атаки на мобильные устройства Apple, принадлежащие сотрудникам компании.
В дополнение к презентации были также опубликованы два отчета: первый о —деталях расследования, второй — о работе двух вредоносных модулей. Подробно описанные этапы исследования вредоносной атаки, удачные и неудачные, представляют особый интерес.
Вкратце напомним основные параметры атаки, которую в «Лаборатории Касперского» назвали «Триангуляцией». В ходе данной кампании были заражены устройства Apple iPhone, принадлежащие нескольким сотрудникам компании. Заражение происходило через сообщения iMessage, причем уязвимость в iOS задействовалась без каких-либо действий со стороны пользователя, а следы полученного вредоносного сообщения позднее удалялись. Вредоносный код не переживает перезагрузку устройства и используется для шпионажа.
Первый сигнал о возможном заражении поступил от системы мониторинга сетевого трафика в корпоративной сети: от Kaspersky Unified Monitoring and Analysis Platform. Первым шагом после обнаружения подозрительной активности стал анализ сетевого трафика с зараженных устройств при помощи программы Wireshark. Уже на этом этапе удалось найти связь между действиями «обращение к серверу Apple для получения сообщения iMessage» и «обращение к командному серверу атакующих (на одном из нескольких доменов)». Но не более того: весь трафик, как с серверами Apple, так и с вредоносной инфраструктурой, был зашифрован.
Очевидным следующим этапом расследования стало бы создание полной цифровой копии всех данных на Apple iPhone. Но это было невозможно ввиду закрытой архитектуры ОС, а также использования актуальных тогда версий iOS 15 и 16. Для них на момент исследования не было доступного метода джейлбрейка, который дал бы прямой доступ к файловой системе. Пришлось довольствоваться бэкапами: этот метод был описан в предыдущих публикациях. Он позволяет вытащить из стандартной резервной копии iPhone временные метки различных событий, происходивших на телефоне. Так удалось обнаружить активность системной компоненты BackupAgent, которая считается устаревшей и в нормальной работе смартфона не задействована. Этот признак позволил создать для проверки любого смартфона на заражение таким же имплантом утилиту, известную как triangle_check.
Далее произошла неудачная попытка перехвата вредоносных сообщений, заражающих устройство. Так как имплант перестает работать после перезагрузки, телефоны заражались повторно. Для перехвата был подготовлен компьютер Mac Mini, на котором залогинились пострадавшие владельцы смартфонов. Это в теории позволяло получить на компьютере копию вредоносного сообщения, но по факту данная схема не сработала. Используя мониторинг сетевого трафика, исследователи зафиксировали заражение смартфона, но на компьютере при этом никакого сообщения не сохранилось.
В результате пришлось прибегнуть к традиционной тактике с установкой программы mitmproxy и перенаправлением всего трафика с iPhone через нее. Это не позволило расшифровать трафик с серверами Apple (так как там используется механизм SSL Pinning). Зато исследователи смогли расшифровать обмен данными с командным сервером. Именно это позволило извлечь два вредоносных модуля, выполняемых на устройстве и подробно описанных в отдельной статье. Код одного из модулей отвечал, в том числе, за удаление следов получения зараженного iMessage. Стало известно, что вредоносное вложение имеет расширение .watchface.
А затем удалось извлечь с серверов Apple и сам вложенный файл. Пересылка файлов в iMessage работает так. Файл шифруется на стороне отправителя и затем загружается на серверы iCloud. Ссылка на загруженный файл отправляется получателю вместе с ключом для расшифровки. В отличие от любого другого обмена данными с серверами Apple, по какой-то причине обмен с iCloud может быть проанализирован при помощи mitmproxy. Это позволило получить зашифрованную копию вредоносного вложения, но не ключ для расшифровки — он отправляется отдельно, по протоколу iMessage, и таким же методом получен быть не может. Исследователи сознательно внесли ошибку в данные, передаваемые в процессе получения зараженного вложения. Это оборвало процесс загрузки файла, но позволило сохранить ключ для расшифровки на устройстве. Ключ в дальнейшем был добыт из бэкапа iPhone.
Таким образом, исследователям «Лаборатории Касперского» удалось добыть код, применяемый на всех этапах атаки. На самом деле, это большое достижение, так происходит далеко не во всех случаях. Труднее всего дается получение вредоносного кода, ответственного за первоначальное заражение устройства. В данном случае исследователи смогли получить большой объем информации, не привлекая внимания атакующих, которые могли в любой момент уничтожить вредоносную инфраструктуру. Так как одной из функций вредоносного импланта было подслушивание, в процессе работы с зараженными устройствами приходилось соблюдать особую осторожность.
Что еще произошло
На прошлой неделе компания Apple выпустила патч, закрывающий одну из уязвимостей, связанных с «Триангуляцией». Патч предназначен для устройств, работающих на относительно старой версии — iOS 15. Ранее та же уязвимость в ядре была закрыта в iOS 16.
Еще одно большое исследование с конференции Security Analyst Summit посвящено атаке StripedFly. Данная вредоносная кампания много лет довольно успешно прикидывалась майнером криптовалют, но на самом деле ее функциональность была гораздо шире, и включала множество инструментов шпионажа.
В более свежем патче до iOS 17.1 закрыт интересный баг, связанный с системой анонимизации устройства при подключении к гостевым Wi-Fi-сетям. Данная функция была представлена в iOS 14 еще в 2020 году и предполагала замену реального MAC-адреса рандомизированным. Как выяснилось, эта фича работала наполовину: идентификатор сетевого устройства действительно менялся, но реальный адрес все равно присутствовал в рассылаемых пакетах multicast, хотя и в другом поле.
Исследователи из Высшей технической школы Цюриха опубликовали работу (новость, веб-сайт, оригинальный PDF), посвященную методам фаззинга процессоров. Благодаря предложенной методике удалось обнаружить множество аппаратных уязвимостей в открытой процессорной архитектуре RISC-V.
В дополнение к презентации были также опубликованы два отчета: первый о —деталях расследования, второй — о работе двух вредоносных модулей. Подробно описанные этапы исследования вредоносной атаки, удачные и неудачные, представляют особый интерес.
Вкратце напомним основные параметры атаки, которую в «Лаборатории Касперского» назвали «Триангуляцией». В ходе данной кампании были заражены устройства Apple iPhone, принадлежащие нескольким сотрудникам компании. Заражение происходило через сообщения iMessage, причем уязвимость в iOS задействовалась без каких-либо действий со стороны пользователя, а следы полученного вредоносного сообщения позднее удалялись. Вредоносный код не переживает перезагрузку устройства и используется для шпионажа.
Первый сигнал о возможном заражении поступил от системы мониторинга сетевого трафика в корпоративной сети: от Kaspersky Unified Monitoring and Analysis Platform. Первым шагом после обнаружения подозрительной активности стал анализ сетевого трафика с зараженных устройств при помощи программы Wireshark. Уже на этом этапе удалось найти связь между действиями «обращение к серверу Apple для получения сообщения iMessage» и «обращение к командному серверу атакующих (на одном из нескольких доменов)». Но не более того: весь трафик, как с серверами Apple, так и с вредоносной инфраструктурой, был зашифрован.
Очевидным следующим этапом расследования стало бы создание полной цифровой копии всех данных на Apple iPhone. Но это было невозможно ввиду закрытой архитектуры ОС, а также использования актуальных тогда версий iOS 15 и 16. Для них на момент исследования не было доступного метода джейлбрейка, который дал бы прямой доступ к файловой системе. Пришлось довольствоваться бэкапами: этот метод был описан в предыдущих публикациях. Он позволяет вытащить из стандартной резервной копии iPhone временные метки различных событий, происходивших на телефоне. Так удалось обнаружить активность системной компоненты BackupAgent, которая считается устаревшей и в нормальной работе смартфона не задействована. Этот признак позволил создать для проверки любого смартфона на заражение таким же имплантом утилиту, известную как triangle_check.
Далее произошла неудачная попытка перехвата вредоносных сообщений, заражающих устройство. Так как имплант перестает работать после перезагрузки, телефоны заражались повторно. Для перехвата был подготовлен компьютер Mac Mini, на котором залогинились пострадавшие владельцы смартфонов. Это в теории позволяло получить на компьютере копию вредоносного сообщения, но по факту данная схема не сработала. Используя мониторинг сетевого трафика, исследователи зафиксировали заражение смартфона, но на компьютере при этом никакого сообщения не сохранилось.
В результате пришлось прибегнуть к традиционной тактике с установкой программы mitmproxy и перенаправлением всего трафика с iPhone через нее. Это не позволило расшифровать трафик с серверами Apple (так как там используется механизм SSL Pinning). Зато исследователи смогли расшифровать обмен данными с командным сервером. Именно это позволило извлечь два вредоносных модуля, выполняемых на устройстве и подробно описанных в отдельной статье. Код одного из модулей отвечал, в том числе, за удаление следов получения зараженного iMessage. Стало известно, что вредоносное вложение имеет расширение .watchface.
А затем удалось извлечь с серверов Apple и сам вложенный файл. Пересылка файлов в iMessage работает так. Файл шифруется на стороне отправителя и затем загружается на серверы iCloud. Ссылка на загруженный файл отправляется получателю вместе с ключом для расшифровки. В отличие от любого другого обмена данными с серверами Apple, по какой-то причине обмен с iCloud может быть проанализирован при помощи mitmproxy. Это позволило получить зашифрованную копию вредоносного вложения, но не ключ для расшифровки — он отправляется отдельно, по протоколу iMessage, и таким же методом получен быть не может. Исследователи сознательно внесли ошибку в данные, передаваемые в процессе получения зараженного вложения. Это оборвало процесс загрузки файла, но позволило сохранить ключ для расшифровки на устройстве. Ключ в дальнейшем был добыт из бэкапа iPhone.
Таким образом, исследователям «Лаборатории Касперского» удалось добыть код, применяемый на всех этапах атаки. На самом деле, это большое достижение, так происходит далеко не во всех случаях. Труднее всего дается получение вредоносного кода, ответственного за первоначальное заражение устройства. В данном случае исследователи смогли получить большой объем информации, не привлекая внимания атакующих, которые могли в любой момент уничтожить вредоносную инфраструктуру. Так как одной из функций вредоносного импланта было подслушивание, в процессе работы с зараженными устройствами приходилось соблюдать особую осторожность.
Что еще произошло
На прошлой неделе компания Apple выпустила патч, закрывающий одну из уязвимостей, связанных с «Триангуляцией». Патч предназначен для устройств, работающих на относительно старой версии — iOS 15. Ранее та же уязвимость в ядре была закрыта в iOS 16.
Еще одно большое исследование с конференции Security Analyst Summit посвящено атаке StripedFly. Данная вредоносная кампания много лет довольно успешно прикидывалась майнером криптовалют, но на самом деле ее функциональность была гораздо шире, и включала множество инструментов шпионажа.
В более свежем патче до iOS 17.1 закрыт интересный баг, связанный с системой анонимизации устройства при подключении к гостевым Wi-Fi-сетям. Данная функция была представлена в iOS 14 еще в 2020 году и предполагала замену реального MAC-адреса рандомизированным. Как выяснилось, эта фича работала наполовину: идентификатор сетевого устройства действительно менялся, но реальный адрес все равно присутствовал в рассылаемых пакетах multicast, хотя и в другом поле.
Исследователи из Высшей технической школы Цюриха опубликовали работу (новость, веб-сайт, оригинальный PDF), посвященную методам фаззинга процессоров. Благодаря предложенной методике удалось обнаружить множество аппаратных уязвимостей в открытой процессорной архитектуре RISC-V.
