LoJax: первый известный UEFI руткит, используемый во вредоносной кампании03.10.2018 21:32

Кибергруппа Sednit, также известная как АРТ28, Strontium и Fancy Bear, работает как минимум с 2004 года. Считается, что группа стоит за рядом резонансных кибератак. Некоторые ИБ-компании и Министерство юстиции США назвали Sednit ответственной за взлом Национального комитета Демократической партии перед выборами в США в 2016 году. Группе приписывают взлом глобальной телевизионной сети TV5Monde, утечку электронных писем Всемирного антидопингового агентства (WADA) и другие инциденты. У Sednit множество целей и широкий спектр инструментов, некоторые из которых мы уже задокументировали ранее, но в этой работе мы впервые детально опишем применение UEFI руткита.

Краткий обзор

Мы обнаружили, что как минимум с начала 2017 года Sednit применяют троянизированную версию старого пользовательского агента программы для защиты устройств от краж разработчика Absolute Software — LoJack. Инструмент привлек внимание ИБ-специалистов по причине использования модуля UEFI/BIOS в качестве механизма для обеспечения персистентности. Мы назвали троянизированную версию этой программы LoJax.

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

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

Модуль UEFI отвечает за внедрение агента LoJax в систему, это первый идентифицированный UEFI руткит группы Sednit. Так как он находится в системной прошивке, он может пережить переустановку Windows и замену жесткого диска.

Был как минимум один случай, когда этот руткит был успешно установлен в системную SPI флеш-память. По нашей информации, это первый UEFI руткит, обнаруженный in-the-wild.

Введение

Группа Sednit использует ряд семейств вредоносного ПО. Подробное описание часто используемых инструментов группы мы приводили в отчете.

Мы отслеживаем активность Sednit на протяжении нескольких лет и выпустили множество отчетов о работе группы — от описания уязвимостей нулевого дня до кастомных программ, таких как Zebrocy. Компоненты, описываемые в данном отчете, образуют отдельную группу.

UEFI руткиты описывались в докладах ИБ-компаний ранее. Известен, например, rkloader, который фигурировал в презентации об утечке данных в Hacking Team, и DerStarke, имплант в загрузке macOS EFI/UEFI, из документов Vault7. Мы знаем о существовании этих инструментов, однако отчетов о компрометации UEFI руткитами не выпускалось.

Теперь мы не только доказали использование in-the-wild прошивки с вредоносным модулем LoJax UEFI, но и обнаружили весь спектр инструментов, которые, скорее всего, использовались для его установки. Интересно отметить, что Sednit использует буткит DownDelph, применявшийся в 2013 и 2014 годах для персистентности Downdelph, одного из бэкдоров Sednit первого этапа. Идея схожа, но в новом варианте UEFI использование буткитов более не представляется возможным. Таким образом, эти два компонента существенно отличаются в поведении.

Данная работа разделена на три секции. В первой мы разберем ранние исследования безопасности LoJack/Computrace и возможности вредоносного применения программы. Второй раздел посвящен процессу исследования, которое в итоге привело нас к руткиту UEFI. Наконец, в третьем разделе мы опишем в деталях различные компоненты LoJax и то, как они обеспечивает персистентность в системе даже после переустановки Windows и замены жесткого диска.

Атрибуция

В то время как многие вендоры уже сделали заявления относительно группы Sednit в прошлом, ESET никоим образом не определяет геополитическую принадлежность. С момента публикации исследования 2016 года наша позиция не изменилась. Определить источник кибератаки на основе научного подхода — комплексная задача, находящаяся за пределами сферы компетенций специалистов ESET. То, что мы называем «группой Sednit» — это просто набор ПО и связанная сетевая инфраструктура, которую мы не можем авторитетно связать с какой-либо конкретной организацией.

Цели

