Atlassian Confluence: le calendrier des correctifs, un test de dépendance en mode commun

Résumé

• Le dossier Confluence révèle un problème structurel de responsabilité: Atlassian pouvait publier un avis, des mesures d'atténuation et des versions corrigées, mais chaque client auto-géré devait encore transformer cet avis en inventaire, temps d'arrêt, exécution de la mise à niveau, analyse post-incident et confiance rétablie.
• CVE-2022-26134 est l'exemple le plus évident de mode commun, car elle a touché Confluence Server et centres de données, permettait l'exécution de code à distance non authentifiée, a été exploitée avant la divulgation publique, a intégré le catalogue des vulnérabilités exploitées connues de la CISA le 2 juin 2022 et a donné lieu à diverses exploitations après la publication des versions corrigées.
• Les responsabilités hébergée et auto-gérée devaient être distinguées. Atlassian a indiqué que ses sites Cloud n'étaient pas affectés, tandis que les clients utilisant Server ou centres de données portaient le fardeau de l'instance en cours: exposition réseau, planification de la mise à niveau, sauvegardes, journalisation, privilèges, enquête et continuité d'activité.
• Un correctif n'équivaut pas à une clôture. Les intervenants ont observé des implants en mémoire, des shells web, des tentatives d'altération des journaux, des tentatives de ransomware, du minage de cryptomonnaie, des charges utiles de bots et un trafic d'exploitation public. Une version corrigée pouvait bloquer un chemin tout en laissant sans réponse les preuves, les identifiants, la persistance et la confiance endommagée.
• Le test de responsabilité consiste à savoir si un écosystème fournisseur-client peut mesurer le temps nécessaire pour retrouver un service digne de confiance, et pas seulement le temps de publication de l'avis ou du premier paquet corrigé.

L'exposition en mode commun est une condition opérationnelle

Confluence est souvent présenté comme un wiki ou un outil de collaboration, mais dans de nombreuses organisations, il devient une mémoire opérationnelle. Il stocke des procédures, des notes d'incident, des explications d'architecture, des pages de politique, des décisions de projet, des procédures de support client, des plans de produit et des liens vers d'autres systèmes. Lorsqu'un produit ayant ce rôle contient une vulnérabilité activement exploitée, le risque ne se limite pas au propriétaire du logiciel. Il touche chaque équipe dont le travail quotidien dépend de l'intégrité et de la disponibilité de ces espaces.

L'avis de sécurité Confluence 2022-06-02d'Atlassian a rendu ce risque public pour CVE-2022-26134. L'avis décrivait un problème d'injection OGNL dans Confluence Server et Confluence centres de données pouvant permettre l'exécution de code à distance non authentifiée. Il précisait également que les sites Atlassian Cloud n'étaient pas affectés. Cette distinction cloud est importante car elle répartit la responsabilité opérationnelle. Un client de service hébergé dépend d'Atlassian pour exploiter le service vulnérable. Un client auto-géré dépend d'Atlassian pour le correctif, mais contrôle l'instance exposée, la fenêtre de changement, les sauvegardes, l'accessibilité réseau, le contexte de privilège et l'enquête post-exploitation.

La vulnérabilité n'était pas un défaut théorique discret. Le rapport d'exploitation zero-day deVolexitya décrit une exploitation pendant le week-end du Memorial Day aux États-Unis avant la divulgation publique, incluant des shells web, un implant BEHINDER en mémoire, un accès au contenu stocké dans Confluence et des tentatives d'altération des journaux. Le rapport indiquait également que Volexity avait informé Atlassian le 31 mai 2022. La réponse publique d'Atlassian a été rapide après ce signalement, mais la rapidité du fournisseur n'a pas effacé la charge de travail répartie entre les clients.

La CISA a ajouté CVE-2022-26134 aucatalogue des vulnérabilités exploitées connuesle 2 juin, avec une date limite au 6 juin pour les agences civiles fédérales concernées. L'alerte distincte de la CISA du 3 juina orienté les agences et les organisations vers les versions corrigées d'Atlassian. La date limite fédérale n'est pas une obligation légale universelle dans le secteur privé. Elle reste néanmoins un signal public fort d'urgence, car elle transforme un « correctif important » en « service activement exploité que les systèmes gouvernementaux doivent traiter immédiatement ».

Le problème du mode commun réside dans le nombre d'organisations confrontées simultanément à la même urgence. Lebulletin de menace de Unit 42estimait à 19 707 le nombre de serveurs Confluence potentiellement affectés visibles sur Internet et à 1 251 les serveurs en fin de vie. Ledossier du DIVDindiquait avoir commencé à notifier les opérateurs d'environ 15 000 instances vulnérables. Ces chiffres ne sont pas des décomptes vérifiés de victimes uniques ou de compromissions réussies. Ils prouvent que la découverte de l'exposition était en soi une tâche opérationnelle de grande ampleur.

Un test de dépendance en mode commun demande si l'écosystème peut absorber cette tâche synchronisée. Atlassian devait publier un périmètre et des correctifs précis. Les clients devaient identifier chaque instance, surtout celles oubliées ou exposées à l'externe. Les fournisseurs de services gérés devaient traduire les avis pour leurs clients. Les agences publiques devaient prioriser l'action d'urgence. Les éditeurs de sécurité devaient publier des observations de détection et de réponse. Les propriétaires métier devaient décider s'il fallait désactiver une plateforme de collaboration dont les employés pouvaient avoir besoin pour répondre.

