Amikor nem csak a Kubernetes sebezhetőségeirő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:
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.):
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:
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.