В процессе исследования мы обнаружили небольшое число различных образов LoJax. На основании данных нашей телеметрии и изучения других программ Sednit, обнаруженных in-the-wild, мы уверены, что этот конкретный модуль редко использовался в сравнении с другими инструментами. Целями, в основном, стали государственные организации, расположенные на Балканах, в Центральной и Восточной Европе.

Ранние исследования Computertrace/LoJack

LoJack — ПО для защиты компьютеров от кражи и потери, разработанное корпорацией Absolute Software. Ранние версии агента известны под названием Computrace. Как следует из прежнего названия, после активации сервиса компьютер может обращаться к своему командному серверу — владелец будет оповещен о местонахождении устройства в случае пропажи или кражи.

Далее в разделе описывается прежняя архитектура LoJack. Злоумышленниками была троянизирована только старая версия ПО, поэтому мы сфокусируемся на ней. Кроме того, Absolute Software выпустила в мае 2018 года заявление о том, что уязвимости, описанные ниже, не влияют на работу последних версий их агентов.

Программа Computrace привлекла внимание ИБ-специалистов, поскольку использовала необычный метод обеспечения персистентности. Ее целью является защита от кражи, поэтому для нее важна устойчивость к переустановке ОС и замене жесткого диска — все это реализовано в модуле UEFI/BIOS, способном выжить после этих действий. Решение предустанавливается в прошивке значительной части ноутбуков разных производителей, пользователю нужно лишь активировать эту функцию. Активацию можно выполнить в BIOS, как показано на рисунке ниже.

Рисунок 1. Активация Computrace в BIOS

Один из первых отчетов о реализации LoJack/Computrace был опубликован в 2009 году. Была раскрыта глобальная архитектура продукта, процесс сбрасывания модулем UEFI/BIOS пользовательского агента на диск и способ связи агента с веб-сервером, подконтрольным Absolute Software. Схему можно понять из рисунка ниже.

Рисунок 2. Механизм персистентности LoJack (примерно 2008 год)

Ниже приведено описание шагов, перечисленных выше:

1. В случае активации модуль UEFI/BIOS выполняется при загрузке. Он пытается найти раздел FAT/FAT32/NTFS. Затем с помощью драйвера NTFS он создает бэкап файла autochk.exe и переписывает его содержимое посредством дроппера, отвечающего за установку компонента пользовательского агента. Файл autochk.exe — исполняемый файл Windows, запускаемый на ранней стадии загрузки системы для проверки возможного повреждения жесткого диска.

2. Когда запускается измененный autochk.exe, его главной целью является внедрение мини-агента rpcnetp.exe и добавление его как службы, чтобы он запускался при каждой перезагрузке. Последний этап работы этого компонента — восстановление оригинальной версии autochk.exe.

3. Мини-агент rpcnetp.exe — небольшой исполняемый файл, целью которого является обеспечение работы основного агента. Если основной агент не работает, rpcnetp.exe пытается подключиться к командному C&C-серверу Absolute Software для его скачивания и исполнения. Сначала мини-агент сделает копию себя, затем внесет изменения в PE заголовок для преобразования в DLL. Эта библиотека затем загружается в память, вызывает процесс svchost.exe и инжектирует туда DLL. Далее запускается процесс iexplore.exe Internet Explorer, и DLL будет инжектирована в него. Последний процесс затем будет использован для связи через интернет. Инжект в сторонние процессы, выполняемый мини-агентом Computrace, часто встречается во вредоносном ПО и редко ассоциируется с легитимным софтом.

4. Теперь полнофункциональный агент работает в системе и может использовать функции Computrace для отслеживания и восстановления.

Описание этого процесса и сетевого протокола, задействованного между мини-агентом и C&C-сервером, было опубликовано в 2014 году. Ввиду отсутствия механизма аутентификации, если злоумышленники контролируют сервер, с которым связывается мини-агент, они могут заставить его скачать произвольный код. Есть несколько механизмов, позволяющих атакующим связаться напрямую с мини-агентом. Наиболее важный для нас использует способ получения мини-агентом адреса C&C-сервера. По факту эта информация хранится в файле конфигурации в самом исполняемом файле.

