Анализ уязвимости 0day Microsoft: возможно угрожает безопасности инфраструктуры Web3
В прошлом месяце в обновлении безопасности Microsoft был обнаружен уязвимость повышения привилегий win32k, используемая в дикой природе. Похоже, что эта уязвимость существует только в ранних версиях систем и не может быть активирована в Windows 11. Такие уязвимости используются давно, и в данной статье будет проанализировано, как злоумышленники могут продолжать использовать эту уязвимость на фоне постоянно улучшающихся новых мер смягчения. Мы завершили весь процесс анализа в среде Windows Server 2016.
Уязвимость 0day относится к уязвимостям, которые не были раскрыты и исправлены, и которые могут быть злоумышленниками использованы с целью нанесения вреда без обнаружения, часто нанося значительный ущерб. Обнаруженная уязвимость 0day находится на уровне операционной системы Windows, и злоумышленники могут получить полный контроль над Windows с её помощью. После получения контроля это может привести к краже личной информации, сбоям системы и потере данных, финансовым потерям, внедрению вредоносного ПО и другим последствиям. В небольшом масштабе это может привести к краже приватных ключей и перемещению цифровых активов; в большом масштабе это может угрожать всей экосистеме Web3, работающей на основе инфраструктуры Web2.
Анализ патча показывает, что это, похоже, всего лишь проблема с многократной обработкой счетчика ссылок объекта. Однако при просмотре старых комментариев кода выясняется, что ранее код блокировал только объект окна, но не блокировал объект меню в окне, что могло привести к неправильной ссылке на объект меню.
Анализируя контекст функции уязвимости, мы обнаружили, что переданное xxxEnableMenuItem() меню обычно уже заблокировано в верхней функции. Так какое меню нужно защищать? Дальнейший анализ показывает, что меню, возвращаемое в xxxEnableMenuItem, может быть двух видов: главное меню окна или подменю меню (, даже подподменю ).
Для создания POC мы разработали специальную четырехуровневую структуру меню и применили специальные настройки для каждого меню, чтобы обнаруживать их через функции. Когда xxxRedrawTitle возвращает пользовательский уровень, мы удалили ссылочные отношения между меню C и меню B, успешно освободив меню C. Таким образом, в точке возврата функции xxxEnableMenuItem объект меню C, на который ссылаются, уже недействителен.
Что касается реализации EXP, мы в основном рассматривали два направления: выполнение кода shellcode и использование примитивов чтения и записи для изменения адреса токена. Учитывая механизмы безопасности в более поздних версиях Windows, мы выбрали второй вариант. Весь процесс эксплуатации можно разделить на две части: как использовать уязвимость UAF для контроля значения cbwndextra и как установить стабильные примитивы чтения и записи.
Мы разработали тщательно спроектированную память, используя объекты имен окон класса окна для освобождения объектов меню, и нашли момент для записи данных в функции xxxRedrawWindow. Для достижения стабильной памяти мы спроектировали структуру из трех последовательных объектов HWND и точно определили порядок расположения объектов по адресу утечки дескриптора ядра в памяти кучи.
В отношении чтения и записи оригинальных примитивов мы используем GetMenuBarInfo() для произвольного чтения, а SetClassLongPtr() для произвольной записи. За исключением операции записи, зависимой от объекта класса второго окна для замены TOKEN, все остальные записи осуществляются с использованием объекта класса первого окна через смещение.
В общем, хотя уязвимость win32k существует давно, Microsoft попыталась переписать эту часть кода ядра с использованием Rust в предварительной версии Windows 11, и в будущем такие уязвимости могут быть устранены. Процесс эксплуатации этой уязвимости относительно прост, основная сложность заключается в том, как контролировать первую запись. Обнаружение этой уязвимости, возможно, зависит от более совершенного контроля покрытия кода. Для обнаружения уязвимостей, помимо внимания к ключевым точкам вызова функций, также может быть полезным обнаружение аномального распределения памяти и чтения/записи смещений данных для выявления аналогичных уязвимостей.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
6
Поделиться
комментарий
0/400
TestnetNomad
· 07-22 18:08
Не паникуйте, win11 на самом деле безопасен.
Посмотреть ОригиналОтветить0
TopBuyerBottomSeller
· 07-21 07:25
Еще одна причина обновить на Windows 11~
Посмотреть ОригиналОтветить0
FlatTax
· 07-20 03:35
Скандал, старый Майкрософт, не дразни!
Посмотреть ОригиналОтветить0
SurvivorshipBias
· 07-20 03:34
Чья это система еще использует win32k?
Посмотреть ОригиналОтветить0
just_another_wallet
· 07-20 03:33
Чуть не взорвал мой старый токен, глядя на это, у меня мурашки по коже.
Посмотреть ОригиналОтветить0
MrRightClick
· 07-20 03:14
Единственная версия системы, которую даже собаки не хотят - Windows 11
Уязвимость 0day в Microsoft раскрыта: безопасность инфраструктуры Web3 может быть под угрозой
Анализ уязвимости 0day Microsoft: возможно угрожает безопасности инфраструктуры Web3
В прошлом месяце в обновлении безопасности Microsoft был обнаружен уязвимость повышения привилегий win32k, используемая в дикой природе. Похоже, что эта уязвимость существует только в ранних версиях систем и не может быть активирована в Windows 11. Такие уязвимости используются давно, и в данной статье будет проанализировано, как злоумышленники могут продолжать использовать эту уязвимость на фоне постоянно улучшающихся новых мер смягчения. Мы завершили весь процесс анализа в среде Windows Server 2016.
Уязвимость 0day относится к уязвимостям, которые не были раскрыты и исправлены, и которые могут быть злоумышленниками использованы с целью нанесения вреда без обнаружения, часто нанося значительный ущерб. Обнаруженная уязвимость 0day находится на уровне операционной системы Windows, и злоумышленники могут получить полный контроль над Windows с её помощью. После получения контроля это может привести к краже личной информации, сбоям системы и потере данных, финансовым потерям, внедрению вредоносного ПО и другим последствиям. В небольшом масштабе это может привести к краже приватных ключей и перемещению цифровых активов; в большом масштабе это может угрожать всей экосистеме Web3, работающей на основе инфраструктуры Web2.
Анализ патча показывает, что это, похоже, всего лишь проблема с многократной обработкой счетчика ссылок объекта. Однако при просмотре старых комментариев кода выясняется, что ранее код блокировал только объект окна, но не блокировал объект меню в окне, что могло привести к неправильной ссылке на объект меню.
Анализируя контекст функции уязвимости, мы обнаружили, что переданное xxxEnableMenuItem() меню обычно уже заблокировано в верхней функции. Так какое меню нужно защищать? Дальнейший анализ показывает, что меню, возвращаемое в xxxEnableMenuItem, может быть двух видов: главное меню окна или подменю меню (, даже подподменю ).
Для создания POC мы разработали специальную четырехуровневую структуру меню и применили специальные настройки для каждого меню, чтобы обнаруживать их через функции. Когда xxxRedrawTitle возвращает пользовательский уровень, мы удалили ссылочные отношения между меню C и меню B, успешно освободив меню C. Таким образом, в точке возврата функции xxxEnableMenuItem объект меню C, на который ссылаются, уже недействителен.
Что касается реализации EXP, мы в основном рассматривали два направления: выполнение кода shellcode и использование примитивов чтения и записи для изменения адреса токена. Учитывая механизмы безопасности в более поздних версиях Windows, мы выбрали второй вариант. Весь процесс эксплуатации можно разделить на две части: как использовать уязвимость UAF для контроля значения cbwndextra и как установить стабильные примитивы чтения и записи.
Мы разработали тщательно спроектированную память, используя объекты имен окон класса окна для освобождения объектов меню, и нашли момент для записи данных в функции xxxRedrawWindow. Для достижения стабильной памяти мы спроектировали структуру из трех последовательных объектов HWND и точно определили порядок расположения объектов по адресу утечки дескриптора ядра в памяти кучи.
В отношении чтения и записи оригинальных примитивов мы используем GetMenuBarInfo() для произвольного чтения, а SetClassLongPtr() для произвольной записи. За исключением операции записи, зависимой от объекта класса второго окна для замены TOKEN, все остальные записи осуществляются с использованием объекта класса первого окна через смещение.
В общем, хотя уязвимость win32k существует давно, Microsoft попыталась переписать эту часть кода ядра с использованием Rust в предварительной версии Windows 11, и в будущем такие уязвимости могут быть устранены. Процесс эксплуатации этой уязвимости относительно прост, основная сложность заключается в том, как контролировать первую запись. Обнаружение этой уязвимости, возможно, зависит от более совершенного контроля покрытия кода. Для обнаружения уязвимостей, помимо внимания к ключевым точкам вызова функций, также может быть полезным обнаружение аномального распределения памяти и чтения/записи смещений данных для выявления аналогичных уязвимостей.