Kubernetes Network Attacks
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
У Kubernetes спостерігається, що за замовчуванням дозволяється встановлення з'єднань між всіма контейнерами, що знаходяться на одному вузлі. Це стосується незалежно від відмінностей у просторах імен. Таке з'єднання поширюється до Layer 2 (Ethernet). Внаслідок цього така конфігурація потенційно піддає систему вразливостям. Зокрема, це відкриває можливість для зловмисного контейнера виконати ARP-спуфінг-атаку проти інших контейнерів, розташованих на тому ж вузлі. Під час такої атаки зловмисний контейнер може обманом перехоплювати або змінювати мережевий трафік, призначений для інших контейнерів.
ARP-спуфінг-атаки передбачають, що зловмисник надсилає підроблені ARP (протокол розв'язання адрес) повідомлення через локальну мережу. Це призводить до зв'язування MAC-адреси зловмисника з IP-адресою легітимного комп'ютера або сервера в мережі. Після успішного виконання такої атаки зловмисник може перехоплювати, змінювати або навіть зупиняти дані в процесі передачі. Атака виконується на Layer 2 моделі OSI, саме тому стандартне з'єднання в Kubernetes на цьому рівні викликає занепокоєння з приводу безпеки.
У сценарії буде створено 4 машини:
ubuntu-pe: Привілейована машина для втечі до вузла та перевірки метрик (необхідна для атаки)
ubuntu-attack: Зловмисний контейнер у стандартному просторі імен
ubuntu-victim: Жертва машина в просторі імен kube-system
mysql: Жертва машина в стандартному просторі імен
Якщо ви хочете більше деталей про мережеві теми, представлені тут, зверніться до посилань.
Говорячи загалом, мережеве з'єднання pod-to-pod всередині вузла доступне через міст, який з'єднує всі поди. Цей міст називається “cbr0”. (Деякі мережеві плагіни встановлять свій власний міст.) cbr0 також може обробляти ARP (Протокол розв'язання адрес) розв'язання. Коли вхідний пакет надходить до cbr0, він може розв'язати MAC-адресу призначення за допомогою ARP.
Цей факт означає, що за замовчуванням кожен под, що працює в одному й тому ж вузлі, зможе спілкуватися з будь-яким іншим подом в тому ж вузлі (незалежно від простору імен) на рівні ethernet (рівень 2).
Отже, можливо виконати ARP Spoofing атаки між подами в одному й тому ж вузлі.
У середовищах kubernetes ви зазвичай знайдете 1 (або більше) DNS-сервісів, що працюють зазвичай у просторі імен kube-system:
У попередній інформації ви можете побачити щось цікаве, IP сервісу - 10.96.0.10, але IP поду, що виконує сервіс, - 172.17.0.2.
Якщо ви перевірите DNS-адресу всередині будь-якого поду, ви знайдете щось подібне:
Однак, под не знає, як дістатися до цієї адреси, оскільки діапазон подів у цьому випадку становить 172.17.0.10/26.
Тому под надішле DNS запити на адресу 10.96.0.10, яка буде перекладена cbr0 на 172.17.0.2.
Це означає, що DNS запит пода завжди буде йти до мосту, щоб перекласти IP-адресу сервісу на IP-адресу кінцевої точки, навіть якщо DNS-сервер знаходиться в тій же підмережі, що й под.
Знаючи це, і знаючи, що ARP атаки можливі, под у вузлі зможе перехопити трафік між кожним подом у підмережі та мостом і модифікувати DNS відповіді від DNS-сервера (DNS Спуфінг).
Більше того, якщо DNS сервер знаходиться в тому ж вузлі, що й атакуючий, атакуючий може перехопити всі DNS запити будь-якого пода в кластері (між DNS-сервером і мостом) і модифікувати відповіді.
Наша мета - викрасти принаймні комунікацію від ubuntu-victim до mysql.
Як вже згадувалося, якщо ви зламали под у тому ж вузлі, що й под DNS-сервера, ви можете MitM з ARPSpoofing мостом і подом DNS та модифікувати всі DNS-відповіді.
У вас є дійсно гарний інструмент і посібник для тестування цього в https://github.com/danielsagi/kube-dnsspoof/
У нашому сценарії, завантажте інструмент у поді атакуючого та створіть файл з назвою hosts
з доменами, які ви хочете спуфити, наприклад:
Виконайте атаку на машину ubuntu-victim:
Якщо ви спробуєте створити свій власний скрипт для спуфінгу DNS, якщо ви просто змініть відповідь DNS, це не буде працювати, тому що відповідь буде мати src IP адресу зловмисного под і не буде прийнята. Вам потрібно згенерувати новий DNS пакет з src IP DNS, куди жертва надсилає DNS запит (це щось на зразок 172.16.0.2, а не 10.96.0.10, це IP адреса служби K8s DNS, а не IP адреса DNS сервера, більше про це в вступі).
Інструмент Mizu є простим, але потужним API переглядачем трафіку для Kubernetes, що дозволяє вам переглядати всю API комунікацію між мікросервісами, щоб допомогти вам у налагодженні та усуненні регресій. Він встановить агенти в обрані поди та збиратиме їх інформацію про трафік і покаже вам це на веб-сервері. Однак для цього вам знадобляться високі дозволи K8s (і це не дуже непомітно).
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)