Рисунок 3. Зашифрованный файл конфигурации LoJack с частичной расшифровкой справа

На рисунке показан файл конфигурации мини-агента LoJack. Использованный метод «шифрования» — простой XOR с однобайтовым ключом. Ключ 0xB5 одинаков для всех изученных мини-агентов. Как видно из рисунка, домен C&C задан в файле. Четыре предшествующие байта содержат IP адрес командного C&C-сервера. В отсутствие валидации по содержимому файла конфигурации, злоумышленники с правами на запись в %WINDIR% могут поменять его содержимое так, что мини-агент будет связываться с их командным сервером, вместо легитимного. Понимая сетевой протокол, можно заставить мини-агент скачать и исполнить произвольный код. Эти риски давно известны, но до недавнего времени механизм не был использован на практике.

LoJack превращается в LoJax

В мае 2018 года в блоге Arbor Network были описаны троянизированные образцы мини-агента LoJack, rpcnetp.exe. Их жестко прописанные сетевые настройки были изменены таким образом, что вредоносные образцы устанавливали связь с С&C-сервером атакующих вместо легитимного сервера Absolute Software. Некоторые домены из числа обнаруженных в троянизированных образцах встречались и ранее — они использовались в конце 2017 года в качестве доменов C&C-серверов для SedUploader — бэкдора первого этапа кибергруппы Sednit. На рисунке ниже показан пример измененной конфигурации в одном из мини-агентов LoJax.

Рисунок 4. Слева — легитимный файл конфигурации, справа — измененный

Различия между легитимным и троянизированным агентами крайне малы, выше приведены почти все. Образцы мини-агента LoJax, которые мы смогли обнаружить — троянизированные версии одного и того же образца мини-агента Computrace, rpcnetp.exe. У всех них идентичные временные метки компиляции и лишь несколько десятков байтов отличаются от оригинала. Помимо изменений в файле конфигурации, есть различия в переменных таймера, определяющих интервалы между соединениями с командным C&C-сервером.

На момент публикации мы обнаружили различные мини-агенты LoJax, используемые в атаках на различные организации на Балканах, в Центральной и Восточной Европе, но у нас не было идей насчет способа их установки. Очевидным объяснением была бы установка с помощью одного из известных бэкдоров Sednit. Не стоит забывать, что LoJack, как хорошо себя зарекомендовавший инструмент, был внесен в белый список многими антивирусными вендорами. Таким образом, даже если в данной кампании использовался только мини-агент, который не выживал после переустановки Windows, у него все равно было преимущество — меньше вероятности детектирования в качестве вредоносного ПО. Но что, если компрометация была еще глубже, и атакующие попытались скопировать LoJack, чтобы дойти до системной прошивки?

Охота за компонентом нижнего уровня

Мы зафиксировали атаки LoJax, нацеленные на несколько организаций на Балканах, в Центральной и Восточной Европе. Во всех них нам удалось найти следы вредоносного ПО Sednit, включая:

SedUploader, бэкдор первого этапа
XAgent, флагманский бэкдор Sednit
Xtunnel, сетевой прокси-инструмент, который может передавать любой сетевой трафик между С&C-сервером в интернете и конечным компьютером в локальной сети

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

Бэкдор XAgent как правило скидывает дополнительные модули в скомпрометированную систему, поэтому на ум сразу приходит, что образцы LoJax доставлялись тем же способом, без каких-либо других механизмов. Можно было бы предположить, что Sednit позаимствовали у решения LoJack только мини-агент. Однако вскоре после начала анализа мы нашли несколько улик, указывающих на то, что источник вдохновения был несколько обширнее.

Драйвер RWEverything (RwDrv) и info_efi.exe

Первая улика была найдена благодаря кастомному инструменту злоумышленников, который при выполнении выгружал информацию о настройках системы нижнего уровня в текстовый файл. Инструмент был обнаружен вместе с некоторыми образцами LoJax. Следующий рисунок показывает фрагмент файла с логами этого инструмента под логичным названием info_efi.exe.

