Réaction à la faille 0-day de Microsoft Exchange

Le 6 mars, Microsoft a signalé des brèches dans le logiciel Microsoft Exchange. IONOS avait déjà appris l’existence de cette vul­né­ra­bi­li­tés le 3 mars et a im­mé­dia­te­ment appliqué les mises à jour fournies par Microsoft à tous les systèmes Exchange qu’il ex­ploi­tait lui-même afin de l’éliminer. Les systèmes IONOS n’ont pas été affectés par la vague d’attaques.

Dans cette interview avec l’ingénieur principal d’Exchange, John Barnes, nous essayons de répondre aux questions les plus im­por­tantes sur le sujet.

Nous avons découvert la vul­né­ra­bi­lité très tôt dans la matinée du 3 mars et nous avons im­mé­dia­te­ment commencé à évaluer quels serveurs devaient être corrigés et à répartir le travail au sein de l’équipe pour accélérer le processus de cor­rec­tion.

Nous avons im­mé­dia­te­ment su que cette mise à jour était très im­por­tante, car il est rare que Microsoft publie des cor­rec­tifs en dehors de son rythme mensuel standard. Dès que nous sommes entrés dans les détails des vul­né­ra­bi­li­tés et que nous avons compris les ra­mi­fi­ca­tions tech­niques, il est devenu évident que ce correctif devait être appliqué le plus ra­pi­de­ment possible.

Nous dé­ve­lop­pons nos pla­te­formes avec une quantité im­por­tante de re­don­dance, de sorte que dans des cir­cons­tances telles que celles-ci, nous sommes en mesure de patcher nos pla­te­formes pendant les heures de bureau sans causer de perte de service pour nos clients. Dans la mesure du possible, cela nous permet également d’au­to­ma­ti­ser le processus de cor­rec­tion, de sorte qu’une grande partie de nos serveurs avaient déjà installé le correctif avant le début de la journée.

Pour les autres parties de notre pla­te­forme, nous avons commencé à appliquer les cor­rec­tifs par étapes, en déplaçant la charge de travail entre les serveurs afin d’éviter une in­ter­rup­tion de service. Cela a duré presque toute la journée de mercredi, en donnant la priorité aux parties de la pla­te­forme qui nous sem­blaient les plus vul­né­rables. Nous avons également fait preuve de vigilance en re­cher­chant toute activité suspecte sur nos pla­te­formes.

Alors que le travail de cor­rec­tion était en cours, nous avons également rejoint un appel de Microsoft con­cer­nant la mise à jour et nous nous sommes organisés avec l’équipe de sécurité IONOS pour nous assurer que l’in­for­ma­tion était transmise à l’ensemble de l’en­tre­prise. L’appel de Microsoft a été par­ti­cu­liè­re­ment ins­truc­tif car l’accent a été mis sur les patchs et non sur l’at­té­nua­tion de l’exploit par d’autres moyens.

Une fois le processus de cor­rec­tion terminé, nous nous sommes con­cen­trés sur la recherche d’in­di­ca­teurs de com­pro­mis­sion. Il s’agit d’un processus long en raison de la taille de nos pla­te­formes et de l’im­por­tance que nous accordons à ces vul­né­ra­bi­li­tés ; nous avons donc consacré plusieurs jours à ce processus d’analyse.

La priorité absolue est de corriger la vul­né­ra­bi­lité le plus ra­pi­de­ment possible, ce qui peut parfois être difficile avec des systèmes critiques pour l’en­tre­prise, comme les mes­sa­ge­ries. Dans des cas comme celui-ci, où la faille peut être très dan­ge­reuse, il peut être né­ces­saire de provoquer une in­ter­rup­tion de service afin de déployer le patch plus ra­pi­de­ment.

En tant qu’hébergeur, nous sommes prêts à réagir ra­pi­de­ment et de manière décisive à ces « incidents ». Comme il s’agit d’une activité quo­ti­dienne, nous disposons des contacts et des in­for­ma­tions né­ces­saires pour être informés le plus ra­pi­de­ment possible, souvent avant les com­mu­ni­qués publiques.

Nos processus sont hautement au­to­ma­ti­sés et gérés, ce qui nous permet de réagir ra­pi­de­ment et d’exploiter des pla­te­formes à l’échelle mondiale, avec géo-re­don­dance, ce qui signifie que les mises à jour peuvent être ap­pli­quées sans in­ter­rup­tion d’activité. En tant qu’hébergeur, nous gérons des pla­te­formes Exchange hébergées à l’échelle mondiale depuis 2010 et nous avons une ex­pé­rience inégalée au-delà de Microsoft. Nous com­pre­nons que ces choses arrivent, et c’est la façon dont vous réagissez qui compte ici.

