Abusing Roles/ClusterRoles in Kubernetes
Hier kan jy potensieel gevaarlike Rolle en ClusterRoles-konfigurasies vind.
Onthou dat jy al die ondersteunde hulpbronne kan kry met kubectl api-resources
Bevoorregte Eskalasie
Verwysend na die kunsvorm om toegang tot 'n ander beginsel binne die cluster te kry met verskillende voorregte (binne die kubernetes cluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies 4 hoof tegnieke om voorregte te eskaleer:
In staat wees om ander gebruikers/groepe/SAs met beter voorregte binne die kubernetes cluster of na eksterne wolke te impersoneer
In staat wees om pods te skep/patch/exec waar jy SAs kan vind of koppel met beter voorregte binne die kubernetes cluster of na eksterne wolke
In staat wees om geheime sleutels te lees aangesien die SAs se tokens as geheime sleutels gestoor word
In staat wees om te ontsnap na die node vanuit 'n houer, waar jy al die geheime sleutels van die houers wat op die node loop, die geloofsbriewe van die node, en die toestemmings van die node binne die wolk waarin dit loop (indien enige) kan steel
'n Vyfde tegniek wat 'n vermelding verdien, is die vermoë om port-forward in 'n houer uit te voer, aangesien jy dalk toegang kan kry tot interessante hulpbronne binne daardie houer.
Toegang tot Enige Hulpbron of Werkwoord (Wildcard)
Die wildcard (*) gee toestemming oor enige hulpbron met enige werkwoord. Dit word deur administrateurs gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enige naamruimte in die cluster kan misbruik.
Toegang tot enige hulpbron met 'n spesifieke werkwoord
In RBAC stel sekere toestemmings aansienlike risiko's:
create
: Gee die vermoë om enige klasteroptie te skep, wat die risiko van voorreg-escalasie inhou.list
: Maak dit moontlik om alle hulpbronne te lys, moontlik om sensitiewe data uit te lek.get
: Maak dit moontlik om geheime van diensrekeninge te benader, wat 'n veiligheidsrisiko inhou.
Pod Skep - Steel Token
'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod koppel en die token steel om die Diensrekening te impersoneer. Dit verhoog effektief die voorregte daaraan.
Voorbeeld van 'n pod wat die token van die bootstrap-signer
diensrekening sal steel en dit na die aanvaller sal stuur:
Pod Skep & Ontsnapping
Die volgende dui al die voorregte aan wat 'n houer kan hê:
Bevoorregte toegang (deaktivering van beskerming en instelling van vermoëns)
Deaktiveer namespaces hostIPC en hostPid wat kan help om voorregte te eskaleer
Deaktiveer hostNetwork namespace, wat toegang gee om wolkvoorregte te steel en beter toegang tot netwerke te verkry
Monteer gasheer se / binne die houer
Skep die pod met:
Een-liner van hierdie tweet en met 'n paar toevoegings:
Nou dat jy kan ontsnap na die node, kyk na post-exploitation tegnieke in:
Steels
Jy wil waarskynlik steels wees, op die volgende bladsye kan jy sien wat jy sou kon toegang as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon aktiveer:
Bevoorreg + hostPID
Slegs bevoorreg
hostPath
hostPID
hostNetwork
hostIPC
Jy kan voorbeelde vind van hoe om die vorige bevoorregte pod-konfigurasies te skep/misbruik in https://github.com/BishopFox/badPods
Pod Skep - Beweeg na die wolk
As jy 'n pod kan skep (en opsioneel 'n diensrekening) kan jy moontlik voorregte in 'n wolkomgewing verkry deur wolkrolle aan 'n pod of 'n diensrekening toe te ken en dit dan te benader. Verder, as jy 'n pod met die gasheer se netwerknaamspasie kan skep, kan jy die IAM-rol van die node-instansie steel.
Vir meer inligting, kyk na:
Pod Escape PrivilegesSkep/Patch Implementering, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Take en Cronjobs
Dit is moontlik om hierdie toestemmings te misbruik om 'n nuwe pod te skep en voorregte soos in die vorige voorbeeld te steel.
Die volgende yaml skep 'n daemonset en eksfiltreer die token van die SA binne die pod:
Pods Uitvoer
pods/exec
is 'n hulpbron in kubernetes wat gebruik word vir die uitvoer van bevele in 'n skaal binne 'n houer. Dit maak dit moontlik om bevele binne die houers uit te voer of 'n skaal binne te gaan.
Daarom is dit moontlik om binne 'n houer te kom en die token van die SA te steel, of om 'n bevoorregte houer binne te gaan, na die node te ontsnap, en al die tokens van die houers in die node te steel en die node te (mis)bruik:
port-forward
Hierdie toestemming maak dit moontlik om een plaaslike poort na een poort in die gespesifiseerde peul te stuur. Dit is bedoel om dit maklik te maak om programme wat binne 'n peul hardloop te ontleed, maar 'n aanvaller kan dit misbruik om toegang te kry tot interessante (soos DB's) of kwesbare programme (web?) binne 'n peul:
Gasheerders Skryfbaar /var/log/ Ontsnapping
Soos aangedui in hierdie navorsing, as jy toegang kan kry of 'n houer kan skep met die gasheerders /var/log/
gids daaraan geheg, kan jy ontsnap uit die houer.
Dit is basies omdat wanneer die Kube-API probeer om die logboeke van 'n houer te kry (deur kubectl logs <pod>
te gebruik), dit die 0.log
lêer van die houer aanvra as deel van die /logs/
eindpunt van die Kubelet diens.
Die Kubelet-diens stel die /logs/
eindpunt bloot wat basies net die /var/log
lêersisteem van die houer blootstel.
Dus kan 'n aanvaller met toegang om in die /var/log/ gids te skryf van die houer hierdie gedrag op 2 maniere misbruik:
Wysig die
0.log
lêer van sy houer (gewoonlik geleë in/var/logs/pods/namespace_pod_uid/container/0.log
) om 'n symboliese skakel te wees wat na/etc/shadow
wys byvoorbeeld. Dan sal jy in staat wees om gasheerders shadow-lêer te eksfiltreer deur:
Indien die aanvaller enige hoof met die regte om
nodes/log
te lees beheer, kan hy net 'n symboliese skakel in/host-mounted/var/log/sym
na/
skep en wanneer hy toegang tothttps://<gateway>:10250/logs/sym/
kry, sal hy die wortel-lêerstelsel van die gasheer lys (die skakel verander kan toegang tot lêers bied).
'n Laboratorium en geoutomatiseerde uitbuiting kan gevind word in https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts
Deurlopende readOnly beskerming omseil
As jy gelukkig genoeg is en die hoogs bevoorregte vermoë CAP_SYS_ADMIN
beskikbaar is, kan jy net die vouer weer monteer as rw:
Oor die omseil van hostPath readOnly beskerming
Soos aangedui in hierdie navorsing is dit moontlik om die beskerming te omseil:
Wat bedoel was om ontsnappings soos die voriges te voorkom deur in plaas daarvan 'n hostPath-montasie te gebruik, gebruik 'n PersistentVolume en 'n PersistentVolumeClaim om 'n gasheer se vouer in die houer te monteer met skryftoegang:
Impersonating bevoorregte rekeninge
Met 'n gebruiker simulasie voorreg, kan 'n aanvaller 'n bevoorregte rekening simuleer.
Gebruik eenvoudig die parameter --as=<gebruikersnaam>
in die kubectl
bevel om 'n gebruiker te simuleer, of --as-group=<groep>
om 'n groep te simuleer:
Of gebruik die REST API:
Lys van Geheime
Die toestemming om geheime te lys kan 'n aanvaller toelaat om werklik die geheime te lees deur die REST API eindpunt te benader:
Lees 'n geheim - bruto-kragtiging van token-ID's
Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, in teenstelling met die wyer lys van geheime voorreg, is daar steeds kwesbaarhede. Standaarddiensrekeninge in die stelsel kan opgesom word, elkeen geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n lukrake vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die bronkode.
Die token word gegenereer uit 'n beperkte 27-karakterset (bcdfghjklmnpqrstvwxz2456789
), eerder as die volledige alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan 'n aanvaller moontlik 'n bruto-kragtige aanval uitvoer om die token in 'n paar uur af te lei, wat moontlik kan lei tot voorreg-escalasie deur toegang tot sensitiewe diensrekeninge.
Sertifikaatondertekeningsversoeke
As jy die werkwoorde skep
in die hulpbron certificatesigningrequests
het (of ten minste in certificatesigningrequests/nodeClient
). Jy kan 'n nuwe CeSR van 'n nuwe node skep.
Volgens die dokumentasie is dit moontlik om hierdie versoeke outomaties goed te keur, so in daardie geval het jy nie ekstra toestemmings nodig nie. Indien nie, sou jy die versoek moet goedkeur, wat 'n opdatering in certificatesigningrequests/approval
en approve
in signers
met resourceName <signerNameDomain>/<signerNamePath>
of <signerNameDomain>/*
beteken.
'n Voorbeeld van 'n rol met al die benodigde toestemmings is:
So, met die nuwe node CSR goedgekeur, kan jy die spesiale regte van nodes misbruik om geheime te steel en priviliges te eskaleer.
In hierdie pos en hierdie een is die GKE K8s TLS Bootstrap-konfigurasie ingestel met outomatiese ondertekening en dit word misbruik om geloofsbriewe van 'n nuwe K8s Node te genereer en dit dan te misbruik om priviliges te eskaleer deur geheime te steel. As jy die genoemde regte het, kan jy dieselfde ding doen. Let daarop dat die eerste voorbeeld die fout omseil wat voorkom dat 'n nuwe node toegang tot geheime binne houers het omdat 'n node slegs die geheime van houers wat daarop gemonteer is, kan benader.
Die manier om dit te omseil is om net 'n node-geloofsbriewe vir die nodenaam waar die houer met die interessante geheime gemonteer is, te skep (maar kyk net hoe om dit in die eerste pos te doen):
AWS EKS aws-auth configmaps
Prinsipale wat configmaps
in die kube-stelsel namespace op EKS kan wysig (moet in AWS wees) clusters kan klastervervalbevoegdhede verkry deur die aws-auth configmap te oorskryf. Die werkwoorde wat nodig is, is update
en patch
, of create
as die configmap nie geskep was nie:
Jy kan aws-auth
gebruik vir volharding om toegang te gee aan gebruikers van ander rekeninge.
Maar, aws --profile other_account eks update-kubeconfig --name <cluster-name>
werk nie vanaf 'n ander rekening nie. Maar eintlik werk aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing
as jy die ARN van die cluster plaas in plaas van net die naam.
Om kubectl
te laat werk, maak seker om die slagoffers kubeconfig te konfigureer en in die aws exec-args voeg --profile other_account_role
by sodat kubectl die ander rekeningprofiel gebruik om die token te kry en kontak te maak met AWS.
Eskalering in GKE
Daar is 2 maniere om K8s-toestemmings aan GCP-prinsipale toe te ken. In enige geval moet die prinsipaal ook die toestemming container.clusters.get
hê om geloofsbriewe te kan versamel om toegang tot die cluster te verkry, of jy sal jou eie kubectl-konfigurasie lêer moet genereer (volg die volgende skakel).
Wanneer daar met die K8s-api-eindpunt gepraat word, sal die GCP-geloofsbriewe gestuur word. Dan sal GCP, deur die K8s-api-eindpunt, eers nagaan of die prinsipaal (per e-pos) enige toegang binne die cluster het, dan sal dit nagaan of dit enige toegang via GCP IAM het. Indien enige van daardie waar is, sal daar gereageer word. Indien nie 'n fout wat voorstel om toestemmings via GCP IAM te gee sal gegee word.
Dan is die eerste metode om GCP IAM te gebruik, die K8s-toestemmings het hul ekwivalente GCP IAM-toestemmings, en as die prinsipaal dit het, sal hy dit kan gebruik.
GCP - Container PrivescDie tweede metode is om K8s-toestemmings binne die cluster toe te ken aan die identifisering van die gebruiker deur sy e-pos (GCP-diensrekeninge ingesluit).
Skep diensrekeninge-token
Prinsipale wat TokenRequests kan skep (serviceaccounts/token
) Wanneer daar met die K8s-api-eindpunt gepraat word, kan SAs (inligting van hier).
ephemeralcontainers
Prinsipale wat update
of patch
pods/ephemeralcontainers
kan uitvoer, kan kodes uitvoer op ander pods, en moontlik ontsnap na hul node deur 'n ephemeral-container met 'n bevoorregte securityContext by te voeg.
ValidatingWebhookConfigurations of MutatingWebhookConfigurations
Prinsipale met enige van die werkwoorde create
, update
of patch
oor validatingwebhookconfigurations
of mutatingwebhookconfigurations
kan dalk in staat wees om een van sulke webhookconfigurations te skep om sodoende toestemmings te eskaleer.
Vir 'n voorbeeld van mutatingwebhookconfigurations
sien hierdie afdeling van hierdie pos.
Eskaleer
Soos wat jy kan lees in die volgende afdeling: Ingeboude Voorregte-Eskalasie Voorkoming, kan 'n prinsipaal nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die werkwoord escalate
oor rolle
of clusterroles
het.
Dan kan hy nuwe rolle skep/opdateer met beter toestemmings as die een wat hy het.
Nodes proxy
Prinsipale met toegang tot die nodes/proxy
subbron kan kodes uitvoer op pods via die Kubelet API (volgens hierdie). Meer inligting oor Kubelet-verifikasie op hierdie bladsy:
Jy het 'n voorbeeld van hoe om RCE te kry deur geautoriseerd te praat met 'n Kubelet API hier.
Verwyder pods + onskeduleerbare nodes
Prinsipale wat pods kan verwyder (delete
werkwoord oor pods
bron), of pods kan verdryf (create
werkwoord oor pods/eviction
bron), of pod-status kan verander (toegang tot pods/status
) en ander nodes onskeduleerbaar kan maak (toegang tot nodes/status
) of nodes kan verwyder (delete
werkwoord oor nodes
bron) en beheer het oor 'n pod, kan pods van ander nodes steel sodat hulle in die gekompromitteerde node uitgevoer word en die aanvaller kan die tokens steel van daardie pods.
Diensstatus (CVE-2020-8554)
Prinsipale wat dienste/status
kan verander, kan die veld status.loadBalancer.ingress.ip
instel om die ongepatchte CVE-2020-8554 uit te buit en MiTM-aanvalle teen die klaster te lanceer. Die meeste mitigasies vir CVE-2020-8554 voorkom slegs ExternalIP-dienste (volgens hierdie).
Nodes en Pods status
Prinsipale met update
of patch
toestemmings oor nodes/status
of pods/status
, kan etikette verander om skeduleringsbeperkings te beïnvloed.
Ingeboude Voorregverhogingsvoorkoming
Kubernetes het 'n ingeboude meganisme om voorregverhoging te voorkom.
Hierdie stelsel verseker dat gebruikers nie hul voorregte kan verhoog deur rolle of rolbindings te verander nie. Die afdwinging van hierdie reël vind plaas op API-vlak, wat 'n beskerming bied selfs wanneer die RBAC-autoriseerder onaktief is.
Die reël bepaal dat 'n gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings besit wat die rol behels. Verder moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of verander: óf klasbreed vir ClusterRoles of beperk tot dieselfde naamspasie (of klasbreed) vir Roles.
Daar is 'n uitsondering op die vorige reël. As 'n hoof het die werkwoord escalate
oor roles
of clusterroles
, kan hy die voorregte van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê.
Kry & Verander RoleBindings/ClusterRoleBindings
Dit lyk asof hierdie tegniek vantevore gewerk het, maar volgens my toetse werk dit nie meer om dieselfde rede wat in die vorige afdeling verduidelik is nie. Jy kan nie 'n rolbinding skep/verander om jouself of 'n ander SA sekere voorregte te gee as jy dit nie reeds het nie.
Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om rolle aan 'n diensrekening te bind. Hierdie voorreg kan moontlik lei tot voorregverhoging omdat dit die gebruiker toelaat om admin-voorregte aan 'n gekompromitteerde diensrekening te bind.
Ander Aanvalle
Sidecar proxy-toep
Standaard is daar geen enkele versleuteling in die kommunikasie tussen pods nie. Wederkerige outentifikasie, tweerigting, pod tot pod.
Skep 'n sidecar proxy-toep
Skep jou .yaml
Wysig jou .yaml en voeg die uitkommentarieerde lyne by:
Sien die logboeke van die skakel:
More inligting by: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Skadelike Toelatingsbeheerder
'n Toelatingsbeheerder onderskep versoek aan die Kubernetes API-bediener voordat die objek volhard word, maar nadat die versoek geïdentifiseer en gemagtig is.
As 'n aanvaller op een of ander manier daarin slaag om 'n Mutatie Toelatingsbeheerder in te spuit, sal hy in staat wees om reeds geïdentifiseerde versoek te wysig. Dit kan potensieel privesc moontlik maak, en meer gewoonlik volhard in die groep.
Voorbeeld van https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Kyk na die status om te sien of dit gereed is:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1628433436353%2FyHUvUWugR.png%3Fauto%3Dcompress%2Cformat%26format%3Dwebp&width=768&dpr=4&quality=100&sign=fe4bc7c0&sv=1)
Bespreek dan 'n nuwe houer:
Wanneer jy die ErrImagePull
-fout sien, kontroleer die beeldnaam met enige van die navrae:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1628433512073%2FleFXtgSzm.png%3Fauto%3Dcompress%2Cformat%26format%3Dwebp&width=768&dpr=4&quality=100&sign=45a94e54&sv=1)
Soos u kan sien in die boafbelding, het ons probeer om die beeld nginx
uit te voer, maar die finale uitgevoerde beeld is rewanthtammana/malicious-image
. Wat het nou gebeur!!?
Tegniese Besonderhede
Die ./deploy.sh
skrips stel 'n muterende webhook-toelatingsbeheerder op, wat versoek aan die Kubernetes API wysig soos gespesifiseer in sy konfigurasie reëls, wat die waargenome uitkomste beïnvloed:
Beste Praktyke
Deaktivering van Outomatiese Montasie van Diensrekeningtokens
Pods en Diensrekeninge: Standaard monteer pods 'n diensrekeningtoken. Om sekuriteit te verbeter, maak Kubernetes dit moontlik om hierdie outomatiese montasie-eienskap te deaktiveer.
Hoe om toe te pas: Stel
automountServiceAccountToken: false
in die konfigurasie van diensrekeninge of pods vanaf Kubernetes weergawe 1.6.
Beperkende Gebruikerstoewysing in RoleBindings/ClusterRoleBindings
Selektiewe Insluiting: Verseker dat slegs nodige gebruikers ingesluit word in RoleBindings of ClusterRoleBindings. Auditeer gereeld en verwyder onvanpaslike gebruikers om streng sekuriteit te handhaaf.
Namespace-Spesifieke Roles Oor Cluster-wye Roles
Roles vs. ClusterRoles: Gee voorkeur aan die gebruik van Roles en RoleBindings vir namespace-spesifieke regte eerder as ClusterRoles en ClusterRoleBindings, wat op die hele cluster van toepassing is. Hierdie benadering bied fynere beheer en beperk die omvang van regte.
Gebruik outomatiese gereedskap
Verwysings
Last updated