Рисунок 5. Выдержка из файл-логов, генерируемых info_efi .exe

Для чтения такого типа информации инструмент имеет в составе драйвер под названием RwDrv.sys. Драйвер ядра идет вместе с RWEverything, бесплатной утилитой, доступной в сети, которая может применяться для прочтения информации по почти всем настройкам нижнего уровня, в том числе интерфейсу PCI Express, памяти, PCI Option ROMs и т.д. Драйвер ядра является легитимным ПО и подписан действительным сертификатом.

Рисунок 6. Сертификат подписи кода RwDrv.sys

ПО RWEverything идет в комплекте с графическим пользовательским интерфейсом, позволяющим получить доступ ко всей этой информации.

Рисунок 7. Скриншот интерфейса RWEverything

Обнаружение инструмента info_efi было первым знаком того, что UEFI модуль LoJax может существовать. При попытке обновить системную прошивку важно иметь информацию о ее вендоре, версии и т.д. Учитывая наличие уязвимостей, позволяющих пользовательским процессам получать доступ и изменять содержимое SPI флеш-памяти там, где хранятся модули UEFI, получение данных о системной прошивке является первым шагом к успешной атаке.

Финальной зацепкой, позволившей нам найти первый UEFI-руткит группы Sednit, стали два инструмента — для дампа SPI флеш-памяти и для записи в нее.

Дамп SPI флеш-памяти

Первым кусочком паззла стал файл под названием ReWriter_read.exe. Он содержал весь код, требуемый для дампа системной SPI флеш-памяти с помощью драйвера RWEverything, RwDrv.sys. Чтобы драйвер устройства произвел необходимые операции, инструмент для дампа должен отправить корректные коды управления вводом-выводом (IOCTL). В то время как RwDrv.sys поддерживает множество различных кодов IOCTL, инструмент-дампер и инструмент для записи, описанные в этом и следующем разделе, используют лишь четыре из них.

RwDrv.sys: поддерживаемые коды IOCTL:

0×22280c — пишет в область памяти, отведенной под ввод-вывод
0×222808 — считывает область памяти, отведенной под ввод-вывод
0×222840 — считывает dword из заданного регистра конфигурации PCI
0×222834 — пишет байт в заданный регистр конфигурации PCI

ReWriter_read сначала создает службу с встроенным драйвером ядра RwDrv.sys и записывает информацию о конфигурации UEFI/BIOS, соответствующие значения трех полей, содержащихся в регистре управления BIOS (BIOS_CNTL): BIOS Lock Enable (BLE), BIOS Write Enable (BIOSWE) и SMM BIOS Write Protect Disable (SMM_BWP). Несмотря на то, что ReWrite_read не использует эти значения, в следующих разделах мы поясним, почему эти поля представляют интерес для данного инструмента.

Следующей задачей инструмента является получение базового адреса области памяти BIOS в SPI и ее размер. Эта информация содержится в регистре главного интерфейса SPI как BIOS Flash Primary Region. Все регистры отображены в памяти в Root Complex Register Block (RCRB), базовый адрес которой может быть получен путем прочтения нужного конфигурационного регистра PCI Configuration Register. ReWriter_read получает этот адрес через использование RwDrv IOCTL 0×22840 и прочтение корректного отступа (в нашем случае 0xF0). Как только базовый адрес области BIOS и ее размер известны, инструмент для дампа читает соответствующее содержимое SPI флеш-памяти и пишет его в файл на диске. Процесс чтения SPI флеш-памяти проиллюстрирован в следующем рисунке. Определения сокращений приведены ниже, в глоссарии.

Рисунок 8. Рабочая последовательность чтения из SPI флеш-памяти