Le défaut produit est devenu un problème de coordination.

L'horloge des correctifs et l'horloge de service étaient différentes

Le délai des correctifs est souvent mesuré du signalement à l'avis, ou de l'avis à la publication de la version corrigée. C'est utile pour la responsabilité du fournisseur, mais cela peut masquer l'horloge de service client. L'horloge client démarre lorsque l'alerte atteint le bon propriétaire et ne s'arrête que lorsque l'organisation peut démontrer que le service vulnérable est corrigé ou isolé, que la période d'exposition a fait l'objet d'une enquête et que le service restauré est suffisamment fiable pour être utilisé.

L'historique des mises à jour de l'avis d'Atlassian montre pourquoi ces horloges ont divergé. L'avis initial du 2 juin mettait en garde contre une exploitation active. Le 3 juin, Atlassian a mis à jour les informations d'atténuation, puis a listé les versions corrigées pour les branches prises en charge. Il a également averti que les clients ne pouvaient pas atteindre les versions corrigées par une mise à niveau progressive. Ce dernier point est un fait de continuité, pas une note de bas de page.

Un produit en cluster qui ne peut pas être corrigé par un processus progressif peut nécessiter un temps d'arrêt plus important, une approbation d'urgence et une perturbation des utilisateurs.

Les pages générales duConfluence Upgrade Hubet de lamise à niveau sans temps d'arrêtd'Atlassian montrent que le travail normal de mise à niveau comprend la préparation, l'examen de compatibilité, les sauvegardes, les considérations de cluster et la vérification. L'avis d'urgence a comprimé ces tâches. Un client devait décider de suivre le chemin de mise à niveau complet, d'appliquer des remplacements de fichiers provisoires ou d'isoler l'instance tout en planifiant un changement plus sûr. Chaque option comportait des risques: exploitabilité continue, interruption opérationnelle, échec de compatibilité ou atténuation incomplète.

Les sauvegardes compliquent ce choix. La documentationBackup and Restored'Atlassian est un guide produit général, mais l'incident a rendu son objectif concret. Un client préparant une correction d'urgence avait besoin d'être sûr que les données pourraient être récupérées en cas d'échec de la mise à niveau. Pourtant, une sauvegarde effectuée après exploitation pouvait conserver des shells web ou un état compromis, et une restauration dans une version vulnérable pouvait recréer le problème. Une sauvegarde n'est pas une clôture. C'est un élément parmi d'autres d'un chemin de récupération soigneusement choisi.

Le National Institute of Standards and Technology a publié les documentsSP 800-40 Rev. 4etSP 1800-31peu avant cet incident. Ces guides présentent l'application de correctifs comme un processus d'entreprise incluant l'identification, la priorisation, les tests, l'installation, la vérification et la gestion des exceptions. Il ne s'agit pas de conclusions propres à Confluence. Ils sont utiles car ils décrivent le travail manquant entre « un correctif existe » et « le risque est maîtrisé ».

Pour Confluence, la vérification comportait plusieurs volets. Chaque instance avait-elle été trouvée, y compris les instances de test, anciennes, exposées à l'externe ou liées à un seul projet? La version était-elle corrigée ou l'accès bloqué? L'atténuation avait-elle été appliquée à chaque nœud? Le service s'exécutait-il avec des privilèges hôte inutiles? Les journaux avaient-ils été préservés avant toute modification ou suppression? Les informations d'identification connectées avaient-elles fait l'objet d'une rotation? Les utilisateurs avaient-ils été informés de ce qu'il fallait éviter pendant la restriction du service?

Le contenu restauré était-il digne de confiance? L'horloge des correctifs pouvait s'arrêter lorsqu'Atlassian publiait les paquets corrigés. L'horloge de service s'arrêtait beaucoup plus tard, si le client disposait de preuves.

C'est pourquoi une vulnérabilité en mode commun peut exposer de manière disproportionnée les organisations plus fragiles. Les grandes entreprises disposent peut-être d'outils de gestion des actifs, de comités de changement, de journaux conservés, d'environnements de test et d'équipes de réponse aux incidents. Les petites équipes peuvent n'avoir qu'un seul administrateur, une seule instance de production, pas d'environnement de test séparé et une capacité limitée à planifier des temps d'arrêt. Le même avis arrive aux deux.

La responsabilité doit tenir compte de cette asymétrie sans prétendre que le fournisseur peut exécuter la correction de chaque client.

Le langage d'exploitabilité avait un poids opérationnel

Le libellé d'un avis de vulnérabilité n'est pas de la communication. Il détermine si les dirigeants autorisent un temps d'arrêt, si les administrateurs arrêtent le travail de routine, si les agences publiques déclenchent des processus d'urgence et si les équipes de sécurité préservent les preuves avant de redémarrer un service. CVE-2022-26134 nécessitait un langage particulièrement clair, car l'exécution de code à distance non authentifiée sur une plateforme de collaboration accessible sur Internet est facile à sous-estimer tant que le rôle métier n'est pas nommé.

