Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 2, сентябрь 2022 г.)

Это третья часть нашей статьи о файловой системе CLFS и пяти уязвимостях этого компонента ОС Windows, встречавшихся в кампаниях шифровальщиков на протяжении года. Если вы еще не ознакомились с предыдущими частями, прочтите сначала их.

Вы можете перейти к нужному разделу из содержания или по ссылкам в конце этой части.

• Часть 1. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков
• Часть 2. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 1: CVE-2022-24521)
• Часть 3. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 2, сентябрь 2022 г.)
• Часть 4. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 3, октябрь 2022 г.)
• Часть 5. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 4: CVE-2023-23376)
• Часть 6. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 5: CVE-2023-28252)

Эксплойт № 2, сентябрь 2022 г.

В сентябре 2022 года были устранены две уязвимости файловой системы CLFS: CVE-2022-35803 и CVE-2022-37969. Последняя из них была обнаружена как уязвимость нулевого дня в ходе эксплуатации «в дикой природе», о чем сообщили Кван Джин (Quan Jin) из DBAPPSecurity, Геньвэй Цзян (Genwei Jiang) из Mandiant, FLARE OTF, CrowdStrike и лаборатория Zscaler ThreatLabz компании Zscaler. Мы не  видели, что бы эта уязвимость использовалась в атаках на наших клиентов до того, как вышло исправление, и полагаем, что она была обнаружена после того, как кто-то загрузил эксплойт нулевого дня на сервис VirusTotal. Хотя информация о использующих этот эксплойт атаках и стоящих за ними злоумышленниках не была опубликована, исследователи из компании Zscaler рассмотрели эксплойт в своей статье. Исходя из опубликованных в ней деталей, мы можем предположить, что данный эксплойт нулевого дня создал тот же автор, который разработал описанный выше эксплойт первого дня к уязвимости CVE-2022-24521.

Однако в этой части мы хотим обсудить другой эксплойт. Тот эксплойт, который мы обнаружили, основывается на коде описанного ранее эксплойта первого дня к уязвимости CVE-2022-24521, закрытой в сентябре 2022 года, при этом он отличается от описанного компанией Zscaler. У него больше сходства с публично описанным эксплойтом для предыдущей уязвимости CVE-2022-24521.

Как уже упоминалось в первой части нашей статьи, посвященной внутреннему устройству файловой системы CLFS, для считывания и записи файлов BLF используются сектора размером в 0x200 байт, причем в последних двух байтах сектора сохраняется сигнатура сектора, а оригинальные байты сохраняются в месте, указанном посредством поля SignaturesOffset в заголовке блока. В легитимных файлах BLF массивы с оригинальными байтами располагаются в последних секторах блоков. Запись сигнатур и оригинальных байтов в соответствующих местоположениях обеспечивают функции ClfsEncodeBlock и ClfsDecodeBlock. Они вызываются, когда код считывает блоки с диска или записывает их на диск.

Эксплойт заменяет в блоке GENERAL_SHADOW множество байтов, если коротко:

1. Эксплойт создает поддельные структуры CLFS_BASE_RECORD_HEADER и CLFS_CONTAINER_CONTEXT где-то в файле BLF.
2. Эксплойт перемещает легитимную структуру CLFS_CLIENT_CONTEXT таким образом, чтобы относительный адрес одного из полей совпал с относительным адресом сигнатуры сектора.
3. Эксплойт модифицирует CLFS_LOG_BLOCK_HEADER->SignaturesOffset и перемещает массив с оригинальными байтами из последнего сектора, где он должен находиться, в первый сектор, где расположен заголовок блока (относительный адрес перед вмешательством: 0x7980, относительный адрес после вмешательства: 0x10).

Ниже представлен результат изменений, выполненных в шаге 3.

Наложение нового массива данных сигнатур на существующий заголовок блока

В результате этих изменений относительный адрес записи теперь накладывается на местоположение оригинальных байтов сектора 12. Сигнатура сектора 12 теперь накладывается на одно из полей CLFS_CLIENT_CONTEXT из-за изменений, выполненных в шаге 2.

Наложение поля CLFS_CLIENT_CONTEXT->fAttributes и сигнатуры сектора 12

Поле CLFS_CLIENT_CONTEXT, на которое теперь наложена сигнатура сектора 12, имеет имя fAttributes. Как уже упоминалось в разделе об устройстве файловой системы CLFS, поле fAttributes содержит флаги атрибутов FILE_ATTRIBUTE, ассоциированных с файлом BLF.

В модифицированном файле BLF поля RecordOffsets[0] и fAttributes теперь соединены сигнатурой сектора 12, и вот к чему это ведет:

1. При открытии файла BLF функция ClfsDecodeBlock копирует оригинальные байты из CLFS_LOG_BLOCK_HEADER->RecordOffsets[0] в местоположение сигнатуры сектора 12 (оно же — поле CLFS_CLIENT_CONTEXT->fAttributes).
2. Чтобы задействовать уязвимость, эксплойт вызывает функцию SetLogArchiveMode с параметром режима CLFS_LOG_ARCHIVE_MODE::ClfsLogArchiveEnabled.
3. Драйвер вызывает функции SetLogFileInfo и FlushMetadata.
4. Значение в поле CLFS_CLIENT_CONTEXT->fAttributes устанавливается равным FILE_ATTRIBUTE_ARCHIVE (0x20), при этом изменяются оригинальные байты сигнатуры сектора 12.
5. FlushMetadata также вызывает функции WriteMetadataBlock/ClfsEncodeBlock для кодировки блоков и последующей записи изменений на диск.
6. ClfsEncodeBlock копирует обновленные оригинальные байты с позиции сигнатуры сектора 12 в местоположение, где они должны храниться, переписывая CLFS_LOG_BLOCK_HEADER->RecordOffsets[0].
7. С этого момента вместо легитимной записи будет использоваться поддельная вредоносная запись.

Указатель на класс CClfsContainer во вредоносной структуре CLFS_CONTAINER_CONTEXT, назначенной поддельной вредоносной записи, имеет предварительно заданное значение 0x5000000. В результате дальнейшая эксплуатация уязвимости практически идентична первому описанному эксплойту.

Перейдите по ссылке, чтобы ознакомиться со следующей частью:

• Часть 4. Драйвер Windows CLFS и пять эксплойтов операторов шифровальщиков (№ 3, октябрь 2022 г.)