С февраля 2022 года сообщалось о новом вымогателе, который, по-видимому, использует 0-дневную уязвимость Windows, согласно исследованию, проведённому Trend Micro.
Более подробную информацию об этом вымогателе можно найти по этой ссылке.
Согласно анализу «Лаборатории Касперского», группа вымогателей Nokoyawa использовала другие эксплойты, нацеленные на драйвер Common Log File System (CLFS), с июня 2022 года, со схожими, но отличными характеристиками, все связанные с одним разработчиком эксплойтов.
В апреле 2023 года, когда Microsoft выпустила патч, был присвоен CVE-2023-28252. Ранее, в 2022 году, аналогичная ошибка в том же компоненте была исследована нами и задокументирована в этом блог-посте

Формат файла Common Log File System (CLFS):

Для анализа необходимо знать формат файла .blf, который обрабатывается уязвимым драйвером Common Log File System с именем CLFS.sys, находящимся в папке драйверов внутри system32.

Более подробную информацию об этом типе файлов можно найти по ссылкам ниже:

https://www.zscaler.com/blogs/security-research/technical-analysis-windows-clfs-zero-day-vulnerability-cve-2022-37969-part

https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-the-common-log-file-system

https://github.com/ionescu007/clfs-docs/blob/main/README.md

https://www.coresecurity.com/core-labs/articles/understanding-cve-2022-37969-windows-clfs-lpe

Уязвимость:

Этот анализ выполнен для Windows 11 21H2, clfs.sys версии 10.0.22000.1574, хотя он также работает на Windows 10 21H2, Windows 10 22H2, Windows 11 22H2 и Windows Server 2022.

В предыдущих версиях Windows необходимо скорректировать некоторые значения, иначе мы получим BSOD.

Microsoft Patch Tuesday апрель 2023.

Вы можете проверить версию драйвера, как показано

Когда уязвимость была опубликована, в апреле 2023 года я вместе с Эстебаном Казимировым начал реверсинг драйвера CLFS.sys, хотя в данном случае одного анализа патча было недостаточно, чтобы понять, где находится ошибка и как её вызвать, поскольку эксплуатация очень сложна.

Позже вышел блог-пост, автор которого на примере образца вредоносного ПО показал некоторые части декопилированного кода HexRays и некоторую информацию, которая указала направление, в котором нужно было вести эксплуатацию.

Очевидно, предоставленная информация была неполной, но без этой помощи вряд ли удалось бы создать PoC, а затем и функциональный эксплойт.

Чтобы было проще понять, мы сначала объясним, как построить PoC, а затем проведём анализ уязвимости.

Этот блог-пост содержит два раздела:

Построение PoC:

1-Получение необходимых адресов ядра для эксплуатации

2-Подготовка пути для создания файлов .blf:

3-Создание файла "trigger blf" с помощью функции CreateLogFile()

4-Формирование файла "trigger blf"

5-Получение адреса BASE BLOCK файла trigger blf в ядре

6-Вызов AddLogContainer с дескриптором trigger blf

7-Подготовка файлов spray blf

8-Подготовка памяти для выполнения spray

9-Запуск ошибки

Отладка:

1-Проверка memory spray

2-Просмотр RecordOffset[12] файла trigger blf

3-Просмотр значения iFlushBlock в файле spray blf

4-Почему он читает из BLOCK 1 SHADOW, а не из BLOCK 0 CONTROL?

5-Почему контрольная сумма равна нулю в файлах blf spray?

6-Завершение эксплуатации.

7-Настоящий патч

Построение PoC:

1-Получение необходимых адресов ядра для эксплуатации

Я создам функцию с именем InitEnvironment для получения некоторых необходимых адресов ядра.

Получаю адрес EPROCESS моего процесса и сохраняю его в переменной g_EProcessAddress, затем адрес EPROCESS процесса SYSTEM, и сохраняю его в system_EPROCESS, затем EHTREAD адрес главного потока моего процесса, и сохраняю его в g_EThreadAddress и, наконец, адрес PREVIOUS MODE, который в этой версии PoC не будет использоваться.

Этот метод хорошо известен, функция GetObjectKernelAddress, вызывает NtQuerySystemInformation дважды с первым аргументом SystemExtendedHandleInformation, первый вызов передаётся с неверным размером и возвращает ошибку, но также возвращает правильный размер, который используется во втором вызове и получает информацию обо всех дескрипторах, затем в цикле перебирает информацию каждого дескриптора и в поле Object правильного handleinfo получает искомый адрес в ядре.

Мне также нужны адреса ядра следующих функций, экспортируемых CLFS.sys:

• ClfsEarlierLsn

• ClfsMgmtDeregisterManagedClient

И экспортируемые функции из NTOSKRNL.exe

• RtlClearBit/PoFxProcessorNotification

• SeSetAccessStateGenericMapping

Для получения этих адресов используется аналогичный метод, который используется для получения базы ядра обоих модулей, путём вызова NtQuerySystemInformation дважды, но в этом случае первый аргумент будет SYSTEM_INFORMATION_CLASS (в PoC я использую функцию FindKernelModulesBase для этой цели).

Затем он загружает CLFS.sys и NTOSKRNL.exe как обычные модули в пользовательском режиме, вызывая LoadLibrary, получает адреса в пользовательском режиме с помощью GetProcAddress, а затем вычитает imagebase из каждого, что даёт смещение функции, и, наконец, добавляет каждое смещение к соответствующим базам ядра, тем самым получая адреса ядра всех необходимых функций.

2-Подготовка пути для создания файлов .blf:

Я создаю функцию с именем createInitialTriggerBlfFile, которая сгенерирует и запишет файл .blf.

Путь, используемый в качестве аргумента в CreateLogFile, отличается от обычного пути; например, чтобы открыть файл 1280.blf, расположенный в папке C:\Users\Public, мы должны указать путь LOG:C:\Users\Public\1280. Это будет сохранено в переменной stored_name_CreateLog.

Я делаю это с помощью wsprintfW(), так как stored_env хранит путь C:\Users\Public, ранее полученный из переменных среды. К этой строке я добавлю префикс LOG: и случайное имя в конце, без расширения .blf.