Microsoft Exchange a fait du déploiement de correctifs d'urgence un test de responsabilité de réparation à long terme

Résumé

• ProxyLogon est devenu un test de responsabilité de réparation à long terme car Microsoft a pu publier rapidement des correctifs d'urgence, mais seuls les propriétaires de serveurs pouvaient prouver que les instances exposées d'Exchange Server avaient été découvertes, mises à jour, examinées, nettoyées et surveillées après l'exploitation.
• La ressource MSRC de Microsoft,Plusieurs mises à jour de sécurité publiées pour Exchange Server, et l'article de sécurité MicrosoftHAFNIUM ciblant les serveurs Exchangeancrent l'avis du fournisseur et l'enregistrement d'attribution initial.
• La directive d'urgence 21-02 de la CISA,Directive d'urgence 21-02, l'alerte de mars 2021 de la CISA,Alerte de mars 2021, et l'avis AA21-062A,AA21-062A, montrent pourquoi il s'agissait d'un problème de continuité du secteur public, et non seulement d'un événement de support produit.
• Les quatre enregistrements de vulnérabilité,CVE-2021-26855,CVE-2021-26857,CVE-2021-26858etCVE-2021-27065, expliquent pourquoi les défenseurs ont dû traiter la chaîne à la fois comme un risque d'entrée et de persistance.
• L'opération de retrait de web shell autorisée par le tribunal du DOJ,Opération de retrait de web shell, a démontré le risque résiduel inhabituel: l'action gouvernementale a retiré des web shells malveillants sélectionnés de certains serveurs, mais la correction, l'enquête, la vérification des identifiants et le nettoyage plus large incombaient toujours aux propriétaires de serveurs.

Les correctifs d'urgence ne créent pas une réparation instantanée

L'urgence d'Exchange Server a commencé par une promesse familière: installer la mise à jour. L'article MSRC de Microsoft, Plusieurs mises à jour de sécurité publiées pour Exchange Server, demandait aux clients de corriger les versions sur site affectées d'Exchange Server. L'article de sécurité de Microsoft, HAFNIUM ciblant les serveurs Exchange, décrivait l'exploitation d'Exchange Server sur site, listait CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 et CVE-2021-27065, et indiquait qu'Exchange Online n'était pas concerné. C'étaient des communications urgentes et nécessaires du fournisseur.

Mais le problème de responsabilité a commencé au moment où les correctifs ont été expédiés. La disponibilité des correctifs est une action du fournisseur. La réparation est un résultat de l'écosystème. Pour un Exchange Server sur site, le propriétaire doit savoir que le serveur existe, qu'il est exposé, connaître la version, installer les mises à jour cumulatives prérequises si nécessaire, appliquer la mise à jour de sécurité, vérifier l'exploitation, supprimer les artefacts, examiner l'exposition des courriels et des identifiants, surveiller la persistance et communiquer le risque.

Ce processus peut s'étendre bien au-delà de la date de publication.

ProxyLogon n'est donc pas seulement une histoire de divulgation de vulnérabilité. C'est une histoire de réparation à long terme. Les serveurs de messagerie sur site sont souvent anciens, critiques pour l'activité, personnalisés et exploités par des organisations aux effectifs de sécurité inégaux. Les agences publiques, les écoles, les petites entreprises, les associations, les municipalités et les clients de services gérés peuvent dépendre d'Exchange tout en manquant de capacité de réponse rapide aux incidents. Un correctif d'urgence dans un tel environnement n'est pas un bouton. C'est une campagne opérationnelle.

L'article de l'équipe Exchange de Microsoft, Publié: mises à jour de sécurité de mars 2021 pour Exchange Server, fournissait le contexte d'installation pour les versions prises en charge et les états de mise à jour cumulative. Ce contexte compte car certaines organisations n'étaient pas à une simple mise à jour de la sécurité. Elles devaient d'abord comprendre l'état de maintenance. Plus le chemin de mise à jour est compliqué, plus les serveurs vulnérables risquent de rester exposés pendant la fenêtre critique.

La leçon n'est pas que Microsoft seul pouvait corriger chaque serveur. Ce n'était pas possible. La leçon est qu'un fournisseur avec un produit sur site largement déployé a la responsabilité de rendre la réparation d'urgence réalisable: chemins de mise à jour clairs, atténuations, scripts de détection, guides pour les intervenants, communication client et modifications ultérieures du produit réduisant la probabilité que des serveurs à long terme non corrigés restent invisibles.

ProxyLogon a combiné entrée, exécution de code et persistance

La chaîne de vulnérabilités était dangereuse car elle pouvait passer de l'accès initial à l'exécution de code et à l'écriture de fichiers. Les enregistrements NVD de NIST pour CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 et CVE-2021-27065 documentent la famille de vulnérabilités dans des enregistrements publics. Le guide pour les intervenants de Microsoft, Guide pour les intervenants enquêtant sur les vulnérabilités d'Exchange Server sur site et y remédiant, expliquait comment les vulnérabilités pouvaient être chaînées, comment les web shells étaient implantés et pourquoi les intervenants devaient enquêter au-delà de la correction.

