{"id":19881,"date":"2022-12-16T12:28:17","date_gmt":"2022-12-16T10:28:17","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=19881"},"modified":"2022-12-16T12:28:17","modified_gmt":"2022-12-16T10:28:17","slug":"log4shell-still-active-2022","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/log4shell-still-active-2022\/19881\/","title":{"rendered":"Log4Shell, un an plus tard"},"content":{"rendered":"<p>Il y a un an, en d\u00e9cembre 2021, la vuln\u00e9rabilit\u00e9 Log4Shell (CVE-2021-44228) de la biblioth\u00e8que Apache Log4j a fait beaucoup de bruit. M\u00eame si l\u2019incident ne faisait plus la une des m\u00e9dias informatiques au printemps, en novembre 2022 elle a fait son grand retour lorsqu\u2019il a \u00e9t\u00e9 dit que des <a href=\"https:\/\/www.cpomagazine.com\/cyber-security\/iranian-hackers-installed-crypto-miner-in-federal-agency-after-exploiting-unpatched-log4shell-vulnerability\/\" target=\"_blank\" rel=\"noopener nofollow\">cybercriminels avaient exploit\u00e9<\/a> cette vuln\u00e9rabilit\u00e9 pour attaquer une agence f\u00e9d\u00e9rale am\u00e9ricaine et pour installer un mineur de cryptomonnaie dans ses syst\u00e8mes. C\u2019est l\u2019occasion d\u2019expliquer ce qu\u2019est vraiment Log4Shell, pourquoi il est trop t\u00f4t pour consid\u00e9rer que c\u2019est termin\u00e9 et comment prot\u00e9ger votre infrastructure.<\/p>\n<h2><\/h2>\n<h2>Qu\u2019est-ce que la biblioth\u00e8que Apache Log4j ?<\/h2>\n<p>Comme Java SDK n\u2019\u00e9tait initialement pas compatible avec la journalisation, les d\u00e9veloppeurs ont d\u00fb cr\u00e9er leurs propres solutions, et lorsque l\u2019API officielle Java Logging est apparue, il y en avait d\u00e9j\u00e0 plusieurs sur le march\u00e9. Apache Log4j est l\u2019une d\u2019elles\u00a0: une c\u00e9l\u00e8bre biblioth\u00e8que Java open-source en d\u00e9veloppement depuis 2001. Ce n\u2019est pas la seule solution de journalisation Java, mais c\u2019est sans aucun doute une des plus utilis\u00e9es. Diverses solutions alternatives sont principalement des rejetons de Log4j qui sont apparus aux diff\u00e9rentes \u00e9tapes de d\u00e9veloppement de la biblioth\u00e8que.<\/p>\n<h2><\/h2>\n<h2>Qu\u2019est-ce que la vuln\u00e9rabilit\u00e9 Log4Shell ?<\/h2>\n<p>La biblioth\u00e8que Log4j permet de connecter automatiquement tous les \u00e9v\u00e9nements syst\u00e8me. Elle utilise un ensemble standard d\u2019interfaces pour acc\u00e9der aux donn\u00e9es de l\u2019API <em>Java Naming and Directory Interface<\/em> (JNDI). En novembre 2021, il s\u2019est av\u00e9r\u00e9 que pendant la journalisation, la biblioth\u00e8que pouvait ex\u00e9cuter les ordres de JNDI pass\u00e9s par un \u00e9v\u00e9nement, par exemple, dans l\u2019en-t\u00eate d\u2019une requ\u00eate, dans le message d\u2019un chat ou dans la description du message d\u2019erreur 404 d\u2019un site Internet.<\/p>\n<p>\u00a0<\/p>\n<p>La vuln\u00e9rabilit\u00e9 <a href=\"https:\/\/www.kaspersky.fr\/blog\/log4shell-critical-vulnerability-in-apache-log4j\/18255\/\" target=\"_blank\" rel=\"noopener\">permet<\/a> aux cybercriminels, du moins en th\u00e9orie, de faire tout ce qu\u2019ils veulent sur le syst\u00e8me de la victime (si aucune mesure de s\u00e9curit\u00e9 suppl\u00e9mentaire n\u2019intervient). En pratique, les escrocs utilisent surtout Log4Shell pour installer ill\u00e9galement des mineurs et pour lancer des attaques de ran\u00e7ongiciels. Cette vuln\u00e9rabilit\u00e9 a aussi \u00e9t\u00e9 utilis\u00e9e de fa\u00e7on <a href=\"https:\/\/www.zdnet.com\/article\/log4shell-flaw-still-being-used-for-crypto-mining-botnet-building-and-rick-rolls\/\" target=\"_blank\" rel=\"noopener nofollow\">plus originale<\/a>, avec des attaques cibl\u00e9es, la distribution du botnet Mirai ou pour du RickRolling, avec la reproduction de l\u2019addictive chanson du chanteur des ann\u00e9es 80 Rick Astley, \u00ab\u00a0Never Gonna Give You Up\u00a0\u00bb.<\/p>\n<p>\u00a0<\/p>\n<h2>Pourquoi cette vuln\u00e9rabilit\u00e9 est-elle si dangereuse et encore mena\u00e7ante ?<\/h2>\n<p>Java est un des principaux langages de programmation et est utilis\u00e9 par de nombreux syst\u00e8mes back end, qu\u2019il s\u2019agisse des petits serveurs d\u2019une entreprise, de syst\u00e8mes d\u2019automation industrielle ou de dispositifs de l\u2019Internet des Objets (IoT). La plupart de ces syst\u00e8mes utilisent la journalisation d\u2019une fa\u00e7on ou d\u2019une autre. Depuis des ann\u00e9es, la solution la plus simple consiste \u00e0 utiliser la biblioth\u00e8que Log4j. Lorsqu\u2019il a \u00e9t\u00e9 communiqu\u00e9 en d\u00e9cembre 2021 qu\u2019il y avait une vuln\u00e9rabilit\u00e9, les experts ont d\u00e9clar\u00e9 que ce serait un <a href=\"https:\/\/www.zdnet.com\/article\/log4j-flaw-why-it-will-still-be-causing-problems-a-decade-from-now\/\" target=\"_blank\" rel=\"noopener nofollow\">probl\u00e8me de taille pour les ann\u00e9es \u00e0 venir<\/a>. Voici pourquoi\u00a0:<\/p>\n<ul>\n<li>Des applications Java en tout genre utilisent la biblioth\u00e8que Log4j. Lorsqu\u2019elle a \u00e9t\u00e9 d\u00e9couverte, la vuln\u00e9rabilit\u00e9 se trouvait dans plus de <a href=\"https:\/\/security.googleblog.com\/2021\/12\/understanding-impact-of-apache-log4j.html\" target=\"_blank\" rel=\"noopener nofollow\">35 000 paquets du d\u00e9p\u00f4t Maven Central<\/a> (le plus grand r\u00e9pertoire de paquets Java), soit 8 % de tous les fichiers infect\u00e9s. Selon nos experts, <a href=\"https:\/\/www.itpro.co.uk\/security\/zero-day-exploit\/361847\/log4shell-zero-day-vulnerability-numbers-revealed\" target=\"_blank\" rel=\"noopener nofollow\">pr\u00e8s de 40 % des r\u00e9seaux dans le monde entier<\/a> \u00e9taient en danger \u00e0 cause de Log4Shell.<\/li>\n<li>En plus des ordinateurs et serveurs conventionnels, Java est aussi utilis\u00e9 par le mat\u00e9riel industriel, m\u00e9dical et sp\u00e9cialis\u00e9. Tous ces \u00e9quipements sont aussi connus pour leur utilisation de la biblioth\u00e8que Log4j.<\/li>\n<li>Les utilisateurs finaux des solutions qui utilisent la biblioth\u00e8que Log4j, et parfaitement inconscients de la pr\u00e9sence de cette vuln\u00e9rabilit\u00e9, pourraient remettre \u00e0 plus tard les mises \u00e0 jour.<\/li>\n<li>Les d\u00e9veloppeurs de solutions qui se servent de la biblioth\u00e8que Log4j auraient pu faire faillite depuis longtemps, abandonner le march\u00e9 ou chercher de l\u2019aide pour leurs programmes. M\u00eame si les utilisateurs finaux voulaient installer une mise \u00e0 jour, cette option n\u2019\u00e9tait peut-\u00eatre plus disponible, alors que changer de programme pourrait s\u2019av\u00e9rer plus difficile que pr\u00e9vu.<\/li>\n<li>Log4j est une biblioth\u00e8que open-source, ce qui signifie que les programmeurs peuvent la copier, la modifier et l\u2019utiliser dans leurs projets. Malheureusement, certains d\u00e9veloppeurs ne respectent pas les r\u00e8gles d\u2019accr\u00e9ditation et n\u2019indiquent pas toujours le code de la paternit\u00e9. En th\u00e9orie, la m\u00eame vuln\u00e9rabilit\u00e9 pourrait \u00eatre d\u00e9tect\u00e9e dans un projet tiers m\u00eame si, officiellement, il n\u2019utilise pas Log4j.<\/li>\n<li>Log4Shell \u00e9tait une vuln\u00e9rabilit\u00e9 de type zero-day, ce qui signifie que les cybercriminels pouvaient l\u2019exploiter avant que des informations ne soient publi\u00e9es \u00e0 son sujet. Certaines <a href=\"https:\/\/www.zdnet.com\/article\/log4j-rce-activity-began-on-december-1-as-botnets-start-using-vulnerability\/\" target=\"_blank\" rel=\"noopener nofollow\">preuves<\/a> laissent entendre que les escrocs ont test\u00e9 la faille pendant neuf jours avant de la rendre publique.<\/li>\n<li>Les produits VMware figurent parmi les victimes, notamment la solution de virtualisation des postes de travail VMware Horizon. Parmi les attaques enregistr\u00e9es, beaucoup ont pu acc\u00e9der au syst\u00e8me via ce programme.<\/li>\n<li>Les mises \u00e0 jour du logiciel auront peu d\u2019effet si les intrus sont d\u00e9j\u00e0 dans le syst\u00e8me. En aucun cas les attaques commencent imm\u00e9diatement apr\u00e8s la p\u00e9n\u00e9tration, et il est fort possible que de nombreux syst\u00e8mes contiennent actuellement une porte d\u00e9rob\u00e9e.<\/li>\n<\/ul>\n<p><strong>\u00a0<\/strong><\/p>\n<h2>Les dommages r\u00e9els<\/h2>\n<p>En toute justice, il convient de souligner que, pour le moment, aucune cons\u00e9quence catastrophique caus\u00e9e par l\u2019exploitation de Log4Shell n\u2019a \u00e9t\u00e9 signal\u00e9e. Du moins en ce qui concerne les cas publics. Cette vuln\u00e9rabilit\u00e9 a tout de m\u00eame \u00e9t\u00e9 un v\u00e9ritable casse-t\u00eate pour les d\u00e9veloppeurs et les experts en s\u00e9curit\u00e9, et a s\u00fbrement g\u00e2ch\u00e9 les vacances de No\u00ebl de milliers d\u2019informaticiens partout dans le monde. Les entreprises qui prennent la s\u00e9curit\u00e9 au s\u00e9rieux, la leur et celle de leurs clients, ont d\u00fb d\u00e9bourser des sommes consid\u00e9rables afin de localiser la vuln\u00e9rabilit\u00e9 dans leurs syst\u00e8mes et dans leurs logiciels, et pour l\u2019\u00e9liminer.<\/p>\n<p>Vous trouverez ci-dessous certains des incidents Log4Shell les plus importants\u00a0:<\/p>\n<ul>\n<li>Le 20 d\u00e9cembre 2021, le minist\u00e8re de la D\u00e9fense belge <a href=\"https:\/\/www.zdnet.com\/article\/belgian-defense-ministry-confirms-cyberattack-through-log4j-exploitation\/\" target=\"_blank\" rel=\"noopener nofollow\">a confirm\u00e9<\/a> une attaque qui exploitait cette vuln\u00e9rabilit\u00e9 au sein de son infrastructure. Naturellement, les d\u00e9tails n\u2019ont pas \u00e9t\u00e9 partag\u00e9s.<\/li>\n<li>Le 29 d\u00e9cembre 2021 des rapports m\u00e9diatiques indiquaient qu\u2019une certaine institution scientifique des \u00c9tats-Unis <a href=\"https:\/\/www.securityweek.com\/chinese-spies-exploit-log4shell-hack-major-academic-institution\" target=\"_blank\" rel=\"noopener nofollow\">avait \u00e9t\u00e9 attaqu\u00e9e via Log4Shell<\/a>. Selon CrowdStrike, le groupe APT Aquatic Panda a exploit\u00e9 la version non corrig\u00e9e du programme VMware Horizon. L\u2019activit\u00e9 suspecte a \u00e9t\u00e9 arr\u00eat\u00e9e \u00e0 temps, mais cet incident montre que de grands groupes de cybercriminels exploitent la vuln\u00e9rabilit\u00e9.<\/li>\n<li>Toujours en d\u00e9cembre 2021, les m\u00e9dias parlaient d\u2019une exploitation de Log4Shell dans les serveurs de Minecraft\u00a0: Java Edition, un serveur qui n\u2019est pas h\u00e9berg\u00e9 par l\u2019\u00e9diteur du jeu (Microsoft). L\u2019entreprise <a href=\"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2021\/12\/11\/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation\/\" target=\"_blank\" rel=\"noopener nofollow\">a confirm\u00e9<\/a> l\u2019information et a attir\u00e9 l\u2019attention sur la simplicit\u00e9 de l\u2019attaque. Les cybercriminels ont partag\u00e9 un code malveillant dans un chat habituel du jeu, ce qui a permis son ex\u00e9cution sur le serveur et sur le dispositif du client vuln\u00e9rable. Ce cas est moins int\u00e9ressant pour la victime mais l\u2019est particuli\u00e8rement en termes de mise en \u0153uvre technique. Dans certaines conditions, une attaque peut \u00eatre r\u00e9alis\u00e9e simplement via un chat interne. C\u2019est inqui\u00e9tant puisque les chats s\u2019utilisent d\u00e9sormais au-del\u00e0 du monde des jeux vid\u00e9o. Ils restent la m\u00e9thode de communication de pr\u00e9dilection de nombreuses entreprises. C\u2019est ce que les entreprises de technologie financi\u00e8re ou d\u2019autres applications utilisent pour l\u2019assistance client.<\/li>\n<li>En juin 2022, l\u2019Agence am\u00e9ricaine de cybers\u00e9curit\u00e9 et de s\u00e9curit\u00e9 des infrastructures (CISA) et l\u2019organisation am\u00e9ricaine <em>US Coast Guard Cyber Command<\/em> (CGCYBER) <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-174a\" target=\"_blank\" rel=\"noopener nofollow\">ont \u00e9mis une alerte<\/a> indiquant que la vuln\u00e9rabilit\u00e9 \u00e9tait encore activement exploit\u00e9e. Le communiqu\u00e9 indiquait que les cybercriminels avaient utilis\u00e9 une faille de VMware Horizon pour acc\u00e9der aux r\u00e9seaux internes de deux organismes gouvernementaux. De plus, les cybercriminels auraient eu acc\u00e8s \u00e0 130 GB de donn\u00e9es sensibles relatives aux forces de l\u2019ordre.<\/li>\n<li>En novembre 2022, la CISA et le FBI <a href=\"https:\/\/www.cisa.gov\/uscert\/ncas\/alerts\/aa22-320a\" target=\"_blank\" rel=\"noopener nofollow\">ont \u00e9mis une autre alerte<\/a> \u00e0 propos d\u2019une attaque Log4Shell qui visait un autre organisme gouvernemental. Les cybercriminels avaient eu acc\u00e8s au syst\u00e8me en f\u00e9vrier, avaient \u00e9t\u00e9 d\u00e9tect\u00e9s en avril et avaient \u00e9t\u00e9 actifs jusqu\u2019en juin-juillet. Pendant ce temps, ils avaient cr\u00e9\u00e9 un compte avec des privil\u00e8ges administrateur, avaient modifi\u00e9 le mot de passe d\u2019un administrateur l\u00e9gitime et avaient t\u00e9l\u00e9charg\u00e9 un logiciel de minage sur le serveur. Il semblerait que l\u2019attaque soit l\u2019\u0153uvre de cybercriminels parrain\u00e9s par le gouvernement iranien. C\u2019est pourquoi certains experts pensent que le minage n\u2019est qu\u2019une couverture utilis\u00e9e pour dissimuler leurs intentions.<\/li>\n<\/ul>\n<h2>Comment prot\u00e9ger votre infrastructure<\/h2>\n<p>N\u2019importe quelle entreprise peut \u00eatre victime de Log4Shell, et c\u2019est souvent simplement parce qu\u2019elle ne sait pas que ses syst\u00e8mes ou ses programmes sont vuln\u00e9rables. Si vous ne savez pas si vos syst\u00e8mes, vos outils, vos produits ou vos services se servent de la biblioth\u00e8que Log4j, il convient de r\u00e9aliser un [security assessment services placeholder]audit de s\u00e9curit\u00e9 approfondi[\/security assessment services placeholder]. En plus de \u00e7a, nous vous invitons \u00e0 suivre les conseils de nos experts pour vous prot\u00e9ger.<\/p>\n<ul>\n<li>Si le programme que vous d\u00e9veloppez utilise Log4j, utilisez la derni\u00e8re version de la biblioth\u00e8que disponible sur la <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/download.html\" target=\"_blank\" rel=\"noopener nofollow\">page du projet<\/a>.<\/li>\n<li>Lisez le <a href=\"https:\/\/logging.apache.org\/log4j\/2.x\/\" target=\"_blank\" rel=\"noopener nofollow\">guide<\/a> officiel <em>Apache Logging Services<\/em> et suivez les indications, le cas \u00e9ch\u00e9ant.<\/li>\n<li>Si des produits tiers utilisent Log4j, mettez \u00e0 jour tous les logiciels vuln\u00e9rables.<\/li>\n<li>Installez des <a href=\"https:\/\/www.kaspersky.fr\/small-to-medium-business-security?icid=fr_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">solutions de s\u00e9curit\u00e9<\/a> robustes et capables de d\u00e9tecter les tentatives d\u2019exploitation des vuln\u00e9rabilit\u00e9s sur les serveurs et sur les postes de travail.<\/li>\n<li>Surveillez l\u2019activit\u00e9 suspecte au sein du p\u00e9rim\u00e8tre de votre entreprise un utilisant des solutions de <a href=\"https:\/\/www.kaspersky.fr\/enterprise-security\/endpoint-detection-response-edr?icid=fr_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">type EDR<\/a> ou des services externes comme ceux de <a href=\"https:\/\/www.kaspersky.fr\/enterprise-security\/managed-detection-and-response?icid=fr_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">d\u00e9tection et de r\u00e9ponse g\u00e9r\u00e9s<\/a>. Cela vous permet de d\u00e9tecter et d\u2019\u00e9liminer les attaques \u00e0 un stade pr\u00e9coce.<\/li>\n<\/ul>\n<p>\u00a0<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kesb-top3\">\n","protected":false},"excerpt":{"rendered":"<p>Un an apr\u00e8s avoir \u00e9t\u00e9 d\u00e9couverte, la vuln\u00e9rabilit\u00e9 Log4Shell est encore pr\u00e9sente.<\/p>\n","protected":false},"author":2484,"featured_media":19882,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150],"tags":[4235,4236,322,446],"class_list":{"0":"post-19881","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-apache","10":"tag-log4j","11":"tag-vulnerabilites","12":"tag-zero-day"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/log4shell-still-active-2022\/19881\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/log4shell-still-active-2022\/24965\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/log4shell-still-active-2022\/20461\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/log4shell-still-active-2022\/10462\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/log4shell-still-active-2022\/27531\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/log4shell-still-active-2022\/25295\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/log4shell-still-active-2022\/25614\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/log4shell-still-active-2022\/28172\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/log4shell-still-active-2022\/34362\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/log4shell-still-active-2022\/46545\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/log4shell-still-active-2022\/20467\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/log4shell-still-active-2022\/29588\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/log4shell-still-active-2022\/33272\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/log4shell-still-active-2022\/25653\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/log4shell-still-active-2022\/31342\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/log4shell-still-active-2022\/31051\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/vulnerabilites\/","name":"Vuln\u00e9rabilit\u00e9s"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19881","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/2484"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=19881"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19881\/revisions"}],"predecessor-version":[{"id":19883,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/19881\/revisions\/19883"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/19882"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=19881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=19881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=19881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}