Це найвищий показник уразливості в історії .NET — приголомшливі 9.9 балів. Проблема залишається відкритою вже тиждень, і спільнота розробників активно обговорює, що відбувається. Розберімося детальніше, чому навколо цього такий галас і що це означає для компаній і програмістів у всьому світі.
Щоб зрозуміти масштаб
Для порівняння пригадаймо уразливість Log4J — настільки серйозну, що про неї повідомляли навіть BBC News. Тоді її рейтинг становив 10.0, тобто максимальний рівень за шкалою CVSS. Microsoft навіть профінансувала професійний документальний фільм про те, наскільки небезпечною була подія з Log4Shell.
Тепер Microsoft оголосила про уразливість у .NET із рейтингом 9.9, майже на рівні Log4J. Це одразу викликало хвилю тривоги, непорозумінь і безліч незручних розмов у IT-відділах по всьому світу.
Як це виглядає на практиці
Типовий діалог цього тижня виглядає приблизно так:
Керівник: «Ця нова уразливість у .NET із рейтингом 9.9 з’явилася на моїй супердорогій панелі безпеки “Executive Security Dashboard 3000”. Пам’ятаєш Log4J чотири роки тому? Там було 10. Це майже те саме. Ми в небезпеці?»
Full-stack програмист: «Все гаразд, босе. Команда .NET уже випустила патч».
Керівник: «Ця проблема існує в .NET роками. Як ми можемо знати, що нас уже не зламали?»
Прогамист: «Ми не знаємо…»
І саме в цьому головна проблема — немає жодних офіційних рекомендацій від команди безпеки .NET. Розробники не знають, де шукати ознаки атаки, як перевірити факт зламу або чи взагалі вони уразливі.
Так, можна перевірити логи — якщо ви їх зберігали — але на цьому все закінчується.
Відсутність чітких відповідей
Не дивно, що така невизначеність викликала обурення у спільноті. На GitHub розробники напряму звертаються до інженерів Microsoft, зокрема до Баррі Доранса, але його відповіді не додають впевненості.
Ось кілька прикладів:
- Питання: Чи уразливий застосунок, якщо він розміщений під IIS? Чи пом’якшує IIS цю проблему?
Відповідь: «Це питання до команди продукту IIS. Я не можу говорити від їхнього імені.» - Питання: Чи допомагає Azure Front Door (веб-фаєрвол Microsoft) пом’якшити цю уразливість?
Відповідь: «Це питання до команди Azure Front Door. Я не можу говорити від їхнього імені.» - Питання: Коли Azure App Service оновить свій runtime?
Відповідь: «Це питання до команди Azure App Service. Я не можу говорити від їхнього імені.» - Питання: Чи буде патч для .NET 6?
Відповідь: «Ні, цей реліз більше не підтримується.»
А коли розробники попросили навести конкретні приклади можливої експлуатації, відповідь була коротка:
«Як я вже сказав вище — ні.»
Azure App Service все ще працює на уразливій версії
Через тиждень після публікації уразливості перевірка нових екземплярів Azure App Service показала, що вони досі працюють на .NET 8.0.16, де є вразливість. Безпечна версія — 8.0.21 — досі не розгорнута.
Це викликає подив, враховуючи, як швидко Microsoft впроваджує оновлення в інших напрямах. Наприклад, GitHub Copilot отримав доступ до GPT-5 того ж дня, коли OpenAI його випустила. То чому ж оновлення .NET runtime із критичним патчем займає стільки часу, особливо при рейтингу 9.9 CVE?
Офіційна позиція Microsoft
Команда App Service опублікувала повідомлення, де заявила, що «працює спільно з командою .NET над усуненням проблем, які заважають вчасно постачати оновлення версій .NET runtime, доступних на платформі Windows».
Також повідомлено про розробку патчу для інфраструктури балансування навантаження, який має пом’якшити уразливість як на Windows-, так і на Linux-екземплярах. Проте оновлень про завершення цього процесу поки що немає.
Поки що Microsoft радить розробникам використовувати self-contained деплоймент — збирати застосунок із параметром --self-contained і вручну вибирати версію runtime. Наразі це єдиний надійний спосіб убезпечити .NET-застосунки в Azure.
Як спільнота реагує
Команда HeroDevs, яка продає платні патчі для застарілих версій .NET (наприклад, .NET 6), випустила на GitHub консольний застосунок для перевірки уразливості вашого runtime.
Цей тестовий інструмент надсилає спеціальні “request smuggling” запити й перевіряє, чи виникає виняток. На уразливій версії .NET 8 тест не проходить, а на виправленій .NET 10 — успішно виконується.
Але важливо: цей тест не демонструє реальної експлуатації уразливості. Він лише показує, що новий runtime по-іншому обробляє некоректні запити. Ніякого обходу авторизації не відбувається.
Спроба зрозуміти суть проблеми
Імовірно, йдеться про атаку типу HTTP Request Smuggling — коли зловмисник ховає один HTTP-запит (наприклад, DELETE) усередині іншого, легітимного запиту (GET), використовуючи HTTP chunking.
Приклад:
GET /user— запит, доступний будь-якому користувачеві з роллю User.DELETE /user— запит, який вимагає роль Admin.
Якщо ці запити об’єднані в один, сервер може розділити їх і обробити окремо. Зазвичай Kestrel (вебсервер .NET) видає виняток BadHttpRequestException, що безпечно.
Але якщо ви винесли перевірку авторизації за межі застосунку — наприклад, у WAF, API Gateway або зовнішній проксі, — цей зовнішній компонент може не побачити прихований запит DELETE. У результаті ваш застосунок у .NET прийме його як дійсний і виконає, вважаючи, що він уже авторизований.
Отже:
- Застосунки з зовнішньою авторизацією можуть бути вразливими.
- Застосунки з вбудованою авторизацією у .NET-коді — найімовірніше, у безпеці.
- WAF, якщо правильно налаштований, повинен блокувати такі запити.
Проблема не лише технічна, а й комунікаційна
Найбільша проблема тут — не стільки сама уразливість, скільки відсутність прозорого спілкування.
«Баррі, будь ласка, як керівник безпеки .NET, поясніть детальніше. Напишіть блог, у якому чітко розкажіть, що відбувається і як перевірити, чи наш застосунок у небезпеці.»
Адже виставивши рейтинг 9.9 без будь-яких інструкцій, Microsoft створила дві ситуації:
- Здається, ніби компанія щось приховує.
- Або ж — поширює паніку без реальної причини.
Якби рейтинг був 7 чи 8, більшість розробників просто встановила б оновлення і забула. Але 9.9 звучить тривожно, особливо коли самі сервіси Azure залишаються неоновленими.
Висновок
Ця ситуація показує: безпека — це не лише про патчі, а й про довіру та комунікацію.
Команда безпеки Microsoft для .NET має не просто випускати CVE-звіти, а чітко пояснювати ризики та підтримувати актуальність середовищ Azure.
Поки що єдиний надійний крок для розробників — збирати застосунки з оновленими runtime вручну та уважно стежити за офіційними оновленнями.