Kubernetes Network Attacks
Вступ
У Kubernetes спостерігається, що типова поведінка дозволяє встановлювати зв'язки між усіма контейнерами, що розташовані на одному вузлі. Це стосується незалежно від розділень просторів імен. Таке з'єднання поширюється на рівень 2 (Ethernet). Внаслідок цього конфігурація потенційно викладає систему на вразливість. Зокрема, це відкриває можливість для зловмисного контейнера виконати атаку підроблення ARP проти інших контейнерів, що розташовані на тому ж вузлі. Під час такої атаки зловмисний контейнер може обманом перехоплювати або змінювати мережевий трафік, призначений для інших контейнерів.
Атаки підроблення ARP включають відправку підроблених повідомлень ARP (протокол розв'язання адрес) по локальній мережі. Це призводить до зв'язування MAC-адреси атакуючого з IP-адресою легітимного комп'ютера або сервера в мережі. Після успішного виконання такої атаки атакуючий може перехоплювати, змінювати або навіть зупиняти дані у процесі передачі. Атака виконується на рівні 2 моделі OSI, тому типове з'єднання в Kubernetes на цьому рівні викликає побоювання з точки зору безпеки.
У сценарії буде створено 4 машини:
ubuntu-pe: Привілейована машина для виходу на вузол та перевірки метрик (не потрібна для атаки)
ubuntu-attack: Зловмисний контейнер у просторі імен за замовчуванням
ubuntu-victim: Машина жертва у просторі імен kube-system
mysql: Машина жертва у просторі імен за замовчуванням
Основна мережева структура Kubernetes
Якщо ви хочете отримати більше деталей про введені тут теми з мережування, перейдіть до джерел.
ARP
Загалом кажучи, мережування вузлів до вузлів всередині вузла доступне через міст, який з'єднує всі вузли. Цей міст називається "cbr0". (Деякі мережеві додатки встановлюватимуть свій власний міст.) cbr0 також може обробляти ARP (протокол розв'язування адрес). Коли вхідний пакет надходить на cbr0, він може вирішити MAC-адресу призначення за допомогою ARP.
Цей факт означає, що, за замовчуванням, кожний під, що працює в одному вузлі, зможе спілкуватися з будь-яким іншим підом в тому ж вузлі (незалежно від простору імен) на рівні Ethernet (рівень 2).
Отже, можливо виконати атаки ARP Spoofing між підами в одному вузлі.
DNS
У середовищах Kubernetes ви зазвичай знайдете 1 (або більше) DNS-сервіси, що працюють зазвичай в просторі імен kube-system:
У попередній інформації ви можете побачити щось цікаве, IP-адреса сервісу - 10.96.0.10, але IP-адреса pod, на якому працює сервіс, - 172.17.0.2.
Якщо ви перевірите DNS-адресу всередині будь-якого pod, ви знайдете щось на кшталт цього:
Проте, підсистема не знає, як дістатися до цієї адреси, оскільки діапазон підсистеми в даному випадку - 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-сервером та мостом) та змінювати відповіді.
ARP-підробка в підсистемах на тому ж вузлі
Нашою метою є вкрасти принаймні комунікацію від ubuntu-victim до mysql.
Scapy
ARPSpoof
DNS Спуфінг
Як вже було зазначено, якщо ви зламаєте підприємство в тому ж вузлі, що і підприємство DNS-сервера, ви можете MitM з ARPSpoofing між мостом та підприємством DNS та змінити всі відповіді DNS.
У вас є дуже гарний інструмент та посібник для перевірки цього за посиланням https://github.com/danielsagi/kube-dnsspoof/
У нашому сценарії завантажте інструмент в підприємство зловмисника та створіть **файл з назвою hosts
** з доменами, які ви хочете спуфінгувати, наприклад:
Виконайте атаку на машину ubuntu-victim:
Якщо ви намагаєтеся створити свій власний скрипт підробки DNS, і просто змінюєте відповідь DNS, це не працюватиме, оскільки відповідь буде мати IP-адресу джерела - IP-адресу зловмисного поду, і вона не буде прийнята. Вам потрібно згенерувати новий пакет DNS з IP-адресою джерела DNS, куди жертва відправляє запит DNS (щось на кшталт 172.16.0.2, а не 10.96.0.10, це IP-адреса служби DNS K8s, а не IP-адреса сервера DNS, більше про це в інтродукції).
Захоплення трафіку
Інструмент Mizu - це простий, але потужний переглядач трафіку API для Kubernetes, який дозволяє вам переглядати всю комунікацію API між мікросервісами для допомоги у відлагодженні та усуненні несправностей. Він встановлює агенти в обраних подах, збирає їх інформацію про трафік та показує вам на веб-сервері. Однак для цього вам знадобляться високі дозволи K8s (і це не дуже приховано).
Посилання
Last updated