Анализ уязвимости 0day от Microsoft: может представлять значительную угрозу для инфраструктуры Web3

В прошлом месяце в обновлении безопасности Microsoft был обнаружен эксплуатируемый уязвимость повышения привилегий win32k. Кажется, что эта уязвимость существует только в ранних версиях Windows и не может быть активирована на Windows 11.

Эксплуатация такого рода уязвимостей существует давно. В этой статье будет проанализировано, как злоумышленники могут продолжать использовать эту уязвимость на фоне постоянно улучшающихся новых мер по смягчению последствий. Мы завершили весь процесс анализа в среде Windows Server 2016.

0day уязвимости относятся к уязвимостям, которые не были раскрыты и исправлены, и могут быть использованы злоумышленниками без обнаружения, что представляет собой огромную угрозу. Обнаруженная 0day уязвимость находится на уровне операционной системы Windows, и хакеры могут получить полный контроль над Windows через эту уязвимость.

Системы, контролируемые хакерами, могут привести к утечке личной информации, сбоям в системе, потере данных, финансовым убыткам, внедрению вредоносного ПО и другим последствиям. Для пользователей Web3 приватные ключи могут быть украдены, цифровые активы могут быть переведены. В более широком смысле, эта уязвимость может даже повлиять на всю экосистему Web3, работающую на основе инфраструктуры Web2.

Анализ патчей

После анализа патча стало ясно, что проблема, похоже, заключается лишь в том, что счетчик ссылок на один из объектов был обработан лишний раз. Поскольку код win32k довольно старый, мы смогли найти некоторые ранние комментарии к исходному коду, которые указывают на то, что ранний код блокировал только объект окна, не блокируя объект меню внутри окна, и здесь объект меню мог быть ошибочно сослаться.

Доказательство концепции уязвимости ( PoC )

Мы обнаружили, что переданное значение xxxEnableMenuItem() обычно уже заблокировано в верхнем уровне функции. Дальнейший анализ показал, что функция MenuItemState в xxxEnableMenuItem возвращает два возможных меню: главное меню окна или подменю в меню (, а также даже подподменю ).

В PoC мы создали специальную четырехуровневую структуру меню и установили конкретные свойства для каждого уровня меню, чтобы выполнить проверки и определения в функции xxxEnableMenuItem. Ключевыми шагами являются удаление некоторых ссылок на меню и освобождение определенных объектов меню, когда xxxRedrawTitle возвращает пользовательский уровень и т.д.

Уязвимость эксплойта (Exp) реализована

Общая идея

Мы в основном рассматривали два направления использования: выполнение кода shellcode и использование примитивов чтения и записи для изменения адреса токена. Учитывая различные факторы, мы выбрали второй вариант.

Вся эксплоитация можно разделить на два ключевых вопроса: как использовать уязвимость UAF для управления значением cbwndextra и как обеспечить стабильные операции чтения и записи после того, как значение cbwndextra будет под контролем.

Реализация первой записи данных

Мы используем объект имени окна в классе WNDClass для захвата и освобождения объектов меню. Ключевым моментом является нахождение места в структуре адреса, которую мы можем построить, в которую можно записывать данные произвольно.

В конечном итоге мы выбрали реализацию записи через битовый флаг AND 2 в функции xxxRedrawWindow. Мы записываем cb-extra класса HWND, а не cb-extra объекта окна, чтобы лучше контролировать размещение памяти.

стабильная память

Мы разработали структуру памяти для как минимум трех последовательных объектов HWND по 0x250 байт, освободив один из них и заняв объект HWNDClass размером 0x250 байт. Передние и задние объекты HWND используются для проверки параметров и в качестве посредника для операций чтения и записи.

Мы точно определяем, располагается ли запрашиваемый объект окна в соответствии с ожиданиями, через утечку адреса дескриптора ядра в памяти.

Изменение чтения и записи примитивов

Мы используем GetMenuBarInfo() для реализации произвольного чтения, а SetClassLongPtr() для реализации произвольной записи. За исключением операции записи, заменяющей TOKEN, все остальные записи выполняются с использованием смещения через объект класса первого окна.

Итог

1. Уязвимость win32k существует давно, но Microsoft пытается переписать соответствующий код ядра с использованием Rust, и в будущем такие уязвимости могут быть устранены в новых системах.

2. Процесс эксплуатации уязвимости относительно прост, основная сложность заключается в том, как контролировать первую запись. Уязвимость все еще сильно зависит от утечки адреса дескриптора кучи на рабочем столе, что по-прежнему является угрозой безопасности для устаревших систем.

3. Обнаружение этой уязвимости, возможно, стало результатом более тщательной проверки охвата кода.

4. При обнаружении уязвимостей, помимо внимания к ключевым точкам функций, вызывающих уязвимости, также следует целенаправленно проверять аномальные размещения в памяти и операции чтения и записи данных в окна.