ISTIO-SECURITY-2026-002
Атака «людина посередині» через VirtualService.
| Подробиці розкриття інформації | |
|---|---|
| CVE(s) | |
| Індекс впливу CVSS | 5.9 AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L |
| Постраждалі випуски | All releases since the introduction of the mesh gateway option in the `VirtualService` resource |
Комітет з безпеки Istio хоче розглянути можливий сценарій атаки «людина посередині», у якому VirtualService може перенаправляти або перехоплювати трафік у межах сервісної мережі. Це впливає лише на середовища з багатокористувацькою орендою на основі просторів імен.
Ця атака дозволяє зловмиснику з дозволом VirtualService в одному просторі імен перенаправляти трафік від будь-якого podʼа в сервісній мережі Istio до сервісу, контрольованого зловмисником. Сценарій атаки зловживає можливістю встановлювати довільні імена хостів у полі spec.hosts.[] ресурсу VirtualService, коли встановлено шлюз mesh. Зловмисник може перехоплювати, перенаправляти та відкидати трафік, що передається між сервісами. Це впливає на трафік до інших сервісів у мережі та до зовнішніх сервісів. Однак зловмисник не може обійти політики авторизації або взаємну TLS-автентифікацію, налаштовану на сервісі призначення.
Зверніть увагу, що проблеми навіть виходять за межі кластера у розгортанні “єдина мережа з кількома кластерами”.
Супроводжувачі Istio вважають цю проблему очікуваною поведінкою в Istio. Кілька їхніх ресурсів, таких як VirtualService, DestinationRule та ServiceEntry, змінюють трафік до конкретного імені хосту по всій мережі, і навіть якщо ці ресурси обмежені простором імен, вони впливають на схеми трафіку мережі (у межах даного кластера). Це навмисний компроміс у використанні, щоб уникнути виснажливих адміністративних контролів для кожного імені хосту та простору імен. На відміну від новішого Kubernetes Gateway API, ці CRD були створені та фактично стабілізовані до того, як RBAC на основі просторів імен взагалі зʼявився в Kubernetes, і зміни порушили б існуючу функціональність.
Тому оператори, які запускають Istio в налаштуваннях багатокористувацької оренди на основі просторів імен або керують єдиною мережею в кількох кластерах, повинні застосувати додаткові запобіжні заходи для підтримки сильної ізоляції. Без цих контролів може відбуватися ненавмисна маніпуляція трафіком між просторами імен на рівні площини даних.
Рекомендоване помʼякшення полягає в міграції на новіший Gateway API в таких налаштуваннях. Коли такі зміни та обмеження неможливі в застарілих налаштуваннях, слід застосувати подальше посилення та обмеження, щоб зменшити вплив цих слабких місць.
Подальші деталі про проблему та помʼякшення можна знайти в публікації в блозі.
Комітет з безпеки Istio хотів би подякувати Sven Nobis та Lorin Lehawany з ERNW Enno Rey Netzwerke GmbH за розкриття цієї проблеми.