baton drop (CVE-2022-21894): уязвимость обхода функции безопасности Secure Boot

Загрузочные приложения Windows позволяют параметру truncatememory удалять блоки памяти, содержащие «постоянные» диапазоны сериализованных данных, из карты памяти, что приводит к обходу Secure Boot.

• Элемент BCD truncatememory удаляет всю память выше указанного физического адреса из карты памяти.
• Это выполняется для каждого загрузочного приложения во время инициализации, до чтения сериализованной политики Secure Boot из памяти.
• Следовательно, такой элемент можно использовать для удаления сериализованной политики Secure Boot из карты памяти.
• Это позволяет использовать опасные параметры в загрузочном приложении (bootdebug, testsigning, nointegritychecks), нарушая тем самым Secure Boot.

Эта проблема была исправлена двумя изменениями:

• После попытки загрузки сериализованной политики Secure Boot, если политика не была загружена, Secure Boot включён, загрузочное приложение не было загружено непосредственно прошивкой UEFI и загрузочное приложение не является bootmgr, инициализация загрузочного приложения завершается с ошибкой.
• При загрузке загрузочного приложения, если оно содержит ресурс VERSIONINFO с полем OriginalFilename и это имя файла содержится в блок-листе (включающем bootmgr.exe и hvloader.exe; в Nickel был добавлен hvloader.efi, но это изменение не было перенесено обратно), загрузка завершается с ошибкой.
  • В Windows 8 и Windows 8.1 hvloader.exe не включён в блок-лист winload — изначально он был включён, что ломало загрузку Hyper-V!
  • Начиная с Windows 10 версии 1809, если установлен определённый бит флагов (используется с элементом flightedbootmgr для загрузки bootmgr с диска), поле OriginalFilename обязательно должно быть bootmgr.exe.

Эксплуатация

Атакующему необходимо обеспечить выделение сериализованной политики Secure Boot выше известного физического адреса.

• По умолчанию она выделяется по наименьшему возможному адресу.
• Изначально сериализованная политика Secure Boot выделялась после её загрузки, до использования любой конфигурации, загруженной из BCD.
  • Начиная с RS1, сериализованная политика Secure Boot выделяется при загрузке загрузочного приложения.
  • Начиная с RS2, любая существующая сериализованная политика Secure Boot освобождается при сериализации политики Secure Boot.
• Сериализованная политика Secure Boot перераспределяется, если при загрузке загрузочного приложения элемент osdevice записи BCD является разделом, зашифрованным BitLocker, где VMK был получен с использованием TPM.
  • Это можно имитировать, установив бит 0 флагов ключа после успешной распаковки TPM; этот бит можно установить вручную в метаданных BitLocker, добавив дополнительные метаданные, указывающие на использование Secure Boot для проверки целостности.

Элемент avoidlowmemory можно использовать, чтобы все выделения физической памяти находились выше указанного физического адреса:

• Начиная с Windows 10 этот элемент запрещён, если включена VBS, но поскольку он используется во время инициализации загрузочного приложения, до чтения сериализованной политики Secure Boot из памяти, загрузка bootmgr с указанием пользовательского пути BCD (с помощью элемента bcdfilepath он же custom:22000023) может использоваться для обхода этого ограничения.
• Если на томе ОС присутствует BitLocker или целевая система работает на TH1 или TH2, этот метод не сработает; поэтому также можно один раз запустить атаку с bootmgr из Windows 8.x, чтобы отключить VBS, а затем вернуть исходный загрузчик.
  • Windows 10 изменил инициализацию загрузочного приложения, чтобы ограничить все PCR TPM один раз, поэтому bootmgr из Windows 8.x не сможет распаковать VMK в системе Windows 10+.

hvloader.efi может быть загружен с элементом nointegritychecks для загрузки самозаверенного mcupdate.dll, чья точка входа будет вызвана до ExitBootServices.

