Аналіз та використання системного уразливості 0day Microsoft
Вступ
Нещодавно безпекове оновлення Microsoft виправило уразливість підвищення привілеїв win32k, яку активно використовують хакери. Ця уразливість головним чином впливає на ранні версії системи Windows і, схоже, не є актуальною для Windows 11. У цій статті буде детально проаналізовано, як під час постійного вдосконалення нових засобів захисту зловмисники можуть продовжувати використовувати такі уразливості. Наша аналітична середа - Windows Server 2016.
Фон вразливості
0day уразливість вказує на неоприлюднені та неусунені безпекові уразливості, подібно до концепції T+0 торгівлі на фінансових ринках. Як тільки такі уразливості будуть зловмисно використані, вони зазвичай можуть завдати величезної шкоди. Виявлена уразливість системного рівня Windows 0day може дозволити зловмисникам отримати повний контроль над системою.
Наслідки контролю системи зловмисниками є серйозними, включаючи витік особистої інформації, збої системи, втрату даних, фінансові втрати, впровадження шкідливих програм тощо. Для користувачів криптовалюти приватний ключ може бути вкрадений, цифрові активи можуть бути переведені. У більш широкому сенсі, цей уразливість може навіть вплинути на всю екосистему 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 HWNDClass, а не в cb-extra об'єкта вікна.
![Numen ексклюзив: уразливість Microsoft 0day може знищити Web3 гру на системному та фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) стабільна пам'ять
Ми спроектували пам'ятне розташування для принаймні трьох поспіль об'єктів HWND по 0x250 байт. Звільняємо проміжні об'єкти, займаючи об'єкт HWNDClass розміром 0x250 байт. Дані з кінця попереднього об'єкта HWND використовуються для перевірки через прапор xxxRedrawWindow, а об'єкт меню наступного об'єкта HWND та об'єкт HWNDClass служать остаточним засобом для читання та запису.
Ми намагаємося контролювати, щоб розмір об'єктів вікна та HWNDClass збігалися, і переконатися, що розширені дані об'єкта вікна достатньо великі. Завдяки адресі ядра, що витікає з пам'яті купи, ми можемо точно визначити, чи об'єкти вікна були запитувані в очікуваному порядку.
![Numen ексклюзив: уразливість Microsoft 0day може зламати Web3 гру на системному та фізичному рівнях]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) реалізація читання та запису примітивів
Будь-яке читання оригінальної мови все ще використовує GetMenuBarInfo###(. Будь-яке записування оригінальної мови використовує SetClassLongPtr)(. Крім записів, що замінюють TOKEN, які залежать від класу другого вікна, інші записи використовують клас першого вікна для реалізації за допомогою зсуву.
![Numen ексклюзив: уразливість Microsoft 0day може зламати Web3 гру на системному+фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
Підсумок
Уразливість win32k існує вже давно, але Microsoft перебудовує відповідний код ядра на Rust, тому в майбутньому нові системи можуть уникнути таких вразливостей.
Процес використання уразливості не є складним, основна складність полягає в тому, як контролювати перший запис. Уразливість все ще серйозно залежить від витоку адреси десктопного купи, що залишається загрозою безпеці для застарілих систем.
Виявлення цього вразливості, ймовірно, стало можливим завдяки більш досконалому контролю покриття коду. Як тільки API системи може досягти найглибшої точки вразливості в виконуваному шляху цільової функції, і об'єкт вікна перебуває в стані багаторівневих вкладених посилань, тестування з використанням фуззу може виявити цю вразливість.
Щодо виявлення експлуатації вразливостей, окрім уваги до ключових моментів функцій, що викликають вразливості, слід також звернути увагу на аномальні структури пам'яті та нетрадиційне читання/запис додаткових даних про вікна або класи вікон, що може допомогти виявити вразливості того ж типу.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Глибина аналізу та технології експлуатації 0day у системі Windows
Аналіз та використання системного уразливості 0day Microsoft
Вступ
Нещодавно безпекове оновлення Microsoft виправило уразливість підвищення привілеїв win32k, яку активно використовують хакери. Ця уразливість головним чином впливає на ранні версії системи Windows і, схоже, не є актуальною для Windows 11. У цій статті буде детально проаналізовано, як під час постійного вдосконалення нових засобів захисту зловмисники можуть продовжувати використовувати такі уразливості. Наша аналітична середа - Windows Server 2016.
Фон вразливості
0day уразливість вказує на неоприлюднені та неусунені безпекові уразливості, подібно до концепції T+0 торгівлі на фінансових ринках. Як тільки такі уразливості будуть зловмисно використані, вони зазвичай можуть завдати величезної шкоди. Виявлена уразливість системного рівня Windows 0day може дозволити зловмисникам отримати повний контроль над системою.
Наслідки контролю системи зловмисниками є серйозними, включаючи витік особистої інформації, збої системи, втрату даних, фінансові втрати, впровадження шкідливих програм тощо. Для користувачів криптовалюти приватний ключ може бути вкрадений, цифрові активи можуть бути переведені. У більш широкому сенсі, цей уразливість може навіть вплинути на всю екосистему 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 HWNDClass, а не в cb-extra об'єкта вікна.
![Numen ексклюзив: уразливість Microsoft 0day може знищити Web3 гру на системному та фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) стабільна пам'ять
Ми спроектували пам'ятне розташування для принаймні трьох поспіль об'єктів HWND по 0x250 байт. Звільняємо проміжні об'єкти, займаючи об'єкт HWNDClass розміром 0x250 байт. Дані з кінця попереднього об'єкта HWND використовуються для перевірки через прапор xxxRedrawWindow, а об'єкт меню наступного об'єкта HWND та об'єкт HWNDClass служать остаточним засобом для читання та запису.
Ми намагаємося контролювати, щоб розмір об'єктів вікна та HWNDClass збігалися, і переконатися, що розширені дані об'єкта вікна достатньо великі. Завдяки адресі ядра, що витікає з пам'яті купи, ми можемо точно визначити, чи об'єкти вікна були запитувані в очікуваному порядку.
![Numen ексклюзив: уразливість Microsoft 0day може зламати Web3 гру на системному та фізичному рівнях]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) реалізація читання та запису примітивів
Будь-яке читання оригінальної мови все ще використовує GetMenuBarInfo###(. Будь-яке записування оригінальної мови використовує SetClassLongPtr)(. Крім записів, що замінюють TOKEN, які залежать від класу другого вікна, інші записи використовують клас першого вікна для реалізації за допомогою зсуву.
![Numen ексклюзив: уразливість Microsoft 0day може зламати Web3 гру на системному+фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
Підсумок
Уразливість win32k існує вже давно, але Microsoft перебудовує відповідний код ядра на Rust, тому в майбутньому нові системи можуть уникнути таких вразливостей.
Процес використання уразливості не є складним, основна складність полягає в тому, як контролювати перший запис. Уразливість все ще серйозно залежить від витоку адреси десктопного купи, що залишається загрозою безпеці для застарілих систем.
Виявлення цього вразливості, ймовірно, стало можливим завдяки більш досконалому контролю покриття коду. Як тільки API системи може досягти найглибшої точки вразливості в виконуваному шляху цільової функції, і об'єкт вікна перебуває в стані багаторівневих вкладених посилань, тестування з використанням фуззу може виявити цю вразливість.
Щодо виявлення експлуатації вразливостей, окрім уваги до ключових моментів функцій, що викликають вразливості, слід також звернути увагу на аномальні структури пам'яті та нетрадиційне читання/запис додаткових даних про вікна або класи вікон, що може допомогти виявити вразливості того ж типу.