L'avis d'Atlassian indiquait que toutes les versions prises en charge de Confluence Server et centres de données étaient affectées et que le problème était activement exploité. L'enregistrement public du problème CONFSERVER-79016liait le défaut à une injection de template OGNL. L'entrée CVE-2022-26134du NVD a ensuite attribué un score de base CVSS 3.1 de 9,8. Les scores sont des instruments grossiers, mais ici le score correspondait à la réalité opérationnelle: aucun compte n'était requis, le service était accessible à distance et l'exécution de code arbitraire sur l'hôte pouvait en résulter.

LaFAQ d'Atlassian pour CVE-2022-26134ajoutait plusieurs points importants pour la responsabilité. Elle indiquait que l'authentification unique ne bloquerait pas l'exploitation, car la vulnérabilité pouvait être déclenchée avant l'authentification. Elle conseillait de mettre à niveau même les instances non exposées à Internet. Elle précisait également qu'Atlassian ne pouvait pas déterminer si l'instance d'un client avait été compromise et recommandait aux clients d'enquêter localement ou avec des spécialistes. Cette déclaration est inconfortable mais honnête. Le fournisseur ne possédait pas les journaux locaux, l'état de la mémoire, les modifications de fichiers et l'activité d'identité de chaque client.

Les intervenants en gestion d'incidents ont fourni les détails pratiques derrière cet avertissement. Volexity a observé un implant en mémoire, des shells web sur disque, un accès aux tables de contenu dans l'environnement du produit et des tentatives d'altération des journaux. Le rapport« observed-in-the-wild » de GreyNoisedécrivait un grand nombre d'adresses sources tentant l'exploitation et une large gamme de charges utiles. L'avis de menace de Cisco Talosfaisait état d'une disponibilité publique de preuve de concept et d'une exploitation active. Sophos a par la suite signalé que desransomwares et autres charges utilesatteignaient des serveurs vulnérables. Ces rapports ne décrivent pas une campagne uniforme. Ils montrent à quelle vitesse un seul chemin d'exploitation s'est diversifié en de nombreuses menaces opérationnelles.

L'avis conjoint mené par la CISA sur les principales vulnérabilités régulièrement exploitées en 2022a ultérieurement inclus CVE-2022-26134 parmi les vulnérabilités les plus couramment exploitées de l'année. Ce statut rétrospectif est important, car il montre que la vulnérabilité n'a pas disparu des préoccupations des défenseurs après la première semaine. Les systèmes non corrigés, restaurés à partir d'anciennes images ou oubliés après une acquisition pouvaient rester utiles aux attaquants.

Un langage d'exploitabilité précis doit donc répondre à quatre questions pratiques. Un attaquant non authentifié peut-il atteindre le chemin? Le service cloud hébergé est-il affecté ou seulement les instances auto-gérées? L'atténuation nécessite-t-elle une mise à niveau complète, un remplacement de fichiers, un isolement réseau ou une mise hors service? L'application du correctif met-elle fin à l'enquête, ou les clients doivent-ils supposer qu'une exploitation a déjà pu se produire? Les documents publics d'Atlassian répondaient à beaucoup de ces questions, et l'écosystème des intervenants a complété les conséquences.

La faiblesse ne résidait pas seulement dans ce que disait l'avis. C'était de savoir si chaque client pouvait agir suffisamment vite.

La responsabilité hébergé contre auto-géré devait être explicite

Le dossier Confluence est un cas de responsabilité partagée, mais pas au sens vague où chacun devrait mieux faire. La responsabilité suit le contrôle. Atlassian contrôlait le développement du produit, la publication des avis, la diffusion des versions corrigées, les instructions d'atténuation propres au produit, le support client et la clarté du périmètre cloud par rapport à l'auto-géré. Les clients contrôlaient l'exposition, l'inventaire des instances, les privilèges d'exploitation, les sauvegardes, la surveillance, l'exécution des changements et l'enquête post-exploitation.

Lerapport sur les incidents de sécurité de l'exercice 22 d'Atlassiana classé la réponse à CVE-2022-26134 comme un incident significatif et a reconnu l'exploitation active d'instances exposées à Internet. Ce rapport produit par l'entreprise est utile car il confirme la sévérité interne du point de vue d'Atlassian. Il ne fournit pas une analyse complète des causes racines expliquant pourquoi la faille a échappé plus tôt, comment les tests de développement sécurisé ont été modifiés par la suite ni comment les contrôles de récurrence ont été validés de manière indépendante.

Lapolitique actuelle de publication des avis de sécuritéd'Atlassian et lesalertes d'avis dans Confluencemontrent comment les canaux de notification et les attentes en matière de sécurité produit sont encadrés aujourd'hui. La politique actuelle ne doit pas être considérée comme la preuve de la politique exacte en vigueur en mai 2022. Elle aide néanmoins à identifier le contrôle de l'écosystème: les clients ont besoin de canaux d'avis fiables et les fournisseurs d'un langage orienté client qui identifie à la fois la sévérité et l'action.