Ce dernier point est le centre de l'enregistrement de responsabilité. Une fois qu'un web shell existe, corriger la vulnérabilité ne supprime pas le web shell. Une fois qu'un attaquant a lu des courriels ou mis en place des outils, la correction n'identifie pas ce qui a été volé. Une fois que les identifiants ont pu être exposés, la correction ne les remplace pas. Une fois qu'un serveur a été utilisé comme point d'appui, la correction ne prouve pas que le reste de l'environnement est propre.

C'est pourquoi les conseils d'atténuation d'urgence sont importants. La page MSRC de Microsoft sur Atténuations des vulnérabilités d'Exchange Server fournissait des ressources de détection et d'atténuation. L'avis PDF de la NSA, Atténuez les vulnérabilités d'Exchange Server, fournissait des conseils techniques fédéraux. L'avis AA21-062A de la CISA, AA21-062A, fournissait des instructions d'atténuation, de détection et de remédiation. Ces enregistrements montrent la séquence attendue: corriger, enquêter, nettoyer, surveiller.

Les rapports des sociétés de sécurité ont ajouté des observations pratiques. Le rapport d'exploitation active de Volexity, Rapport d'exploitation active, décrivait l'exploitation et l'activité de web shell observées avant la publication publique du correctif. L'analyse des vulnérabilités d'Exchange Server de Palo Alto Networks Unit 42, Analyse des vulnérabilités, et l'article de Tenable, Article sur les vulnérabilités, ont aidé les défenseurs à comprendre la chaîne. Le contexte plus ancien de Mandiant sur China Chopper toujours actif aide à expliquer pourquoi la persistance des web shells a une longue traîne.

Ce ne sont pas des enregistrements universels de victimes, mais ils soutiennent le problème pratique de réponse.

La question de responsabilité de réparation est simple: après la mise à jour, chaque organisation pouvait-elle prouver qu'il n'y avait pas de web shell restant, pas de persistance active, pas de chemin d'identifiants exposés, pas d'accès à la boîte aux lettres non examiné? Si non, le serveur était corrigé mais pas complètement réparé.

Les agences publiques ont dû agir plus rapidement que les procédures d'achat normales

La directive d'urgence 21-02 de la CISA, Atténuez les vulnérabilités des produits Exchange sur site, exigeait que les agences fédérales du pouvoir exécutif civil identifient les systèmes affectés, les déconnectent ou les mettent à jour immédiatement et rendent compte de l'état. L'alerte du 3 mars de la CISA, Alerte du 3 mars, annonçait la directive et mettait en garde contre les vulnérabilités. Cette action fédérale montre à quelle vitesse l'incident Exchange est devenu un problème de continuité du secteur public.

Le courrier électronique gouvernemental n'est pas une application générique. Il transporte les communications des citoyens, les travaux politiques, les enquêtes, les achats, la coordination de la santé publique, l'administration scolaire et la gestion des urgences. Si un serveur Exchange sur site est compromis, le préjudice peut inclure la confidentialité, la confiance opérationnelle et la continuité. Les agences ne peuvent pas simplement attendre les fenêtres de maintenance normales lorsque des web shells peuvent déjà être présents.

Les directives d'urgence révèlent également la charge opérationnelle de l'inventaire. Pour s'y conformer, les agences devaient savoir où se trouvaient les serveurs Exchange. Les services informatiques parallèles, les environnements hérités, les instances de test et les serveurs oubliés deviennent des passifs en de tels moments. La première question n'est pas « pouvons-nous corriger? » mais « connaissons-nous chaque système nécessitant une correction? » La responsabilité du secteur public dépend de la mise à jour de cet inventaire avant l'urgence.

L'entrée du catalogue des vulnérabilités connues exploitées de la CISA pour CVE-2021-26855, Catalogue KEV, a ensuite intégré la vulnérabilité dans une discipline de remédiation fédérale plus large. Le traitement KEV aide à réduire la probabilité que les agences traitent les vulnérabilités exploitées comme un arriéré ordinaire. Mais le catalogue ne peut pas nettoyer un serveur. Il fixe l'urgence. Les agences ont encore besoin de capacité opérationnelle.

La leçon pour le secteur public est plus large que les agences fédérales. Les gouvernements des États et locaux, les écoles, les organismes de santé publique et les entrepreneurs publics exécutent souvent des courriels sur site plus anciens. Ils peuvent avoir des équipes plus petites et des achats plus lents. Un correctif d'urgence Exchange peut exposer des lacunes dans la gestion des actifs, la journalisation, les contrats de réponse aux incidents, les contrats de services gérés et les procédures de sauvegarde. ProxyLogon a transformé ces lacunes en questions de risque public.

Note typographique

Le retrait de web shell par le FBI a montré à quel point le résidu était inhabituel

La preuve publique la plus frappante du risque à long terme a été l'annonce par le Département de la Justice en avril 2021 d'un effort autorisé par le tribunal pour perturber l'exploitation d'Exchange Server, publiée comme Le DOJ annonce un effort autorisé par le tribunal. L'annonce indiquait que le FBI avait copié et retiré des web shells de centaines d'ordinateurs vulnérables aux États-Unis. La notification de l'industrie privée du FBI, Notification de l'industrie privée, décrivait l'opération et les conseils continus.

