Résumé

  • CVE-2022-26134 était une vulnérabilité critique d'injection OGNL dans Confluence Server et centres de données auto-gérés. Elle permettait à un attaquant distant non authentifié d'exécuter du code arbitraire. Atlassian Cloud n'était pas affecté. Volexity a signalé le zero-day à Atlassian le 31 mai 2022 après avoir enquêté sur une exploitation pendant le week-end du Memorial Day américain. Atlassian a publié son avis le 2 juin et a listé les versions corrigées le 3 juin.
  • Cette réponse rapide du fournisseur n'a pas mis fin à l'exposition des clients. CISA a ajouté la vulnérabilité à son catalogue de vulnérabilités exploitées connues le 2 juin et a exigé que les agences fédérales américaines bloquent immédiatement le trafic Internet et mettent à jour ou suppriment les produits concernés d'ici le 6 juin. Les mesures Internet et les rapports des intervenants ont ensuite montré un balayage généralisé, plusieurs types de charges utiles, des tentatives de ransomware, du cryptomining, des activités de robots, des implants en mémoire et des shells web.
  • La charge opérationnelle était asymétrique. Atlassian pouvait produire centralement des correctifs, mais chaque client devait identifier toutes les instances et nœuds, confirmer les versions, restreindre l'accès, sauvegarder les données, tester le changement, accepter un arrêt d'urgence, appliquer le correctif ou l'atténuation intermédiaire, le valider et rétablir le service.
  • Le correctif était nécessaire mais pas suffisant. Volexity a observé un implant en mémoire uniquement, des shells web sur disque, un accès à la base de données et des tentatives de modification des journaux.
  • La responsabilité devrait suivre la capacité de contrôle. Atlassian contrôlait le développement sécurisé, l'enquête sur la vulnérabilité, les correctifs rétroportés, la qualité des versions, l'avis et les conseils de détection spécifiques au produit. Les clients contrôlaient l'inventaire des actifs, l'exposition publique, les privilèges d'exploitation, les limites du réseau, la journalisation, la sauvegarde, l'exécution des changements, la réponse aux incidents et la continuité.
  • La leçon durable est de mesurer le temps nécessaire pour obtenir un service digne de confiance, pas seulement le temps nécessaire pour obtenir un correctif.

Une vulnérabilité, quatre horloges

La chronologie conventionnelle des vulnérabilités a deux points de terminaison: la divulgation et le correctif. Cela est utile pour mesurer la réponse d'un fournisseur, mais cela compresse le travail du client en un instant imaginaire. CVE-2022-26134 rend le temps manquant visible.

La première horloge était l'horloge du fournisseur. Elle a commencé lorsqu'Atlassian a reçu suffisamment d'informations pour reproduire et évaluer le défaut. Volexity dit avoir contacté Atlassian le 31 mai. L' avis de sécurité d'Atlassian enregistre une publication le 2 juin à 13h00 Pacific et une mise à jour le 3 juin à 10h00 ajoutant sept versions corrigées. Sur la base des preuves publiques, Atlassian a confirmé une vulnérabilité critique activement exploitée, attribué un CVE, communiqué le risque, préparé des rétroports dans les branches supportées et publié rapidement des corrections.

La seconde était l'horloge de confinement et de changement. Elle a commencé séparément chez chaque client. Un avertissement devait atteindre une personne ayant autorité pour agir. Cette personne avait besoin d'un inventaire des déploiements Confluence, des nœuds, des versions, des routes externes, des propriétaires, des dépendances et du statut de support. Chaque instance affectée devait ensuite être déconnectée, restreinte, mise à niveau, atténuée ou supprimée. L'horloge ne s'arrêtait pas parce qu'un correctif devenait disponible;

elle ne s'arrêtait que lorsque le client pouvait démontrer qu'aucune instance vulnérable n'était plus accessible.

La troisième était l'horloge médico-légale. L'exploitation active a précédé la divulgation publique. Les clients devaient donc se demander si des attaquants les avaient atteints avant le correctif. Cette enquête dépendait des preuves conservées: journaux web, système d'exploitation, endpoint, identité, réseau et application. Elle pouvait s'étendre à l'acquisition de mémoire, à la comparaison du système de fichiers, à l'examen des identifiants et à l'inspection des systèmes connectés. Un correctif modifiait l'exploitabilité future. Il ne pouvait pas réécrire la période antérieure à l'installation.

La quatrième était l'horloge de continuité. Confluence contient généralement des procédures opérationnelles, des enregistrements de projet, des connaissances internes, des manuels d'incident et un historique des décisions. Le restreindre ou l'arrêter pouvait nuire au travail même sans destruction de données. La restauration nécessitait plus que le redémarrage d'un service: les utilisateurs devaient avoir confiance dans la disponibilité, l'intégrité et la sécurité de la plateforme. Si le wiki contenait les instructions nécessaires pour récupérer le wiki, une réponse de sécurité pouvait exposer une dépendance circulaire.

Ces horloges répartissent différentes responsabilités. Un fournisseur peut raccourcir le temps nécessaire pour obtenir un correctif applicable pour tout le monde. Il ne peut pas inventorier l'instance fantôme d'un client, planifier sa maintenance, préserver ses journaux ou décider quel processus métier peut tolérer une interruption. Un client peut isoler et renforcer son déploiement. Il ne peut pas inspecter le dossier de développement privé du fournisseur ni créer indépendamment un correctif supporté à la même vitesse. La responsabilité devient plus claire lorsque chaque partie est évaluée par rapport à l'horloge qu'elle peut contrôler.