Введение
В предыдущем посте о «Триангуляции» мы рассказывали о TriangleDB, основном импланте этой кампании, его протоколе связи с командным сервером и командах, которые он может получать. В частности, мы упоминали, что он также поддерживает загрузку дополнительных модулей. Кроме того, мы с самого начала отмечали, что вся операция отличается особой скрытностью. В этот раз мы подробнее расскажем об этом важном аспекте атаки — скрытности и инструментах, с помощью которых злоумышленники ее достигали, а также разберем активность импланта после компрометации и несколько компонентов, использованных в цепочке заражения, которые нам удалось получить и проанализировать.
Компоненты валидации
В предыдущих постах мы описали цепочку заражения операции «Триангуляция»: на устройство приходит вредоносное сообщение iMessage, которое запускает выполнение цепочки эксплойтов, в конечном итоге приводящее к загрузке импланта TriangleDB. Более наглядно эта цепочка показана на схеме ниже.
Помимо эксплойтов и компонентов TriangleDB в нее входят два «валидатора», а именно, валидатор, написанный на JavaScript, и бинарный валидатор. Они собирают и отправляют на командный сервер различную информацию об устройстве жертвы, которая затем используется в том числе для того, чтобы убедиться, что iPhone или iPad, на который собираются загрузить TriangleDB, не является исследовательским устройством. Это помогает злоумышленникам не выдать свои эксплойты и имплант.
JavaScript-валидатор
Цепочка заражения начинается с того, что пользователь получает iMessage с невидимым вложением, содержащим эксплойт, не требующий взаимодействия с пользователем. Конечная цель этого эксплойта — незаметно открыть HTML-страницу, расположенную по уникальному URL-адресу на домене backuprabbit[.]com. На этой странице находится обфусцированный JavaScript-код криптографической библиотеки NaCl и зашифрованная полезная нагрузка — JavaScript-валидатор. Он проводит множество различных проверок, в том числе записывает результаты арифметических операций, таких как Math.log(-1) или Math.sqrt(-1), и проверяет доступность таких компонентов, как Media Source API, WebAssembly и т. д.
Кроме того, как мы уже упоминали ранее, валидатор собирает данные об устройстве при помощи технологии Canvas Fingerprinting: рисует желтый треугольник при помощи WebGL и вычисляет его контрольную сумму. Именно из-за этого треугольника мы назвали всю кампанию «Триангуляцией».
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
context.bufferData(context.ELEMENT_ARRAY_BUFFER, l, context.STATIC_DRAW); context.useProgram(C); context.clearColor(0.5, 0.7, 0.2, 0.25); context.clear(context.COLOR_BUFFER_BIT); context.drawElements(context.TRIANGLES, l.length, context.UNSIGNED_SHORT, 0); C.L = context.getAttribLocation(C, Z('VE')); C.W = context.getUniformLocation(C, Z('Zv')); context.enableVertexAttribArray(C.L); context.vertexAttribPointer(C.L, 3, context.FLOAT, !1, 0, 0); context.uniform2f(C.W, 1, 1); context.drawArrays(context.TRIANGLE_STRIP, 0, 3); var h = new Uint8Array(262144); context.readPixels(0, 0, 256, 256, context.RGBA, context.UNSIGNED_BYTE, h); data['xT'] = h[88849]; data['jHWOO'] = h[95054]; data['aRR'] = h[99183]; data['ffJEi'] = h[130012]; for (var p = 0, _ = 0; _ < h.length; _++) p += h[_]; data['WjOn'] = p; |
Код, рисующий треугольник
Сам треугольник
После завершения всех проверок, валидатор шифрует собранную информацию и отправляет ее на еще один уникальный адрес на домене backuprabbit[.]com, чтобы в ответ получить (или не получить) следующую стадию цепочки заражения.
Бинарный валидатор
Как можно видеть на схеме цепочки заражения, этот валидатор запускается непосредственно перед загрузкой TriangleDB. Если JavaScript-валидатор — это скрипт, то этот валидатор представляет собой бинарный файл Mach-O, поэтому мы назвали его «бинарный валидатор». После запуска он расшифровывает конфигурацию (файл plist) при помощи алгоритма AES.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<key>sco</key> <array> <string>DeleteLogs</string> <string>DeleteArtifacts</string> <string>ProcessList</string> <string>InterfaceList</string> <string>JailbreakDetect</string> <string>EnableAdTracking</string> <string>DeviceInfo</string> <string>InstalledApps</string> </array> <key>sda</key> <dict> <key>sdf</key> <array/> <key>sdi</key> <true/> <key>sdk</key> <array> <string>c99218578c03cfe347fababc838dd9f2</string> <string>3d527800ad9418b025340775eaf6454c</string> <string>07d2143cea9fe70f7a0fcc653a002403</string> <string>c66cc1d90cce4e9cb6b631e063c83d61</string> |
Файл конфигурации содержит список действий (например, DeleteLogs, DeleteArtifacts), которые должен выполнить валидатор. В частности, он:
- Удаляет из директории /private/var/mobile/Library/Logs/CrashReporter записи о сбоях, появившиеся в процессе эксплуатации.
- Ищет следы вредоносного сообщения iMessage в различных базах данных, таких как ids-pub-id.db и knowledgeC.db, и удаляет их. Для этого в конфигурации валидатора содержатся 40 MD5-хэшей различных Apple ID, которые использовались для отправки iMessage. Мы смогли взломать большую часть этих хэшей и получить список email-адресов Apple ID, используемых злоумышленниками.
mailto:travislong544[at]yahoo.com mailto:norsarall87[at]outlook.com mailto:jesteristhebestband[at]gmail.com mailto:christineashleysmith[at]gmail.com mailto:homicidalwombat[at]yahoo.com mailto:nigelmlevy[at]gmail.com mailto:supercatman15[at]hotmail.com mailto:shannonkelly404[at]gmail.com mailto:superhugger21[at]gmail.com mailto:parkourdiva[at]yahoo.com mailto:naturelover1972[at]outlook.com mailto:sasquatchdreams[at]outlook.com mailto:trunkfullofbeans[at]yahoo.com mailto:danielhbarnes2[at]gmail.com mailto:patriotsman121[at]gmail.com mailto:wheelsordoors[at]yahoo.com mailto:janahodges324[at]gmail.com mailto:mibarham[at]outlook.com |
mailto:tinyjax89[at]gmail.com mailto:nonbaguette[at]yahoo.com mailto:slbrimms96[at]outlook.com mailto:costamaria91[at]outlook.com mailto:hyechink97[at]gmail.com mailto:greatoleg9393[at]mail.com mailto:popanddangle[at]outlook.com mailto:maxjar90[at]mail.com mailto:chongwonnam[at]gmail.com mailto:wopperplopper1[at]aol.com mailto:bajablaster101[at]gmail.com mailto:carlson31773[at]outlook.com mailto:fsozgur[at]outlook.com mailto:soccerchk835[at]gmail.com mailto:stephamartinez122[at]gmail.com mailto:popcornkerner[at]gmail.com mailto:pupperoni1989[at]outlook.com mailto:biglesterjames5[at]gmail.com |
- Получает список запущенных на устройстве процессов и сетевых интерфейсов.
- Проверяет устройство на наличие джейлбрейка. В валидаторе предусмотрены проверки на использование большого списка инструментов для джейлбрейка, в том числе 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.
Заполучив эти файлы, злоумышленники удаляют их с устройства, чтобы жертва не могла найти в них потенциальные следы компрометации. После удаления логов злоумышленники отправляют импланту несколько команд CRXPollRecords, инструктирующих его периодически отправлять на сервер файлы из каталога /private/var/tmp. Имена этих файлов должны соответствовать одному из следующих регулярных выражений:
Регулярное выражение | Тип данных |
^(kng|dky).+\.dat$ |
Данные о местоположении |
^adr3.+\.dat$ |
Файлы, связанные с базами данных приложений |
^sr6d.+\.(dat|srm)$ |
Записи с микрофона |
^S5L.+\.kcd$ |
Данные связки ключей |
^ntc.+\.db2$ |
Неизвестно |
^(\w[247F][023A][24BC]|\w[4AEF][349B][169D]){2}-\w[05AF][3468][124C]-4[123A][09AD][356A]-[89AB]\w\w\w-(\w[126A][24CE][348B]|\w[29DE][168D][156D]){3}$ |
Неизвестно |
Файлы с этими именами содержат результаты выполнения модулей. Для загрузки модулей на зараженное устройство применяются команды CRXUpdateRecord и CRXRunRecord. Мы опишем эти модули ниже.
Запись с микрофона
Один из самых опасных модулей с точки зрения приватности — модуль записи с микрофона под названием msu3h (мы полагаем, что 3h означает три часа — продолжительность записи по умолчанию). После запуска он расшифровывает свою конфигурацию с помощью кастомного алгоритма (вариация хэширования из GTA IV), но дальнейшие операции выполняет только при заряде батареи не менее 10%.
Помимо ожидаемых параметров, таких как длительность записи и AES-ключ для шифрования записей, файл конфигурации содержит настройки более изощренных функций, например:
- suspendOnDeviceInUse — определяет, будет ли останавливаться запись при включении экрана устройства;
- syslogRelayOverride — определяет, нужно ли записывать звук при захвате системных логов.
Звуковые фрагменты записываются с помощью API Audio Queue и сжимаются кодеком Speex, а затем подвергаются AES-шифрованию. Помимо звука каждая запись содержит диагностические сообщения с четырехбайтовыми идентификаторами событий:
Идентификатор | Сообщение |
0x6265676E | запись началась; |
0x736C726E | запись остановлена из-за мониторинга системных логов; |
0x6465766E | запись остановлена из-за включения экрана устройства; |
0x6964736E | запись остановлена из-за нехватки свободного места; |
0x656E646E | запись завершена. |
Эксфильтрация связки ключей
По неизвестной причине злоумышленники решили добавить дополнительный модуль эксфильтрации связки ключей, хотя такая функциональность уже есть в TriangleDB. Этот модуль наследует логику модуля TriangleDB, но в значительной степени основывается на коде из проекта iphone-dataprotection.keychainviewer.
Модули кражи данных SQLite
Многие iOS-приложения хранят внутренние данные с помощью SQLite. Вполне ожидаемо, что злоумышленники предусмотрели несколько модулей, способных извлекать сведения из различных баз данных SQLite. У всех модулей одинаковая кодовая база, но они выполняют различные SQL-запросы. Опять же, каждый модуль сопровождается зашифрованной конфигурацией. Однако, если ее расшифровать, можно увидеть только стандартные переменные, такие как путь к файлу, ключ AES, строка запроса и т. д.
Код этих модулей весьма своеобразен. Например, злоумышленники реализовали обертку вокруг функции fopen(), добавив флаг Z (он означает, что создаваемый файл должен быть зашифрован при помощи AES и сжат при помощи zlib). Новый флаг используется в сочетании со стандартным флагом w (запись), как показано на рисунке ниже.
Интересно также то, что модули кражи данных SQLite содержат три ветви кода для разных версий iOS: ниже 8.0, от 8.0 до 9.0, а также для 9.0 и более поздних.
Каждый из найденных нами модулей выполняет различные запросы к базе данных SQL. Например, один из модулей обрабатывает данные об использовании приложений, взятые из базы knowledgeC.db. Другой модуль извлекает метаданные фотографий, по которым можно узнать, кто в кадре: ребенок или взрослый, мужчина или женщина (см. рисунок ниже), а также автоматически распознанный текст в медиафайлах и прочие сведения.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
... END AS 'Face(s) Detected', CASE face.ZAGETYPE WHEN 1 THEN 'Baby / Toddler' WHEN 2 THEN 'Baby / Toddler' WHEN 3 THEN 'Child / Young Adult' WHEN 4 THEN 'Young Adult / Adult' WHEN 5 THEN 'Adult' else 'Unknown' END AS 'Subject Age Estimate', CASE face.ZGENDERTYPE WHEN 1 THEN 'Male' WHEN 2 THEN 'Female' else 'Unknown' END AS 'Subject Gender', person.ZDISPLAYNAME AS 'Subject Name' ... |
Неудивительно, что злоумышленники также проявляли интерес и к SMS-сообщениям, переписке в WhatsApp и Telegram, — мы обнаружили модули, эксфильтрующие и эти данные.
Модуль мониторинга местоположения
Этот модуль запускается в отдельном потоке и пытается выдать себя за пакет, который имеет авторизацию для доступа к сервисам определения местоположения, указанным в конфигурации (например, /System/Library/LocationBundles/Routine.bundle). Модуль пытается определить местоположение не только по GPS, но и через сеть GSM. Для этого он получает значения MCC (MobileCountryCode), MNC (MobileNetworkCode), LAC (LocationAreaCode) и CID (CellID) через фреймворк CoreTelephony.
Через сеть GSM можно узнать примерное местоположение жертвы, даже если данные GPS недоступны.
Заключение
Злоумышленники, стоящие за кампанией «Операция Триангуляция», приложили немало усилий к тому, чтобы избежать обнаружения. Они включили в цепочку заражения два валидатора, чтобы убедиться, что эксплойты и имплант не попадут в руки исследователей. Конфигурация записи через микрофон позволяет останавливать ее, когда жертва пользуется экраном. Модуль отслеживания местоположения анализирует метаданные сети GSM, если стандартная функциональность GPS отключена.
Злоумышленники также продемонстрировали глубокое понимание внутренних особенностей iOS и использовали недокументированные приватные API в ходе атаки. Кроме того, они реализовали в некоторых модулях поддержку версий iOS, предшествующих 8.0. Напомним, они были широко распространены до 2015 года, что дает представление о том, как долго данные модули могли использоваться.
Наконец, некоторые компоненты цепочки заражения содержат код, который может указывать на то, что атаки нацелены не только на iOS, но и на macOS, хотя на момент публикации следов «Триангуляции» на устройствах под управлением macOS обнаружено не было.
Несмотря на то, что операция «Триангуляция» отличается высоким уровнем скрытности, мы смогли получить всю цепочку эксплойтов, имплант и дополнительные модули. О том, как нам удалось обойти защиту, реализованную атакующими, вы можете услышать на конференции Security Analyst Summit (SAS), где Игорь Кузнецов представит презентацию «Операция Триангуляция: соединяя все точки» и расскажет о том, как эта продолжительная атака была остановлена. Если же вы не сможете добраться до Пхукета, то после конференции мы опубликуем пост с основными моментами этой презентации.
Индикаторы компрометации
Модуль эксфильтрации связки ключей
MD5 527bb38d4716c019b65da64d0f851a70
SHA-1 a468613d31c90ac94bbd313bc70c5c6638c91603
SHA-256 64f36b0b8ef62634a3ec15b4a21700d32b3d950a846daef5661b8bbca01789dc
Модуль геолокации
MD5 da5d3c0d3ad8df77ff6f331066636e42
SHA-1 a5a93e8d48fdef8c02066b9020445b50ebc81a8f
SHA-256 7e779a019f250d8cec9761d1230296236a8b714743df42c49ce8daf818d542e7
Модуль кражи SMS-сообщений
MD5 adb9e4b7a75eccc37f6941a5cbc7685b
SHA-1 6e9cd17fcc8b14cc860ce980c5e919494a10eec9
SHA-256 c2393fceab76776e19848c2ca3c84bea0ed224ac53206c48f1c5fd525ef66306
Модуль записи с микрофона
MD5 ac2444e7f7b0a4b084ad8c9ae8ac26c8
SHA-1 10509067ba5d9d985e932ea77f089491dee1611d
SHA-256 ff2f223542bbc243c1e7c6807e4c80ddad45005bcd78a77f8ec91de29deb2f6e
Выдающаяся скрытность кампании «Операция Триангуляция»