"Какой изящный ход – называть стандартный буткит имплантом," — подумали мы.
Всё началось около года назад, когда в распоряжение нашего отдела исследований поступили дорогостоящие подставки под кофе, а именно несколько железок от Cisco – коммутаторы Catalyst 3850, Catalyst 6500 (о технике написания шеллкодов под этого "зверя" ранее был доклад на ) и межсетевой экран ASA 5525-X.
Найдя несколько баг в межсетевом экране, которые позволяли «провалиться» в систему, получив стандартный шелл (разработчик был своевременно проинформирован), мы задумались над импактом – что можно сделать такого страшного, чтобы нанесло бы максимальный урон. И тут… слитые в 2013-м году Сноуденом пришлись как нельзя кстати. В них рассказывалось про имплант для PIX и ASA под названием , покрывающий Cisco PIX 500-й серии и Cisco ASA серии 5505, 5510, 5520, 5540, 5550. Как вы можете заметить, в каталоге АНБ из представленного большого диапазона поддерживаемых версий не было упоминания об имеющемся в нашем распоряжении ASA 5525-X, что, в свою очередь, породило спортивный интерес в части создания своего импланта под серию 5525-X в качестве PoC.
О своем видении и реализации импланта под ASA 5525-X мы будем рассказывать на конференции и выложим его исходные коды. Также, в качестве бонуса, мы продемонстрируем реализацию аналогичного импланта для Catalyst 3850.
Важно отметить, что разработанный имплант для целевых 5525-X немного отличается от JETPLOW ввиду того, что 5525-X построена на архитектуре Intel x86_64, и использует UEFI, а Catalyst 3850 базируется на архитектуре MIPS64.
Архив от The Shadow Brokers
С момента публикации было достаточно много статей, посвященных анализу содержимого бесплатной части архива (, ). Кто-то подался в конспирологию, связывая константное значение Q32 c Equation Group, кто-то просто отмахнулся, опрометчиво заявив, что выложенные эксплойты способны поразить только старые версии ASA и никакой угрозы не представляют.
В данной работе мы предлагаем абстрагироваться от подковерных бульдожьих игр, не разбираться, кто кого взломал и кто кого в этом подозревает, а на основе имеющегося опыта reverse engineering оборудования Cisco (и других подобных железок), а также анализа вредоносного кода, провести хладнокровный технический анализ самого импланта (см. директорию BANANAGLEE/), предназначенного под оборудование данного вендора. Ведь факт остается фактом – представленные в архиве файлы действительно являются набором средств эксплуатации неопубликованных ранее уязвимостей и средств негласного съема информации, использующих буткит-технологию. Несмотря на отсутствие части файлов, находящиеся в архиве инструменты отлично работают и выполняют свою задачу. Здесь нельзя не восхититься объемом проделанной работы.
Перед тем как перейти непосредственно к анализу импланта, стоит рассмотреть целевое железо, на которое он устанавливается, а именно архитектуру межсетевых экранов от Cisco.
Что такое межсетевой экран от Cisco
ASA и PIX
Экосистема Cisco огромная, просто поражает масштабами. Только широко известных операционных систем у них с десяток:
- IOS
- IOS XE
- IOS XR
- NX-OS
- CatOS
- AsyncOS
- Firepower OS
- ОС AireOS
- NX OS
- ОС PIX
- ОС ASA
- …
- x86
- x86_64
- ARM
- MIPS
- PowerPC
- …
Сегодня нами будут рассмотрены две линейки аппаратных межсетевых экранов: PIX (Private Internet Exchange) и ASA (Adaptive Security Appliance), пришедшая на замену PIX. Обе железки имеют x86 (Intel и AMD) совместимую архитектуру.
Загрузка межсетевого экрана
Как и в большинстве устройств от Cisco, в межсетевых экранах задачу загрузки выполняет некоторый bootstrap-код, называемый ROMMON (ROM Monitor). ROMMON в самом начале своей работы выполняет задачи по инициализации аппаратных компонентов, после чего считывает текущую конфигурацию из NVRAM. В случае отсутствия необходимости перехода в режим ROM Monitor mode (confreg 0x00), использует GRUB для загрузки образа (загрузочного образа с расширением .bin) операционной системы, для чего передает ему имя считанного из NVRAM файла.
Процесс загрузки ASA/PIX выглядит так:
Загрузочный образ ASA и PIX являются файлом, который хранится на флешке, более известной нам как flash:/. Структура загрузочных образов выглядит так:
Эволюция образов ASA видна в том, что, начиная с версии 8.x.x, Cisco перешла на использование ОС Linux. Далее, в качестве примера рассмотрим содержимое загрузочного asa831-k8.bin (ниже мы прокомментируем, почему был выбран данный образ):
Распаковав rootfs, можно выделить несколько интересных особенностей:
- Используемое ядро: Linux version 2.6.29.6 (builders@ff-bldcheck-05) (gcc version 4.0.2) #1 PREEMPT Thu Mar 4 15:59:06 MST 2010.
- Директория, содержащая файлы межсетевого экрана: /tmp/asa831-k8-rootfs/asa.
- Основной исполняемый файл имеет путь /tmp/asa831-k8-rootfs/asa/bin/lina и исполняется с правами root.
- Принудительное отключение ASLR (далее в статье мы рассмотрим, как это используют разработчики импланта):
Компоненты загрузочного образа и последовательность их загрузки
Нет смысла рассматривать MBR и FirstLdr, поскольку они никак не участвуют в загрузке и являются рудиментами, тянущимися ещё с версий образов под PIX.
Все загрузчики, кроме MBR, имеют заголовки, описываемые следующей (отличается лишь значение поля a_midmag):
SecondLdr
Имеет сигнатуру (значение поля a_midmag): 0x0064010B.
Если детально не вдаваться в подробности работы данного загрузчика, то можно сказать, что он используется только в случае загрузки ROMMON'ом образа по протоколу tftp. ROMMON располагает загружаемый образ в физической памяти с учетом смещения SecondLdr и его заголовка по адресу 0x13FE0, и передает на него управление (1*). Основная задача этого загрузчика – проверка целостности загружаемого образа, проверка поддержки целевой платформы, релокация остальной части образа, начиная с BootLdr по адресу 0x100000 и передача управления на его точку входа (2*).
BootLdr
Данный загрузчик имеет сигнатуру 0x107, основная задача – подготовка ядра к запуску, повторная проверка поддержки целевой платформы, генерация идентификатора данной платформы, релокация тела StubLdr по адресу 0x13FE0 (с учетом заголовка) и передача на него управления (2). В качестве аргумента передается указатель на вычисленный идентификатор платформы.
Также на данный загрузчик может передать управление GRUB (1), что, в принципе, никак не влияет на его адрес загрузки.
StubLdr
Имеет сигнатуру 0x0064010B, основной задачей данного загрузчика является распаковка и загрузка ядра (3).
Важно отметить, что в случае с образом под PIX (начиная с версии образов 6.2), ядро имеет аналогичный загрузчику BootLdr заголовок.
JETPLOW
Что касается терминологии, то при анализе архива мы заметили, что название JETPLOW используется для обозначения ранних версий импланта (в основном, для PIX), а новым версиям дано название SCREAMINGPLOW, при этом, в некоторых из управляющих компонентов последних версий присутствует частичная поддержка старых версий.
Нами был произведен анализ последней версии набора утилит BannanaDaiquiri 3.1.2 (директория BANANAGLEE/BG3121) и входящий в её состав ScreamingPlow версии 2.8 (SCP28). В качестве целевого оборудования был выбран межсетевой экран Cisco ASA 5505 с ROMMON версии 1.0(12)13 и загрузочный образ версии 8.3.1 (asa831-k8.bin). Последнюю версию импланта мы взяли потому, что в ней присутствует поддержка большего числа серий целевых межсетевых экранов, расширен набор возможностей и улучшена архитектура.
Способы заражения
Установка импланта возможна:
- через пост-экплуатацию, к примеру, после удаленной эксплуатации уязвимости. Подобный эксплоит можно также найти в выложенном архиве (см. EXPLOITS/EXBA);
- через использование загрузочного образа. Такое заражение может быть произведено удаленно по сети или при наличии физического доступа к устройству. Например, в офисе транспортной компании.
В ней упоминается некий, отсутствующий в архиве, ключевой (инженерный) загрузочный образ image.bin, загружаемый по сети с использованием протоколов tftp, ftp и http(s).
Пример из документации:
На случай заражения более ранних серий межсетевых экранов, а именно PIX, разработчики заботливо предоставляют оператору скрипты автоматизации развертывания веб-сервера Apache (см. файл OPS/apache_setup.sh и документацию SCRIPTS/Apache_Setup.txt) для последующей загрузки инженерных образов по протоколу http(s).
Данный инженерный образ должен быть индивидуально сгенерирован под конкретный целевой межсетевой экран на основании некоторой базовой информации о нем (серия, версия ROMMON и т.д.). Помимо этого, при генерации образа должен быть указан идентификатор импланта, который в последующем будет использоваться для различения зараженных устройств и коммуникации с ними.
Всё взаимодействие с инженерным образом производится по сети (UDP 500). Для этого используется несколько утилит:
- инфектор (в последних версиях имеет имя BPICKER, в более старых – writeScreamingPlow и writeJetPlow);
- утилита LP для мониторинга и последующего управления.
Подготовка к заражению
Как уже говорилось ранее, в последней версии утилит BannanaDaiquiri для формирования карты образа BIOS Flash используется утилита BPICKER (см. файл BANANAGLEE/BG3121/Install/LP/BPICKER-3100). Данная утилита, после подключения к инженерному образу, получает от него информацию о целевом оборудовании. Затем на её основании в текущей директории производится поиск архива с именем <platform_name>-moduledata-<bg_version>.tgz, который содержит составные части импланта. К сожалению, в опубликованной части архива присутствует только файл asa-moduledata-3101.tgz. Произведя распаковку архива, можно наблюдать следующую структуру каталогов:
Для выбранной нами версии импланта, файл, содержащий карты образа BIOS Flash, имеет имя asa/asa5505_101213_install_SCP28.pif. Ключ для расшифровки pif-файлов можно обнаружить через анализ утилиты BPICKER.
Для выбранной нами версии импланта, нас интересуют pif-файлы с именами asa/asa5505_101213_install_SCP28.pif для инсталляции и asa/asa5505_101213_uninstall_SCP28.pif для деинсталляции.
Расшифровать все имеющиеся в архиве pif-файлы можно следующим образом:
Расшифрованный xml-файл asa5505_101213_install_SCP28.pif содержит следующее:
Как видно по коду, в данном xml-файле находится корневой элемент platform, описывающий целевую платформу ASA 5505 с ROMMON версии 1.0(12)13 "на борту", оригинальный образ которого находится в файле bin/asa5505/asa5505_101213_bios_sectors1-E_clean.bin. Для BIOS данной платформы существуют патчи, описываемые в элементе patchList. Каждый из них имеет адрес назначения, и делится на два типа: файл на диске и код (inline).
Код патчей, имеющих тип inline, на основании пользовательских данных, формируется с помощью библиотеки для платформы libasa.so (см. атрибут lib корневого элемента platform), которая подгружается утилитой BPICKER.
На этом этапе стоит отметить, что в более ранних версиях утилит в составе BannanaDaiquiriформирование карты BIOS Flash происходило непосредственно в самом инфекторе, где пути до составных частей типа file были строго прописаны.
Заражение и последующая верификация
Весь процесс заражения, выполняемый инфектором, заключается в последовательной отправке сконфигурированных патчей инженерному образу. Для проверки корректности произведенного эффекта, на основании содержимого элемента validationList, выполняется повторное чтение участков памяти с последующим подсчетом хэш-суммы считанных данных. В то время как элементы в signatureListиспользуются для того, чтобы убедиться, что целевая система не заражена или удаление импланта было успешно выполнено.
На картинке ниже показано, как выглядит BIOS Flash до и после заражения.
Анализ составных частей импланта
Из приведенного выше содержимого xml-файла asa5505_101213_install_SCP28.pif видно, что сам имплант состоит из четырех основных частей: First Code Area, Second Code Area, First User Area, Second User Area и некоторого Hook'а:
Далее, для краткости изложения, мы будем оперировать аббревиатурами FCA, SCA, FUA и SUA, для обозначения соответствующих частей импланта, а Hook, пожалуй, останется Hook'ом.
Теперь рассмотрим каждую из составных частей. Произведем мы это в порядке, обратном тому, в котором их задействует имплант, что позволит упростить, а главное – не оборвать цепочку происходящих событий.
Second User Area (SUA @ 0xFFF70000)
Данная часть является основной и единственной полезной нагрузкой импланта, в то время как все остальные, по сути, являются её загрузчиком. SUA содержит в себе код полезной нагрузки импланта (A), а также некоторую вспомогательную информацию (B), описывающую окружение, в котором коду полезной нагрузки предстоит работать.
Код полезной нагрузки предназначен для установки связи с командным сервером (C&C Server).
Вспомогательная информация включает в себя, к примеру:
- инструкции по определению версии основного процесса;
- адреса различных функций в адресном пространстве основного процесса, которые код полезной нагрузки использует в своей работе (например, функции для работы с сетью);
- смещения внутри ключевых структур основного процесса, с которыми коду полезной нагрузки предстоит работать, и др.
Рассмотрим назначение отдельных структур:
- UA_DIR – корневая структура, содержащая смещения остальных структур относительно начала SUA.
- OS8_INFO – структура, содержащая адреса, по которым в основном процессе располагаются константы со значением версии. Следует отметить, что в указанной структуре расположены адреса только для основного процесса lina (8.x.x и выше), поскольку различаются от версии к версии (отсюда название – OS8). Константа с версией основного процесса malina (7.x.x) всегда располагается по адресу 0x100040.
- BG_GEN_INFO – структура, содержащая размер и версию кода полезной нагрузки импланта.
- BG_OS_INFO – структура, содержащая информацию, описывающую конкретную версию основного процесса.
Формирование комплекса структур осуществляется с использованием набора .dat файлов, каждый из которых описывает окружения для какой-либо конкретной версии основного процесса (см. файлы BANANAGLEE/BG3121/Dats/*.dat).
В качестве чистого образа SUA и дальнейшего формирования для него заголовка используется файл bin/BG_312_SCREAM_UA_full_support.bin.
First User Area (FUA @ 0xFFF6DF00)
Представленный фрагмент, именуемый авторами как PBD, состоит из заголовка PBD Header (A), и кода загрузчика userarea (B).
Код загрузчика формирует конечный образ userarea, в состав которого входит код полезной нагрузки из SUA и одна из структур BG_OS_INFO, выбор которой зависит от текущей версии основного процесса. Если в составе SUA нет структуры BG_OS_INFO для текущей версии основного процесса, загрузчик не сможет приступить к формированию userarea. В этом случае, загрузчик просто завершит свою работу и сообщит SP Main об ошибке.
Схематично это можно представить следующим образом:
Заметим, что SUA – это код полезной нагрузки и информация об окружении, из которых в следствии работы загрузчика из FUA будет собрана сама полезная нагрузка, именуемая просто userarea.
Для хранения PBD Header в теле FUA отводятся первые 256 байт. Восстановленная структура PBD Header представлена ниже:
Заголовок PBD Header заполняется на основании пользовательских данных и содержит информацию, необходимую импланту для связи с C&C (IP-адреса, ключи шифрования, периоды "отстука" и т.д.). В качестве чистого образа FUA, и дальнейшего формирования для него заголовка, используется файл bin/BG_312_PBD_config_CLEAN.bin.
First Code Area (FCA @ 0xFFF60000)
Содержимое этой части можно разделить на 3 элемента:
- A) Поддельный обработчик системного вызова mmap2, задачей которого является перехват управления основного процесса.
- B) Код SP Main, который в результате своей работы должен обеспечить передачу управления на код полезной нагрузки userarea. Его работу можно разделить на две части: вызов загрузчика userarea из FUA, а, в случае неудачи, передача управления на код аварийной связи с C&C.
- C) Код для аварийной связи с C&C это, на наш взгляд, одна из самых интересных частей импланта. О нем мы расскажем в одном из следующих разделов.
Second Code Area (SCA @ 0xFFFEC480)
SCA содержит в себе код поддельного SMI-обработчика, на который будет передано управление в один из моментов загрузки системы. Задача этого обработчика – внедрение FCA, FUA и часть SUA в адресное пространство основного процесса и дальнейшее обеспечение передачи управления на SP Main из FCA.
Код SCA находится в файле bin/asa5505/SCP28/asa5505_patchEC480.bin.
Hook (@ 0xFFFE18BF)
Данный патч накладывается на код BIOS, ответственный за копирование оригинального SMI-обработчика в пространство SMRAM:
Задача Hook'а – копирование в SMRAM поддельного SMI-обработчика из SCA и сохранение перед этим адреса оригинального обработчика. Последнее действие необходимо для того, чтобы система продолжала функционировать в штатном режиме, в случае, если источник SMI не относится к работе импланта.
Код Hook'a находится в файле bin/asa5505/SCP28/asa5505_patchE18BF.bin.
Загрузка импланта
Первоначальная загрузка
Первый этап загрузки импланта начинается в момент выполнения BIOS’ом копирования кода обработчика SMI в область SMRAM. При установке импланта на устройство, этот код изменяется таким образом, чтобы вместо оригинального обработчика там оказался поддельный обработчик из SCA. После чего, выполнение кода SCA будет происходить при обработке процессором любого #SMI прерывания. Поскольку существует , по которым ICH/PCH инициирует #SMI, SCA заранее не знает, в какой момент времени начнется выполнение его кода. Для этого в коде SCA присутствует множество проверок на выполнение тех или иных условий, необходимых ему для своей работы. В случае, если какое-либо условие не выполняется, SCA передает управление дальше по цепочке обработке #SMI, в ожидании подходящего момента для продолжения работы:
В результате анализа имеющихся в публичной части архива компонентов импланта, нам не удалось установить, какое именно #SMI прерывание используется для инициации работы SCA. Однако с уверенностью можно сказать, что это прерывание должно быть периодическим и иметь достаточно малый интервал между срабатываниями, поскольку некоторые части кода SCA должны быть выполнены в строго определенный момент загрузки ОС/основного процесса.
Первоначально, SCA находится в ожидании следующих условий:
- защищенный режим (CR0.PM == 1);
- страничная организации памяти (CR0.PG == 1, CR3 != NULL);
- готовность IDT/GDT.
Выполнение этих условий означает, что ядро/загрузчик закончили подготовку окружения и готовы к запуску пользовательских процессов, а значит, можно начинать проникновение.
Знакомство с жертвой
На данном этапе импланту необходимо сделать следующее: обеспечить передачу управления на код SP Main из основного процесса межсетевого экрана и предоставить доступ SP Main к остальным частям импланта, расположенным на BIOS Flash.
Для этого SCA необходимо определить, с каким загрузочным образом имплант имеет дело – для ASA или для PIX. Именно от этого будет зависеть выбор того или иного механизма проникновения в основной процесс.
Определение версии осуществляется через анализ заголовка загрузчика BootLdr, расположенного по виртуальному адресу 0x100000 (который обязательно должен быть мапингом на физический адрес 0x100000).
Если размер кодового раздела больше 8 MiB – мы имеем дело с PIX, в противном случае жертвой оказалась ASA.
Проникновение в основной процесс malina (PIX)
Несмотря на то, что в настоящей статье в качестве цели для импланта рассматривается, в основном, ASA и её основной процесс lina, в первую очередь мы рассмотрим механизм проникновения в процесс malina. Как будет видно далее, часть кода в SP Main, связанная с аварийным режимом работы импланта (о котором мы так же расскажем далее), аналогична в своей механике с кодом, который используется для проникновения в основной процесс malina.
В первую очередь, SCA необходимо создать мапинг BIOS Flash в адресное пространство основного процесса. Для этого SCA напрямую работает с последней записью Page Directory, которая содержит адрес Page Table для последних 4-х MiB 32-битного адресного пространства (BIOS Flash Map).
Каждый Page Table Entry модифицируется таким образом, чтобы обеспечить доступ на чтение и запись из user space к каждой странице BIOS Flash Map.
Затем SCA производит в основном процессе поиск функции, пролог которой начинается с последовательности байт 55 53 65 57, что соответствует инструкциям push ebp, ebx, esi, edi. В основном процессе malina присутствует единственная функция с таким прологом (в качестве примера нами была использована прошивка версии 7.2.2 для PIX):
Непосредственно за функцией _td_ctx_enter следует функция _td_ctx_exit, куда далее кодом SCA будет установлен сплайс:
Приведенные выше функции вызываются при смене контекста трэда.
Далее, посредством поиска в теле основного процесса перекрестных ссылок на строки "duart_open", "malloc" и "CHECKHEAPS...", SCA устанавливает адреса функций malloc и checkheaps. Функция mallocбудет в дальнейшем использована для копирования FCA и FUA из BIOS Flash в RAM. Функция checkheapsбудет пропатчена таким образом, чтобы скрыть изменения, которые SCA внесет в кодовую секцию основного процесса:
Затем, после патчинга функции checkheaps, SCA изменит флаг доступа к страницам памяти, принадлежащим кодовой секции основного процесса, таким образом, чтобы разрешить туда запись. Далее SCA установит сплайс в функцию _td_ctx_exit:
Код устанавливаемого сплайса:
Указанный код выделит 64 KiB памяти под FCA и FUA, и далее передаст управление обратно в SCAпосредством программного #SMI, который произведет копирование части FCA и FUA в выделенную память.
В завершение своей работы, SCA заменит адрес возврата таким образом, чтобы по возвращению из функции _td_ctx_exit управление было передано в SP Main. Передача управления осуществляется на функцию, расположенную по смещению 0x25E относительно начала релоцированной части FCA.
Общая схема процесса проникновения выглядит следующим образом:
Теперь в игру вступает SP Main. Как мы помним, основная задача загрузчика импланта, а значит, и SP Main – обеспечить выполнение кода из SUA (userarea).
В начале своей работы SP Main передает управление на загрузчик userarea, расположенный в FUA. В случае, если работа загрузчика увенчалась успехом, SP Main просто возвращает управление обратно в основной процесс – его работа на этом завершена. В противном случае, SP Main переходит в так называемый "аварийный режим работы", о котором мы подробнее расскажем в соответствующем разделе.
Проникновение в основной процесс lina (ASA)
Как мы помним, у SCA есть две задачи: организовать передачу управления на SP Main и создать мапинг BIOS Flash в user space. И обе решаются весьма элегантным способом – через подмену адреса обработчика системного вызова mmap2 в таблице syscall_table. Новый адрес в таблице указывает на код модифицированного обработчика, который до того был заботливо скопирован кодом SCA в адресное пространство ядра на место кода, осуществляющего перевод процессора в защищенный режим.
Адрес таблицы syscall_table извлекается из тела функции , которая отвечает за обработку int 0x80 (syscall). Обработчик int 0x80 описывается дескриптором в IDT, который находится по смещению 0x400 относительно начала IDT.
Таким образом, имплант "убивает" сразу двух "зайцев": получает возможность изменять аргументы вызова mmap2 "на лету" прозрачно для user space-процесса, а также может выполнять привилегированные инструкции. Через изменение аргументов mmap2 имплант способен смапить в адресное пространство процесса другую область файла и с другими флагами доступа. Поскольку целью SCA является создание мапинга BIOS Flash, необходимо, чтобы в качестве файлового дескриптора выступал открытый дескриптор /dev/mem. К счастью, единственный процесс, который использует mmap2для создания мапинга из устройства /dev/mem по смещению 0xFF000 страниц – это lina.
Как можно видеть в коде, lina для каких-то своих целей создает мапинг первых 512 KiB BIOS Flash. Несмотря на то, что в указанную область попадают разделы FCA, FUA и SUA, размер мапинга всё равно будет увеличен до 1 MiB внутри модифицированного обработчика mmap2, а также будет дано разрешение на выполнение кода из смапленной области памяти. Таким образом решается задача доставки указанных компонентов в адресное пространство процесса lina.
Теперь необходимо обеспечить передачу управления на SP Main. Здесь на помощь приходит тот факт, что код обработчика mmap2 выполняется с привилегиями ядра, следовательно, имеет доступ к привилегированным инструкциям для работы с портами ввода/вывода, что, в свою очередь, позволяет организовать передачу управления обратно на код SCA посредством программного #SMI.
Далее SCA определяет, где в стэке ядра находится адрес sysenter_ret (адреса, по которому будет передано управление при возврате из обработчика системных вызовов), и подменяет его на адрес кода SP Main. Затем SCA возвращает управление ядру посредством RSM, которое завершает обработку системного вызова и передает управление на код SP Main, который, в свою очередь, находится в адресном пространстве основного процесса:
Общая схема процесса проникновения выглядит следующим образом:
Процесс работы кода SP Main, на который теперь будет передано управление, аналогичен тому, который был описан в предыдущем разделе для основного процесса malina. Отличия состоят в расположении точки входа (в случае с lina точка входа расположена по смещению 0x62200 относительно начала мапинга BIOS Flash), и в коде "аварийного режима работы", который будет рассмотрен далее.
Аварийный режим работы импланта
В аварийный режим работы имплант переходит в случае, если загрузчик из FUA по каким-то причинам не смог обеспечить загрузку userarea. Подобное развитие событий происходит, как правило, по причине отсутствия в SUA информации о текущей версии основного процесса. Например, загрузочный образ межсетевого экрана был обновлен до более поздней версии, информации о котором не существовало на момент сборки импланта). В таком режиме SP Main из имеющихся функций для работы с сетью, которые точно присутствуют в коде основного процесса, собирает средства для связи с C&C, чтобы сообщить ему: "Хьюстон, у нас проблемы. Это какая-то неправильная Lina. Что мне делать?".
Дальнейшее развитие событий зависит от того, в каком окружении происходит работа. Несмотря на то, что код для коммуникации с C&C един для всех версий основного процесса, механизм сбора информации об окружении целиком зависит от конкретной версии основного процесса.
Здесь имеет смысл более подробно рассмотреть алгоритм действий импланта в случае, если основным процессом оказалась lina. В это случае SP Main придется самостоятельно выполнить часть работы по переносу FCA и FUA в RAM и установке сплайса в тело функции _td_ctx_enter, в то время как для процесса malina эти действия были выполнены еще на этапе SCA. Кроме того, SP Main предстоит установить базовый адрес загрузки lina путем анализа информации, полученной из ОС. В случае с процессом malina в этом нет необходимости, так как версия всегда доступна по постоянному адресу 0x100040.
Первым делом SP Main переносит своё тело (FCA) и PBD Header из смапленного пространства BIOS Flash в anonymous mapping внутри адресного пространства процесса.
Далее SP Main определяет адрес загрузки образа основного процесса. Для этого он парсит /proc/self/mapsи извлекает из него информацию о базовом адресе загрузки lina.
Теперь, зная адрес загрузки ELF-образа основного процесса, SP Main производит поиск функции _td_ctx_enter по алгоритму, аналогичному использованному SCA в случае, если основным процессом является malina (по сигнатуре пролога 55 53 65 57).
Затем при помощи системного вызова mprotect с памяти, где расположена данная функция, снимается защита от записи, и в тело функции внедряется сплайс, который передаст управление обратно в SP Mainпри переключении контекста выполнения.
Все процессы, которые будут описаны далее, выполняются одинаково как для lina, так и для malina.
При получении управления из установленного в _td_ctx_enter сплайса, SP Main производит поиск в адресном пространстве процесса функционала, необходимого ему для дальнейшей работы. В неполный состав искомых функций входят функции: для работы с сетью (socket, bind, sendto, close, etc.); для получения информации о сетевых интерфейсах (сбор статистики, конфигурация, etc.); для работы с SNMP (определение сетевого окружения); для работы с syslog и другие.
Поиск указанных функций осуществляется через перекрестные ссылки на строки, которые уникальны и характерны для искомых функций. Код, который осуществляет поиск, в своей совокупности занимает чуть ли не большую часть FCA (см. код данной функции в FCA по смещению 0x2D60).
Затем, после сбора всей нужной информации, имплант устанавливает новый сплайс в mainперехваченного потока. Задачей сплайса является передача управления на код, ответственный непосредственно за организацию обратного канала связи с C&C, чистку логов и прочие действия.
Коммуникация с имплантом
Протокол коммуникаций в контексте модели OSI
Наиболее наглядным способом рассмотрения модели коммуникации между имплантом и C&C нам представляется рассмотрение с точки зрения модели OSI.
На сетевом уровне используются протоколы IPv4 и IPv6, в зависимости от конфигурации импланта.
На транспортном уровне используется протокол UDP. Номер исходящего порта имплант выбирает из промежутка PBD_Header.min_src_port – PBD_Header.max_src_port. В качестве номера порта назначения имплант принимает исходящий порт из первого пакета, принятого от C&C.
На сеансовом уровне сообщения представляются в виде так называемых Benign-пакетов, несущих в себе некоторую метаинформацию о полезной нагрузке, непосредственно сами данные полезной нагрузки, а также сведения, необходимые принимающей стороне для сборки фрагментов полезной нагрузки в единое целое. Последнее необходимо ввиду того, что максимальный размер Benign-пакета равен 512 байт (BENIGNSIZE в терминах импланта), в то время, как размер полезной нагрузки может его превышать. Подробнее формат Benign-пакета мы рассмотрим в следующем разделе.
На уровне представления для защиты информации сторонами используются шифрование по алгоритму RC6 для защиты части Benign-пакета.
На прикладном уровне коммуникации осуществляются в формате "запрос – ответ". Инициатором запроса может выступать как сервер, так и имплант. Данные на прикладном уровне передаются в виде полезной нагрузки в составе Benign-пакетов.
Структура Benign-пакета
Структура Benign-пакета, на основании проведенного реверс-инжиниринга, представляется нам следующим образом:
Поле type содержит тип запроса/ответа, который передается в данном пакете.
Доступные типы пакетов (запросы и ответы):
- HELLO
- AUTH_RESP
- CHALLENGE
- ACK
- ERROR
- GOODBYE
- READ
- WRITE
- MALLOC
- FREE
- EXEC
- MOD_INFO
- MOD_DATA
- MOD_LIST
- MOD_ACTIVATE
- MOD_DEACTIVATE
- MOD_REMOVE
- COMMAND_ADD
- COMMAND_LIST
- BOX_INFO
- FRAG_TYPE
- LAST_IN_LIST
Поле pkt_ID содержит порядковый номер пакета в текущем сеансе коммуникации.
Поле benign_payload_length содержит размер полезной нагрузки в поле payload.
Поле sequenceNumber используются для сборки фрагментов одного запроса, размер полезной нагрузки которого превышает 512 байт.
Поле ackNumber используется, чтобы обозначить на какой именно запрос данный пакет содержит ответ.
Поле cf_crc, предположительно, используется на стороне импланта для быстрого определения, являются ли данные во входящем UDP-пакете Benign-пакетом.
Для защиты передаваемой информации часть пакета, которая начинается с поля BenignPacket2.salt, шифруется с применением алгоритма RC6. В качестве ключа для шифрования используется значение поля PBD_Header.default_key1. В качестве вектора инициализации используется значение поля cv, которое является первыми 16-байтами SHA-1 хэша, вычисленного на основе тех данных, к которым впоследствии применялось шифрование. Значение поля salt выбирается случайно на основании defauly_key1 и .
Регистрация импланта на Beacon-сервере
В случае, если установка импланта была произведена с использованием физического доступа к устройству, либо если оператор потерял связь с имплантом, например, вследствие изменения внешнего IP-адреса устройства, имплант должен, по прохождению определенного промежутка времени, заново сообщить свои "координаты" на Beacon-сервер.
Для того, чтобы передать свой IP-адрес и идентификатор, имплант отправляет на выбранный Beacon-сервер стандартный DNS-запрос с единственной записью класса A (address record), содержащей доменное имя видаwww.subdomain.domain.com. Здесь domain – домен первого уровня, который, предположительно, не несет смысловой нагрузки и используются лишь для отвлечения внимания, а subdomain – зашифрованный идентификатор импланта.
Схожая технология используется, например, в для получения "отстука" с зараженных машин.
Код формирования DNS пакета:
При получении DNS-запроса Beacon-сервер определит IP-адрес импланта как исходящий адрес в заголовке IP-пакета и вычислит идентификатор импланта, исходя из расшифрованного значения subdomain.
При этом, следует отметить, что Beacon-сервер не посылает ответа на DNS-запрос, поэтому имплант продолжает попытки до тех пор, пока с ним не будет установлено соединение, либо количество попыток не превысит 400 на один цикл перезагрузки платформы.
Адреса Beacon-серверов чередуются между собой в зависимости от порядкого номера DNS-запроса: для четных номеров используется PBD_Header.primary_beacon_IP, а для нечетных – PBD_Header.secondary_beacon_IP.
Таким образом, на Beacon-сервере сохраняется вся необходимая информация, которая впоследствии будет использована оператором для установки соединения с имплантом. При это сам "отстук" будет скрыт в стандартном DNS-запросе, которые, как правило, в большом количестве проходят через любой межсетевой экран, установленный во внешнем периметре.
Несомненным преимуществом такого способа информирования является то, что в транзитном трафике Beacon-пакет ничем не будет выделяться среди обычных DNS-запросов.
При ближайшем рассмотрении, структура сгенерированного имени выглядит следующим образом:
www.[dev_id?][implant_id_enc][some_obf].[domain].com, где
- dev_id? – символ 'A', что предположительно означает "ASA" (1 байт);
- implant_id_enc – зашифрованный идентификатор импланта (8 байт);
- some_obf – получается в результате обфускации implant_id_enc (8 байт);
- domain – соответствует значению поля domain структуры PBD_Header (8 байт).
Coming soon...
К сожалению, объем информации полученный в результате исследования импланта не представляется возможным полностью осветить в рамках одной статьи. Поэтому пытливого читателя ждет продолжение, в котором мы раскроем следующие темы:
- Подробно разберем алгоритм работы DGA.
- Проведем детальный анализ полезной нагрузки userarea.
- Рассмотрим протокол взаимодействия импланта с оператором.
Противодействие импланту
Компания Cisco в своем официальном предлагает ряд мер:
Что можно сказать об этом?
Да, это все, конечно, хорошо и правильно, но будете ли вы доверять результатам вывода команд на скомпрометированном устройстве? Имплант без особых проблем может перехватывать нужные ему функции и в качестве результата выдавать то, что вы хотите увидеть: корректные контрольные суммы, оригинальный конфигурационный файл, «вычищенный до блеска» лог-файл и т.д.
Что касается команды , то внимательный читатель заметит, что она нацелена всего лишь на проверку целостности загрузочного образа, что абсолютно не имеет смысла делать на инфицированном устройстве, поскольку рассмотренный нами имплант работает исключительно в памяти. Проверка потенциально инфицированного устройства его же средствами и под его же управлением – довольно бесперспективная затея.
Что касается логов, то забегая чуточку вперед, стоит отметить, что JETPLOW в процессе своей работы без особых проблем их чистит.
Как быть?
В антивирусной индустрии давно придуманы такие средства, как загрузочные образы, с которых можно загрузиться и проверить всю текущую систему. Да, но одно – сделать это для обычного компьютера, и совсем другое – для проприетарной железки, которая с неохотой подгружает непонятные для неё загрузочные образы.
Мы сейчас над этим работаем и надеемся, что в ближайшее время выложим в открытый доступ такой образ для ОС ASA и исходные коды к нему, с помощью которых можно будет проверить свой межсетевой экран на предмет заражения JP/SCP. Использование подобного загрузочного образа становится возможным благодаря тому, что данный имплант не обладает никакими механизмами самозащиты.
А как же SecureBoot и Trust Anchor?
О данных механизмах защиты мы уже немного говорили в в разделе "Про заражение устройств Cisco". И мы думаем, вы уже сами способны ответить на этот вопрос, просто вспомнив, какой зоопарк устройств, архитектур и ОС у Cisco.
Вывод
Несмотря на отсутствие части файлов в опубликованном The Shadow Brokers архиве, мы пришли к следующим выводам:
- Данные от The Shadow Brokers соответствуют материалам, опубликованным Эдвардом Сноуденом, как мы указали в самом начале статьи.
- В разработке JETPLOW/SCREAMINGPLOW участвовало множество высококлассных специалистов, которыми была проделана огромная работа.
- Без аппаратной защиты (TPM) подобные JETPLOW могут появляться и дальше, поскольку программными средствами от этого не защититься.
Авторы статьи
- Бажин Роман
- Максим Малютин
