Аналіз серйозних вразливостей системи Microsoft Windows: може загрожувати безпеці екосистеми Web3
Минулого місяця в безпековому патчі, випущеному Microsoft, було виправлено уразливість підвищення привілеїв Windows, яку використовують хакери. Ця уразливість в основному впливає на ранні версії системи Windows, Windows 11, здається, не підлягає впливу.
У цій статті буде проаналізовано, як атакуючі продовжують використовувати такі вразливості на фоні постійного посилення заходів безпеки. Наш аналіз базується на Windows Server 2016.
Фон вразливості
Це 0day вразливість, тобто вразливість, яка ще не була опублікована і виправлена. Зловмисники можуть використовувати її для атак без відома користувачів, що має величезні руйнівні наслідки.
Завдяки цій уразливості на рівні Windows, хакери можуть отримати повний контроль над системою. Це може призвести до витоку особистої інформації, аварії системи, втрати даних, фінансових втрат та інших серйозних наслідків. Для користувачів Web3 приватні ключі та цифрові активи можуть бути вкрадені. З більш широкої точки зору, ця уразливість може навіть вплинути на всю екосистему Web3, що базується на інфраструктурі Web2.
Аналіз патчів
Аналізуючи код патча, проблема, здається, полягає в тому, що лічильник посилань на один об'єкт був оброблений зайвий раз. Переглядаючи ранні коментарі до виходу, ми виявили, що раніше код блокував лише об'єкт вікна, а не об'єкт меню у вікні, що могло призвести до неправильного посилання на об'єкт меню.
Відтворення вразливості
Аналізуючи контекст функції вразливості, ми виявили, що передане xxxEnableMenuItem() меню зазвичай вже заблоковане у верхньому функції, тут виникає питання, який саме об'єкт меню потрібно захистити.
Подальший аналіз показав, що функція MenuItemState в xxxEnableMenuItem повертає два можливих меню: головне меню вікна або підменю (, навіть підпідменю ).
Ми створили спеціальну чотирирівневу структуру меню для активації вразливості, ці меню повинні відповідати деяким специфічним умовам для проходження перевірки в функції. Ключовим моментом є те, що коли xxxRedrawTitle повертає рівень користувача, потрібно видалити деякі посилання між меню, звільнивши конкретні об'єкти меню. Таким чином, в момент повернення функції xxxEnableMenuItem, посилання на ці об'єкти меню вже буде недійсним.
Використання вразливостей
При розробці експлуатуючої програми (exp) ми в основному розглядали два варіанти:
Виконання shellcode коду: посилання на ранні схожі вразливості, але в новій версії Windows можуть бути деякі перешкоди.
Використання примітивів читання/запису для зміни адреси токена: цей метод нещодавно має публічний експеримент, на який можна посилатися, і має хорошу універсальність для розташування пам'яті на робочому столі та примітивів читання/запису.
Ми вибрали другий варіант, розділивши весь процес використання на два етапи: як використати вразливість UAF для контролю значення cbwndextra, а також як стабільно реалізувати операції читання та запису.
Ключовим є знайти місце, в яке можна записувати дані у структурі адреси, яку ми можемо побудувати. Врешті-решт, ми обрали реалізувати це через операцію AND з прапорцем у функції xxxRedrawWindow.
Для досягнення стабільної пам'яті, ми спроектували щонайменше три послідовних об'єкти HWND по 0x250 байтів, звільняючи середній об'єкт, зайнятий об'єктом HWNDClass. Передні та задні об'єкти HWND використовуються для перевірки через функцію та реалізації остаточних операцій читання та запису.
Ми також точно визначаємо, чи об'єкти розташовані згідно з очікуваннями, використовуючи адреси зламаних ядерних дескрипторів. Щодо операцій читання та запису, ми використовуємо GetMenuBarInfo() для реалізації довільного читання та SetClassLongPtr() для реалізації довільного запису.
Висновок
Microsoft намагається переписати код, пов'язаний з win32k, використовуючи Rust, в майбутньому такі вразливості можуть бути усунені в новій системі.
Використання таких вразливостей є відносно простим, в основному залежить від витоку адреси десктопного стека. Якщо цю проблему не вирішити повністю, застарілі системи продовжуватимуть стикатися з проблемами безпеки.
Виявлення цієї вразливості, можливо, стало можливим завдяки більш досконалим технологіям перевірки покриття коду.
Щодо виявлення експлуатації вразливостей, крім моніторингу ключових функцій, слід також звернути увагу на аномальні розташування пам'яті та поведінку читання і запису даних.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
7
Репост
Поділіться
Прокоментувати
0/400
SelfSovereignSteve
· 08-14 15:57
Використовуйте Linux, що тут можна обирати?
Переглянути оригіналвідповісти на0
rug_connoisseur
· 08-13 09:13
Ще одна дірка у Windows, вже звикли!
Переглянути оригіналвідповісти на0
rekt_but_not_broke
· 08-12 05:14
Заробіток не терпить зволікань, Гаманець спочатку потрібно захистити!
Переглянути оригіналвідповісти на0
MetaLord420
· 08-12 05:02
Грати в Windows і все ще ризикувати з web3?!
Переглянути оригіналвідповісти на0
SighingCashier
· 08-12 05:00
Стара система має цю проблему, її вже давно слід було змінити.
Переглянути оригіналвідповісти на0
ForkMaster
· 08-12 04:59
обдурювати людей, як лохів не виходить? бігти за вразливістю для Майнінгу?
Вразливості системи Windows загрожують безпеці екосистеми Web3. Експерти Глибина аналізують механізми використання.
Аналіз серйозних вразливостей системи Microsoft Windows: може загрожувати безпеці екосистеми Web3
Минулого місяця в безпековому патчі, випущеному Microsoft, було виправлено уразливість підвищення привілеїв Windows, яку використовують хакери. Ця уразливість в основному впливає на ранні версії системи Windows, Windows 11, здається, не підлягає впливу.
У цій статті буде проаналізовано, як атакуючі продовжують використовувати такі вразливості на фоні постійного посилення заходів безпеки. Наш аналіз базується на Windows Server 2016.
Фон вразливості
Це 0day вразливість, тобто вразливість, яка ще не була опублікована і виправлена. Зловмисники можуть використовувати її для атак без відома користувачів, що має величезні руйнівні наслідки.
Завдяки цій уразливості на рівні Windows, хакери можуть отримати повний контроль над системою. Це може призвести до витоку особистої інформації, аварії системи, втрати даних, фінансових втрат та інших серйозних наслідків. Для користувачів Web3 приватні ключі та цифрові активи можуть бути вкрадені. З більш широкої точки зору, ця уразливість може навіть вплинути на всю екосистему Web3, що базується на інфраструктурі Web2.
Аналіз патчів
Аналізуючи код патча, проблема, здається, полягає в тому, що лічильник посилань на один об'єкт був оброблений зайвий раз. Переглядаючи ранні коментарі до виходу, ми виявили, що раніше код блокував лише об'єкт вікна, а не об'єкт меню у вікні, що могло призвести до неправильного посилання на об'єкт меню.
Відтворення вразливості
Аналізуючи контекст функції вразливості, ми виявили, що передане xxxEnableMenuItem() меню зазвичай вже заблоковане у верхньому функції, тут виникає питання, який саме об'єкт меню потрібно захистити.
Подальший аналіз показав, що функція MenuItemState в xxxEnableMenuItem повертає два можливих меню: головне меню вікна або підменю (, навіть підпідменю ).
Ми створили спеціальну чотирирівневу структуру меню для активації вразливості, ці меню повинні відповідати деяким специфічним умовам для проходження перевірки в функції. Ключовим моментом є те, що коли xxxRedrawTitle повертає рівень користувача, потрібно видалити деякі посилання між меню, звільнивши конкретні об'єкти меню. Таким чином, в момент повернення функції xxxEnableMenuItem, посилання на ці об'єкти меню вже буде недійсним.
Використання вразливостей
При розробці експлуатуючої програми (exp) ми в основному розглядали два варіанти:
Виконання shellcode коду: посилання на ранні схожі вразливості, але в новій версії Windows можуть бути деякі перешкоди.
Використання примітивів читання/запису для зміни адреси токена: цей метод нещодавно має публічний експеримент, на який можна посилатися, і має хорошу універсальність для розташування пам'яті на робочому столі та примітивів читання/запису.
Ми вибрали другий варіант, розділивши весь процес використання на два етапи: як використати вразливість UAF для контролю значення cbwndextra, а також як стабільно реалізувати операції читання та запису.
Ключовим є знайти місце, в яке можна записувати дані у структурі адреси, яку ми можемо побудувати. Врешті-решт, ми обрали реалізувати це через операцію AND з прапорцем у функції xxxRedrawWindow.
Для досягнення стабільної пам'яті, ми спроектували щонайменше три послідовних об'єкти HWND по 0x250 байтів, звільняючи середній об'єкт, зайнятий об'єктом HWNDClass. Передні та задні об'єкти HWND використовуються для перевірки через функцію та реалізації остаточних операцій читання та запису.
Ми також точно визначаємо, чи об'єкти розташовані згідно з очікуваннями, використовуючи адреси зламаних ядерних дескрипторів. Щодо операцій читання та запису, ми використовуємо GetMenuBarInfo() для реалізації довільного читання та SetClassLongPtr() для реалізації довільного запису.
Висновок
Microsoft намагається переписати код, пов'язаний з win32k, використовуючи Rust, в майбутньому такі вразливості можуть бути усунені в новій системі.
Використання таких вразливостей є відносно простим, в основному залежить від витоку адреси десктопного стека. Якщо цю проблему не вирішити повністю, застарілі системи продовжуватимуть стикатися з проблемами безпеки.
Виявлення цієї вразливості, можливо, стало можливим завдяки більш досконалим технологіям перевірки покриття коду.
Щодо виявлення експлуатації вразливостей, крім моніторингу ключових функцій, слід також звернути увагу на аномальні розташування пам'яті та поведінку читання і запису даних.