Кроме двух первых шагов, исполняемых только один раз, операции повторяются в цикле, пока не будут прочтены все данные из SPI флеш-памяти. Процесс также хорошо описан здесь. Затем ReWriter_read проводит валидацию размера слитого образа. Он парсит дескриптор памяти образа для получения диапазона BIOS, областей Gigabit Ethernet (GbE) и Management Engine (ME). Добавление размеров этих трех областей позволяет инструменту-дамперу вычислить все содержимое SPI флеш-памяти. Если размер совпадает с размером, полученным из чтения области регистра BIOS Flash Primary, образ считается верным.

Патч прошивки UEFI

Вторым кусочком паззла был файл под названием ReWriter_binary.exe. В этом файле содержится доказательство того факта, что Sednit добрались до прошивки. Файл содержит код для применения патча выгруженного образа UEFI и обратной записи троянизированной версии в SPI флеш-память. В данном разделе опишем, как устроен этот бинарный файл.

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

Хранящиеся в UEFI образе данные разложены по томам посредством файловой системы (FFS). Как следует из названия, это специальная файловая система для хранения образов прошивки. Тома содержат файлы с идентификаторами GUID. Каждый файл обычно состоит из множества секций, одна из которых содержит собственно исполняемый PE/COFF, являющийся образом UEFI. Ниже для более простого понимания схемы приведен скриншот из UEFITool, опенсорсного проекта для работы с образами прошивки UEFI.

Рисунок 9. Пример загруженного в UEFITool образа прошивки UEFI

ReWriter_binary анализирует все тома прошивки, найденные в области BIOS SPI флеш-памяти и ищет определенные файлы:

Ip4Dxe (8f92960f-2880–4659-b857–915a8901bdc8)
NtfsDxe (768bedfd-7b4b-4c9f-b2ff-6377e3387243)
SmiFlash (bc327dbd-b982–4f55–9f79–056ad7e987c5)
DXE Core

Рисунок 10. Результат использования декомпилятора Hex-Rays в томах прошивки

Ip4Dxe и NtfsDxe — драйверы DXE. В UEFI прошивке драйверы DXE — образы PE/COFF, созданные либо для аппаратной абстракции, либо для организации работы служб для использования другими драйверами DXE или UEFI приложениями. Такие драйверы обнаруживаются и загружаются DXE Foundation через DXE диспетчер (ядро DXE) на ранней стадии процесса загрузки. После завершения этой фазы все службы, такие как OS loader, доступны для работы с UEFI приложениями. Обычно DXE драйверы хранятся в одном и том же томе. Однако DXE dispatcher может быть в отдельном.

ReWriter_binary ищет Ip4Dxe только для того, чтобы понять, содержит ли данный том драйверы DXE. Как мы опишем позднее, этот том становится кандидатом для установки вредоносного драйвера DXE driver. Он также ищет ядро DXE и добавляет том, в котором он расположен, в качестве другого кандидата на место под запись руткита. Свободное доступное пространство в каждом из этих томов хранится и позже используется для проверки достаточности для добавления вредоносного драйвера.

NtfsDxe — драйвер AMI NTFS DXE. Если он присутствует в томе прошивки, его расположение сохраняется и позже используется, чтобы убрать этот файл из тома. В разделе, посвященном UEFI руткиту, мы увидим, почему он удаляет этот файл.

Что касается образа SmiFlash, то информация, относящаяся к нему, хранится, но в малвари нигде не используется. Что интересно, образ уязвим. Поэтому мы считаем, что операторы Sednit могут работать над использованием этих уязвимостей. Это может позволить им записывать в SPI флеш-память даже правильно сконфигурированных систем. Как мы расскажем далее, в текущем виде инструмент может записывать только в область BIOS неправильно сконфигурированных или достаточно старых систем (на материнских платах с чипсетами старше Platform Controller Hub, представленными примерно в 2008 году).