Les clients auto-gérés portaient la charge opérationnelle la plus lourde. Une instance Confluence Server ou centres de données peut se trouver derrière un pare-feu, sur l'Internet public, derrière un proxy, dans un hébergement géré ou sur une ancienne infrastructure. Elle peut être la propriété de l'informatique centrale, d'une unité opérationnelle, d'une équipe projet ou d'un prestataire. Elle peut contenir des procédures à jour ou du contenu obsolète que personne ne considère comme critique pour l'activité jusqu'à ce que l'urgence survienne.

Le fournisseur ne peut pas identifier de manière fiable tous ces déploiements depuis l'extérieur, surtout lorsque les licences, les relations avec les revendeurs, les fusions et les changements réseau masquent la propriété.

Cela ne signifie pas que les clients portent seuls le risque. L'avis du fournisseur doit être précoce, clair, exploitable et maintenu. Des versions corrigées doivent être disponibles pour les branches prises en charge. L'atténuation provisoire doit être précise. Les réponses publiques doivent éviter de se cacher derrière un langage générique du type « appliquer les correctifs » lorsque l'exploitation active modifie le risque.

La réponse d'Atlassian a été rapide après le signalement, mais le dossier public ne répond pas à la question de savoir pourquoi un tel chemin d'exécution non authentifié, affectant un large périmètre, existait et quelles preuves d'assurance produit ont été modifiées après l'événement.

Pour les clients, la norme de responsabilité devrait être brutalement pratique. Une plateforme de collaboration auto-gérée accessible publiquement doit avoir un propriétaire, un canal de correctifs, une autorité de maintenance, une sauvegarde testée, des journaux protégés en dehors de l'hôte applicatif, une surveillance de l'hôte ou des terminaux, des limites réseau et un plan de communication d'urgence qui ne dépend pas uniquement de la plateforme compromise.

Si une entreprise ne peut pas répondre qui possède l'instance et comment elle serait mise hors ligne en quelques heures, elle n'a pas seulement un problème de gestion des vulnérabilités. Elle a un problème de dépendance à la mémoire opérationnelle.

La clôture côté client exigeait des preuves, pas seulement des numéros de version

L'installation d'une version corrigée de Confluence était nécessaire. Elle ne constituait pas, en soi, un blanc-seing. Un client exploité avant l'application du correctif devait répondre aux questions suivantes: le contenu a-t-il été lu ou modifié, des shells web subsistent-ils, des informations d'identification ont-elles été exposées, les journaux ont-ils été altérés, des utilisateurs créés par l'attaquant existent-ils, d'autres hôtes ont-ils été atteints et le contenu restauré peut-il être considéré comme fiable?

Le compte rendu de Volexity est important ici, car il faisait état d'activités à la fois résidentes en mémoire et basées sur des fichiers. Une simple analyse de fichiers pouvait manquer une catégorie. Un simple redémarrage pouvait en supprimer une autre tout en perdant des preuves volatiles. Un contrôle de version pouvait indiquer que l'instance était corrigée alors que la persistance subsistait ailleurs. LaFAQ d'Atlassianconfiait à juste titre l'évaluation de la compromission aux clients et aux intervenants spécialisés, car Atlassian ne pouvait pas voir l'état local de chaque client.

La journalisation est donc un contrôle, pas un luxe. Lesrecommandations de la CISA sur l'utilisation de la journalisationdans les systèmes métier sont générales, mais elles s'appliquent directement à ce type d'incident. Si les journaux résident uniquement sur l'hôte compromis, s'ils tournent trop rapidement ou si le service lui-même peut les altérer, la confiance après exploitation devient fragile. Un client peut appliquer le correctif sans pouvoir prouver ce qui s'est passé. L'absence de preuves devient alors un coût opérationnel.

Leguide actuel de gestion des vulnérabilitésdu National Cyber Security Centre britannique met l'accent sur la propriété, la priorisation, le comportement de mise à jour par défaut, l'acceptation des exceptions par la direction et la vérification. Leguide de réponse et de récupération pour les petites entreprisesdu NCSC ajoute la dimension de continuité: préparer, identifier, résoudre, signaler et apprendre. Il ne s'agit pas de conclusions propres à Confluence. Ils sont utiles, car les clients de Confluence allaient des grandes entreprises sophistiquées aux petites organisations ayant besoin d'un modèle de réponse simple.

La clôture exigeait également un jugement métier. Confluence peut contenir les instructions pour répondre à l'urgence Confluence. Il peut conserver des listes de contacts fournisseurs, des notes d'architecture ou des plans de continuité. Le mettre hors ligne peut ralentir la réponse. Le laisser en ligne peut préserver un chemin pour l'attaquant. Une organisation résiliente conserve les procédures d'urgence et les chemins de contact en dehors du système dont la confiance peut faillir. La dépendance en mode commun ne réside pas seulement dans le fait que de nombreuses organisations utilisent Confluence.

Elle tient à ce que de nombreuses organisations y stockent leur mémoire de réponse.

Les numéros de version ne constituent donc une preuve que s'ils sont accompagnés d'éléments plus larges. Quelles instances étaient concernées? Lesquelles étaient exposées à Internet? Lesquelles ont été corrigées, isolées ou mises hors service? Lesquelles ont fait l'objet d'une enquête sur l'activité antérieure au correctif? Quels identifiants ont fait l'objet d'une rotation? Quels journaux ont été préservés? Quels propriétaires métier ont accepté le risque résiduel? Quels utilisateurs ont été informés que le service était à nouveau digne de confiance?