Cette opération doit être interprétée de manière étroite et sérieuse. Elle n'a pas corrigé les serveurs. Elle n'a pas supprimé tous les artefacts possibles. Elle n'a pas décidé que les environnements étaient propres. Elle a retiré des web shells sélectionnés dans le cadre d'une opération autorisée par le tribunal sur certains systèmes. Cette limitation est précisément pourquoi l'opération compte. Le résidu de l'exploitation était suffisamment grave pour que les forces de l'ordre cherchent l'autorisation de retirer des artefacts de systèmes privés, tout en laissant aux propriétaires le reste de la charge de réparation.

L'action a révélé une réalité douloureuse: certains propriétaires de serveurs n'avaient pas retiré eux-mêmes les web shells. Ils ignoraient peut-être qu'ils étaient compromis. Ils manquaient peut-être de compétences, d'outils, de temps ou de conscience. Ils avaient peut-être corrigé mais pas nettoyé. Ils étaient peut-être de petites organisations sans équipe de réponse aux incidents. Le résidu de web shell a transformé une urgence logicielle en une action gouvernementale de perturbation inhabituelle.

Pour la responsabilité, l'opération du DOJ fait deux points à la fois. Premièrement, les autorités publiques interviennent parfois lorsque l'échec du nettoyage privé crée un risque continu. Deuxièmement, cette intervention n'absout pas les propriétaires de serveurs ni l'écosystème des fournisseurs de construire de meilleures voies de réparation. La nécessité d'une telle opération suggère que les conseils de correction, les outils d'atténuation, la notification et le support des services gérés n'ont pas atteint chaque environnement vulnérable assez rapidement.

La norme de réparation à long terme devrait inclure la preuve que la correction et le retrait des artefacts sont liés. Un propriétaire de serveur ne devrait pas pouvoir marquer l'incident comme clos après l'installation d'une mise à jour si les chemins de web shell connus n'ont pas été vérifiés. Un fournisseur de services gérés ne devrait pas traiter les environnements clients comme corrigés à moins que l'évaluation de la compromission ne soit également traitée. Un fournisseur devrait concevoir des conseils d'urgence de sorte que la différence entre correction et nettoyage soit indubitable.

Les petites organisations ont hérité d'exigences de réponse de niveau entreprise

ProxyLogon a été particulièrement difficile pour les petites et moyennes organisations car Exchange Server peut être critique pour la mission sans être doté en personnel professionnel à l'échelle de l'entreprise. Un petit cabinet d'avocats, un bureau gouvernemental local, une école, une clinique, un fabricant ou une association peut dépendre d'Exchange sur site parce qu'il a été installé des années plus tôt, intégré aux flux de travail ou géré par un petit fournisseur informatique. Lorsqu'une exploitation d'urgence frappe, cette organisation a soudainement besoin d'une réponse de niveau entreprise.

Elle doit identifier le serveur, déterminer l'exposition, appliquer les mises à jour, exécuter des scripts de détection, examiner les journaux IIS, inspecter les fichiers suspects, évaluer l'accès à la boîte aux lettres, faire pivoter les identifiants, surveiller la persistance, communiquer avec les utilisateurs et peut-être engager une aide extérieure. C'est une charge de travail importante pour une petite équipe. Le sujet de l'automatisation de la sécurité compte ici car les outils et les scripts peuvent réduire la charge manuelle, mais seulement s'ils sont clairs, sûrs et accessibles.

Les conseils d'atténuation et d'intervention de Microsoft ont tenté de fournir de tels outils. L'article de mise à jour trimestrielle de l'équipe Exchange, Publié: mises à jour trimestrielles d'Exchange de mars 2021, pointait également vers le contexte de maintenance plus large. Plus tard, Microsoft a introduit le service d'atténuation d'urgence Exchange dans un article intitulé Nouvelle fonctionnalité de sécurité dans la mise à jour cumulative de septembre 2021 pour Exchange Server.

Cette fonctionnalité ultérieure compte car elle montre une réponse au niveau du produit au problème à long terme: les atténuations intégrées peuvent faire gagner du temps lorsque la correction immédiate est difficile.

L'atténuation d'urgence ne remplace pas la correction, et une fonctionnalité ultérieure ne prouve pas que chaque environnement de 2021 a été réparé. Mais elle reconnaît la réalité. Certains opérateurs Exchange ne corrigeront pas instantanément. Certains manqueront les avis. Certains auront des versions non prises en charge. Certains auront besoin de temps pour installer les mises à jour cumulatives. Un produit avec une longue traîne sur site a besoin de mécanismes qui réduisent les dommages pendant que les clients rattrapent leur retard.

La responsabilité des petites organisations est partagée. L'opérateur ne devrait pas faire fonctionner indéfiniment des serveurs de messagerie exposés non pris en charge. Les fournisseurs de services gérés devraient inventorier et corriger rapidement les serveurs clients. Les fournisseurs devraient rendre les conseils d'urgence compréhensibles pour les non-spécialistes. Les agences publiques devraient fournir des alertes claires. Les assureurs et les auditeurs devraient exiger des preuves que les services à haut risque exposés à Internet sont connus et couverts par les plans de réponse aux incidents.

ProxyLogon a montré qu'aucun acteur ne peut porter seul la longue traîne.

Les données de scan ont aidé à trouver l'exposition, mais l'exposition n'est pas une compromission

