Исследования в области безопасности UEFI BIOS уже не являются чем-то новомодным, но в последнее время чувствуется некоторый дефицит образовательных материалов по этой теме (особенно —  на русском языке). В этой статье мы постараемся пройти весь путь от нахождения уязвимости и до полной компрометации UEFI BIOS. От эксплуатации execute примитива до закрепления в прошивке UEFI BIOS. Автор статьи Закиров Руслан @backtrace. Предполагается, что читатель уже знаком с основами UEFI BIOS и устройством подсистемы SMM.   В качестве подопытного кролика мы взяли ноутбук DELL Inspiron 7567. Причины выбора этого ноутбука следующие: нам известно, что в старой прошивке этого ноутбука есть известная уязвимость CVE-2017-5721, а также он есть у нас в наличии. Первое, что происходит с ноутбуком при начале исследований - определение местоположения SPI флеш-памяти на материнской плате. Обнаружить этот чип можно визуально после разборки ноутбука. SPI флеш-память практически всегда находится на нижней стороне материнской платы, поэтому полный разбор ноутбука не требуется. Иногда даже достаточно снять крышку для доступа к HDD. После обнаружения SPI флеш-памяти есть 2 варианта развития событий: Подключаем любым доступным способом флеш-память к программатору напрямую от ноутбука (строго в выключенном состоянии); Выпаиваем этот чип, для того чтобы можно было поместить его в кроватку (адаптер), что позволит быстро переподключать флеш-память от ноутбука к программатору и обратно. Мы в нашей работе используем универсальный программатор ChipProg-481, но, в целом, подойдёт любой SPI программатор. Наличие программатора необходимо, поскольку ошибка при работе с содержимым флешки может привести к тому, что ноутбук станет "кирпичом". В таком случае восстановление его работоспособности будет возможно лишь при помощи перезаписи содержимого SPI флеш-памяти заранее снятым с нее дампом "до экспериментов". Также наличие программатора позволит заливать модифицированные прошивки со специальным "бэкдором" для расширение возможностей анализа.   Наша работа будет производиться над версией прошивки 1.0.5 (link). При отсутствии возможности откатиться до этой версии прошивки вы можете воспользоваться нашим дампом. После снятия дампа с SPI флеш-памяти возникает необходимость открыть этот бинарный файл. Для этой цели существует UEFITool, который позволяет не только просматривать содержимое прошивки UEFI BIOS, но и производить поиск, извлекать, добавлять, заменять и удалять компоненты прошивки. Функции, связанные с пересборкой прошивки доступны только в Old Engine версии. Для остальных задач лучше использовать New Engine (содержит "NE" в названии файла).   Довольно часто нужные кодовые модули EFI можно найти внутри дампа по их названиям (напрмер, UsbRt). Но в некоторых случаях вендоры не сохраняют информацию о названиях модулей в прошивке. В таком случае поиск требуемого модуля следует производить при помощи его GUID, но это сработает только с общеизвестными модулями. Нередко разработчики BIOS добавляют в прошивки проприетарные модули, и при отсутствии информации о названиях модулей приходится придумывать свои собственные.   GUID модулей можно найти в следующих источниках: В открытой реализации UEFI EDKII В репозитории (U)EFI Whitelisting Project В прошивке UEFI BIOS другого ноутбука, в котором названия модулей сохранены В интегрированных базах различных инструментов и плагинов При анализе модулей наиболее полезными инструментами являются IDA Pro и Ghidra. Но наличие только этих инструментов будет недостаточно. В этих материалах можно подробно узнать об актуальных инструментах при исследовании UEFI BIOS: How efiXplorer helping to solve challenges in reverse engineering of UEFI firmware Арсенал исследователя UEFI BIOS (слайды) Нам понадобятся следующие инструменты: UEFITool - о нем говорилось выше CHIPSEC - при помощи этого фреймворка мы будем разрабатывать наш PoC RWEverything - очень полезный инструмент, который позволяет взаимодействовать с различными аппаратными ресурсами компьютера, и все это при помощи GUI Плагины для IDA Pro: efiXplorer и/или ida-efitools2 Если вы приверженец Ghidra, то вам понадобится плагин efiSeek Для обработки дампа SMRAM нам понадобится скрипт smram_parse Это не исчерпывающий, но достаточный список инструментов этой тематики. Как можно заметить, все перечисленные инструменты относятся к типу инструментов статического анализа. Как же обстоят дела с инструментами динамического анализа? Можно рассмотреть следующий список актуальных инструментов: efi_dxe_emulator qiling Несмотря на существование подобных инструментов и их активное развитие, в практическом плане при поиске уязвимостей в подсистеме SMM они представляют нулевую ценность, поскольку ориентированы на эмуляцию фаз PEI и DXE.   В таком случае появляется вопрос: как же производить отладку? Отладку можно производить при помощи технологии Intel DCI. Информацию об использовании данной технологии можно получить из следующих материалов: Tapping into the Core Debug UEFI code by single-stepping your Coffee Lake-S hardware CPU Debugging System with DCI and Windbg Проблема этой технологии в том, что работает она далеко не везде. Поэтому отладка зачастую производится методом проб и ошибок.   Попробуем самостоятельно найти уязвимость в модуле UsbRt. Для начала откроем дамп BIOS в UEFITool, после чего сделаем поиск по тексту "UsbRt", и обнаружим, что это название в прошивке отсутстует (вендор не оставил информацию о названиях модулей) либо называется он по-другому.Произведя поиск в различных источниках (например, здесь) мы определяем, что модулю UsbRt соответствует GUID 04EAAAA1-29A1-11D7-8838-00500473D4EB. Теперь, при помощи поиска по GUID, мы можем извлечь соответствующую секцию образа PE32. На самом деле UEFITool содержит в себе базу общеизвестных GUID-ов, но надпись "USBRT" пришлось бы искать глазами, поскольку поиск по тексту не включает в себя записи из базы GUID-ов.   Здесь и далее будет использоваться инструмент IDA Pro с указанными выше плагинами, но все необходимые манипуляции доступны и в Ghidra.   После открытия модуля UsbRt в IDA Pro нам необходимо найти обработчик software прерываний. Чаще всего все достаточно просто - после отработки плагина ida-efitools2 функция уже подписана как "DispatchFunction". Но в данном случае эта функция относится к протоколу EFI_SMM_USB_DISPATCH2_PROTOCOL, который нас не сильно интересует. Нам следует отталкиваться от перекрестных ссылок на EFI_SMM_SW_DISPATCH2_PROTOCOL_GUID, чтобы определить место использования интересующего нас протокола. Так мы сможем понять какая функция регистрируется в качестве обработчика software прерываний. Я назвал обнаруженный обработчик как "SwDispatchFunction". Также можно заметить, что этому обработчику соответствует SMI прерывание #31h.    Здесь стоит обратить внимание на некий глобальный указатель на структуру "usb_data", на основе которой происходит много операций. Из неё же извлекается структура "request", откуда в свою очередь извлекается некий индекс. Ниже можно заметить, что на основе индекса происходит вызов функции из массива.    Сделаем вид, что просмотрели все 24 функции, и наибольший интерес у нас вызвала функция с индексом 14 (sub_80003080), которую назовём как "subfunc_14".   Функция, после нескольких арифметических операций, извлекает и передает указатель из структуры usb_data в следующую функцию:  Здесь мы обнаруживаем просто изумительную функцию! Помимо возможности исполнить произвольный адрес эта функция так же позволяет передать вплоть до 7 аргументов! Но главный вопрос - можем ли мы управлять передаваемым указателем?    Приступим к изучению указателя usb_data. Список перекрестных ссылок не оставляет никаких надежд усомниться в местонахождении инициализации данного указателя:  Судя по всему, нам придётся искать модуль, который производит установку протокола EFI_USB_PROTOCOL (сразу после того как убедились, что этот протокол не устанавливается в модуле UsbRt):  На данном этапе, возможно, уместно было бы воспользоваться плагином efiXplorer для поиска нужного модуля, но мы сделаем по старинке. Копируем GUID интересующего нас протокола (ida-efitools2 позволяет это делать при помощи горячей клавиши Ctrl-Alt-G) либо извлекаем соответствующие этому GUID байты. Полученную информацию используем для поиска в прошивке при помощи UEFITool (ставим галочку Header and body). Сразу можно отсечь модули, у которых вхождения не только в PE32, но и в "MM dependecy section" (секция зависимостей модуля), поскольку модуль не может одновременно предоставлять протокол и зависеть от него.На выбор остаётся Bds, SBDXE, Setup, CsmDxe, UHCD, KbcEmul и некий безымянный модуль. Можно бегло просмотреть все эти модули на предмет установки протокола EFI_USB_PROTOCOL, но что-то мне подсказывает, что первая буква в аббревиатуре UHCD означает Usb, поэтому перейдем сразу к нему.    EFI_USB_PROTOCOL действительно устанавливается в этом модуле. Тут же мы видим указатель usb_data. Также важно отметить, что в первое поле структуры EFI_USB_PROTOCOL записывается сигнатура "USBP" ('PBSU' при обратном порядке байтов). Осталось понять, откуда берётся usb_data.    Структура аллоцируется при помощи той же функции, что и в случае с EFI_USB_PROTOCOL. Также устанавливается сигнатура "$UDA" (Usb DAta?). Как же происходит аллокация памяти?    Вот где собака зарыта! Память выделяется при помощи EFI_BOOT_SERVICES, т.е. в фазе DXE. Это значит, что память не размещена внутри SMRAM, поэтому ОС имеет полный доступ к этой памяти, осталось только найти нужные структуры в ней. Тут не помешает отметить, что память выделяется с типом "AllocateMaxAddress", из-за чего с высокой долей вероятности выделенный буфер будет располагаться где-то неподалеку от начала SMRAM.    У нас начинает вырисовываться следующий алгоритм эксплуатации обнаруженной уязвимости: Ищем в памяти сигнатуру "$UDA" - так мы установим расположение структуры usb_data; По определенному смещению заменяем указатель в структуре на подконтрольный адрес; Также обновляем структуру request в usb_data, чтобы вынудить обработчик исполнить subfunc_14; В той же структуре можно указать буфер с нашими аргументами для вызываемой функции; Генерируем software прерывание #31h. Для всех перечисленных действий нам потребуется привилегии ядра (Ring 0). Но писать эксплоит в виде системного драйвера выглядит довольно трудозатратно и долго.Под эту задачу идеально подходит фреймворк CHIPSEC, который написан на Python, и который имеет все необходимые примитивы по работе с физической памятью, PCI, прерываниями и прочими аппаратными функциями.CHIPSEC для доступа к аппаратным ресурсам использует собственный самоподписанный системный драйвер. Из-за этого ОС необходимо переключать в тестовый режим. Но CHIPSEC также позволяет использовать драйвер RWEverything, который имеет валидную цифровую подпись. Этот вариант имеет некоторые подводные камни, как, например, ограничение на размер выделяемой физической памяти, который не может превышать 0x10000 байт. Инициализация и генерирование прерывания через фреймворк CHIPSEC выглядит следующим образом: Приступим к поиску usb_data в памяти. Мы пользуемся особенностью памяти, выделенной по типу AllocateMaxAddress, производя поиск от SMRAM в обратном порядке. Также нет смысла сверять каждый байт, поскольку для этого буфера выделялись страницы памяти, поэтому шагаем по 4096 байт.   Теперь подготовим нашу структуру request и обновим соответствующий указатель в usb_data: И самое интересное - изменяем указатель по смещению 0x78 (именно такое значение получается после всех вычислений в функции subfunc_14) в структуре usb_data. Модуль UsbRt затем попытается его исполнить в процессе обработки прерывания. По исполнению этого кода можно заметить, что система намертво зависла. Но дело совсем не в том, что по адресу 0x12345678 располагается невесть что, а в том, что произошло аппаратное исключение Machine Check Exception. Наступило оно по причине того, что современные платформы предотвращают исполнение SMM кода вне региона SMRAM (SMM_Code_Chk_En).   Обойти это ограничение относительно легко - достаточно посмотреть адрес функции memcpy в модуле UsbRt (или любом другом) в дампе SMRAM. Но без дампа SMRAM адрес так просто не узнать. И здесь мы переходим ко второй части этой статьи. Главный минус текущего варианта эксплоита в том, что он позволяешь лишь исполнить код по указанному адресу. Для свободы действий необходимо придумать способ развить эксплоит до полноценного read-write-execute примитива.   Мы можем исполнить любой код в SMRAM, но мы не знаем расположение функций внутри SMRAM. Значит, нужно самостоятельно определить базовый адрес какого-либо модуля. И уже относительно этого базового адреса мы сможем получить адрес интересующей нас функции (memcpy, например).   Как мы уже могли заметить, часть используемых данных при работе SMM хранится вне SMRAM. Некоторые структуры инициализируются в процессе работы фазы DXE, и по завершению этой фазы остаются висеть мертвым грузом в зарезервированной памяти, лишая ОС возможности воспользоваться ей. В таких структурах иногда можно обнаружить указатели в область SMRAM. При изучении происхождения этих структур можно наткнуться на очень полезные указатели.   Хорошим примером такой структуры является SMM_CORE_PRIVATE_DATA. Даже название уже интригует. Эти "приватные данные" легко находятся по сигнатуре "smmc" в зарезервированных областях памяти. Структура описана в репозитории EDK2: В нашем случае нам бы очень пригодился указатель PiSmmCoreImageBase, по которому располагается модуль PiSmmCore. К сожалению, наша система старовата, и настоящая структура не совсем соответствует описанию. До некоторого момента последних трёх указателей в этой структуре не существовало, как можно заметить в репозитории. В таком случае мы вынуждены прибегнуть к иному способу.   Мы уже знаем, что в памяти располагаются структуры usb_data и usb_protocol. Вполне возможно, что эти структуры содержат указатели на функции внутри модуля UsbRt.   Если мы вернёмся к месту инициализации указателя usb_data в модуле UsbRt, то можем заметить, что в коде происходит замена некоторых указателей в протоколе EFI_USB_PROTOCOL: Указателями являются функции модуля UsbRt - как раз то, что нам надо. Сконцентрируемся на указателе по смещению +0x50 (+0xA), поскольку он наиболее близок к базовому адресу (это пока не важно).    Извлечь этот указатель достаточно просто: А теперь всё просто: открываем UsbRt в дизассемблере, сопоставляем виртуальный адрес функции с фактическим, находим функцию memcpy, вычисляем разницу между двумя функциями, прибавляем разницу к фактическому адресу полученной функции. Физический адрес функции memcpy получен!   Наш эксплоит теперь можно дополнить. Мы можем, например, сделать полный дамп SMRAM. И возможность передавать аргументы наконец пригодилась: Дамп SMRAM получили. Но на душе все равно как-то гадко. Мы ведь вручную сопоставили адреса функций и посчитали разницу до функции memcpy. Нельзя ли сделать это автоматически? Давайте представим, что мы эксплуатируем ноутбук какого-нибудь члена Национального комитета Демократической партии США. Нам не до сопоставления функций, нужно сделать все в один клик. Более того, нельзя просто взять и положить рядом извлеченный модуль UsbRt. Версия может же отличаться.   Для извлечения актуальной версии модуля идеально подходит специальный регион физической памяти, в которой расположена отображённая на память (memory mapped) флеш-память. Смапленную флеш-память можно прочитать в самом конце 4 ГБ-ного пространства физической памяти. Начало региона зависит от размера флеш-памяти.   Для нас достаточно знать начало и размер BIOS региона. В этом нам поможет регистр BIOS_BFPREG, который находится в SPIBAR. В нем хранятся значения базового смещения и предела BIOS региона внутри флеш-памяти. Это позволяет нам вычислить размер BIOS региона. Поскольку BIOS регион принято хранить последним, то на основе размера этого региона можно определить физический адрес региона в смапленной флеш-памяти.   Благодаря широким возможностям фреймворка CHIPSEC у нас есть возможность в автоматизированном режиме распаковать считанную из памяти часть прошивки и извлечь необходимый модуль. Далее пойдёт очень хитрая математика: У нас есть указатель на функцию из UsbRt, который был наиболее близок к базовому адресу модуля (вот теперь это стало важно); Из него можно вычесть смещение входной точки, что приблизит нас к нашей цели; Осталось вычислить разницу между входной точкой и имеющейся функцией; Для начала можно выравнить указатель вверх до 0x1000 байт, все равно базовый адрес тоже будет выравнен; Затем можно вычесть 0x2000 байт. Почему именно это число? Оно было установлено путем обсервации прошивок других версий и других вендоров. Кстати, занимательный факт: в UEFI модулях SectionAlignment равняется FileAlignment (0x20), из-за чего все смещения внутри файла на диске совпадают со смещениями в образе модуля в памяти. Это сделано для экономии места в регионе SMRAM.   Базовый адрес получен. Дело за малым - определить функцию memcpy. В прошивках UEFI используется memcpy, которая реализована в EDK2 (она на самом деле называется CopyMem). Поэтому она должна совпадать у всех вендоров. Так что будет достаточно безопасно реализовать поиск функции по начальным опкодам. Теперь в нашем арсенале полностью автоматизированный эксплоит, позволяющий не только исполнять код внутри SMRAM, но и произвольно читать и писать в любую область физической памяти. Возможность свободно взаимодействовать с памятью SMRAM - это, конечно, здорово. Но без возможности закрепиться в прошивке полноценная атака не получится, поскольку после перезагрузки системы память сбросится, очевидно. Следующим шагом будет поиск возможности модифицировать прошивку, которая хранится в SPI флеш-памяти.   В первую очередь стоит ознакомиться с результатами тестов CHIPSEC, которые покажут наличие защитных функций флеш-памяти: По результатам тестов можно понять, что в системе действует защита BIOSWE=0 + BLE=1. Это означает, что стандартными функциями записи во флеш-память (доступны в CHIPSEC) у нас не получится что-либо изменить в прошивке. Механизм SPI Protected Ranges не сконфигурирован на этой системе. Это значит, что мы могли бы внести изменения при помощи модуля SMM. Однако, есть еще два механизма, которые могут помешать нам это сделать.   CHIPSEC не может проверить наличие этих механизмов, но в нашей системе они существуют. Эти механизмы - Intel BIOS Guard и Intel Boot Guard. Первый механизм не даст нам произвести запись в кодовые регионы BIOS, а второй, при условии, что мы все же смогли переписать BIOS, не позволит модифицированной прошивке загрузиться при запуске системы.Но мы все же рассмотрим как можно работать с SPI посредством SMM-драйвера.   Возвращаемся к UEFITool и ищем модуль, название которого как-то связано с Flash и SMI. Идеальным кандидатом является модуль FlashSmiSmm. При его детальном изучении в дизассемблере может сложиться впечатление, что он не регистрирует никаких software прерываний, в нем даже EFI_SMM_SW_DISPATCH2_PROTOCOL_GUID не фигурирует! На самом деле этот модуль регистрирует другой тип software прерывания, который называется ACPI SMI. Чтобы определить место регистрации ACPI SMI в IDA Pro можно воспользоваться функцией "List cross references to..." на поле EFI_SMM_SYSTEM_TABLE2.SmiHandlerRegister в окне структур.  Модуль регистрирует один ACPI SMI, предварительно считав UEFI переменную "FlashSmiBuffer", название которой недвусмысленно говорит о том, что в переменной хранится указатель на буфер для работы с флеш-памятью.  Конкретный ACPI SMI идентифицируется своим GUID, который указывается вторым аргументом функции SmiHandlerRegister (HandlerType). В нашем случае это 4052aca8-8d90-4f5a-bfe8-b895b164e482. Он нам далее понадобится. Теперь рассмотрим непосредственно саму функцию обработчика.   FlashSmiBuffer действительно используется для передачи задачи и аргументов. Если переключить отображение констант на символьное представление, то всё становится более менее очевидно:  Fe - Flash Erase Fu - Flash Read (тут чисто логически, не понятно при чем тут "u") Fw - Flash Write Wd - Write Disable We - Write Enable Осталось лишь написать прототип для работы с SPI флеш-памятью, учитывая то, что обработчик реализован в виде ACPI SMI.   Таким незатейливым способом мы смогли заставить SMM драйвер прочитать для нас часть прошивки.   Препарировать UEFI BIOS довольно интересно, хоть и немного однообразно. Когда надоест искать и находить RCE в SMM, можно переключиться на BIOS Guard и Boot Guard, в которых тоже можно найти кучку уязвимостей, а сам процесс поиска доставит кучу удовольствия. А если и это надоест, то самое время переключиться на изучение самого сложного, что можно найти в современных PC - Intel ME.