После выделения необходимых метаданных ReWriter_binary патчит дамп образа UEFI и добавляет вредоносный драйвер DXE. Сначала он создает заголовок файла (EFI_FFS_FILE_HEADER). Затем он выбирает том места назначения, руководствуясь расположением Ip4Dxe и ядра DXE, а также свободным местом, доступным в этих томах. ReWriter_binary встраивает сжатый раздел, содержащий образ PE и раздел User interface, определяющий человеко-читаемое имя файла: SecDxe. Сжатый раздел добавляется к заголовку файла и пишется в конец тома, в свободное пространство. На рисунке ниже показана структура — ее отображение в UEFITool.

Рисунок 11. Вид в UEFITool файла SecDxe

Наконец, если драйвер NtfsDxe присутствует в образе, он будет удален. Файловая система прошивки хранит файлы и их содержимое последовательно, поэтому процесс достаточно прост:

находится отступ до свободного места в конце тома
поверх образа NtfsDxe пишется 0xFF байтов
последующая часть тома прошивки копируется, начиная с отступа там, где располагался NtfsDxe
остальная часть файловой системы заполняется 0xFF байтами, то есть свободным местом

Запись пропатченной прошивки обратно в SPI флеш-память

После успешного внесения изменений в образ прошивки следующий этап — ее запись обратно в SPI флеш-память. Перед тем, как погрузиться в этот процесс, нам необходимо охарактеризовать некоторые защиты от записи BIOS, важные в данном случае. Другие существующие механизмы, такие как BIOS Range Write Protection, остаются в стороне, так как их ReWriter_binary не проверяет.

Платформа применяет несколько защитных механизмов для блокирования неавторизованных попыток записи в область BIOS. Нужно сказать, что эти механизмы по умолчанию не включены. За их корректную настройку отвечает прошивка. Эти конфигурации представлены в регистре управления BIOS (BIOS_CNTL). Он содержит бит BIOS Write Enable (BIOSWE), который необходимо переключить на »1» для получения возможности записи в область BIOS флеш-памяти SPI. Так как платформа не должна позволять какие-либо попытки записи в область BIOS, есть еще один бит в BIOS_CNTL для защиты BIOSWE — это BIOS Lock Enable (BLE). Когда он выставлен, механизм должен блокировать бит BIOSWE и оставлять значение равное »0». Однако решение имеет уязвимость. Когда приходит запрос смены бита BIOSWE на »1», бит BIOSWE на »1», и лишь после этого платформа прерывает задачу с помощью System Management Interrupt (SMI), код этого SMI выполняет смену бита BIOSWE обратно на »0».

В данной версии решения есть множество проблем. Во-первых, обработчик SMI оставлен для разработчиков прошивки. Поэтому если в прошивке не реализован этот код, бит BLE оказывается бесполезен, так как назад на »0» бит BIOSWE выставляться не будет. Во-вторых, в таком случае мы имеем «уязвимость состояния гонки», которая позволяет полностью обойти этот механизм, даже если обработчик SMI реализован корректно. Для применения этой уязвимости атакующему необходимо запустить поток, непрерывно выставляющий BIOSWE на »1», в то время как другой поток должен писать данные в SPI флеш-память. Согласно работе Калленберга и Войтчука, эта атака работает на многоядерных процессорах и также может успешно применяться на одноядерных процессорах с включенной технологией Hyper-Threading.

Для решения этой проблемы в платформу был добавлен новый механизм защиты, сконфигурированный через BIOS_CNTL. Он введен в семействе чипсетов от Intel Platform Controller Hub (PCH). Если бит конфигурации выставлен, SMM BIOS Write Protect Disable (SMM_BWP) обеспечит возможность записи в область BIOS только в том случае, если все ядра работают в режиме System Management Mode (SMM) и BIOSWE выставлен на значение »1». Это эффективно защищает систему от «уязвимости состояния гонки», описанной выше. Однако, как и в случае с BLE, SMM_BWP нужно активировать со стороны прошивки. Поэтому прошивка, в которой неверно настроены эти механизмы, оставляет в системе риск предоставления неавторизованного права записи в область BIOS.