La mesure de l'exposition est devenue une partie majeure de la réponse. Le projet de Shadowserver sur les Vulnérabilités d'Exchange Server a fourni un contexte de scan et d'exposition aux vulnérabilités. De tels projets aident les défenseurs et les agences publiques à voir la longue traîne du risque exposé à Internet. Ils peuvent montrer si les populations exposées diminuent après les correctifs et les avis.

Mais l'exposition n'est pas la même chose que la compromission. Un scan peut suggérer qu'un serveur Exchange est joignable ou a un certain profil de réponse. Il ne peut pas toujours prouver la version exacte, l'exploitation réussie, la présence de web shell, le vol de données ou le nettoyage. Inversement, un serveur peut être corrigé après compromission et nécessiter encore une enquête. La carte d'exposition est un outil de triage, pas un enregistrement final.

Cette distinction compte pour la communication publique. Les gros titres sur des milliers de serveurs exposés ou vulnérables peuvent mobiliser l'action, mais ils peuvent aussi brouiller les catégories. Les propriétaires de serveurs doivent savoir s'ils sont exposés, vulnérables, exploités, corrigés, nettoyés ou surveillés. Chaque état implique une action différente. Un inventaire propre devrait suivre ces états séparément.

Les messages du gouvernement et des fournisseurs devraient renforcer cela. « Appliquer la mise à jour » n'est qu'une action. « Exécuter les étapes de détection et de remédiation » en est une autre. « Supposer une compromission si exposé pendant la fenêtre » peut être approprié dans certains contextes, mais même cette hypothèse doit se traduire par une enquête concrète. Le problème à long terme est en partie un problème de classification: trop d'organisations marquent un serveur comme sûr parce qu'une tâche est terminée.

L'enregistrement de réparation devrait donc inclure des preuves de transition d'état. Quand le serveur a-t-il été découvert? Quand a-t-il été isolé ou mis à jour? Des indicateurs ont-ils été trouvés? Des web shells ont-ils été retirés? Les identifiants ont-ils été remplacés? L'accès aux courriels a-t-il été évalué? La surveillance a-t-elle été renforcée? Qui a vérifié la clôture? Sans ces horodatages, l'organisation a un événement de correction, pas un enregistrement d'incident.

Les serveurs de messagerie sont à la fois des systèmes de continuité et de confidentialité

Exchange Server est à la fois une plateforme de communication et un référentiel d'historique sensible. Un serveur de messagerie compromis peut exposer des messages, des pièces jointes, des contacts, des calendriers, des discussions juridiques, des dossiers d'achat, la correspondance des agences publiques, des identifiants envoyés par courriel, des flux de réinitialisation de mot de passe et des plans d'affaires internes. Il peut également affecter la continuité car le courriel est la façon dont les organisations coordonnent le travail, la réponse aux incidents, les fournisseurs, les clients et les communications publiques.

Ce double rôle rend la réparation plus compliquée. Si un serveur de fichiers est compromis, une organisation peut se concentrer sur les fichiers. Si un serveur de messagerie est compromis, l'organisation doit se demander quelles boîtes aux lettres ont été accédées, quels messages contenaient des identifiants ou des données sensibles, quels contacts externes ont été affectés et si les attaquants ont pu utiliser le serveur pour envoyer des courriels ou pivoter. Le serveur est à la fois une archive et un canal de contrôle en direct.

Les conseils d'intervention de Microsoft et l'avis de la CISA ont reconnu cela en se concentrant sur l'enquête et la remédiation, pas seulement sur la correction. L'opération du FBI reflétait également le problème de persistance. Un web shell sur un serveur de messagerie est un chemin d'accès continu. Même après correction, il peut être utilisé s'il n'est pas retiré. Même après retrait, l'organisation doit se demander ce que l'attaquant a fait avant le retrait.

Pour la continuité du secteur public, le rôle du courriel est encore plus marqué. Les agences utilisent le courriel pour coordonner les services, la réponse d'urgence, les contrats, les prestations, les écoles, les tribunaux et la santé. Si le système de messagerie est suspect, le travail ordinaire ralentit. Le personnel peut déplacer les conversations vers d'autres canaux, mais cela peut créer des problèmes de gestion des dossiers et de sécurité. Un serveur de messagerie compromis peut donc produire des coûts de gouvernance immédiats et différés.

L'enregistrement de réparation responsable devrait inclure la confidentialité et la continuité. L'organisation a-t-elle rétabli une utilisation sûre du courriel? A-t-elle identifié les boîtes aux lettres potentiellement exposées? A-t-elle préservé les preuves? A-t-elle notifié les personnes concernées lorsque requis? A-t-elle réinitialisé les identifiants qui ont pu transiter par le courriel? A-t-elle surveillé l'usurpation ou le mouvement latéral? A-t-elle mis à jour les plans de continuité pour que la prochaine urgence de courriel ait un canal alternatif?

La réparation par le fournisseur s'est poursuivie après mars

Les travaux ultérieurs d'Exchange de Microsoft comptent car ProxyLogon a exposé un problème de maintenance du produit qui ne s'est pas terminé en mars 2021. Le service d'atténuation d'urgence Exchange, décrit dans L'article de Microsoft sur la mise à jour cumulative de septembre 2021, a été conçu pour appliquer automatiquement des atténuations temporaires sous certaines conditions. La mise à jour ultérieure de la feuille de route d'Exchange, Mise à jour de la feuille de route d'Exchange Server, a continué à discuter de la direction de maintenance.