Sans ces réponses, l'organisation a corrigé un produit mais n'a pas nécessairement restauré une surface de travail fiable.

La question de responsabilité de second niveau

Les premières analyses de cet incident se concentraient souvent sur l'asymétrie temporelle des correctifs, l'écart entre le correctif du fournisseur et la correction du client. La deuxième grille de lecture est plus large: la dépendance en mode commun. Une plateforme de collaboration peut résider discrètement au sein de nombreuses organisations indépendantes tout en créant une exposition synchronisée. Lorsqu'une seule vulnérabilité déclenche la même urgence partout, la question devient de savoir si l'écosystème peut prioriser la réparation sans que chaque client ne réapprenne seul la même leçon.

Le premier élément de cet écosystème est la preuve fournisseur. Atlassian devrait être évalué non seulement sur la rapidité de son avis, mais sur la clarté de l'exploitabilité, le périmètre hébergé contre auto-géré, le support des branches, la précision des mesures d'atténuation, la réactivité du support et l'assurance post-incident. Le dossier public témoigne d'une réponse d'urgence rapide après le rapport de Volexity. Il ne démontre pas publiquement un dossier détaillé de réparation de l'assurance produit. Cette lacune n'est pas une accusation. C'est la limite des preuves.

Le deuxième élément est l'inventaire client. Les clients ne peuvent pas corriger ce qu'ils ne trouvent pas. Les estimations d'exposition publique d'Unit 42 et le travail de notification du DIVD montrent que des entités externes pouvaient voir un grand nombre d'instances. Si un organisme externe à but non lucratif peut trouver un hôte vulnérable avant que le propriétaire n'agisse, le propriétaire a un problème de propriété des actifs. Plus une plateforme devient centrale pour le travail, moins il est acceptable que son propriétaire soit ambigu.

Le troisième élément est l'automatisation. La correction d'urgence ne devrait pas dépendre de la lecture de l'avis par chaque administrateur au moment idéal. Les organisations ont besoin de renseignements automatisés sur les vulnérabilités, de cartographie des actifs, d'évaluation de l'accessibilité, de vérifications de configuration, de procédures de maintenance et d'escalade vers les propriétaires métier. L'automatisation ne peut pas décider de tous les arbitrages, mais elle peut réduire le délai entre l'alerte publique et l'action qualifiée.

Le quatrième élément est la conception de la continuité. Confluence peut être un service de connaissances plutôt qu'un système de paiement, mais la perte de connaissances peut paralyser la récupération. Si les équipes ont besoin de Confluence pour savoir comment isoler Confluence, la dépendance est circulaire. Un environnement mature conserve a minima une cartographie d'urgence, une liste de contacts et un processus de récupération en dehors du système de collaboration principal.

Le cinquième élément est la transparence sur les inconnues résiduelles. Aucune source n'établit combien d'organisations uniques ont été compromises via CVE-2022-26134. Aucun document public n'établit l'état d'exploitation de chaque client. Aucun rapport public d'Atlassian n'explique entièrement pourquoi le défaut a échappé plus tôt ni comment la récurrence a été empêchée. Ces inconnues devraient être énoncées plutôt que comblées par des suppositions confiantes.

Le test du mode commun n'est donc pas « Atlassian a-t-il publié un correctif? » mais « la population des organisations dépendantes de Confluence a-t-elle pu traduire un seul avis fournisseur en une réparation vérifiée avant que la surface d'attaque partagée ne devienne un préjudice partagé? » Le bilan de 2022 montre un succès partiel et des frictions évidentes. La rapidité du fournisseur a compté. La préparation des clients a compté. Les intervenants externes ont compté. La prochaine étape de responsabilité consiste à relier leurs preuves.

Les preuves de dépendance doivent précéder l'urgence

La leçon la plus dure de Confluence est qu'une dépendance ne peut pas être gouvernée pour la première fois pendant l'exploitation. Lorsqu'un avis indique qu'un service de collaboration auto-géré est vulnérable à l'exécution de code à distance non authentifiée, l'organisation a déjà perdu la fenêtre de planification tranquille. Les bons propriétaires, inventaires, fenêtres de maintenance, états de sauvegarde et autorité d'urgence devraient exister avant l'arrivée de l'alerte. Sinon, la réponse à l'incident commence par un travail de découverte qui aurait dû être une opération ordinaire.

Un propriétaire de Confluence devrait pouvoir répondre à des questions de base sans lancer une nouvelle enquête. Quels processus métier dépendent de l'espace? L'instance est-elle Server, centres de données ou Cloud? Est-elle accessible depuis Internet? Sur quelle branche de version se trouve-t-elle? La branche est-elle prise en charge? Qui peut approuver un temps d'arrêt? Quels plugins créent un risque de compatibilité? Où sont stockées les sauvegardes? Quels journaux sont protégés en dehors de l'hôte? Quelles identités et quels jetons sont stockés ou liés depuis le service?

Si ces réponses ne sont pas prêtes, la vulnérabilité a deux rayons d'impact: le rayon technique créé par le défaut et le rayon organisationnel créé par l'incertitude.