В качестве альтернативы на системах, отличных от AMD64, можно использовать winload.efi до TH2 с элементом testsigning; это допускает самозаверенные двоичные файлы с EKU szOID_NT5_CRYPTO в сертификате.

В системах ARMv7 для получения выполнения кода необходима загрузка пропатченного самозаверенного hal.dll с импортом mcupdate.dll.

В системах x86 и AMD64 файл, загружаемый как mcupdate.dll, должен называться mcupdate_*.dll, где * — строка производителя CPUID (GenuineIntel, AuthenticAMD и т. д.).

В системах ARM64 этот метод не может быть использован, поскольку самой ранней доступной подписанной производственной сборкой является WinPE из RS2; поэтому в настоящее время возможно только выполнение кода с подключённым отладчиком (с использованием bootdebug).

Включённые файлы

Этот репозиторий включает следующие файлы:

• Предоставляется исходный код простого payload. Этот payload просто бесконечно ожидает прерывание, поскольку без поиска интересных функций и переменных в вызывающем загрузочном приложении невозможно сделать что-либо ещё.
  • Поскольку mcupdate.dll выполняется по виртуальному адресу с включённой трансляцией страниц, невозможно напрямую вызвать функции EFI (для вызова функций EFI необходимо отключить трансляцию страниц; возврат к виртуальному адресу при отключённой трансляции страниц не приведёт к хорошим последствиям).
  • Для вызова функций EFI payload должен вызвать BlImgLoadPEImageEx или BlImgLoadPEImageFromSourceBuffer с установленным битом 0 во флагах, чтобы загрузить дополнительный payload с сопоставлением физических адресов с виртуальными 1:1.
    • Кроме того, он может вызвать BlImgAllocateImageBuffer с тем же установленным битом, чтобы выделить память с сопоставлением физических адресов с виртуальными 1:1; затем загрузить payload самостоятельно (или переназначить себя туда).
• ISO-образ, эксплуатирующий эту проблему на AMD64, использующий bootmgfw из Windows 8 RTM и hvloader из TH1 RTM.
  • Используемый здесь payload выводит сообщение на экран, используя функцию из hvloader, полученную по смещению, и затем бесконечно зацикливается.
• ISO-образ, эксплуатирующий эту проблему на AMD64, использующий bootmgr из RS1 и hvloader из TH1 RTM.

Послесловие

Эта проблема может быть использована для извлечения ключей BitLocker (где Secure Boot используется для проверки целостности).

• Хотя это возможно, точный метод получения выполнения кода с полученными ключами BitLocker для произвольного тома в памяти раскрываться не будет.

Исправление этой проблемы также исправило другую проблему, у которой нет CVE.

• bootmgr игнорирует любую уже находящуюся в памяти таблицу ключей BitLocker и выделяет новую, не затирая старую.
  • Поэтому атакующий может загрузить bootmgr RS2+ из bootmgr (указав произвольный osdevice, где Secure Boot используется для проверки целостности), загрузиться в WinPE, загрузить известный уязвимый драйвер и использовать его для поиска и извлечения существующей таблицы ключей BitLocker в физической памяти.

Ни одно известное уязвимое загрузочное приложение ещё не было отозвано.

• Пока отзыв не произойдёт, атакующий может просто принести свои собственные уязвимые загрузчики.
• Отзыв приведёт к тому, что все существующие установочные/восстановительные носители Windows и старые резервные копии не смогут загрузиться.
  • Сбой загрузки произойдёт даже при отключённом Secure Boot, поскольку bootmgr проверяет свою собственную подпись.

Обновление (2023-05-10)

Произошёл неполный отзыв, а также появился ещё один CVE (CVE-2023-24932). Всё ещё существуют уязвимые bootmgfw, которые не были отозваны, а также дополнительные исправления, устраняющие только случай, когда bootmgr загружает bootmgr. Чтобы заставить Microsoft действовать, понадобился лишь обнародованный буткит ;)
Если вы достаточно креативны, вы найдёте способ обойти отзыв более чем 2000 файлов bootmgfw ;)