Ces sources ultérieures ne doivent pas être traitées comme une preuve que chaque compromission ProxyLogon a été nettoyée. Ce sont des preuves de gouvernance du produit. Elles montrent que Microsoft a reconnu le besoin d'une protection plus automatisée dans la base installée sur site. Cette reconnaissance est importante car les produits sur site vieillissent de manière inégale. Les clients retardent les mises à jour cumulatives. Certains environnements sont isolés de la gestion moderne. D'autres sont exposés mais mal surveillés. Les fonctionnalités d'atténuation d'urgence peuvent réduire le risque pendant le décalage.

Néanmoins, l'atténuation automatisée a des limites. Elle peut nécessiter une mise à jour cumulative prise en charge. Elle peut ne pas s'appliquer aux versions non prises en charge. Elle peut créer des problèmes de compatibilité. Elle peut réduire l'exposition pour un chemin spécifique sans éliminer tout risque. Elle peut ne pas retirer les web shells existants. Les clients ont toujours besoin de correction, d'enquête et de nettoyage. L'automatisation aide pour la longue traîne; elle n'élimine pas la responsabilité.

Le devoir durable du fournisseur est de rendre le chemin de réparation plus court et plus clair. Les correctifs d'urgence devraient pouvoir être installés par un large éventail de clients. Les atténuations devraient être disponibles lorsque les correctifs ne peuvent pas être installés immédiatement. Les conseils de détection devraient être faciles à exécuter et à interpréter. Les canaux de support devraient prioriser les clients à haut risque. La documentation devrait expliquer quand la reconstruction est plus sûre que le nettoyage.

Les produits à longue traîne devraient avoir des cycles de vie et des chemins de mise à niveau qui réduisent l'exposition non prise en charge.

ProxyLogon montre également pourquoi la migration vers le cloud n'est pas la seule réponse. Microsoft a dit qu'Exchange Online n'était pas affecté par ces vulnérabilités, et de nombreuses organisations utilisent le courriel hébergé dans le cloud pour éviter d'exécuter des serveurs de messagerie exposés. Mais de nombreuses organisations exécutent encore Exchange sur site pour des raisons hybrides, réglementaires, de coût, héritées ou opérationnelles. La question de responsabilité est de savoir comment gouverner la population restante sur site, pas seulement comment dire à tout le monde de partir.

Les fournisseurs de services gérés sont devenus partie de la chaîne de réparation

De nombreuses petites organisations ne gèrent pas Exchange seules. Elles dépendent de fournisseurs de services gérés, de sociétés informatiques locales, de fournisseurs d'hébergement ou de consultants. Pendant ProxyLogon, ces fournisseurs sont devenus partie de la chaîne de réparation. Ils devaient suivre les inventaires clients, appliquer les mises à jour, exécuter la détection, communiquer le risque, préserver les preuves et escalader la compromission suspectée. Si un fournisseur gérait plusieurs serveurs Exchange, sa vitesse de réponse affectait de nombreuses organisations.

Les contrats devraient définir ce rôle d'urgence avant une crise. Le fournisseur a-t-il l'autorité d'appliquer des correctifs d'urgence sans attendre une fenêtre de maintenance? Surveille-t-il les avis des fournisseurs? Effectue-t-il une évaluation de compromission ou seulement l'installation de mises à jour? Maintient-il des journaux? Informe-t-il les clients d'une exploitation suspectée? Dispose-t-il d'une assurance cyber? Sait-il quand faire appel à des intervenants en cas d'incident? ProxyLogon a transformé ces conditions contractuelles en faits opérationnels.

Le client a également des devoirs. Il devrait savoir quel fournisseur gère Exchange, quelle version est en cours d'exécution, si le serveur est exposé, comment fonctionnent les sauvegardes, comment les journaux sont conservés et qui prend les décisions d'urgence. L'externalisation ne supprime pas le besoin de sensibilisation aux actifs. Une petite entreprise peut ne pas exécuter elle-même les étapes techniques, mais elle devrait pouvoir demander des preuves qu'elles ont été effectuées.

Les agences publiques et les assureurs peuvent aider en exigeant des preuves plus claires. Après une vulnérabilité critique exploitée, « nous avons corrigé » ne devrait pas suffire pour les systèmes à haut risque. Les preuves devraient inclure la date, la version, les résultats de détection, l'examen des artefacts, les actions sur les identifiants et la surveillance. Pour les clients de services gérés, ces preuves devraient être livrées sous une forme que le client peut conserver. Sinon, le prochain audit ou avis de violation part de la mémoire.

La longue traîne de ProxyLogon était en partie un problème de marché: de nombreuses petites organisations ont acheté l'opération de messagerie comme un service auprès de fournisseurs locaux sans nécessairement acheter une réponse aux incidents. L'exploitation d'urgence effondre cette distinction. Si un fournisseur gère le serveur, il doit être prêt pour une évaluation de compromission ou avoir un chemin pour l'obtenir rapidement.

La mesure finale est une réparation vérifiable

La leçon de responsabilité la plus forte de ProxyLogon est que la réparation doit être vérifiable. Un propriétaire de serveur devrait pouvoir montrer la chronologie allant de l'avis de vulnérabilité à la découverte d'inventaire, l'installation du correctif, l'atténuation, l'évaluation de compromission, le nettoyage, l'examen des identifiants et la surveillance. Un fournisseur devrait pouvoir montrer comment il a réduit la difficulté de cette chronologie. Les autorités publiques devraient pouvoir voir si les populations exposées diminuent et si les agences critiques se sont conformées.