ReWriter_binary читает содержимое регистра управления BIOS, чтобы выбрать верный путь.

Сначала он проверяет, выставлен ли BIOSWE. Если это так, он переходит в фазу записи. Если BIOSWE отключен, он проверяет значение бита BLE. Если оно не установлено, он меняет значение бита BIOSWE и начинает записывать пропатченную прошивку. Если бит BLE установлен, он проверяет отключенное состояние SMM_BWP и применяет «уязвимость состояния гонки», описанную выше. Если бит SMM_BWP выставлен, операция завершается неуспешно. Рисунок ниже иллюстрирует процесс.

Рисунок 12. Древовидная схема принятия решения в процессе записи

Предполагая, что конкретный анализируемый файл ReWriter_binary использовался для развертывания UEFI руткита, можно прийти к заключению, что либо прошивка неверно сконфигурировала защиту от записи BIOS, либо чипсет машины жертвы старше, чем Platform Controller Hub.

ReWriter_binary не смог бы заменить прошивку UEFI на хорошо настроенной современной системе. Однако при поиске уязвимого образа SmiFlash UEFI парсинг томов прошивки UEFI предполагает, что злоумышленники могли работать и с более продвинутыми техниками обхода защиты записи BIOS.

Очень похожим на процедуру чтения образом происходит запись в SPI флеш-память:

Рисунок 13. Последовательность записи в SPI флеш-память

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

Когда процесс записи выполнен, содержимое SPI флеш-памяти выгружается еще раз в файл image.bin. Та же самая проверка целостности, которая проводилась ReWriter_read, выполняется на новом слитом образе. Затем образ, прочитанный из SPI флеш-памяти, сравнивается с пропатченным образом в памяти.

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

На финальном этапе ключ реестра устанавливается на значение:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute = "autocheck autochk *”

Затем служба RwDrv останавливается и удаляется. Важно, что ключу системного реестра Windows присваивается значение этой строки, так как руткит UEFI ищет именно эту строку для ее изменения и исполнения своего компонента в процессе запуска Windows. Мы более подробно расскажем об этом, когда будем описывать руткит UEFI и его компоненты.

Технический анализ LoJax

Инструмент для дампа, патчинга и записи в SPI флеш-память кастомизирован для конкретного образа прошивки и его нельзя использовать на любой системе. При этом полный модуль UEFI выделить можно. Первое, что мы сделали после получения этого модуля — изучили данные телеметрии, чтобы узнать, встречался ли он ранее. В этом нам пришлось полагаться на новый сканер UEFI, который может сканировать системную прошивку. Мы установили, что модуль UEFI группы Sednit был установлен в системе как минимум один раз, а это означает, что данный руткит действительно применяется in-the-wild.

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

На рисунке ниже представлен обзор работы UEFI руткита вплоть до загрузки ОС. Сначала драйвер SecDxe DXE загружается диспетчером DXE. Таким образом настраивается функция уведомления по группе событий EFI_EVENT_GROUP_READY_TO_BOOT. Когда прошивка готова выбрать устройство загрузки и запустить загрузчик ОС, вызывается функция уведомления. Она выполняет три действия:

загружает встроенный драйвер NTFS DXE для предоставления доступа и возможности записи в разделы NTFS
пишет два файла в раздел NTFS Windows: rpcnetp.exe и autoche.exe
меняет ключ реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\BootExecute»: до: «autocheck autochk *»; после: «autocheck autoche *» .

Рисунок 14. Процесс загрузки системы, зараженной руткитом UEFI

SecDxe: Вредоносный драйвер DXE

В данном разделе мы раскроем последовательность событий, происходящих в скомпрометированной системе. Начнем с описания руткита, а затем следуем по цепочке событий вплоть до финальных компонентов, разворачиваемых на уровне операционной системы.

UEFI руткит группы Sednit — это драйвер DXE с GUID идентификатором 682894B5-6B70-4EBA-9E90-A607E5676297.

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