L'avis d'Atlassian séparait à juste titre Atlassian Cloud des instances auto-gérées Confluence Server et centres de données. Cette distinction aurait dû déclencher une cartographie des dépendances chez chaque client. Les équipes utilisant Cloud devaient comprendre que la CVE spécifique ne s'appliquait pas à leur site hébergé. Les équipes utilisant Server ou centres de données devaient immédiatement prendre la propriété et agir. Dans les organisations mixtes, les deux pouvaient être vrais.

Une entreprise pouvait utiliser Atlassian Cloud de manière centrale tandis qu'une unité opérationnelle, une société acquise, un laboratoire ou un prestataire exploitait encore une ancienne instance auto-gérée. La dépendance en mode commun devient difficile à voir lorsque l'architecture officielle et la réalité du terrain diffèrent.

Les logiciels en fin de vie sont particulièrement importants. L'estimation d'Unit 42 des systèmes potentiellement affectés visibles sur Internet incluait un ensemble de versions en fin de vie. Le statut de fin de vie modifie la responsabilité, car le chemin de correction peut ne pas être direct. Un client ne peut plus supposer un support fournisseur de routine, des tests de compatibilité ou une mise à niveau de branche prise en charge. Le choix devient l'isolement d'urgence, la migration, le support étendu payant là où il est disponible, ou l'acceptation d'un risque non pris en charge.

Ce choix appartient aux propriétaires métier avant l'exploitation, pas à un administrateur à minuit.

La notification externe ne devrait pas non plus être la principale méthode de découverte des actifs. Le travail de notification du DIVD était précieux, et le scan à but d'intérêt public peut aider à réduire les dommages. Mais lorsqu'une entité externe trouve des milliers d'instances vulnérables, cette découverte révèle un problème de gouvernance plus profond: de nombreux opérateurs ne connaissaient pas suffisamment leur couche de collaboration exposée. Une organisation mature devrait être reconnaissante pour l'avertissement extérieur tout en se demandant pourquoi elle en avait besoin.

Les preuves de dépendance incluent également la connaissance des contrats et du support. Un client peut compter sur un hébergeur, un revendeur, un fournisseur de services gérés ou une équipe de plateforme interne pour exploiter Confluence. La personne qui reçoit l'avis d'Atlassian n'est peut-être pas celle qui peut appliquer le correctif. Celle qui peut appliquer le correctif n'est peut-être pas autorisée à mettre le service hors ligne. Le propriétaire métier peut ne pas comprendre pourquoi une indisponibilité du wiki est plus sûre qu'une vulnérabilité d'exécution exposée.

Une cartographie des dépendances devrait inclure ces chemins de décision. Sinon, l'avis devient un message à la recherche d'un propriétaire.

Les guides de gestion des correctifs du NIST sont utiles ici, car ils considèrent l'application de correctifs comme une capacité planifiée plutôt qu'une tâche héroïque. L'identification, la priorisation, l'acquisition, les tests, l'installation, la vérification et la gestion des exceptions nécessitent tous des données avant la crise. Une urgence Confluence comprime ces étapes, mais la compression n'est pas l'élimination. La seule façon d'agir rapidement sans changement imprudent est d'avoir déjà répété à quoi ressemble un changement rapide pour ce service.

Le prisme du mode commun change également la façon dont les organisations envisagent la communication. Si Confluence contient le manuel de réponse aux incidents, les listes de contacts d'urgence, les schémas d'architecture et les notes de support fournisseur, alors la restriction de cette même plateforme peut supprimer les instructions nécessaires pour la restreindre. Une équipe résiliente conserve un dossier de réponse minimal en dehors de la plateforme de collaboration: propriétaires, versions actuelles, chemins réseau, emplacements des sauvegardes, informations d'identification d'urgence, procédures clés et contacts externes.

Ce dossier n'est pas prestigieux. C'est la différence entre une plateforme de connaissance et un piège de connaissance.

L'artefact de responsabilité est un dossier de clôture

Après une vulnérabilité comme CVE-2022-26134, l'artefact le plus utile est un dossier de clôture. Ce n'est pas un communiqué de presse, ni une capture d'écran d'une version corrigée, ni une déclaration vague indiquant que le système a été corrigé. C'est une explication structurée de la manière dont l'organisation est passée de l'avis à un service digne de confiance. Le dossier doit être suffisamment précis pour qu'un propriétaire métier, un auditeur, un assureur ou une fonction de supervision du secteur public puisse comprendre ce qui a été fait et ce qui reste incertain.

Le dossier de clôture commence par le périmètre. Il liste chaque instance Confluence considérée, y compris la production, le staging, le développement, les systèmes mis hors service mais accessibles, les systèmes de sociétés acquises, les arrangements hébergés et les versions non prises en charge. Il indique lesquelles étaient Atlassian Cloud et donc hors du périmètre produit de cette CVE, et lesquelles étaient Server ou centres de données. Il précise lesquelles étaient exposées à Internet et lesquelles étaient internes. Il indique le propriétaire de chaque instance.

Le périmètre n'est ennuyeux que jusqu'au moment où une instance sans propriétaire devient la brèche.