Je pense que les en­tre­prises les plus exposées sont les petites en­tre­prises qui utilisent des serveurs Exchange sur site et qui n’ont pas né­ces­sai­re­ment les res­sources né­ces­saires pour suivre le ca­len­drier tri­mes­triel des mises à jour cu­mu­la­tives de Microsoft.

Lorsque Microsoft a ini­tia­le­ment publié les mises à jour, elles n’étaient dis­po­nibles que pour les deux dernières mises à jour cu­mu­la­tives de chaque version d’Exchange, ce qui signifie que les en­tre­prises qui n’étaient pas à jour devaient installer les dernières mises à jour cu­mu­la­tives avant de pouvoir corriger la vul­né­ra­bi­lité. Ce processus peut s’avérer beaucoup plus complexe que la simple ins­tal­la­tion d’une mise à jour de sécurité pour Exchange et prend beaucoup plus de temps, ce qui augmente l’ex­po­si­tion de l’en­tre­prise à cette vul­né­ra­bi­lité.

Pour cette vul­né­ra­bi­lité spé­ci­fique : Microsoft re­com­mande ce Heal­th­Check pour connaître le niveau de correctif de vos serveurs et dé­ter­mi­ner si vous devez les mettre à jour. Il se peut notamment que Microsoft Update n’indique pas que vous avez une mise à jour en attente si vos serveurs Exchange ne sont pas patchés à la dernière mise à jour cu­mu­la­tive. Le script Test-Proxy­Lo­gon est un script Microsoft qui vous aidera à iden­ti­fier tout in­di­ca­teur de com­pro­mis­sion.

En général, j’ai trouvé que le scanner de vul­né­ra­bi­lité Nessus était par­ti­cu­liè­re­ment efficace pour iden­ti­fier les vul­né­ra­bi­li­tés et les serveurs non patchés.

Cet exploit était par­ti­cu­liè­re­ment grave, un exploit de type « exécution de code à distance non au­then­ti­fiée en tant que système ». Il est par­ti­cu­liè­re­ment dangereux dans ce cas, car les serveurs Microsoft Exchange disposent gé­né­ra­le­ment d’un haut niveau de privilège sur l’Active Directory, qui est le principal système d’au­then­ti­fi­ca­tion et d’au­to­ri­sa­tion pour les systèmes Windows dans une en­tre­prise.

Cela signifie que les risques pour l’en­tre­prise sont ex­trê­me­ment élevés, avec une pos­si­bi­lité im­por­tante de vol/des­truc­tion des données de l’en­tre­prise, de perte de capacité de fonc­tion­ne­ment, etc. Il est difficile de minimiser l’impact possible pour l’en­tre­prise si un hacker parvenait à exploiter cette vul­né­ra­bi­lité.

Je pense qu’il est toujours difficile de donner un « feu vert » définitif avec ce genre de vul­né­ra­bi­li­tés. Nous avons effectué tous les scans, sur la base des in­for­ma­tions ac­tuel­le­ment fournies par Microsoft, et nous n’avons rien remarqué de notable, mais un hacker mal­veil­lant et vraiment doué peut rendre très difficile la détection d’une com­pro­mis­sion.

Plusieurs sources d’in­for­ma­tion ont révélé que ces vul­né­ra­bi­li­tés spé­ci­fiques avaient été iden­ti­fiées pour la première fois début janvier et signalées de manière trans­pa­rente à Microsoft. Fin février, des attaques plus étendues ont été iden­ti­fiées juste avant que Microsoft ne publie les cor­rec­tifs. Cela signifie qu’il y a un délai important pour la mise en œuvre de l’exploit initial.

Je pense que cela peut amener les en­tre­prises à réévaluer leur choix de continuer à héberger leurs systèmes de mes­sa­ge­rie sur site et le coût réel de leur main­te­nance par rapport à l’hé­ber­ge­ment de ces systèmes es­sen­tiels pour l’en­tre­prise chez un four­nis­seur de services Cloud de confiance.

Plus d’in­for­ma­tions :

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/

https://msrc-blog.microsoft.com/2021/03/05/microsoft-exchange-server-vul­ne­ra­bi­li­ties-mi­ti­ga­tions-march-2021/