SecDxe — небольшой драйвер DXE, который, в основном, делает две вещи. Он устанавливает протокол, определяемый по GUID 832d9b4d-d8d5-425f-bd52-5c5afb2c85dc, который никогда не используется. Затем он создает связанное с функцией уведомления событие. Функция уведомления настраивается на вызов, по сигналу на группу EFI_EVENT_GROUP_READY_TO_BOOT. Сигнал на эту группу событий приходит от менеджера загрузки, когда он готов к выбору устройства для загрузки.

Рисунок 15. Результат прохода декомпилятора Hex-Rays по процессу создания события

Функция уведомления использует вредоносное поведение UEFI руткита Sednit. Она пишет компоненты в файловую систему NTFS Windows. Как правило, прошивка UEFI единолично работает с разделом системы EFI, поэтому драйвер NTFS обычно не включен. Только файловые системы на FAT поддерживаются как разделы для загрузки. Поэтому UEFI прошивка не обязательно идет в комплекте с драйверами NTFS. По этой причине SecDxe имеет свой встроенный NTFS драйвер. Этот драйвер загружается первым и соединяется с дисковым устройством. То есть устанавливает EFI_SIMPLE_FILE_SYSTEM_PROTOCOL на дисковые устройства с NTFS разделами, таким образом включая к ним файловый доступ.

Теперь, когда все готово для записи файлов в разделы Windows, SecDxe сбрасывает rpcnetp.exe и autoche.exe. Затем rpcnetp.exe устанавливается в %WINDIR%\SysWOW64 на 64-битных версиях Windows или %WINDIR%\System32 на 32-битных версиях. А autoche.exe устанавливается в %WINDIR%\SysWOW64. На следующем рисунке показан процесс, отвечающий за запись этих файлов на диск.

Рисунок 16. Результат прохода декомпилятора Hex-Rays по процессу записи файлов на диск

Затем SecDxe открывает %WINDIR%\System32\config\SYSTEM, файл с бэкапом набора ключей реестра HKLM\SYSTEM. Он парсит файл, пока не находит ‘autocheck autochk *’ и не заменяет ‘k’ в ‘autochk’ на ‘e’. В результате ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute’ меняется на ‘autocheck autoche *’. При следующей загрузке Windows autoche.exe будет запущен вместо autochk.exe.

Драйвер NTFS от Hacking Team

Как уже раньше обсуждалось, в модуль SecDxe встроен драйвер NTFS. Есть серьезные доказательства того, что операторы Sednit не стали писать собственный драйвер, а скомпилировали копию обнародованного драйвера NTFS DXE от Hacking Team.
Их драйвер NTFS в качестве ядра использует опесорсный проект ntfs-3g. Это просто обертка, чтобы заставить его работать как драйвер UEFI DXE. Сам по себе файл INF с информацией о сборке драйвера Hacking Team перечисляет имена файлов проекта ntfs-3g. В строках кода SecDxe NTFS драйвера также перечисляются многие из этих имен файлов:

- c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c - c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c

Интересно отметить, что путь к проекту совпадает с тем, что можно обнаружить у vector-edk, проекта Hacking Team по разработке EFI. В vector-edk есть субпроект NtfsPkg с абсолютно идентичной схемой директорий. Файлы исходного кода проекта ntfs-3g находятся по тому же адресному пути. И хотя сами по себе пути ничем не примечательны, мы считаем, что это не простое совпадение.

Сравнивая утекший в сеть исходный код с тем, что мы получили на выходе декомпилятора Hex-Rays, становится очевидно, что это один и тот же проект. На рисунке ниже представлен пример сравнения функции NtfsDriverBindingStart, взятой из vector-edk/NtfsPkg/NtfsDxe/Ntfs.c. Комментарии из оригинального кода HT убраны для лучшего восприятия. Логика и последовательность вызовов функций одинаковы. Оба проекта даже используют од