La réparation vérifiable n'exige pas la publication publique de chaque journal ou détail médico-légal. Elle exige un enregistrement suffisamment bon pour que l'organisation, son conseil d'administration, ses clients, ses auditeurs et ses régulateurs comprennent ce qui a été fait. Dans une petite organisation, cet enregistrement peut être un rapport de service géré. Dans une agence fédérale, il peut s'agir d'une preuve de conformité à une directive. Dans une grande entreprise, il peut s'agir d'un dossier d'enquête d'incident. La forme peut différer. Les catégories de preuves ne devraient pas.

ProxyLogon ne devrait pas être rappelé seulement comme un événement de correctif Microsoft. C'était un test de la base installée: qui connaissait ses serveurs Exchange, qui pouvait les mettre à jour rapidement, qui pouvait trouver des web shells, qui pouvait évaluer l'exposition des courriels, qui pouvait protéger les petites organisations et qui pouvait prouver la clôture après le passage de l'urgence. L'opération de retrait de web shell du DOJ reste un signe vivant que la longue traîne était réelle.

La leçon publique est tout aussi pratique. Pour les systèmes sur site exposés à Internet, la correction est un minimum. L'enregistrement de responsabilité commence par la correction et se poursuit par la détection, le nettoyage, la rotation des identifiants, l'avis aux utilisateurs et l'amélioration ultérieure du produit. Si ces étapes ne sont pas prouvées, la correction d'urgence devient du théâtre: une action visible qui peut laisser un résidu invisible.

Les fonctionnalités d'atténuation ultérieures de Microsoft, les directives et avis de la CISA, l'action fédérale des forces de l'ordre, les rapports de la communauté de sécurité et les devoirs des opérateurs locaux pointent tous vers la même conclusion. Le chemin du correctif à la sécurité est long. Les organisations qui dépendent d'Exchange ont besoin de preuves que le chemin a été réellement parcouru.

La clôture nécessite une liste de contrôle différente de la correction

Le guide d'intervention MSRC de Microsoft sur les Vulnérabilités d'Exchange Server sur site: enquête et remédiation indique clairement que les défenseurs devaient rechercher des web shells et d'autres artefacts, pas seulement installer des mises à jour. Cette distinction aurait dû produire deux listes de contrôle distinctes dans chaque organisation affectée. La première liste de contrôle est la correction: identifier la version, satisfaire les prérequis, installer la mise à jour, vérifier la build.

La seconde est la clôture: rechercher une compromission, retirer les artefacts, faire pivoter les identifiants, examiner l'accès aux boîtes aux lettres, préserver les preuves, surveiller la réentrée et décider si une notification est requise.

Les organisations préfèrent souvent la première liste de contrôle car elle a une ligne d'arrivée visible. Un serveur a un correctif ou non. La seconde liste de contrôle est plus désordonnée. Elle demande si des attaquants étaient présents avant le correctif, si les journaux remontent assez loin, si les web shells ont été retirés, si d'autres persistances subsistent, si les boîtes aux lettres ont été accédées et si un mouvement latéral a eu lieu. Ce travail peut nécessiter des compétences qu'une petite organisation n'a pas.

L'avis AA21-062A de la CISA, AA21-062A, et l'avis d'atténuation de la NSA, Avis d'atténuation, ont aidé à définir cette seconde liste de contrôle pour les défenseurs. Le problème n'est pas l'absence de conseils. C'est l'adoption opérationnelle. Les conseils doivent atteindre la personne qui possède le serveur, être compréhensibles pour être exécutés et correspondre aux outils et à l'autorité de l'organisation.

Les fournisseurs de services gérés devraient transformer les listes de contrôle de clôture en rapports clients. Un rapport ne devrait pas simplement dire « Exchange mis à jour ». Il devrait indiquer quel serveur a été mis à jour, quand, à partir de quelle version, quelles étapes de détection ont été exécutées, si des web shells ont été trouvés, ce qui a été retiré, si les identifiants ont été remplacés, si les sauvegardes ont été vérifiées et quelle surveillance reste en place. Ce rapport devient la preuve du client lorsque les assureurs, auditeurs, régulateurs ou utilisateurs affectés demandent ce qui s'est passé.

Pour les grandes organisations, la clôture devrait alimenter la gouvernance des risques. Si Exchange était exposé, les dirigeants devraient savoir combien de temps il est resté vulnérable après l'avis public, si une compromission a été trouvée, quelles unités commerciales utilisaient le serveur, si des boîtes aux lettres sensibles ont été affectées et ce qui a empêché une réparation plus rapide. Si la réponse est « nous ne savions pas que le serveur existait », le problème de réparation est la gestion des actifs. Si la réponse est « nous savions mais ne pouvions pas corriger », le problème est la préparation à la maintenance.

Si la réponse est « nous avons corrigé mais n'avons pas enquêté », le problème est la maturité de la réponse aux incidents.

Les serveurs non pris en charge et en retard sont un risque communautaire

