17.05.2026
1 хв
168
Дослідник безпеки заявив, що Microsoft відмовилася визнавати критичну вразливість в Azure, яка могла відкривати доступ до чужих хмарних ресурсів і telemetry data. Компанія не видала CVE та назвала проблему наслідком конфігурації клієнтів, а не дефектом самої платформи.
Дослідник безпеки звинуватив Microsoft у тому, що компанія непомітно виправила критичну вразливість Azure Backup for AKS після відхилення його звіту та блокування видачі CVE. Йдеться про проблему, яка могла дозволити отримати права адміністратора Kubernetes-кластера, маючи лише низькопривілейовану роль Backup Contributor.
Вразливість виявив дослідник Джастін О’Лірі ще у березні 2026 року. 17 березня він передав звіт до Microsoft Security Response Center, однак уже 13 квітня компанія відхилила повідомлення.
У Microsoft заявили, що проблема нібито не є вразливістю безпеки, оскільки для атаки зловмисник «вже мав мати адміністративний доступ». Сам О’Лірі назвав це трактування повністю неправильним.
«Це фактично невірно. Уразливість дозволяє користувачеві без прав доступу до Kubernetes отримати доступ адміністратора кластера. Атака не вимагає наявного доступу до кластера – вона його надає», – пояснив дослідник.
Після відмови Microsoft О’Лірі звернувся до CERT/CC. Там незалежно підтвердили проблему та присвоїли їй ідентифікатор VU#284781. Спочатку публічне розкриття планували на 1 червня 2026 року, але цього так і не сталося.
За словами дослідника, 4 травня Microsoft звернулася до MITRE із проханням не видавати CVE для цієї проблеми. Компанія знову наполягала, що атака потребує попереднього адміністративного доступу.
Зрештою CERT/CC закрив справу через правила ієрархії CNA, оскільки Microsoft має право самостійно вирішувати питання видачі CVE для власних продуктів.
Проблема стосувалася Azure Backup for AKS і механізму Trusted Access, який використовується для резервного копіювання Kubernetes-кластерів.
Служба резервного копіювання Azure для AKS використовує довірений доступ для надання прав адміністратора кластера розширенням резервного копіювання в кластерах Kubernetes.
За словами О’Лірі, цей недолік дозволяв будь-кому, хто мав лише роль «Співавтор резервного копіювання» в резервному сховищі, активувати цей зв’язок «Довірений доступ», не маючи попередньо дозволів Kubernetes.
Зловмисник може ввімкнути резервне копіювання на цільовому кластері AKS, що призведе до автоматичного налаштування Azure довіреного доступу з правами адміністратора кластера. Звідти зловмисник може витягувати секрети за допомогою операцій резервного копіювання або відновлювати шкідливі робочі навантаження в кластері.
О’Лірі класифікував проблему як вразливість Confused Deputy (CWE-441), де межі довіри Azure RBAC та Kubernetes RBAC взаємодіяли таким чином, що обходили очікувані засоби контролю авторизації.
Речник Microsoft повідомив:
«Наша оцінка дійшла висновку, що це не вразливість безпеки, а радше очікувана поведінка, яка вимагає вже існуючих адміністративних прав у середовищі клієнта. Тому жодних змін у продукті для вирішення цієї проблеми не було внесено, і жодних оцінок CVE чи CVSS не було надано». Однак, після оприлюднення свого звіту цього місяця, О’Лірі зазначив, що початковий шлях атаки більше не працює.
«Поточна поведінка повертає помилки, яких не існувало у березні 2026 року», – заявляє він:
ПОМИЛКА: UserErrorTrustedAccessGatewayReturnedForbidden
“Прив’язка ролі довіреного доступу відсутня/її було видалено”
За словами О’Лірі, тепер перед увімкненням резервного копіювання Azure Backup for AKS потрібно вручну налаштувати надійний доступ, що змінило попередню поведінку, коли Azure налаштовував його автоматично.
