Анализ и использование системного уязвимости 0day от Microsoft
Введение
Недавнее обновление безопасности Microsoft устранило уязвимость повышения привилегий win32k, которая использовалась хакерами. Эта уязвимость в основном затрагивает ранние версии операционной системы Windows и, похоже, не влияет на Windows 11. В данной статье мы подробно проанализируем, как злоумышленники могут продолжать использовать такие уязвимости на фоне постоянного улучшения новых защитных мер. Наша аналитическая среда — Windows Server 2016.
Фон уязвимости
0day уязвимость относится к нераскрытым и неустраненным уязвимостям безопасности, аналогично понятию T+0 в финансовом рынке. Как только такие уязвимости будут злонамеренно использованы, они могут нанести огромный ущерб. Обнаруженная уязвимость 0day на уровне системы Windows позволяет злоумышленнику получить полный контроль над системой.
Серьезные последствия для систем, контролируемых злоумышленниками, включают утечку личной информации, сбой системы, потерю данных, финансовые убытки и внедрение вредоносных программ. Для пользователей криптовалюты это может привести к кражам приватных ключей и перемещению цифровых активов. В более широком смысле этот уязвимость может повлиять на всю экосистему Web3, основанную на инфраструктуре Web2.
Анализ патчей
Анализ патч-кода показывает, что проблема, похоже, заключается в том, что счетчик ссылок на один объект обрабатывается несколько раз. Просматривая ранние комментарии к исходному коду, мы обнаружили, что предыдущий код блокировал только объект окна, но не блокировал объект меню в окне, что могло привести к неверной ссылке на объект меню.
Проверка уязвимости
Анализируя контекст функции уязвимости, мы обнаружили, что переданное xxxEnableMenuItem() меню обычно уже блокируется в верхнем уровне функции. Так какой конкретный объект меню следует защищать? Дальнейший анализ обработки объекта меню в xxxEnableMenuItem показывает, что функция MenuItemState возвращает два возможных меню: главное меню окна или подменю(, которое включает подподменю).
Для проверки уязвимости мы создали специальную четырехуровневую структуру меню и установили некоторые специфические условия для обхода проверки в функции xxxEnableMenuItem. Когда xxxRedrawTitle возвращается к пользовательскому уровню, мы удаляем ссылочные отношения меню C и B, успешно освобождая меню C. Наконец, когда функция xxxEnableMenuItem в ядре возвращается к функции xxxRedrawTitle, объект меню C, который собирались ссылаться, уже недействителен.
Эксплуатация уязвимостей
Общая концепция
Перед тем как определить схему использования, мы обычно проводим некоторые теоретические анализы, чтобы избежать траты времени на непрактичные схемы. В данном случае использование уязвимости в основном рассматривает два направления:
Выполнение shellcode: ссылаясь на ранние подобные уязвимости, однако в более поздних версиях Windows могут возникнуть некоторые трудности в их решении.
Использование примитивов чтения и записи для изменения токена: даже в последние два года существуют открытые примеры для справки. Нам необходимо сосредоточиться на том, как впервые контролировать cbwndextra как очень большое значение, когда память UAF повторно используется.
Таким образом, мы разделим весь процесс эксплуатации на две части: как использовать уязвимость UAF для управления значением cbwndextra и как после управления этим значением реализовать стабильные примитивы чтения и записи.
Первичное запись данных
После активации уязвимости система не обязательно сразу же崩溃. Неправильное использование данных объектов окна с контролируемой памятью в основном происходит в функциях xxxEnableMenuItem MNGetPopupFromMenu() и xxxMNUpdateShownMenu().
Мы используем объект имени окна из класса WNDClass для захвата и освобождения памяти объекта меню. Ключевым моментом является нахождение места, в структуре адреса, которую мы можем построить, где можно записывать данные произвольно, даже если только на один байт.
В конечном итоге мы нашли два жизнеспособных решения в функции xxxRedrawWindow. Учитывая некоторые ограничивающие факторы, мы выбрали вариант, основанный на операции AND с флагами 2, и решили записать cb-extra класса HWND, а не cb-extra объекта окна.
стабильная память
Мы разработали память для как минимум трех последовательных объектов HWND размером 0x250 байт. Освобождаем промежуточный объект, занимая объект HWNDClass размером 0x250 байт. Данные из конца предыдущего объекта HWND используются для проверки через флаг xxxRedrawWindow, а объект меню следующего объекта HWND и объект HWNDClass служат в качестве окончательного медиатора для операций чтения и записи.
Мы стараемся контролировать, чтобы размер объектов окна и объектов HWNDClass совпадал, и гарантируем, что расширенные данные объекта окна достаточно велики. По адресу дескриптора ядра, утечащего в куче памяти, мы можем точно определить, расположены ли запрашиваемые объекты окна в ожидаемом порядке.
Реализация чтения и записи примитивов
Любое чтение оригинального языка все еще использует GetMenuBarInfo(). Для любого записи оригинального языка используется SetClassLongPtr(). За исключением операции записи TOKEN, которая зависит от объекта класса второго окна, все остальные записи используют объект класса первого окна с использованием смещения.
Итог
Уязвимость win32k существует давно, но Microsoft в настоящее время переписывает соответствующий код ядра на Rust, и в будущем новая система может исключить подобные уязвимости.
Процесс эксплуатации уязвимости не считается сложным, основная сложность заключается в том, как контролировать первую запись. Уязвимость все еще сильно зависит от утечки адреса дескриптора кучи рабочего стола, что все еще представляет собой угрозу безопасности для устаревших систем.
Обнаружение этой уязвимости, возможно, стало результатом более совершенного контроля покрытия кода. Как только API системы может достичь самой глубокой точки уязвимости на пути выполнения целевой функции, и объект окна находится в состоянии многократной вложенной ссылки, тестирование на основе фуззинга может обнаружить эту уязвимость.
Для обнаружения эксплуатации уязвимостей, помимо внимания к ключевым точкам функций, вызывающих уязвимости, также следует обращать внимание на аномальное распределение памяти и нетрадиционное чтение и запись смещений дополнительных данных окон или классов окон, что может помочь в обнаружении уязвимостей того же типа.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
23 Лайков
Награда
23
3
Поделиться
комментарий
0/400
OnChainDetective
· 08-01 09:21
ах классический win32k... шаблон совпадает с предыдущими APT эксплойтами, если честно
Глубина анализа и технологии эксплуатации 0day уязвимостей на уровне Windows
Анализ и использование системного уязвимости 0day от Microsoft
Введение
Недавнее обновление безопасности Microsoft устранило уязвимость повышения привилегий win32k, которая использовалась хакерами. Эта уязвимость в основном затрагивает ранние версии операционной системы Windows и, похоже, не влияет на Windows 11. В данной статье мы подробно проанализируем, как злоумышленники могут продолжать использовать такие уязвимости на фоне постоянного улучшения новых защитных мер. Наша аналитическая среда — Windows Server 2016.
Фон уязвимости
0day уязвимость относится к нераскрытым и неустраненным уязвимостям безопасности, аналогично понятию T+0 в финансовом рынке. Как только такие уязвимости будут злонамеренно использованы, они могут нанести огромный ущерб. Обнаруженная уязвимость 0day на уровне системы Windows позволяет злоумышленнику получить полный контроль над системой.
Серьезные последствия для систем, контролируемых злоумышленниками, включают утечку личной информации, сбой системы, потерю данных, финансовые убытки и внедрение вредоносных программ. Для пользователей криптовалюты это может привести к кражам приватных ключей и перемещению цифровых активов. В более широком смысле этот уязвимость может повлиять на всю экосистему Web3, основанную на инфраструктуре Web2.
Анализ патчей
Анализ патч-кода показывает, что проблема, похоже, заключается в том, что счетчик ссылок на один объект обрабатывается несколько раз. Просматривая ранние комментарии к исходному коду, мы обнаружили, что предыдущий код блокировал только объект окна, но не блокировал объект меню в окне, что могло привести к неверной ссылке на объект меню.
Проверка уязвимости
Анализируя контекст функции уязвимости, мы обнаружили, что переданное xxxEnableMenuItem() меню обычно уже блокируется в верхнем уровне функции. Так какой конкретный объект меню следует защищать? Дальнейший анализ обработки объекта меню в xxxEnableMenuItem показывает, что функция MenuItemState возвращает два возможных меню: главное меню окна или подменю(, которое включает подподменю).
Для проверки уязвимости мы создали специальную четырехуровневую структуру меню и установили некоторые специфические условия для обхода проверки в функции xxxEnableMenuItem. Когда xxxRedrawTitle возвращается к пользовательскому уровню, мы удаляем ссылочные отношения меню C и B, успешно освобождая меню C. Наконец, когда функция xxxEnableMenuItem в ядре возвращается к функции xxxRedrawTitle, объект меню C, который собирались ссылаться, уже недействителен.
Эксплуатация уязвимостей
Общая концепция
Перед тем как определить схему использования, мы обычно проводим некоторые теоретические анализы, чтобы избежать траты времени на непрактичные схемы. В данном случае использование уязвимости в основном рассматривает два направления:
Выполнение shellcode: ссылаясь на ранние подобные уязвимости, однако в более поздних версиях Windows могут возникнуть некоторые трудности в их решении.
Использование примитивов чтения и записи для изменения токена: даже в последние два года существуют открытые примеры для справки. Нам необходимо сосредоточиться на том, как впервые контролировать cbwndextra как очень большое значение, когда память UAF повторно используется.
Таким образом, мы разделим весь процесс эксплуатации на две части: как использовать уязвимость UAF для управления значением cbwndextra и как после управления этим значением реализовать стабильные примитивы чтения и записи.
Первичное запись данных
После активации уязвимости система не обязательно сразу же崩溃. Неправильное использование данных объектов окна с контролируемой памятью в основном происходит в функциях xxxEnableMenuItem MNGetPopupFromMenu() и xxxMNUpdateShownMenu().
Мы используем объект имени окна из класса WNDClass для захвата и освобождения памяти объекта меню. Ключевым моментом является нахождение места, в структуре адреса, которую мы можем построить, где можно записывать данные произвольно, даже если только на один байт.
В конечном итоге мы нашли два жизнеспособных решения в функции xxxRedrawWindow. Учитывая некоторые ограничивающие факторы, мы выбрали вариант, основанный на операции AND с флагами 2, и решили записать cb-extra класса HWND, а не cb-extra объекта окна.
стабильная память
Мы разработали память для как минимум трех последовательных объектов HWND размером 0x250 байт. Освобождаем промежуточный объект, занимая объект HWNDClass размером 0x250 байт. Данные из конца предыдущего объекта HWND используются для проверки через флаг xxxRedrawWindow, а объект меню следующего объекта HWND и объект HWNDClass служат в качестве окончательного медиатора для операций чтения и записи.
Мы стараемся контролировать, чтобы размер объектов окна и объектов HWNDClass совпадал, и гарантируем, что расширенные данные объекта окна достаточно велики. По адресу дескриптора ядра, утечащего в куче памяти, мы можем точно определить, расположены ли запрашиваемые объекты окна в ожидаемом порядке.
Реализация чтения и записи примитивов
Любое чтение оригинального языка все еще использует GetMenuBarInfo(). Для любого записи оригинального языка используется SetClassLongPtr(). За исключением операции записи TOKEN, которая зависит от объекта класса второго окна, все остальные записи используют объект класса первого окна с использованием смещения.
Итог
Уязвимость win32k существует давно, но Microsoft в настоящее время переписывает соответствующий код ядра на Rust, и в будущем новая система может исключить подобные уязвимости.
Процесс эксплуатации уязвимости не считается сложным, основная сложность заключается в том, как контролировать первую запись. Уязвимость все еще сильно зависит от утечки адреса дескриптора кучи рабочего стола, что все еще представляет собой угрозу безопасности для устаревших систем.
Обнаружение этой уязвимости, возможно, стало результатом более совершенного контроля покрытия кода. Как только API системы может достичь самой глубокой точки уязвимости на пути выполнения целевой функции, и объект окна находится в состоянии многократной вложенной ссылки, тестирование на основе фуззинга может обнаружить эту уязвимость.
Для обнаружения эксплуатации уязвимостей, помимо внимания к ключевым точкам функций, вызывающих уязвимости, также следует обращать внимание на аномальное распределение памяти и нетрадиционное чтение и запись смещений дополнительных данных окон или классов окон, что может помочь в обнаружении уязвимостей того же типа.