Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Атака "подобная" потому что, описана вами, в этом заключается все подобие?
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Извините, но я с вами не согласен.
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
В каталогах должны также лежать файлы %Реестр%.LOG1 и %Реестр%.LOG2, для корректного парсинга сырых данных.
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Запуск RECmd для необходимых файлов реестра, который выгружает только необходимые ветки
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
"file.name": "(default)",
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Посоветовавшись, мы решили, почему нет, скорее всего, SANS явно вне всех этих политических игр.
Еще в 21 году начались проблемы.
Знающие люди поймут, что знать наизусть изменения всех временных меток в NTFS при различных манипуляциях в разных версиях винды – это задачка не из легких. Когда я решала свой тест, я без задней мысли эти вопросы просто смотрела в Windows Forensic Poster.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Куда хуже, если применяются программы типа BitLocker и выполняется полнодисковое шифрование. Сбор криминалистических артефактов затрудняется. Вся надежда на то, что киберпреступник наследил по оплошности. [...] Или же где-то остались незашифрованные диски. Если же такая атака затронула абсолютно все хосты организации, шансы достать артефакты ничтожно малы.
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Некоторые клиенты просят лишь восстановить зашифрованные файлы, чтобы не платить выкуп. [...] К тому же большинство современных программ-вымогателей работают так, что шифрование необратимо и без приватного ключа с ним не справится даже гений криптографии. Стараемся объяснить это клиенту, а дальше все зависит от его понимания ситуации и приоритетов.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
После этого с https://app-ins-001.amscloudhost[.]com:443/dn01 осуществляется загрузка RedCurl.FSABIN, который сохраняется в папку C:\Users[user]\AppData\Local\VirtualStore</code>с именем [...]
Отслеживайте запуск подозрительных файлов из папки C:\Users[user]\AppData\Local через планировщик заданий Windows.
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?
«Имеется ли на накопительной системе (системном блоке) информация о номере банковской карты № XXXX XXXX XXXX XXXX (номер счета XXXXXXXXXXXXXXXXXXXX)?»
«Имеется ли на накопительной системе (системном блоке) информация об абонентском номере X-XXX-XXX-XX-XX?»
Ответы на эти вопросы не требуют цитирования (указания в заключении или записи на прилагаемый носитель) всех обнаруженных данных. По сути, следователю можно дать и ответ "да, информация о номере банковской карты обнаружена, точка", а в исследовательской части указать только одно вхождение.
Объект представлен в чёрном полимерном пакете.
А как эксперт определил, что пакет именно полимерный? Какие исследования проводил для этого? Это, как бы, не общие, а специальные знания уже. И не в той области.
установлено, что настройки даты/времени системной платы СБ соответствуют текущим значениям
Вот прямо так и соответствуют? Обычно отклонения есть, хотя бы секунд 5. Объект все-таки еще в очереди лежит месяц-другой.
Занято, байт
Это значение зависит от версии драйвера NTFS. Наличие в Windows функции Storage Reserve может искусственно занижать объем свободного пространства в томе (даже если это внешний накопитель).
А где подписка эксперта? По ней вообще иногда можно сразу сказать, что эксперт лжет (статью 57 УПК РФ не читал, либо дал подписку после оформления заключения).
Обязательно еще про баг напишите, который "портил" данные в создаваемой копии. Velociraptor используют многие, баг был довольно легко воспроизводимый, но, видимо, его списывали на "это же работающая система, данные могут меняться".
Очень хорошо, что процесс хорошо воспроизводится на данных, на которых он и должен хорошо воспроизводиться. Особенно, когда речь идет об установленных экземплярах операционных систем, на которые не имитировалось воздействие злоумышленника. Или имитировалось, но не тем способом, а гораздо более простым. "Не работает" — это не значит, что у вас ошибка высвечивается, а значит, что сама концепция настолько ужасна, что ее уже и не исправить.
Ведь я говорю о ситуации, когда контроль целостности проходит успешно, но для данных (файлов или значений ключей реестра), не соответствующих "неизменному" ("доверенному", "эталонному") состоянию. Потому что модуль доверенной загрузки "увидел" ожидаемые данные (значение хеш-функции от них совпало с "эталоном"), а операционная система "увидела" другие данные, хотя исходный набор байтов на накопителе был тот же самый (и будет хуже, если "другие данные" — это контролируемые злоумышленником).
Если модификация структур файловых систем и кустов реестра на низком уровне вообще не рассматривается — это не значит, что проблемы нет. Выше уже была ссылка, где про драйвер FAT в Linux: если вы смонтируете специально подготовленный образ файловой системы в режиме "только чтение" (хотя и в режиме "чтение-запись" можно), то в Linux вы увидите директорию с какими-то файлами (и эти файлы могут иметь именно то содержимое, которое вы ожидаете увидеть), а в Windows это будет уже директория без части файлов (или даже без всех файлов). Цена вопроса — модификация одного байта в индексной записи (в Windows этот байт остановит цикл перечисления индексных записей в директории, в Linux — нет, листинг директории продолжится). Не используете Linux, "залатали" эту возможность? Есть еще десятки других.
Все это верно, но делать после этого вывод о том, что предзагрузочный контроль целостности именно поэтому не работает – очень радикально. На краевых случаях – возможны проблемы, но они выявляются и решаются.
Радикально? Нет. Эти граничные случаи — как раз то, на что может целиться атакующий. Если в повседневной жизни они не возникают, то тут возникнуть вполне могут.
А как решать эти проблемы? Писать парсеры файловых систем NTFS и FAT, реестра Windows, которые бы полностью соответствовали реализациям в Windows, включая все граничные случаи? Когда напишете подобное (скажем, потратив на это пять лет работы, ибо нужно досконально изучить в IDA Pro и WinDbg все эти драйверы и подсистемы ядра), "эталонная" реализация уже изменится (ту же реализацию реестра в ядре Windows регулярно перерабатывают, "подбрасывая" новые граничные случаи).
Масштаб проблемы серьезный, сама проблема носит принципиальный характер, поэтому и пишу, что "не работает".
Журнал транзакций той же NTFS в ViPNet SafeBoot контролируется на непустоту – скорее всего, приведенный сценарий не пройдет (хотя он описан очень поверхностно). Да и непонятно, с чем именно поздравляете :).
Журнал NTFS не может быть пустым при обычной работе операционной системы Windows. В нем всегда что-то есть. Контролировать можно незавершенность транзакций, но в данном случае речь шла про журналы реестра (файлы SYSTEM.LOG1, SYSTEM.LOG2 и т. д.).
Файлы реестра тоже можно контролировать на незавершенность транзакций, вот только умеет ли средство доверенной загрузки делать это корректно? Тут проблемы могут начаться и с реализации расчета контрольной суммы заголовка.
А вот здесь противоречие всему написанному выше – “Все животные равны, но некоторые равнее других”? :)
файлов на диске (на разделах с ФС FAT*, NTFS, ext2/3/4);
реестра Windows (на уровне ключей/значений);
Предзагрузочный контроль целостности не работает.
У вас возникают проблемы как только вы уходите от схемы "текущий компонент проверяет целостность только тех компонентов (данных), которые сам сразу и запускает (использует)".
В качестве примера возьмем CVE-2021-27094 и CVE-2021-28447 — загрузчик ядра (winload) читает и хеширует (для измерения с помощью TPM) данные из некоторых значений у определенных ключей реестра, а затем (в рамках той же загрузки) ядро (ntoskrnl) читает и использует данные из этих же значений (у тех же ключей и из того же загруженного куста реестра), однако данные значений уже отличаются от ранее хешированных (описание на английском). То бишь загрузчик ядра "видит" одни данные, вполне ожидаемые ("доверенные", "эталонные"), а ядро "видит" в том же месте другие данные (которые могут нарушать действующую политику, отсюда и признание этой ситуации уязвимостью, ведь хешируются ожидаемые данные, а используются какие-то другие, контролируемые атакующим, т. е. атакующий, имеющий права администратора в операционной системе или возможность модифицировать содержимое накопителя пока компьютер выключен, может подготовить такой файл куста реестра, что загрузчик ядра "увидит" одни данные, а ядро "увидит" другие данные ровно в том же месте).
Почему так происходит? Потому что реализация поддержки реестра в загрузчике ядра и в ядре различается — всего два, казалось бы, незначительных различия в коде привели к двум уязвимостям. А все из-за того, что измерение данных инициируется компонентом, который является предыдущим по отношению к тому, который эти данные использует, — а надо было, если делать архитектуру грамотно, хешировать и измерять все в рамках ядра (одного компонента).
Вы не можете парсить файловую систему NTFS или реестр Windows именно так, как это делает сама Windows. Даже "импорт" функций парсинга из менеджера загрузки или загрузчика ядра (bootmgr и winload) не поможет, потому что они тоже отличаются от того, что происходит после передачи управления ядру.
В итоге: добро пожаловать в мир, где модуль доверенной загрузки "видит" конфигурационный файл средства защиты информации, имеющий "ожидаемое" содержимое, а после загрузки это будет уже пустой файл (такое можно сделать, если модуль доверенной загрузки использует драйвер ntfs-3g для работы с файловыми системами NTFS, ведь в нем тоже есть различия в парсинге, если сравнивать с драйвером ntfs.sys).
Отключаете режим "fast startup"? Поздравляю, его элемент — запись данных реестра только в журнал транзакций — можно активировать путем изменения одной переменной ядра.
Как разработчик парсеров реестра Windows, файловых систем NTFS, FAT12/16/32 и exFAT могу сказать, что таких частных случаев масса и все их учесть невозможно.
Вот еще один — https://github.com/dosfstools/dosfstools/issues/174 ("Windows cannot see files listed after such directory entry in all the subsequent clusters of the directory file... Linux does not stop scanning directory upon encountering such entry, the problem can only be seen when the media is accessed from the Windows machine"). Простыми словами: в файловой системе FAT12/16/32 можно создать такую директорию, которая будет иметь некоторые файлы, видимые в Linux, но невидимые в Windows. И привет всем модулям доверенной загрузки на базе Linux! Да, атакующему нужны права администратора, но это входит в модель угроз, от которых должен защищать модуль доверенной загрузки (иначе зачем это все встраивание в UEFI, можно ведь просто драйвером Windows реализовать тогда).
P. S. А можно еще вернуться во времена, когда ставился "бряк" на 0x0000:0x7C00, чтобы вместо загрузчика операционной системы подставить загрузчик того самого "Аккорд-АМДЗ". У них в старых моделях вообще парсинг всего сделан — достойно, но неэффективно.
В Windows 10 есть Storage Reserve – функция, по умолчанию включенная для системного тома (который обычно диск C:). Эта функция, помимо прочего, сокращает "видимый" объем свободного пространства в файловой системе, чтобы свободное место с точки зрения пользователя "закончилось" раньше, чем это реально происходит (это делается, чтобы операционная система могла поставить обновления, используя зарезервированную область; при этом сама зарезервированная часть свободного пространства заранее как-то не выделяется, все реализовано в банальном уменьшении "видимого" объема свободного пространства).
CCleaner такие области чистить не умеет (даже если подключить очищаемый накопитель как внешний, а не работать на "живой" системе), только cipher. А в этих областях вполне могут быть пользовательские данные.
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
Еще парсер реестра Windows в systemd есть.
https://github.com/systemd/systemd/blob/main/src/boot/efi/bcd.c
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Но зачем? RECmd и Registry Explorer восстанавливают меньше удаленных данных, чем реально есть.
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Еще в 21 году начались проблемы.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?
Теперь так:
А где "\" между "Users" и "%имя_пользователя%"?
Этот шаблон пути не очень соответствует примеру, что указан ниже.
Ответы на эти вопросы не требуют цитирования (указания в заключении или записи на прилагаемый носитель) всех обнаруженных данных. По сути, следователю можно дать и ответ "да, информация о номере банковской карты обнаружена, точка", а в исследовательской части указать только одно вхождение.
А как эксперт определил, что пакет именно полимерный? Какие исследования проводил для этого? Это, как бы, не общие, а специальные знания уже. И не в той области.
Вот прямо так и соответствуют? Обычно отклонения есть, хотя бы секунд 5. Объект все-таки еще в очереди лежит месяц-другой.
Это значение зависит от версии драйвера NTFS. Наличие в Windows функции Storage Reserve может искусственно занижать объем свободного пространства в томе (даже если это внешний накопитель).
А где подписка эксперта? По ней вообще иногда можно сразу сказать, что эксперт лжет (статью 57 УПК РФ не читал, либо дал подписку после оформления заключения).
Обязательно еще про баг напишите, который "портил" данные в создаваемой копии. Velociraptor используют многие, баг был довольно легко воспроизводимый, но, видимо, его списывали на "это же работающая система, данные могут меняться".
Заблуждения программистов об именах.
Очень хорошо, что процесс хорошо воспроизводится на данных, на которых он и должен хорошо воспроизводиться. Особенно, когда речь идет об установленных экземплярах операционных систем, на которые не имитировалось воздействие злоумышленника. Или имитировалось, но не тем способом, а гораздо более простым. "Не работает" — это не значит, что у вас ошибка высвечивается, а значит, что сама концепция настолько ужасна, что ее уже и не исправить.
Ведь я говорю о ситуации, когда контроль целостности проходит успешно, но для данных (файлов или значений ключей реестра), не соответствующих "неизменному" ("доверенному", "эталонному") состоянию. Потому что модуль доверенной загрузки "увидел" ожидаемые данные (значение хеш-функции от них совпало с "эталоном"), а операционная система "увидела" другие данные, хотя исходный набор байтов на накопителе был тот же самый (и будет хуже, если "другие данные" — это контролируемые злоумышленником).
Если модификация структур файловых систем и кустов реестра на низком уровне вообще не рассматривается — это не значит, что проблемы нет. Выше уже была ссылка, где про драйвер FAT в Linux: если вы смонтируете специально подготовленный образ файловой системы в режиме "только чтение" (хотя и в режиме "чтение-запись" можно), то в Linux вы увидите директорию с какими-то файлами (и эти файлы могут иметь именно то содержимое, которое вы ожидаете увидеть), а в Windows это будет уже директория без части файлов (или даже без всех файлов). Цена вопроса — модификация одного байта в индексной записи (в Windows этот байт остановит цикл перечисления индексных записей в директории, в Linux — нет, листинг директории продолжится). Не используете Linux, "залатали" эту возможность? Есть еще десятки других.
Радикально? Нет. Эти граничные случаи — как раз то, на что может целиться атакующий. Если в повседневной жизни они не возникают, то тут возникнуть вполне могут.
А как решать эти проблемы? Писать парсеры файловых систем NTFS и FAT, реестра Windows, которые бы полностью соответствовали реализациям в Windows, включая все граничные случаи? Когда напишете подобное (скажем, потратив на это пять лет работы, ибо нужно досконально изучить в IDA Pro и WinDbg все эти драйверы и подсистемы ядра), "эталонная" реализация уже изменится (ту же реализацию реестра в ядре Windows регулярно перерабатывают, "подбрасывая" новые граничные случаи).
Масштаб проблемы серьезный, сама проблема носит принципиальный характер, поэтому и пишу, что "не работает".
Журнал NTFS не может быть пустым при обычной работе операционной системы Windows. В нем всегда что-то есть. Контролировать можно незавершенность транзакций, но в данном случае речь шла про журналы реестра (файлы SYSTEM.LOG1, SYSTEM.LOG2 и т. д.).
Файлы реестра тоже можно контролировать на незавершенность транзакций, вот только умеет ли средство доверенной загрузки делать это корректно? Тут проблемы могут начаться и с реализации расчета контрольной суммы заголовка.
Здесь про "теплую ламповость" было.
Предзагрузочный контроль целостности не работает.
У вас возникают проблемы как только вы уходите от схемы "текущий компонент проверяет целостность только тех компонентов (данных), которые сам сразу и запускает (использует)".
В качестве примера возьмем CVE-2021-27094 и CVE-2021-28447 — загрузчик ядра (winload) читает и хеширует (для измерения с помощью TPM) данные из некоторых значений у определенных ключей реестра, а затем (в рамках той же загрузки) ядро (ntoskrnl) читает и использует данные из этих же значений (у тех же ключей и из того же загруженного куста реестра), однако данные значений уже отличаются от ранее хешированных (описание на английском). То бишь загрузчик ядра "видит" одни данные, вполне ожидаемые ("доверенные", "эталонные"), а ядро "видит" в том же месте другие данные (которые могут нарушать действующую политику, отсюда и признание этой ситуации уязвимостью, ведь хешируются ожидаемые данные, а используются какие-то другие, контролируемые атакующим, т. е. атакующий, имеющий права администратора в операционной системе или возможность модифицировать содержимое накопителя пока компьютер выключен, может подготовить такой файл куста реестра, что загрузчик ядра "увидит" одни данные, а ядро "увидит" другие данные ровно в том же месте).
Почему так происходит? Потому что реализация поддержки реестра в загрузчике ядра и в ядре различается — всего два, казалось бы, незначительных различия в коде привели к двум уязвимостям. А все из-за того, что измерение данных инициируется компонентом, который является предыдущим по отношению к тому, который эти данные использует, — а надо было, если делать архитектуру грамотно, хешировать и измерять все в рамках ядра (одного компонента).
Вы не можете парсить файловую систему NTFS или реестр Windows именно так, как это делает сама Windows. Даже "импорт" функций парсинга из менеджера загрузки или загрузчика ядра (bootmgr и winload) не поможет, потому что они тоже отличаются от того, что происходит после передачи управления ядру.
В итоге: добро пожаловать в мир, где модуль доверенной загрузки "видит" конфигурационный файл средства защиты информации, имеющий "ожидаемое" содержимое, а после загрузки это будет уже пустой файл (такое можно сделать, если модуль доверенной загрузки использует драйвер ntfs-3g для работы с файловыми системами NTFS, ведь в нем тоже есть различия в парсинге, если сравнивать с драйвером ntfs.sys).
Отключаете режим "fast startup"? Поздравляю, его элемент — запись данных реестра только в журнал транзакций — можно активировать путем изменения одной переменной ядра.
Как разработчик парсеров реестра Windows, файловых систем NTFS, FAT12/16/32 и exFAT могу сказать, что таких частных случаев масса и все их учесть невозможно.
Вот еще один — https://github.com/dosfstools/dosfstools/issues/174 ("Windows cannot see files listed after such directory entry in all the subsequent clusters of the directory file... Linux does not stop scanning directory upon encountering such entry, the problem can only be seen when the media is accessed from the Windows machine"). Простыми словами: в файловой системе FAT12/16/32 можно создать такую директорию, которая будет иметь некоторые файлы, видимые в Linux, но невидимые в Windows. И привет всем модулям доверенной загрузки на базе Linux! Да, атакующему нужны права администратора, но это входит в модель угроз, от которых должен защищать модуль доверенной загрузки (иначе зачем это все встраивание в UEFI, можно ведь просто драйвером Windows реализовать тогда).
P. S. А можно еще вернуться во времена, когда ставился "бряк" на 0x0000:0x7C00, чтобы вместо загрузчика операционной системы подставить загрузчик того самого "Аккорд-АМДЗ". У них в старых моделях вообще парсинг всего сделан — достойно, но неэффективно.
https://dfir.ru/2018/07/21/a-live-forensic-distribution-executing-malicious-code-from-a-suspect-drive/
Ну и ссылка на тест: https://dfir.ru/2020/06/29/storage-reserve-blocks-some-tools-from-thoroughly-wiping-unallocated-space/
В Windows 10 есть Storage Reserve – функция, по умолчанию включенная для системного тома (который обычно диск C:). Эта функция, помимо прочего, сокращает "видимый" объем свободного пространства в файловой системе, чтобы свободное место с точки зрения пользователя "закончилось" раньше, чем это реально происходит (это делается, чтобы операционная система могла поставить обновления, используя зарезервированную область; при этом сама зарезервированная часть свободного пространства заранее как-то не выделяется, все реализовано в банальном уменьшении "видимого" объема свободного пространства).
CCleaner такие области чистить не умеет (даже если подключить очищаемый накопитель как внешний, а не работать на "живой" системе), только cipher. А в этих областях вполне могут быть пользовательские данные.