La deuxième partie est l'action. Pour chaque instance concernée, le dossier doit indiquer si elle a été arrêtée, bloquée d'Internet, mise à niveau vers une version corrigée, atténuée via les instructions provisoires d'Atlassian, mise hors service ou migrée. Il doit préciser le calendrier: quand l'avis a été reçu, quand l'accès a été modifié, quand la version corrigée a été installée, quand la vérification s'est terminée et quand les utilisateurs ont été autorisés à revenir. Il doit également enregistrer pourquoi une exception a été acceptée et qui l'a acceptée.

L'acceptation par la direction des exceptions de mise à jour est importante, car le risque n'est plus purement technique une fois que l'exploitation active est publique.

La troisième partie est la préservation des preuves. Si l'exploitation était active avant la divulgation, une organisation doit supposer que les journaux, la mémoire, les fichiers et les informations d'identification connectées peuvent avoir de l'importance. Le dossier de clôture doit indiquer quelles preuves ont été préservées avant le redémarrage ou la mise à niveau, quels journaux étaient disponibles, si des images hôte ou des captures de mémoire ont été réalisées lorsque cela était approprié, et quelles preuves n'ont pas pu être récupérées.

Cela ne signifie pas que chaque petite organisation doit mener une enquête médico-légale sophistiquée. Cela signifie que l'organisation doit connaître la différence entre « nous avons cherché et n'avons trouvé aucune preuve » et « nous n'avions pas de preuves à examiner ».

La quatrième partie est l'évaluation de la compromission. Le rapport de Volexity a montré que l'exploitation pouvait impliquer des shells web, des implants en mémoire, un accès au stockage de contenu et une altération des journaux. Sophos, GreyNoise, Talos et Unit 42 ont montré que l'exploitation ultérieure pouvait inclure plusieurs familles de charges utiles.

Un dossier de clôture doit donc documenter les vérifications effectuées: examen du système de fichiers à la recherche de chemins de shells web connus, vérification des processus et de la persistance, journaux applicatifs, indicateurs de reverse shell, utilisateurs inattendus, connexions sortantes, accès au stockage de contenu, exposition des informations d'identification et alertes des terminaux. Il doit également indiquer si une aide spécialisée a été utilisée ou pourquoi elle ne l'a pas été.

La cinquième partie est l'examen des systèmes connectés. Confluence est rarement isolé. Il peut s'intégrer à des fournisseurs d'identité, des systèmes de code source, des plateformes de tickets, des outils CI/CD, de messagerie, des espaces de stockage de documents et des dépôts de contenu structuré. Si l'hôte Confluence a été compromis, les informations d'identification utilisées par ces intégrations peuvent nécessiter une rotation ou un examen. Un dossier de correction étroit qui ignore les informations d'identification connectées peut laisser à l'attaquant un chemin qui survit à la vulnérabilité d'origine.

La clôture doit donc inclure les comptes de service, les jetons d'API, les mots de passe de stockage de contenu et les sessions administratives.

La sixième partie est la restauration métier. Les utilisateurs ne doivent pas revenir sur la plateforme simplement parce qu'un processus serveur est en cours d'exécution. Ils ont besoin de savoir si le contenu est intact, si les modifications effectuées pendant la fenêtre de réponse ont été préservées, si les pièces jointes sont disponibles, si la recherche fonctionne, si les notifications sont fiables et si des pages ou des espaces sont restreints en attente d'examen. Si la plateforme contient des procédures opérationnelles, l'intégrité du contenu compte autant que la disponibilité.

La septième partie est l'apprentissage. Le dossier de clôture doit identifier pourquoi l'instance était exposée, pourquoi elle se trouvait sur sa branche de version, si les canaux d'alerte ont atteint les bonnes personnes, si l'approbation du temps d'arrêt a été lente, si les sauvegardes ont été testées, si les journaux étaient adéquats et si les manuels d'urgence se trouvaient en dehors de Confluence. C'est là que la responsabilité passe du blâme à l'amélioration du contrôle. L'objectif n'est pas de punir la personne qui a appliqué le correctif. C'est de rendre le prochain avis en mode commun moins chaotique.

Le rôle d'Atlassian dans une telle clôture est de fournir les faits spécifiques au produit dont les clients ont besoin: plages affectées, branches corrigées, validité de l'atténuation, notes d'exploitabilité, périmètre cloud, contraintes de mise à niveau et précautions post-exploitation. Le rôle des clients est de transformer ces faits en preuves locales. Les agences publiques et les intervenants externes peuvent aider en priorisant, en observant et en publiant le contexte de détection. Aucun de ces acteurs ne peut remplacer complètement les autres. Le dossier de clôture est le lieu où leurs preuves se rencontrent.

Les vulnérabilités Confluence répétées devraient changer la question au conseil

CVE-2022-26134 n'est pas la seule vulnérabilité critique de Confluence dans la mémoire publique. Le schéma plus large de corrections d'urgence répétées de Confluence devrait faire évoluer la question au niveau du conseil, de « avons-nous corrigé cette CVE? » à « pourquoi cette couche de collaboration nécessite-t-elle à plusieurs reprises des actions d'urgence, et comment limitons-nous les conséquences métier lorsqu'elle le fait? » Un conseil n'a pas besoin de connaître tous les détails d'OGNL. Il a besoin de savoir si l'organisation est structurellement prête pour le prochain avis Confluence.