ProxyLogon a révélé un problème de risque communautaire autour des serveurs sur site non pris en charge ou en retard. Le serveur Exchange exposé d'une organisation peut devenir un point de lancement, une source de spam, une cible de vol de données ou un point d'appui pour une intrusion plus large. Le préjudice peut commencer localement, mais l'infrastructure de messagerie compromise peut affecter les correspondants, les partenaires, les clients et la confiance du public dans les communications. C'est pourquoi la correction à long terme n'est pas seulement le risque privé du propriétaire.

Les conseils de l'équipe Exchange de Microsoft autour des Mises à jour de sécurité de mars 2021 et des Mises à jour trimestrielles d'Exchange ultérieures pointent vers le problème de maintenance. Certains clients étaient sur des mises à jour cumulatives prises en charge et ont pu agir rapidement. D'autres ont dû rattraper leur retard. Certains ont peut-être exécuté des versions non prises en charge. Plus l'écart de maintenance est long, plus la réparation d'urgence devient difficile.

Le service d'atténuation d'urgence Exchange ultérieur décrit dans Septembre 2021 était une réponse à ce risque communautaire. Les atténuations temporaires peuvent réduire l'exposition pendant que les clients préparent des mises à jour complètes. Mais l'atténuation temporaire dépend des clients étant sur des versions pouvant recevoir la fonctionnalité et des organisations acceptant le modèle d'atténuation. Il ne peut pas protéger chaque serveur abandonné ou non pris en charge.

Les autorités publiques peuvent aider en utilisant la mesure de l'exposition et la notification. Le projet de scan des vulnérabilités d'Exchange de Shadowserver, Projet de scan des vulnérabilités, montre comment une mesure externe peut identifier les populations pouvant nécessiter une action. Une telle mesure devrait être associée à une communication prudente: les données d'exposition ne sont pas une preuve de compromission, mais elles peuvent aider les intervenants nationaux et sectoriels à atteindre les propriétaires qui pourraient autrement manquer l'avis.

La leçon du risque communautaire est que la base installée a besoin de soins continus. Les fournisseurs devraient concevoir des chemins de mise à jour qui réduisent les frictions. Les clients devraient maintenir les serveurs dans des états pris en charge. Les fournisseurs de services gérés devraient maintenir des inventaires. Les gouvernements et les organismes sectoriels devraient avertir les organisations exposées. Les assureurs et les auditeurs devraient pénaliser les infrastructures de messagerie invisibles exposées à Internet. La longue traîne ne diminue que lorsque chaque acteur traite les serveurs en retard comme un risque partagé.

L'exposition de la boîte aux lettres est plus difficile à expliquer que la compromission du serveur

Un web shell est un artefact visible. L'exposition de la boîte aux lettres peut être plus difficile à expliquer. Un serveur Exchange compromis peut permettre l'accès aux messages, pièces jointes, carnets d'adresses, éléments de calendrier ou fonctions administratives. Mais déterminer exactement quel contenu de boîte aux lettres a été lu peut être difficile, surtout si la journalisation était incomplète ou si les attaquants utilisaient un accès au niveau du serveur. Cela crée un problème de notification et de confiance après le nettoyage technique.

L'article initial de Microsoft sur HAFNIUM, HAFNIUM ciblant les serveurs Exchange, et le centre de ressources MSRC, Centre de ressources Exchange Server, se concentraient sur les mises à jour urgentes et l'exploitation observée. Pour les organisations concernées, la question suivante était souvent plus difficile: quel courriel l'attaquant a-t-il atteint? La réponse peut ne pas être binaire. Certaines organisations ont pu trouver des preuves d'accès claires. D'autres ne pouvaient qu'inférer le risque à partir de la compromission du serveur et de la présence d'artefacts.

Cette incertitude devrait faire partie de la communication publique. Si une organisation ne peut pas déterminer l'accès exact à la boîte aux lettres, elle devrait dire quelles preuves elle a, ce qui lui manque et quelles mesures de protection sont raisonnables. Les utilisateurs peuvent avoir besoin de réinitialiser les mots de passe, de revoir les pièces jointes sensibles, de surveiller le hameçonnage ciblé ou de déplacer temporairement les communications vers des canaux plus sûrs. Les partenaires peuvent avoir besoin de se méfier des messages envoyés pendant une fenêtre.

Les équipes juridiques et de gestion des dossiers peuvent avoir besoin de préserver le matériel d'enquête.

Le côté continuité a également besoin d'explication. Si le courriel est mis hors ligne pour enquête, quel canal alternatif est faisant autorité? Si le courriel reste en ligne pendant le nettoyage du serveur, quelles restrictions s'appliquent? Si une agence publique communique avec les résidents, comment éviter de perdre la confiance du public? Ces questions sont opérationnelles, pas purement techniques.

ProxyLogon a fait de la confiance dans la boîte aux lettres une catégorie de réparation. Un serveur corrigé peut encore laisser les utilisateurs se demander si d'anciennes conversations ont été lues ou si de nouveaux messages peuvent être fiables. L'enregistrement de réparation le plus solide devrait expliquer à la fois le statut de l'infrastructure et le statut de confiance dans la communication. C'est ainsi qu'un incident de courriel devient véritablement clos.

L'urgence de la correction devrait être assortie de la découverte par le propriétaire

