BitLocker Attacks

Список публичных атак на BitLocker. Любая публичная атака с потенциальной возможностью воздействия на BitLocker, но точный метод которой до сих пор не опубликован (например, baton drop), выходит за рамки.

Большинство атак нацелены на случай, когда VMK запечатан только с помощью TPM, что является настройкой по умолчанию и используется автоматическим BitLocker вместе с хранением ключа восстановления в учётной записи Microsoft.

По умолчанию, начиная с Windows 8, используется проверка целостности Secure Boot, если Secure Boot включён.

Если вам необходимо запечатать VMK только через TPM, наиболее безопасной конфигурацией для этого будет использование устаревшей проверки целостности с PCR 0, 2, 4, 7, 11 (а также поддержание системы в полностью обновлённом состоянии).
Обратите внимание, что это защитит только от программных атак.

Содержание

• Атаки на оборудование
• Программные атаки

Атаки на оборудование

Атаки на оборудование обычно полезны только тогда, когда у злоумышленника есть физический доступ к системе, где VMK запечатан только через TPM.

Программные атаки

Программные атаки обычно представляют собой уязвимости в bootmgr или другом загрузочном приложении, где эксплуатация возможна с полученными ключами BitLocker в памяти для произвольного тома.
Если внутри загрузочного приложения можно получить выполнение кода, атакующий типа «evil cleaner» может установить буткит, который сам будет работать с производными ключами в памяти (или когда ключи ещё можно получить), и таким образом скомпрометировать систему, где вместо TPM или дополнительно к TPM используется пароль или ключ запуска.

Опасная ассоциация

Уязвимая система будет иметь установленными обновления мая 2022 или июня 2022, но не более поздние.

GUID связанных параметров является частью хешируемых данных, поэтому используемый элемент устройства должен быть помечен как не проверяемый.
Для Windows 7 и ниже нет элементов, которые можно использовать (хотя при использовании нестандартных пользовательских настроек это всё ещё может быть возможно).
В Windows 8 и выше osloader!osdevice по умолчанию не проверяется и, как таковой, может быть использован.
Самый простой способ эксплуатации — использовать редактор сырых устройств BCD, bcdeditmod, хотя редактирование куста реестра BCD вручную также возможно (разберитесь сами).

Эксплуатация включает:

• возьмите BCD с целевого устройства, создайте два элемента устройства
• скопируйте osdevice из {default} в первый элемент
• установите GUID связанных параметров в {default}!osdevice на первый элемент устройства
• установите GUID связанных параметров в {first}!osdevice на второй элемент устройства
• задайте любые «опасные» параметры (например, debug) во втором элементе устройства
• загрузите целевое устройство с использованием этого BCD и того же бинарного файла bootmgfw, который оно использовало

bitpixie

Эта уязвимость существовала более 17 лет; самой ранней известной сборкой, в которой она была введена, является 6.0.5231.2 (winmain_idx03.051004-2120) от октября 2005 года.
При использовании проверки целостности Secure Boot атака с понижением версии всё ещё сработает для эксплуатации этой уязвимости.Настройте PXE-сервер загрузки с уязвимым bootmgfw.efi (если используется устаревшая проверка целостности, это должен быть bootmgfw.efi с целевого устройства), переименованным правильно для загрузки EFI.

Для BCD настройте одну запись по умолчанию, где device — это зашифрованное BitLocker устройство osdevice; path — "\"; и последовательность восстановления.

Последовательность восстановления должна указывать на одну запись startup, где device — boot, path указывает на приложение EFI, которое нужно запустить (с PXE-сервера); и включён pxesoftreboot.

Когда Secure Boot отключён, это приложение EFI может быть просто приложением, сканирующим физическую память в поисках keytable BitLocker для дампа.

Когда Secure Boot включён, это приложение EFI может использовать известный обход Secure Boot (при необходимости требуется физический доступ).
Для эксплуатации загрузочного приложения Windows таким способом вам нужно будет заменить BCD на ваш второй файл BCD на PXE-сервере.
Это означает нажатие клавиши со стрелкой во время запуска bootmgr, чтобы принудительно показать меню загрузки; а затем замену BCD на PXE-сервере в этот момент.

Дешифрование по нажатию кнопки

Эксплуатация включает:

• Создайте образ диска защищённого BitLocker osvolume. Этот метод получения FVEK приводит к фактической потере данных!
• Загрузитесь в WinRE любым способом (при необходимости принудительно через восстановление при запуске или просто задайте элемент BCD bootsequence и т. д.).
• Запустите сброс (Устранение неполадок -> Сброс этого ПК -> Удалить всё). Быстрее выбрать «Локальная переустановка». Обязательно выберите «Просто удалить мои файлы».
  • Если выбрать «Сохранить файлы», будет запрошен ключ восстановления.
  • Если WinRE системы не уязвима, ключ восстановления также будет запрошен.
