Microsoft оголосила про значний крок уперед у галузі кіберзахисту на основі штучного інтелекту
Microsoft оголосила про значний крок уперед у галузі кіберзахисту на основі штучного інтелекту
Microsoft оголосила про значний крок вперед в області кіберзахисту на основі ІІ: нова агентна система безпеки допомогла дослідникам виявити 16 нових вразливостей у мережному стеку та стеку автентифікації Windows, включаючи чотири критичні вразливості віддаленого виконання коду в таких компонентах, як стек TCP/IP ядра Windows і служба I. Вони використовували новий багатомодельний агентний сканер Microsoft Security (кодова назва MDASH), розроблений командою Microsoft Autonomous Code Security. На відміну від одноробних підходів, цей інструмент координує роботу понад 100 спеціалізованих агентів ІІ в рамках ансамблю перспективних та спрощених моделей для виявлення, аналізу та доказу експлуатованих помилок від початку до кінця.
Результати говорять самі за себе: 21 із 21 виявленої вразливості з нульовою кількістю помилкових спрацьовувань на приватному тестовому драйвері; 96% повнота виявлення за результатами п'яти років підтверджених випадків Центру реагування на інциденти безпеки Microsoft (MSRC) у clfs.sys та 100% у tcpip.sys; і лідируючий у галузі показник 88,45% у загальнодоступному бенчмарку CyberGym, що охоплює 1507 реальних уразливостей — найкращий результат у таблиці лідерів, що приблизно на п'ять пунктів випереджає наступний показник.
Стратегічний висновок очевидний: виявлення вразливостей в ІІ перейшло з розряду дослідницьких цікавостей у категорію виробничого захисту корпоративного рівня, і стійка перевага полягає в агентній системі, що оточує модель, а не в якійсь окремій моделі. Кодове ім'я MDASH використовується командами розробників безпеки Microsoft та тестується невеликою групою клієнтів у рамках обмеженого приватного попереднього тестування.
У цьому пості пояснюється, як працює кодове ім'я MDASH, що ми випустили сьогодні, чого навчилися в процесі роботи та як ви можете зареєструватися для участі у закритому попередньому перегляді.
Виявлення вразливостей за допомогою ІІ в гіпермасштабі
Команда Microsoft Autonomous Code Security (ACS) була створена для того, щоб перетворити дослідження вразливостей з використанням ІІ з простого наукового інтересу на розробку виробничих рішень корпоративного масштабу. Декілька членів цієї команди прийшли до Microsoft з команди Team Atlanta, яка виграла конкурс DARPA AI Cyber Challenge з призом у 29,5 мільйонів доларів, створивши автономну систему кіберлогічного аналізу, яка знаходила та виправляла реальні помилки у складних проектах з відкритим вихідним кодом. Уроки, викладені з цієї роботи, особливо рівень інженерних рішень, необхідних для того, щоб передові мовні моделі виконували професійний аудит безпеки, стали основою нашої нової багатомодельної системи агентного сканування (кодова назва MDASH).
Кодова база Microsoft є складним завданням для аудиту безпеки з кількох причин:
Величезна пропрієтарна поверхня. Windows, Hyper-V, Azure, а також екосистеми драйверів пристроїв і служб навколо них — це приватні кодові бази Microsoft, що не входять до навчального корпусу будь-якої стандартної мовної моделі, і з ними дійсно складно працювати: угоди про виклик ядра, інваріанти IRP і блокувань, межі довіри IPC та ідіоми всередині компонентів. На цій поверхні моделі доводиться справді міркувати.
DevSecOps у масштабі. Кожна виявлена проблема має реальний відповідальний, процес сортування та план впровадження виправлень по вівторках. Немає «тихої скриньки» для припущень; якщо інструмент видає шум, цей шум стає проблемою всім.
Цінні цілі. Windows, Hyper-V, Xbox та Azure обслуговують мільярди користувачів. Вигода від виявлення однієї-єдиної серйозної помилки надзвичайно висока - як і вартість хибного спрацьовування в компоненті першого рівня.
Результати, представлені в цьому пості, є наслідком тісної співпраці між ACS, Microsoft Offensive Research & Security Engineering (MORSE) та Microsoft Windows Attack Research and Protection (WARP). WARP та MORSE відповідають за глибоке та складне дослідження загроз Windows; ACS надає конвеєр виявлення та перевірки на основі штучного інтелекту. Разом команди розробили зрілу систему інструментів.
Кодова назва: MDASH – нова багатомодельна система агентного сканування від Microsoft Security.
За своєю суттю, Codename MDASH - це система виявлення та усунення вразливостей, керована агентом. Модель – це один із вхідних параметрів. Система – це продукт.
Корисною уявною моделлю є представлення цього процесу як структурованого конвеєра, який приймає кодову базу та видає перевірені, підтверджені результати:
Етап підготовки: обробляє вихідний код цільового об'єкта, створює індекси з урахуванням мови програмування, а потім будує модель поверхні атаки та загроз на основі аналізу попередніх комітів.
Етап сканування: Запускає спеціалізованих агентів-аудиторів по потенційних шляхах виконання коду, видаючи результати з гіпотезами та доказами.
Етап перевірки : Запускається друга група учасників — дебатерів, які наводять аргументи за та проти досяжності та можливості використання кожного з отриманих результатів.
Етап дедуплікації: поєднує семантично еквівалентні результати (наприклад, угруповання на основі фрагментів).
Етап доказу: Формує та виконує вхідні параметри, що запускають помилку, якщо клас помилки це допускає. На етапі доказу динамічно перевіряється попередня умова і формулюються вхідні параметри, що запускають помилку, для підтвердження існування вразливості (наприклад, ASan C/C++).
На практиці це працює завдяки трьом властивостям:
Ансамбль різноманітних моделей, що ефективно керуються за допомогою кодової назви MDASH. Жодна модель не є найкращою на кожному етапі. Багатомодельна агентна система сканування використовує панель моделей, що настроюється. Вона включає моделі SOTA як основний засіб логічного висновку, спрощені моделі як економічний засіб для обговорення великого обсягу питань, а також другу окрему модель SOTA як незалежний контраргумент. Розбіжності між моделями власними силами є сигналом: коли аудитор зазначає щось як підозріле, а учасник обговорення неспроможна це спростувати, наступна достовірність цього висновку підвищується.
Спеціалізовані агенти. Аудитор міркує не так, як сперечальник, а сперечальник — не так, як доводить. Кожен етап конвеєра має свою роль, режим підказок, інструменти та критерії зупинки. Ми не очікуємо, що одна підказка зробить усе; ми не очікуємо, що один агент зможе розпізнати, підтвердити та використати помилку за один прохід. У Codename MDASH працює понад 100 спеціалізованих агентів, створених на основі глибокого дослідження минулих поширених уразливостей та загроз (CVE) та їх виправлень, які працюють незалежно один від одного для виявлення помилок, а результати їхнього аудиту будуть об'єднані в єдиний звіт.
Наскрізний конвеєр з плагінами, що розширюються. Конвеєр має свої особливості, але він не замкнутий. Плагіни дозволяють експертам у предметній області додавати контекст, який базові моделі не можуть побачити самостійно – угоди про виклик ядра, правила IRP, інваріанти блокувань, межі довіри IPC, кінцеві автомати кодеків. p align="justify"> Плагін для доказу CLFS, який ми описуємо нижче, є одним з таких прикладів: плагін для предметної області, який знає, як створити файл журналу, що запускає процес, на основі потенційного результату. Наприклад, можна використовувати розширені можливості логування команди Windows за допомогою бази даних користувача аналізу коду або бази даних CodeQL.
Перевагою такої архітектури є переносимість між поколіннями моделей. Етапи націлення, валідації, дедуплікації та перевірки в конвеєрі за своєю конструкцією не залежать від моделі, що дозволяє використовувати найкращі можливості будь-якої моделі. Коли з'являється нова модель, A/B-тестування порівняно з поточною панеллю здійснюється лише однією зміною конфігурації. При поліпшенні моделі попередні інвестиції клієнта – файли області видимості, плагіни, конфігурації, калібрування – зберігаються, дозволяючи клієнтам використати весь потенціал безпеки.
Використання кодового імені MDASH у дослідженнях у галузі безпеки.
Для оцінки можливостей багатомодельного агентного сканування пошуку помилок необхідно спочатку вивчити код, який ніколи раніше не використовувався моделлю. Це унеможливлює те, що модель «засвоїла відповіді на тест». Ми просканували StorageDrive, приклад драйвера пристрою, який використовується в інтерв'ю Microsoft для дослідників у сфері наступальної безпеки. Драйвер містить 21 навмисно впроваджену вразливість, включаючи помилки використання пам'яті після звільнення (UAF) в ядрі, проблеми обробки цілих чисел, прогалини в перевірці IOCTL та помилки блокування. Оскільки StorageDrive - це закритий код, який ніколи не публікувався, ми можемо з упевненістю припустити, що він не був включений до навчальних даних сучасних мовних моделей.
Ми запустили тестовий стенд на StorageDrive, використовуючи його стандартну конфігурацію. Результати виявилися разючими: всі 21 еталонна вразливість були правильно ідентифіковані, при цьому в цьому запуску не було жодного хибного спрацьовування.
Цей простий тест показує, що можливості алгоритму MDASH щодо міркувань та виявлення вразливостей можуть бути порівняні з можливостями професійних дослідників у галузі наступальних операцій.
Потім ми використовуємо це обладнання для проведення аудиту безпеки найважливішої для системи Windows частини, а саме мережного стека TCP/IP.
Два глибоких занурення
Наведені нижче приклади характерні для можливостей нового конвеєра багатомодельного генетичного сканування Microsoft Security, недоступних при використанні однієї моделі . Перший приклад - це стан гонки ядра, пов'язане з використанням звільненої пам'яті після звільнення, що вимагає аналізу часу життя об'єкта в рамках нетривіального потоку управління та трьох незалежних паралельних шляхів звільнення пам'яті. Другий приклад - це подвійне звільнення пам'яті, пов'язане з псевдонімами, яке охоплює шість вихідних файлів і проявляється лише на тлі коректно обробленої ділянки у тій самій кодовій базі.
CVE-2026-33827 — Видалений неавтентифікований UAF у tcpip.sys через SSRR
Уразливість виникає у шляху прийому IPv4 у Windows через некоректне управління часом життя об'єкта Path з підрахунком посилань всередині функції Ipv4pReceiveRoutingHeader. Після виклику пошуку маршруту функція видаляє своє єдине посилання, що їй належить, на Path за допомогою операції розіменування, але пізніше повторно використовує той же покажчик при обробці суворої маршрутизації джерела і запису (SSRR). Оскільки лічильник посилань об'єкта може досягти нуля на ранньому етапі звільнення пам'яті, базова пам'ять може бути повернена в розподільник пам'яті, прив'язаний до конкретного процесора, і згодом повторно використана, перетворюючи подальший доступ до класичного використання пам'яті після звільнення в контексті ядра.
Це відбувається на мережному шляху, що обробляє контрольовані зловмисником метадані пакетів, що робить його доступним на підвищеному рівні IRQL у мережевому стеку. Основна проблема ускладнюється моделлю паралельного доступу до кешу шляху та пов'язаними з ним процедурами очищення. Після того, як сторона, що викликає, відмовляється від права власності, життєздатність об'єкта Path повністю залежить від зовнішніх посилань, що зберігаються в загальних структурах даних. Декілька незалежних підсистем, включаючи збирач кешу шляху, явні процедури очищення та складання сміття, керовану станом інтерфейсу, можуть одночасно видаляти об'єкт і відкидати останнє посилання. Ці операції не синхронізовані з вікном виконання на стороні прийому цієї функції, і блокування для серіалізації доступу не утримується. В результаті в системах SMP звільнений об'єкт може бути повернутий і перезаписаний до наступного розіменування, перетворюючи просту помилку порядку виконання ситуації гонки використання після звільнення з реальною можливістю виконання.
З точки зору експлуатації вразливість доступна віддаленому неавтентифікованому зловмиснику через спеціально сформовані пакети IPv4, що містять опцію SSRR, які проходять стандартні перевірки. Розіменування застарілого покажчика може запустити ланцюжок доступу через звільнену пам'ять, потенційно приводячи до контрольованого читання та сильнішого примітиву пошкодження, якщо звільнений простір виділено під впливом зловмисника. Хоча для експлуатації потрібно виграти вузьке тимчасове вікно та вплинути на повторне використання розподільника пам'яті, поєднання віддаленої доступності, контексту виконання ядра та потенційної можливості контрольованого маніпулювання пам'яттю підвищує рівень серйозності проблеми до критичного.
Чому в системах з однією моделлю цей баг був упущений?
В одному примірнику моделі ця помилка часто залишається непоміченою, оскільки порушення часу життя не видно локально навіть у межах однієї й тієї функції. Звільнення посилання на Path та її подальше повторне використання розділені нетривіальним потоком управління — альтернативною гілкою, множинними перевірками валідації та кількома умовами раннього видалення — що порушує просту схему «звільнення-потім-використання», на яку покладається більшість детекторів. Без відстеження володіння посиланням цих проміжних станах модель бачить дві незалежні операції, а чи не тимчасову залежність. У результаті розіменування не виглядає підозрілим саме собою, навіть незважаючи на те, що семантика підрахунку посилань гарантує, що покажчик може бути вже недійсним.
Вирішальний сигнал знаходиться поза безпосереднього контексту. Та ж логічна операція з'являється і в іншому місці в правильному порядку; всі необхідні дані витягуються з об'єкта до того, як буде відкинуто посилання. Це робить момент виклику не очевидним зловживанням, а чи не протиріччям.
Для виявлення цього потрібно міжфайловий аналіз: виявлення аналогічних шаблонів, зіставлення їх намірів та виявлення відхилень. Крім того, досяжність залежить від поєднання кількох умов - вхідних даних, що встановлюють прапор SSRR, конфігурації за замовчуванням, що дозволяє шлях, та паралельних підсистем, які можуть звільнити об'єкт протягом періоду доступності. Одноетапний аналіз поєднує ці кроки та втрачає взаємодію між ними, тоді як поетапний підхід може пов'язати порушення прав власності, модель паралельного доступу та зовні керований тригер у узгоджений шлях експлуатації.
Повідомлення . Вразливість CVE-2026-33827 виправлена в квітневому оновленні Patch Tuesday.
CVE-2026-33824: Неавтентифікований IKEv2 SA_INIT + фрагментація → подвійне звільнення пам'яті → локальне віддалене виконання коду
Уразливість перебувала у службі IKEEXT, компоненті Windows, що відповідає за генерацію ключів IKE та AuthIP для IPsec, і була доступна віддаленому неавтентифікованому зловмиснику за протоколом UDP/500 на будь-якому хості, налаштованому як відповідач IKEv2 (RRAS VPN, DirectAccess, машина Always з'єднання). Відправивши спеціально сформований IKE_SA_INIT, що містить корисне навантаження «IPsec Security Realm Id» постачальника Microsoft, за якою слідує єдиний фрагмент IKEv2 (RFC 7383 SKF), який негайно збирається заново, зловмисник міг ініціювати детерміноване подвійне звільнення1.
Оскільки IKEEXT працює від імені LocalSystem всередині svchost.exe, це шлях віддаленого виконання коду до аутентифікації в одному з контекстів з найвищими привілеями в системі. Причина - це типова помилка володіння. Коли IKEEXT повторно впроваджує зібраний фрагмент через конвеєр прийому, він дублює контекст прийому пакета за допомогою плоского копіювання пам'яті (memcpy). Це поверхове копіювання: воно клонує байти структури, але не виділені в купі області пам'яті, на які вона вказує. Одна з цих областей — це наданий зловмисником ідентифікатор галузі безпеки, і після копіювання як контекст у черзі, так і активний SA в основному режимі містять один і той самий покажчик, і обидва вважають, що володіють ним.
При завершенні роботи кожен із них звільняє пам'ять, що призводить до подвійного звільнення. Послідовність запуску - два UDP-пакети, без стану гонки і без спеціальних часових параметрів. IKEEXT працює від імені LocalSystem svchost.exe. Подвійне звільнення фрагмента купи фіксованого розміру – добре відомий примітив ушкодження у сучасних Windows; ми не публікуємо подальші деталі експлуатації. Для забезпечення доступності потрібно, щоб хост мав політику відповіді IKEv2, яка приймає запропоновані перетворення - вразливість доступна в правилах безпеки з'єднань RRAS VPN, DirectAccess, Always-On VPN і IPsec в їх типових конфігураціях, але хост Start-Service IKEEXT без політики відповіді не уяві. Служба IKEEXT DEMAND_START за замовчуванням запущена; якщо існує політика відповіді, BFE запустить її при першому вхідному пакеті IKE, тому зловмиснику не потрібно, щоб IKEEXT вже працював.
Чому системи з однією моделлю не виявили цієї помилки
Помилка являє собою помилку життєвого циклу псевдонімів, що зачіпає шість файлів: ike_A.c(неправильне копіювання пам'яті), ike_B.c(джерело псевдоніма і перше локальне копіювання в стек), ike_C.c(неправильне звільнення пам'яті), ike_D.c(як ike_E.c(місце віддаленого заповнення буфера) та ike_F.c(диспетчер IKEv2 та місце читання UAF, що передує другому звільненню пам'яті). Аналіз одного файлу її не виявляє. Найбільш переконливим доказом існування помилки є правильна версія того ж шаблону в тій же кодовій базі, розташована ike_D.c відразу після memcpyселектора. Для виявлення цієї помилки аудитор має розпізнати відсутній крок в одному місці, посилаючись на існуючий крок в іншому. Наші спеціалізовані аудитори призначені для виявлення саме таких порівнянь; етап обговорення змушує їх вистояти під перехресним допитом.
Повідомлення. Вразливість CVE-2026-33824 виправлена в квітневому оновленні Patch Tuesday.
Наскільки функціональним є кодовий бренд MDASH?
Оновлення по вівторках та StorageDrive – це сигнали, що вказують на майбутнє. Два ретроспективні тести показують, як система працює в порівнянні з реальними, добре перевіреними версіями коду.
Згадаймо історичні випадки із MSRC. Ми повторно запустили перевірку з кодовим ім'ям MDASH на передпатч-знімках двох ретельно перевірених компонентів Windows і виміряли, чи були б (повторно) виявлені історично підтверджені MSRC помилки:
clfs.sys: 96% відкликання по 28 випадках MSRC за п'ять років.
tcpip.sys: 100% відкликання продукції за 7 випадками MSRC за п'ять років.
Це найпереконливіші внутрішні дані, які ми публікуємо, і вони мають особливе значення: база даних інцидентів MSRC — це істина про те, що дійсно використовували зловмисники, що вимагало оновлення у вівторок і на що довелося реагувати захисникам. Система, яка відновлює 96% уразливостей із п'ятирічного списку MSRC у ретельно перевіреному компоненті ядра, виявляє не теоретичні слабкі місця, а справді важливі помилки.
Ми ретельно продумуємо, що ці цифри кажуть, а що ні. Це ретроспективні показники виявлення помилок у внутрішньому коді з обмеженою кількістю випадків. Вони показують, що система була б корисною, якби існувала на той час. Самі по собі вони не передбачають, що наступні 38 помилок у CLFS будуть виявлені з тією самою швидкістю. Прогнозний сигнал – це сама група оновлень Patch Tuesday.
Розширення для перевірки CLFS як наочний приклад. Показник повноти виявлення CLFS 96% частково пояснюється етапом перевірки. Багато результатів перевірки CLFS виглядають цікавими, поки ви не спробуєте створити файл журналу, який запускає процес; Виявлення потенційної помилки без доказу на практиці – це запис у списку завдань для сортування. Розроблений нами плагін для перевірки CLFS знає, як створювати файли журналів, що запускають процес, на основі потенційної помилки: він досить добре розуміє структуру контейнера на диску, послідовність перевірки блоків та кінцевий автомат у пам'яті, щоб направити шлях до цільового об'єкта. Саме для цього і призначена розширюваність плагінів: базові моделі не повинні і не повинні враховувати специфічні для Microsoft інваріанти файлової системи. Плагін впроваджує їх, модель використовує їх, і в результаті виходять помилки, що залишаються перевіреними, а не помилки, які реєструються та забуваються.
CyberGym. На загальнодоступному бенчмарку CyberGym - корпусі з 1507 реальних завдань відтворення вразливостей, взятих зі 188 проектів OSS-Fuzz - багатомодельна агентна система сканування Microsoft Security досягає показника успішності 88,45%, що є найвищим результатом в опублікованій таблиці лідерів ніж у наступної за популярністю системи, 83,1%. Цей результат отримано з використанням загальнодоступних моделей. Переконливі результати свідчать про те, що навколишня агентна система робить істотний внесок у наскрізну продуктивність, виходячи за рамки можливостей самої моделі. Для оцінки ми використовували конфігурацію CyberGym за умовчанням (рівень 1), яка надає вразливий вихідний код та високорівневий опис вразливості. Для взаємодії з протоколом оцінки CyberGym ми розширили етап перевірки системи, щоб вона могла автономно надсилати вхідні дані для підтвердження концепції (PoC) та отримувати прапори.
Аналіз помилок, виявлених у решті приблизно 12%, показує дві помітні структурні закономірності: серед помилок, спрямованих на неправильну ділянку коду, 82% були пов'язані із завданнями з розпливчастими описами, в яких також були ідентифікатори функцій або файлів, що говорить про те, що якість опису є важливим фактором точності сканування. Ми також виявили випадки, коли агент створював вхідні дані в стилі libFuzzer, але для еталонного завдання фактично були потрібні вхідні дані у форматі honggfuzz, що призводило до збоїв у відтворенні коректних результатів через невідповідність формату тестового набору даних.
Що все це означає
Нині у галузі виявлення вразливостей з допомогою ІІ перестає бути спекулятивним завданням і починає перетворюватися на інженерну проблему. Результати, представлені в цьому «Вівторку оновлень», та ретроспективний аналіз п'ятирічних випадків CLFS MSRC свідчать про те, що виявлення вразливостей за допомогою ІІ може масштабуватись.
Як ми зрозуміли, створюючи MDASH і використовуючи його в Microsoft, він має більшу портативність: всю роботу виконує модуль, а модель є одним із вхідних параметрів
Це має значення у трьох конкретних аспектах.
По-перше, виявлення потрібно композиція, яку неможливо реалізувати з допомогою одного запроса . Помилки, описані в цьому пості - tcpip.sysгонка, ikeext.dllланцюжок псевдонімів - не видно моделі, якій передана одна функція. Вони видно системі, яка може послідовно порівнювати шаблони між файлами, проводити багатокроковий аналіз досяжності, обговорювати питання між спеціалізованими агентами та будувати докази від початку до кінця. Використання однієї моделі недооцінює можливості моделей; надмірно довірені окремі агенти перевершують можливості моделей у плані надійності. Мистецтво полягає у створенні системи навколо моделі, а система – це велика частина інженерної роботи.
По-друге, валідація — це різниця між виявленою проблемою та виправленою. Сканер, який наголошує на потенційних помилках, — це сканер, який формує список завдань для сортування. Програма Patch Tuesday стала такою, якою вона є, тому що система, яка її створила, не зупиняється на потенційних помилках — вона обговорює їх, видаляє дублікати та доводить їхню наявність. Валідація - це не просто галочка; це окремий конвеєр агентів і плагінів, і саме тут зрештою зосереджена більшість повсякденної роботи інженерів.
По-третє, система поглинає поліпшення моделей, що робить її довговічною. Коли з'являється нова модель, етапи націлення, обговорення, видалення дублікатів та перевірки не потрібно переписувати; ми змінюємо конфігурацію та повторно запускаємо A/B-тестування. Інвестиції клієнта – контекст проекту, плагіни сканування, агенти перевірки – зберігаються. Ця архітектурна властивість має найбільше значення з часом, тому що лотерея моделей продовжуватиметься, і будь-яка система, цінність якої залежить від конкретної моделі, — це система, яку необхідно перебудовувати кожні шість місяців.
Для фахівців із захисту — незалежно від масштабу та типу коду — висновок той самий. Правильне питання, яке слід поставити інструменту виявлення вразливостей в ІІ, полягає не в тому, яку модель він використовує, а в тому, що він робить із цією моделлю і що залишається після появи наступної моделі?