La correction d'urgence suppose que quelqu'un sait qui possède le système. ProxyLogon a exposé la fragilité de cette hypothèse. Une organisation peut avoir des serveurs Exchange de production, des serveurs hybrides, des systèmes de test, des hôtes retirés mais toujours en fonctionnement, des serveurs de messagerie gérés par des sous-traitants et des points d'accès oubliés exposés à Internet. Un avis de correctif atteint l'équipe de sécurité, mais le serveur vulnérable peut appartenir à une unité commerciale, un bureau local, un ancien fournisseur de services gérés ou aucune personne clairement nommée.

C'est pourquoi la directive d'urgence 21-02 de la CISA, Directive d'urgence 21-02, a commencé par l'identification et le signalement, pas seulement l'installation. Pour les agences fédérales, savoir où se trouvait Exchange sur site faisait lui-même partie de l'action d'urgence. La même discipline s'applique en dehors du gouvernement. L'inventaire des actifs n'est pas une liste administrative; c'est le premier contrôle lors d'un événement d'exploitation de masse.

La découverte du propriétaire devrait inclure la propriété technique et commerciale. Le propriétaire technique peut appliquer des correctifs ou appeler le fournisseur. Le propriétaire commercial comprend si le serveur prend en charge les boîtes aux lettres légales, les services publics, les communications des dirigeants, les comptes étudiants, les opérations cliniques ou l'accès aux archives. Sans les deux, les équipes de réponse peuvent corriger la machine mais manquer les implications commerciales de l'exposition.

L'enregistrement du propriétaire devrait également inclure l'autorité. Qui peut déconnecter le serveur si une compromission est suspectée? Qui peut approuver un temps d'arrêt d'urgence? Qui peut dépenser de l'argent pour une réponse externe? Qui peut notifier les utilisateurs? Qui peut décider de reconstruire plutôt que de nettoyer? ProxyLogon a compressé ces décisions en jours. Les organisations qui n'avaient pas désigné d'autorité à l'avance ont dû négocier pendant que les attaquants étaient déjà en mouvement.

Les conseils des fournisseurs et du gouvernement ne peuvent aller très loin si la propriété manque. Le centre de ressources Exchange Server de Microsoft, Centre de ressources, l'alerte de la CISA, Alerte, et les rapports des sociétés de sécurité pouvaient dire aux défenseurs ce qui comptait. Ils ne pouvaient pas nommer chaque serveur négligé. Cela reste le devoir du client, et pour les petites organisations, c'est souvent le devoir le plus important.

La réparation durable est donc un inventaire testé par le propriétaire. Au moins périodiquement, les organisations devraient prouver que chaque système de messagerie exposé à Internet a un propriétaire nommé, une version prise en charge, un chemin de mise à jour, un plan de sauvegarde, un plan de journalisation, une autorité en cas d'incident et une étiquette d'impact commercial. Lorsque le prochain correctif d'urgence arrivera, la première heure ne devrait pas être consacrée à demander qui possède le serveur.

Les décisions de reconstruction devraient faire partie du plan

Nettoyer un serveur Exchange compromis peut être difficile. Si des web shells, des processus suspects ou des journaux incertains sont présents, les défenseurs peuvent devoir décider si le retrait suffit ou si une reconstruction à partir d'un support fiable est plus sûre. Cette décision dépend de la tolérance commerciale, de la qualité des sauvegardes, des besoins de preuve et de la confiance de l'organisation dans le confinement. Elle ne devrait pas être improvisée après l'exploitation.

L'opération de retrait de web shell du DOJ, Opération de retrait, illustre la limite du retrait d'artefact. Retirer un web shell connu réduit un chemin d'accès. Cela ne prouve pas que le serveur est autrement digne de confiance. La notification du FBI, Notification, renforçait la nécessité pour les propriétaires de serveurs de poursuivre la remédiation. C'est la question de reconstruction sous forme publique: quel niveau de preuve est suffisant pour refaire confiance au système?

Les organisations devraient définir à l'avance les déclencheurs de reconstruction. Par exemple, un web shell confirmé plus des journaux inadéquats peuvent nécessiter une reconstruction. La preuve d'un mouvement latéral peut nécessiter une réponse environnementale plus large. Le statut de version non prise en charge peut nécessiter une migration plutôt qu'une réparation. L'exposition de boîtes aux lettres sensibles peut nécessiter un examen juridique avant la restauration. Ces déclencheurs aident les équipes techniques à agir de manière décisive sans attendre un débat exécutif ad hoc.

La planification de la reconstruction expose également la réalité des sauvegardes. Une reconstruction propre nécessite un support d'installation fiable connu, une documentation de configuration, une protection des données de courrier, des restaurations testées et un moyen de préserver les preuves médico-légales avant l'effacement. Les petites organisations découvrent souvent lors d'incidents que les sauvegardes existent mais que les étapes de restauration sont incertaines. ProxyLogon a montré que la correction d'urgence et la reprise après sinistre sont liées;

un serveur qui ne peut pas être reconstruit en toute sécurité devient plus difficile à clore.

La norme de responsabilité n'est pas que chaque serveur compromis doive toujours être reconstruit. C'est que l'organisation devrait savoir quand la reconstruction est le chemin le plus sûr et avoir les moyens de le faire. La réparation à long terme est plus solide lorsque les décisions de nettoyage sont régies par des seuils de preuve plutôt que par l'espoir.