• Когда сброс дойдёт до ~98%, принудительно выключите систему (удерживая кнопку питания 7 секунд / и т. п.).
• Снова включите систему — она должна снова загрузиться в WinRE и показать ошибку. Закрытие ошибки должно привести к перезагрузке.
• Когда увидите синий экран «Обновление», нажмите Shift+F10, чтобы открыть оболочку.
• Выполните manage-bde -pause C:, а затем manage-bde -protectors -delete C:
• Принудительно выключите систему (снова).

На этом этапе метаданные BitLocker на диске будут содержать VMK в открытом виде.
Сделайте его дамп и используйте этот VMK для расшифровки FVEK.
Расшифрованный FVEK можно использовать на созданном ранее образе диска для расшифровки раздела.

Обратите внимание: мне удалось успешно использовать эту уязвимость только на Windows 10 в очень специфических обстоятельствах (BitLocker только с TPM, без ключа восстановления). Однако другие успешно использовали эту уязвимость с помощью уязвимой WinRE на Windows 11 (Nickel).

Утечка RAM

Насколько мне известно, эта уязвимость существует столько же, сколько и сам менеджер загрузки — она присутствует уже в 6.0.5098.0 (winmain_beta1.050628-1740) от июня 2005 года, хотя это предшествует BCD, поэтому в таких ранних сборках эксплуатация была бы иной. Похоже, соответствующий код существовал и раньше (код, связанный с ramdisk, в сборке 5048 от апреля 2005 года выглядит так же), но сборка 5098 — самая ранняя из сборок с дампом, где BitLocker присутствует в какой-то форме.

Чтобы воспользоваться этим, вам нужно настроить запись по умолчанию и последовательность восстановления, как в bitpixie. Это нужно для того, чтобы при загрузке файла для устройства ОС были получены ключи.

Последовательность восстановления должна иметь дополнительную запись устройства для настройки ramdisk. Используйте для этого bcdeditmod. Здесь используйте пользовательский элемент, например custom:21100000. Пример записи устройства, которую можно здесь использовать: !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] — вам нужно заменить блочное устройство part2 на то, что указано в BCD вашей целевой системы.

Затем этот файл можно выгрузить из памяти любым способом, который вам подходит. Я предпочитаю использовать более старую winload для загрузки самоподписанного mcupdate через меню дополнительных параметров, но доступны и другие варианты (например, программная перезагрузка PXE в стороннюю операционную систему; возможен дамп памяти из WinPE с помощью bugcheck или известного уязвимого драйвера, но winload пометит эту область памяти как свободную в карте памяти NT, поэтому она может быть перезаписана, если в winload не заданы другие параметры, помечающие эту память как сбойную и т. п.).

В этот репозиторий включена реализация PoC моего предпочтительного метода в виде ramleak.zip. Прочтите прилагаемый readme с инструкциями по использованию.

Отдельное спасибо Максиму Суханову — на это меня вдохновило прочтение разбора CrashXTS и поиск иного способа возможного дампа hiberfil.sys.

А теперь мои собственные мысли об этой ошибке и о yellowkey:

Это был первый случай, когда у меня возникла реальная проблема с отправкой материала в MSRC, и в основном это было недопонимание с их стороны, связанное с Secure Boot. Учитывая, что другая BitLocker 0day была обнародована, я решил выпустить это сейчас; я вынашивал это почти год, размышляя, что с ним делать.

В отличие от yellowkey, я не буду делать громких заявлений о том, что это «бэкдор»; по моему мнению, yellowkey — не бэкдор. Связанный компонент относится к WinPE (не специфичен для WinRE), а основная «уязвимость» там — удаление winpeshl.ini, чтобы достичь этого пути выполнения. Я прекрасно понимаю, почему Microsoft считала, что удаление этого файла в сценарии WinRE+BitLocker невозможно.

Поскольку загрузка ramdisk с раздела, зашифрованного BitLocker, на самом деле является функцией загрузочной среды — хотя мне и пришлось использовать существующий трюк, чтобы заставить её работать, — другие тоже могли бы назвать это бэкдором, если бы захотели, но я не буду заходить так далеко. Загрузочная среда сложна (и продолжает разрастаться: последний bootmgfw_ex.efi больше не помещается в образ 2.88MB — конец эпохи), и было обнаружено несколько уязвимостей из-за того, как определённые функции взаимодействуют друг с другом.