Confluence Data Center et Confluence Server sont affectés par une importante faille de sécurité. Révélée il y a une semaine par Atlassian, l’éditeur des produits, elle est activement exploitée depuis ce week-end. Elle permet d’obtenir un compte administrateur.
Atlassian n'est pas forcément connue du grand public, mais cette entreprise australienne commercialise des produits largement utilisés dans le monde professionnel. On la connait notamment pour Jira et surtout Trello.
Or, un petit vent de panique souffle actuellement chez Atlassian et une partie de sa clientèle. Confluence Data Center et Confluence Server, deux produits centrés sur la collaboration, le travail en équipe, la mise en commun, l’organisation et le wiki, sont en effet au centre de l'attention. Cette solution, labellisée simplement Confluence, peut être utilisée dans le cloud d’Atlassian ou sur site. Et justement, les versions sur site sont percées d’une importante faille qu’il est urgent de colmater par une mise à jour.
Cette faille, estampillée CVE-2023-22518, a été révélée il y a une semaine, accompagnée de mises à jour pour les produits concernés. Cependant, dans les jours qui ont suivi, la brèche a été examinée de près par plusieurs chercheurs, et les détails ont commencé à affluer. Il n’a pas fallu longtemps pour que les premières exploitations voient le jour. Dès ce week-end, plusieurs entreprises en faisaient les frais. Or, la faille est simple à exploiter et permet beaucoup.
Une faille critique
La vulnérabilité CVE-2023-22518 est clairement critique et correspond au pire des scénarios : elle peut être exploitée à distance pour aboutir à l’exécution de commandes arbitraires.
C’est ce qui se passe depuis ce week-end, comme l’observe notamment la société de sécurité Rapid7 dans un billet publié hier. Les chercheurs ont observés une chaine de processus d’exécution semblables chez divers clients Confluence qui ont choisi de rendre leurs serveurs accessibles sur Internet. Une telle cohérence est le signe, selon eux, d’une exploitation de masse.
La faille est de type « Improper Authorization » et permet de contourner l’authentification dans les deux produits Confluence. Elle est exploitée par l’envoi de requêtes spécialement conçues, permettant alors aux acteurs malveillants d’obtenir un compte administrateur. De là, un boulevard leur est ouvert, qui leur a notamment servi à déployer des ransomwares.
« Dans de multiples chaînes d'attaque, Rapid7 a observé l'exécution de commandes post-exploitation pour télécharger une charge utile malveillante hébergée à 193.43.72[.]11 et/ou 193.176.179[.]41, ce qui, en cas de succès, a conduit au déploiement d'un ransomware Cerber […] », indique ainsi Rapid7.
En tant que telle, la vulnérabilité ne permet pas directement l’exfiltration de données. Mais, comme indiqué par Atlassian, elle permet la modification de l’état du serveur et l’installation d’une charge utile provenant d’une source malveillante. Cette charge peut prendre les données en otage.
Une dangerosité révisée à la hausse
Dans son bulletin initial du 31 octobre, Atlassian ne prenait déjà pas de gants : « Toutes les versions de Confluence Data Center et Server sont affectées par cette vulnérabilité non exploitée. Cette vulnérabilité de type Improper Authorization permet à un attaquant non authentifié de réinitialiser Confluence et de créer un compte administrateur de l'instance Confluence. En utilisant ce compte, un attaquant peut alors effectuer toutes les actions disponibles pour l'administrateur de l'instance de Confluence, ce qui entraîne – mais sans s'y limiter – une perte totale de la confidentialité, de l'intégrité et de la disponibilité ».
La note attribuée était déjà de 9,1 sur 10 (toujours à 9,1 sur le site du NIST, mais critique dans tous les cas). Dans la même journée cependant, une première mise à jour de Bala Sathiamurthy, responsable de la sécurité chez Atlassian, indiquait que les clients étaient vulnérables à « une importante perte de données ». À ce moment, aucune exploitation n’était encore à signaler, mais l’entreprise prévenait ses clients qu’ils devaient mettre à jour leurs produits sur site sans tarder, évoquant des « mesures immédiates », dont les mots étaient en gras et soulignés.
Deux jours plus tard, nouvelle mise à jour. Atlassian dit avoir « observé que des informations critiques sur la vulnérabilité ont été publiées, ce qui augmente le risque d'exploitation ». On ne sait pas si l’entreprise a souhaité critiquer les personnes qui ont publié des informations sur la faille dans les jours qui ont suivi, à l’instar de Petrus Viet, qui a montré l’efficacité de l’exploitation dans une vidéo sur Mastodon.
Le 3 novembre, nouvelle mise à jour, cette fois pour avertir qu’un client a remonté une exploitation active. Atlassian insiste à nouveau sur l’urgence de la mise à jour. La dernière mise à jour date du 6 novembre et fait état de multiples exploitations.
L’entreprise indique avoir relevé la note CVSS à 10, « en raison de l’évolution de la portée de l’attaque ». La faille en elle-même n’a pas changé, mais sa dangerosité prend désormais en compte une exploitation très active par des acteurs malveillants.
Un nombre croissant de victimes
Les exploitations de la faille ont pris de l’ampleur à partir de dimanche. Elles continuent à l’heure actuelle. Les entreprises visées sont situées dans de nombreux pays, dont les États-Unis, Taïwan, l’Ukraine, la Géorgie, la Lettonie ou encore la Moldavie.
Selon Andrew Morris, PDG de la société de sécurité GreyNoise, les attaques proviennent systématiquement des trois mêmes adresses IP :
- 176.179[.]41
- 43.72[.]11
- 145.6[.]112
The DFIR Report a publié sur X (Twitter) une série de captures montrant notamment le message reçu par l’une des victimes, de la part d’un groupe se nommant C3RB3R, connu pour le ransomware du même nom.
Dans les autres captures, on peut observer par exemple la tentative de mouvement latéral post-exploit vers d’autres parties du réseau. Une fois dans le réseau interne, ils peuvent par exemple tenter leur chance sur le port SMB/445.
🚨Confluence exploit (CVE-2023-22518) Leads to C3RB3R Ransomware🚨
— The DFIR Report (@TheDFIRReport) November 6, 2023
➡️Exploit source: 193.187.172.73
➡️Download & Exec: http://193[.]187[.]172[.]73/tmp[.]1u
➡️Lateral Movement: Attempts to spread over SMB/445
➡️Extension: LOCK3D
h/t @GreyNoiseIO pic.twitter.com/VdO5EUjPOj
Le rapport de Rapid7 pointe pour sa part plusieurs processus parents et enfants dont la présence doit être surveillée sur les serveurs Linux et Windows car ils font partie de l’attaque.
À chaque fois, la commande whoami est utilisée pour afficher le nom de l’usager et son identificateur effectif (UID). Ses groupes et sa règle d’authentification sont également indiqués. Après quoi, des commandes sont exécutés en Base64 pour en générer d’autres, en Python 2 ou 3.
Une mise à jour urgente
Atlassian insiste depuis une semaine sur la dangerosité de la faille et l’urgence de la situation. Les versions 7.19.16, 8.3.4, 8.4.4, 8.5.3 et 8.6.1 sont corrigées et doivent être installées aussi rapidement que possible.
Si pour une raison ou une autre l’application du correctif est impossible, il est recommandé de couper l’accès internet des serveurs Confluence. Une autre solution d’atténuation est de désactiver les points d’extrémité suivants :
- /json/setup-restore.action
- /json/setup-restore-local.action
- /json/setup-restore-progress.action
Commentaires (15)
Que veut dire cette symbologie [.] sur une IP ? Jamais vu ça avant !
A mon avis, le but est de ne pas donner l’IP complète, même s’il n’y a que 254 possibilités pour la retrouver, vu les informations disponibles.
+1, c’est pour éviter que l’article sorte quand on cherche lesdites IP aussi. C’est une donnée personnelle après tout. En suivant le lien on a les IP complètes.
Je pense qu’à la base c’est surtout pour éviter un accès involontaire vers les adresses quand elles sont complètes.
J’ai aussi vu des bases d’URL problématiques avec hXXp(s) par exemple pour éviter les accès par erreur.
Après, comme expliqué, il faut que le serveur soit accessible par l’attaquant. Dans beaucoup d’entreprises, elles ont du Confluence on-premise, et dispo uniquement depuis un réseau privé. Mais pour celles qui laissent leur instance accessible depuis le web, elles ont effectivement dû avoir un coup de chaud.
Cela me fait penser à Atlassian qui évoquait (au moins depuis l’an dernier) la volonté d’arrêter prochainement de proposer des versions on-premise, pour se limiter à leur version cloud, donc hébergée par Atlassian. Alors autant on peut faire confiance à Atlassian pour patcher leurs instances rapidement, autant se posent plein d’autres soucis : coût, confidentialité, données hébergées à l’étranger… la liste est longue, et ça rouspétait très fort chez les clients d’Atlassian. Je serais curieux de voir où ça en est cette histoire…
Pour être dans la DSI de grosses boites très dépendantes de cet outil, pour l’instant ils sortent le chéquier. Atlassian pour pousser leurs clients à passer en SaaS a doubler voir quintupler le prix des licences. Le prix en SaaS n’est pas bcp mieux mais t’enlève la partie matériel et administration de l’instance.Donc pour l’instant les DSI alignent des millions … en réfléchissant a passer a autre chose.
Un peu comme quand Oracle avait fait la même chose, ce qui avait largement profiter à PostgreSQL.
Microsoft commence avancer ses pions avec Azure DevOps. Et comme bcp de ces boite passe sous Office 365, s’il la joue bien ils pourraient bien prendre part de marché non négligeable.
Ça vous dirait pas une solution concurrente pour potentiellement beaucoup moins cher au-delà des frais d’installation / migration ? xd
Si je comprends bien en fait c’est les chercheurs qui ont creusé cette faille pour comprendre ce qu’il y avait derrière et qui ont leakés pleins de détails qui ont permis l’exploit, j’ai bon ?
Si c’est ça alors clairement pas chapeau aux chercheurs concernés qui auraient dû attendre un peu que tout le monde puisse patcher leurs instances ou au moins ne rien leaker avant un certain temps.
on utilisait la version de jira cloud hébergé par atlassian et on avait bien raler pour qu’ils mettent des serveurs en europe avec rgpd et tout mais après plusieurs années vu que ça n’a pas été fait on est parti de jira. Donc si je comprends bien il n’y a toujours pas de serveurs EU tu confirmes ?
Sans parler de la latence à certaines heures lorsque le traffic US est ultra chargé les instance mettaient des plombes à se charger. Toujours le soucis ?
Pour les données en France je n’ ai pas l’information.
Revenant de missions chez un gros FAI canadien et le gros énergéticien du Québec, les données de documentation stockées étant clairement critiques, c’est on-premise sinon rien. Et ca s’alarmait (à raison) quand aux futures offres cloud-only. Ce n’est même pas la localisation des données à l’étranger qui pose problème, c’est carrément que ça sorte des murs desdites entreprises.
Mes missions en France, dans de grands groupes, notamment à développer des services étatiques, c’était exactement le même souci. Faut pas que ça sorte des murs. Donc implicitement ça restera aussi en France. Mais pour les autres situations, je ne suis pas compétent.
Mais je me dis que si Atlassian va jusqu’au bout de son idée, il y aura des serveurs en UE, si ce n’est déjà fait. En toute logique. Et en croisant les doigts 😀
Exactement. MS est bien installé avec Sharepoint, qui s’intègre de plus en plus avec Office et Teams. La concurrence corpo est là. Ce qui n’est pas un mal.
Nous ils ont coupé l’accès externe directement le 31 octobre, en attendant de pouvoir patcher.
Bonjour,
J’ai buggé quand j’ai lu “les versions sur site”.
Je n’ai jamais entendu cette expression.
On parle tout le temps de version “On Permise” ou “On Prem’ ” ou hébergée.
Voilà voilà.
Je découvre encore des trucs, c’est ouf. Merci
C’était quoi la découverte du coup ?
Juste que la traduction en français de “On premise” c’est “Sur site” ?
Oui.
c’est tout à fait ça, et j’ai vu la même chose pour les noms de domaine (nextinpact[.]com).
Par contre, c’est pénible quand tu veux faire des recherches