- Тема
23k Популярність
55k Популярність
5k Популярність
15k Популярність
30k Популярність
722 Популярність
112k Популярність
26k Популярність
26k Популярність
7k Популярність
- Закріпити
23k Популярність
55k Популярність
5k Популярність
15k Популярність
30k Популярність
722 Популярність
112k Популярність
26k Популярність
26k Популярність
7k Популярність
Уразливість 0day загрожує системі Win та може поставити під загрозу безпеку інфраструктури Web3
Аналіз уразливості 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 та використання примітивів читання/запису для зміни адреси токена. Враховуючи різні фактори, ми вибрали останній.
Вся exp може бути розділена на дві ключові проблеми: як використати вразливість UAF для контролю значення cbwndextra, а також як реалізувати стабільні операції читання та запису після контролю значення cbwndextra.
реалізація першого запису даних
Ми використовуємо об'єкт імені вікна у класі вікна WNDClass для зайняття звільненого об'єкта меню. Ключовим є знайти місце в адресній структурі, яке ми можемо побудувати, куди можна записувати дані.
В кінці кінців ми вирішили реалізувати запис за допомогою бітового оператора AND 2 у функції xxxRedrawWindow. Ми записуємо cb-extra HWNDClass, а не cb-extra об'єкта вікна, щоб краще контролювати розкладку пам'яті.
 стабільна пам'ять
Ми спроектували принаймні три послідовні об'єкти HWND розміром 0x250 байт в пам'яті, звільнивши середній, який займає об'єкт HWNDClass розміром 0x250 байт. Передні та задні об'єкти HWND використовуються відповідно для перевірки параметрів та як засіб для читання/запису.
Ми точно визначаємо, чи об'єкт вікна, що запитується, розташований як очікувалося, через адресу ядрового дескриптора, витоку в пам'яті.
![Numen ексклюзив: уразливість 0day Microsoft може зламати Web3 на системному та фізичному рівнях]###https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) зміни в читанні та запису примітивів
Ми використовуємо GetMenuBarInfo###( для реалізації довільного читання, використовуючи SetClassLongPtr)( для реалізації довільного запису. Окрім операцій запису, що замінюють TOKEN, інші записи виконуються з використанням об'єкта класу першого вікна з використанням зміщення.
![Numen ексклюзив: уразливість 0day Microsoft може зруйнувати гру Web3 на системному та фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
Підсумок
Хоча вразливість win32k існує вже давно, Microsoft намагається переписати відповідний код ядра за допомогою Rust, у майбутньому такі вразливості можуть бути усунені в нових системах.
Процес експлуатації цієї вразливості відносно простий, основна складність полягає в тому, як контролювати перший запис. Вразливість все ще серйозно залежить від витоку адреси десктопного стека, що залишається загрозою безпеці для застарілих систем.
Виявлення цієї уразливості, можливо, стало можливим завдяки більш досконалому контролю покриття коду.
Для виявлення використання вразливостей, окрім уваги до ключових точок функцій, що викликають вразливість, також слід цілеспрямовано перевіряти аномальне розташування пам'яті та операції читання та запису даних вікна.
![Numen ексклюзив: вразливість Microsoft 0day може зруйнувати Web3 гру на системному + фізичному рівнях])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(