Cette préparation a un coût. Maintenir Confluence à jour peut nécessiter des temps d'arrêt, un examen des plugins, une communication utilisateur, des tests et des frictions métier occasionnelles. Restreindre l'accès Internet peut nécessiter un VPN, un accès zero-trust ou des changements dans les flux de travail des partenaires. La conservation des journaux et des sauvegardes protégées coûte du stockage et du temps de personnel. La mise hors service d'instances non prises en charge peut nécessiter un travail de migration. Ces coûts sont souvent visibles avant un incident, tandis que la brèche évitée est invisible.

La responsabilité consiste à rendre le risque évité suffisamment visible pour que les dirigeants ne traitent pas la maintenance comme un entretien ménager facultatif.

La dimension de verrouillage est également réelle. Les espaces Confluence peuvent accumuler des années de mémoire institutionnelle. La migration est difficile, car les pages, les autorisations, les pièces jointes, les liens, les macros et les intégrations s'intègrent profondément dans le travail. Cette adhérence peut rendre les décisions de mise à niveau d'urgence plus difficiles. Un plugin fragile ou un ancien thème peut maintenir une organisation sur une branche vulnérable, car la migration semble trop perturbatrice. La commodité métier de rester en place devient une exposition de sécurité.

Un processus de gouvernance mature nomme cet arbitrage au lieu de le laisser enfoui dans un arriéré de tickets.

Pour les clients du secteur public et réglementés, la question au conseil devrait inclure la continuité. Si Confluence héberge des plans d'urgence, des interprétations de politiques, des notes de cas, une documentation d'infrastructure ou des procédures de service, alors une fermeture pour raisons de sécurité peut affecter le travail public. Le propriétaire doit savoir quelles informations doivent être disponibles en dehors de Confluence lors d'un événement de sécurité. Il ne s'agit pas seulement d'hygiène cyber. C'est la continuité de la mémoire institutionnelle.

Il est probable que le test de dépendance en mode commun se reproduise, car les plateformes de collaboration largement utilisées concentrent la connaissance. La leçon du dossier Atlassian de 2022 n'est pas que les clients devraient se méfier de la plateforme. C'est que la confiance devrait être limitée sur le plan opérationnel. Les clients devraient pouvoir corriger rapidement, isoler plus vite encore, enquêter honnêtement et garder la connaissance essentielle accessible même lorsque la plateforme est suspecte. Le fournisseur devrait faciliter ce travail avec des avis précis, opportuns et techniquement francs.

L'écosystème devrait mesurer le succès par la clôture vérifiée, et non par le moment où une version corrigée apparaît.

Il y a aussi une leçon en matière d'approvisionnement. Les acheteurs demandent souvent si un produit de collaboration prend en charge l'authentification, les sauvegardes, les canaux de support et la haute disponibilité. Ils devraient également demander comment les consignes de sécurité d'urgence atteignent les opérateurs, à quelle vitesse les branches prises en charge reçoivent les correctifs, ce qui se passe lorsqu'une version corrigée ne peut pas être atteinte par une mise à niveau progressive et quelles preuves les clients doivent conserver avant de redémarrer une instance suspecte.

Ces questions ne rendent pas l'acheteur responsable du code du fournisseur. Elles le rendent responsable de savoir comment un outil partagé sera gouverné à la prochaine urgence.

Note typographique

La typographie est l'art et la technique d'agencer les caractères pour rendre le langage écrit lisible, compréhensible et esthétiquement agréable. Elle implique le choix des polices, des tailles de points, des longueurs de ligne, de l'interlignage et de l'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés comprennent le choix de la police, le crénage, le suivi et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Ce qui devrait être mesuré ensuite

Un tableau de bord post-incident utile mesurerait le délai de prise de conscience client, le délai de confirmation de l'inventaire, le délai d'isolement pour les systèmes exposés à Internet, le délai pour atteindre une version corrigée prise en charge, le délai de confiance médico-légale et le délai de restauration du service métier. Ce sont des horloges différentes. Les combiner en une seule métrique de correctif donne l'illusion d'un écosystème plus maîtrisé qu'il ne l'est.

Pour Atlassian, les preuves publiques durables comprendraient le dossier des avis, les améliorations du support client, les changements de développement sécurisé, l'analyse des variantes et la manière dont les équipes produit réduisent la probabilité qu'un chemin d'évaluation d'expression non authentifié puisse se reproduire. Pour les clients, les preuves durables comprendraient les listes de propriétaires, les journaux protégés, les manuels d'urgence, les sauvegardes testées, les procédures de rotation des informations d'identification et l'approbation métier pour mettre hors ligne les systèmes de collaboration en cas d'exploitation active.

Pour les agences publiques, les preuves durables comprendraient une priorisation contraignante, le cas échéant, et des conseils clairs pour les organisations non fédérales confrontées au même risque sans la même autorité.

L'incident Confluence enseigne finalement que les logiciels de collaboration peuvent devenir une infrastructure. Une fois ce stade atteint, une vulnérabilité critique n'est plus seulement un événement de maintenance produit. C'est un test pour savoir si la connaissance, la continuité et les preuves de sécurité sont suffisamment bien réparties pour qu'une seule faille n'oblige pas chaque organisation dépendante à improviser en même temps.