mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-14 13:56:30 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -4,9 +4,9 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
У Kubernetes спостерігається, що за замовчуванням дозволяється встановлення з'єднань між **усіма контейнерами, що знаходяться на одному вузлі**. Це стосується незалежно від відмінностей у просторах імен. Таке з'єднання поширюється до **Layer 2** (Ethernet). Внаслідок цього, така конфігурація потенційно піддає систему вразливостям. Зокрема, це відкриває можливість для **зловмисного контейнера** виконати **ARP-спуфінг-атаку** проти інших контейнерів, розташованих на тому ж вузлі. Під час такої атаки зловмисний контейнер може обманом перехоплювати або змінювати мережевий трафік, призначений для інших контейнерів.
|
||||
У Kubernetes спостерігається, що за замовчуванням дозволяється встановлення з'єднань між **усіма контейнерами, що знаходяться на одному вузлі**. Це стосується незалежно від відмінностей у просторах імен. Таке з'єднання поширюється до **Рівня 2** (Ethernet). Внаслідок цього така конфігурація потенційно піддає систему вразливостям. Зокрема, це відкриває можливість для **зловмисного контейнера** виконати **атаку ARP-спуфінгу** проти інших контейнерів, розташованих на тому ж вузлі. Під час такої атаки зловмисний контейнер може обманом перехоплювати або змінювати мережевий трафік, призначений для інших контейнерів.
|
||||
|
||||
ARP-спуфінг-атаки включають **зловмисника, який надсилає підроблені ARP** (протокол вирішення адрес) повідомлення через локальну мережу. Це призводить до зв'язування **MAC-адреси зловмисника з IP-адресою легітимного комп'ютера або сервера в мережі**. Після успішного виконання такої атаки зловмисник може перехоплювати, змінювати або навіть зупиняти дані в процесі передачі. Атака виконується на Layer 2 моделі OSI, саме тому стандартне з'єднання в Kubernetes на цьому рівні викликає занепокоєння з приводу безпеки.
|
||||
Атаки ARP-спуфінгу передбачають, що **зловмисник надсилає підроблені ARP** (протокол розв'язання адрес) повідомлення через локальну мережу. Це призводить до зв'язування **MAC-адреси зловмисника з IP-адресою легітимного комп'ютера або сервера в мережі**. Після успішного виконання такої атаки зловмисник може перехоплювати, змінювати або навіть зупиняти дані в процесі передачі. Атака виконується на Рівні 2 моделі OSI, саме тому стандартне з'єднання в Kubernetes на цьому рівні викликає занепокоєння з приводу безпеки.
|
||||
|
||||
У сценарії буде створено 4 машини:
|
||||
|
||||
@@ -102,12 +102,12 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
|
||||
|
||||
### ARP
|
||||
|
||||
Загалом, **мережеве з'єднання pod-to-pod всередині вузла** доступне через **міст**, який з'єднує всі поди. Цей міст називається “**cbr0**”. (Деякі мережеві плагіни встановлять свій власний міст.) **cbr0 також може обробляти ARP** (протокол розв'язання адрес). Коли вхідний пакет надходить до cbr0, він може розв'язати MAC-адресу призначення за допомогою ARP.
|
||||
Говорячи загалом, **мережеве з'єднання pod-to-pod всередині вузла** доступне через **міст**, який з'єднує всі поди. Цей міст називається “**cbr0**”. (Деякі мережеві плагіни встановлять свій власний міст.) **cbr0 також може обробляти ARP** (протокол розв'язання адрес) розв'язання. Коли вхідний пакет надходить до cbr0, він може розв'язати MAC-адресу призначення за допомогою ARP.
|
||||
|
||||
Цей факт означає, що за замовчуванням **кожен под, що працює в одному вузлі**, зможе **спілкуватися** з будь-яким іншим подом в тому ж вузлі (незалежно від простору імен) на рівні ethernet (рівень 2).
|
||||
|
||||
> [!WARNING]
|
||||
> Тому можливі A**RP Spoofing атаки між подами в одному вузлі.**
|
||||
> Отже, можливо виконати A**RP Spoofing атаки між подами в одному вузлі.**
|
||||
|
||||
### DNS
|
||||
|
||||
@@ -145,16 +145,16 @@ nameserver 10.96.0.10
|
||||
```
|
||||
Однак, под **не знає**, як дістатися до цієї **адреси**, оскільки **діапазон подів** у цьому випадку становить 172.17.0.10/26.
|
||||
|
||||
Тому под надішле **DNS запити на адресу 10.96.0.10**, яка буде **перекладена** cbr0 **на** **172.17.0.2**.
|
||||
Отже, под надішле **DNS запити на адресу 10.96.0.10**, яка буде **перекладена** cbr0 **на** **172.17.0.2**.
|
||||
|
||||
> [!WARNING]
|
||||
> Це означає, що **DNS запит** пода **завжди** буде йти до **мосту** для **перекладу** **IP-адреси сервісу на IP-адресу кінцевої точки**, навіть якщо DNS сервер знаходиться в тій же підмережі, що й под.
|
||||
> Це означає, що **DNS запит** пода **завжди** буде йти до **мосту** для **перекладу** **IP служби на IP кінцевої точки**, навіть якщо DNS сервер знаходиться в тій же підмережі, що й под.
|
||||
>
|
||||
> Знаючи це, і знаючи, що **ARP атаки можливі**, **под** у вузлі зможе **перехопити трафік** між **кожним подом** у **підмережі** та **мостом** і **модифікувати** **DNS відповіді** від DNS сервера (**DNS Спуфінг**).
|
||||
>
|
||||
> Більше того, якщо **DNS сервер** знаходиться в **тому ж вузлі, що й атакуючий**, атакуючий може **перехопити всі DNS запити** будь-якого пода в кластері (між DNS сервером і мостом) і модифікувати відповіді.
|
||||
|
||||
## ARP Спуфінг у подах в тому ж вузлі
|
||||
## ARP Спуфінг у подах в одному вузлі
|
||||
|
||||
Наша мета - **викрасти принаймні комунікацію від ubuntu-victim до mysql**.
|
||||
|
||||
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
|
||||
```
|
||||
## DNS Spoofing
|
||||
|
||||
Як вже згадувалося, якщо ви **зламали под у тому ж вузлі, що й под DNS-сервера**, ви можете **MitM** з **ARPSpoofing** **містком** і **подом DNS** та **модифікувати всі DNS-відповіді**.
|
||||
Як вже згадувалося, якщо ви **зламали под на тому ж вузлі, що й под DNS-сервера**, ви можете **MitM** з **ARPSpoofing** **мостом** і **подом DNS** та **модифікувати всі DNS-відповіді**.
|
||||
|
||||
У вас є дійсно гарний **інструмент** і **посібник** для тестування цього в [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
|
||||
|
||||
У нашому сценарії, **завантажте** **інструмент** у поді атакуючого та створіть **файл з назвою `hosts`** з **доменами**, які ви хочете **спуфити**, наприклад:
|
||||
У нашому сценарії, **завантажте** **інструмент** в поді атакуючого та створіть **файл з назвою `hosts`** з **доменами**, які ви хочете **спуфити**, наприклад:
|
||||
```
|
||||
cat hosts
|
||||
google.com. 1.1.1.1
|
||||
@@ -260,13 +260,13 @@ dig google.com
|
||||
google.com. 1 IN A 1.1.1.1
|
||||
```
|
||||
> [!NOTE]
|
||||
> Якщо ви спробуєте створити свій власний скрипт для DNS спуфінгу, якщо ви **просто змініть DNS-відповідь**, це **не** буде **працювати**, тому що **відповідь** буде мати **src IP** адресу **зловмисного** **под** і **не буде** **прийнята**.\
|
||||
> Вам потрібно згенерувати **новий DNS-пакет** з **src IP** DNS, куди жертва надсилає DNS-запит (це щось на зразок 172.16.0.2, а не 10.96.0.10, це IP-адреса K8s DNS-сервісу, а не IP-адреса DNS-сервера, більше про це в вступі).
|
||||
> Якщо ви спробуєте створити свій власний скрипт для спуфінгу DNS, якщо ви **просто змініть DNS-відповідь**, це **не** буде **працювати**, тому що **відповідь** буде мати **src IP** адресу **зловмисного** **под** і **не буде** **прийнята**.\
|
||||
> Вам потрібно згенерувати **новий DNS-пакет** з **src IP** DNS, куди жертва надсилає DNS-запит (це щось на зразок 172.16.0.2, а не 10.96.0.10, це IP-адреса служби K8s DNS, а не IP-адреса DNS-сервера, більше про це в вступі).
|
||||
|
||||
## Capturing Traffic
|
||||
|
||||
Інструмент [**Mizu**](https://github.com/up9inc/mizu) є простим, але потужним API **переглядачем трафіку для Kubernetes**, що дозволяє вам **переглядати всю API-комунікацію** між мікросервісами, щоб допомогти вам у налагодженні та усуненні регресій.\
|
||||
Він встановить агенти в обраних подах і збиратиме їх інформацію про трафік, а потім покаже вам це на веб-сервері. Однак для цього вам знадобляться високі дозволи K8s (і це не дуже непомітно).
|
||||
Він встановить агенти в обраних подах і збиратиме їх інформацію про трафік, показуючи вам це на веб-сервері. Однак для цього вам знадобляться високі дозволи K8s (і це не дуже непомітно).
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Reference in New Issue
Block a user