Des milliers de petites et moyennes entreprises souffrent car Rackspace a subi un incident de sécurité sur leur service Hosted Exchange.

Hier, 2 décembre 2022, Rackspace a annoncé une panne de son serveur Exchange hébergé :

Mise à jour suivie tout au long de la journée, mais était un peu vague :

Je me suis impliqué à la fin, car j'ai remarqué quelque chose et l'ai documenté dans ce fil:

Le service géré de Rackspace utilise principalement les noms d'hôte mex*.emailsrvr.com pour Exchange et OWA :

Et puis, en regardant les données Shodan les plus récentes, il était clair que le cluster Exchange affichait des numéros de build longs Exchange qui étaient anciens :

Ce numéro de build Exchange date d'août 2022, avant que les correctifs ProxyNotShell ne soient disponibles :

Les numéros de build longs d'échange ne sont pas toujours fiables… mais c'est un signe qu'il convient de garder à l'esprit.

J'ai écrit à propos de ProxyNotShell, une vulnérabilité que j'ai nommée - désolé, ici : ProxyNotShell - l'histoire des zéro jours revendiqués dans Microsoft Exchange | de Kevin Beaumont | Double Pulsar

Tôt ce matin, Rackspace a précisé qu'il s'agissait d'un incident de sécurité :

Contexte de la menace

Maintenant, il est possible que la violation de Rackspace se soit produite en raison d'autres problèmes - mais comme rappel général, je suggérerais quelques points clés sur la menace :

• Les atténuations fournies par Microsoft pour ProxyNotShell peuvent être contournées. IIS Rewrite, que Microsoft a utilisé pour les atténuations, ne décode pas correctement toutes les URL et peut donc être contourné pour être exploité. Si vous vous êtes appuyé sur l'atténuation PowerShell ou l'application EEMS, votre serveur Exchange est toujours vulnérable — Microsoft ne vous l'a tout simplement pas dit clairement . Le correctif consiste à patcher.
• Bien que la vulnérabilité nécessite une authentification, les exploits fonctionnent sans authentification multifacteur car Exchange Server ne prend pas encore en charge l'authentification moderne, car Microsoft a dépriorisé le travail de mise en œuvre (traité dans l'autre blog).
• Si vous êtes un MSP exécutant un cluster partagé, tel que Hosted Exchange, cela signifie qu'un compte compromis sur un client compromettra l'ensemble du cluster hébergé. C'est un risque élevé.

• Il est très important que les administrateurs d'Exchange Server obtiennent à la fois la dernière mise à jour cumulative et la mise à jour de sécurité pour Exchange Server 2013/2016/2019.
• Dans le cas d'Exchange Server 2013, il s'agit de CU23 Nov22SU alias build 10.0.1497.44. Vous pouvez vérifier vos numéros de build auprès de Shodan, ou les administrateurs Exchange peuvent utiliser ce Powershell ci-dessous. Vérifiez .

$ExchangeServers = Get-ExchangeServer | Sort-Object Name
ForEach ($Server in $ExchangeServers) {
    Invoke-Command -ComputerName $Server.Name -ScriptBlock { Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo } }
}

• Si vous utilisez Microsoft Defender Vulnerability Management, vérifiez les numéros de build dans le produit plutôt que de vous fier aux vulnérabilités identifiées (vous remarquerez pourquoi).
• Si vous externalisez la gestion de Microsoft Exchange et que vous disposez de ressources, vous devez demander une preuve que chaque serveur est corrigé pour chaque mise à jour. Je me rends compte que la plupart des organisations qui externalisent n'auront pas cette ressource.
• Vous devriez balayer vos serveurs Exchange, si vous avez présenté OWA sur Internet en particulier, pour les webshells (portes dérobées pour plus tard) et les signes d'activité post-compromis. Pour ce faire, le moyen le plus simple consiste à exécuter Microsoft Safety Scanner et Sophos Scan & Clean , qui sont des outils d'analyse ponctuels, pour balayer et nettoyer automatiquement un système.

La correction d'Exchange Server est extrêmement compliquée, dans certains cas risquée - combien d'administrateurs avons-nous eu des pannes de serveur ? - et déroutant. Microsoft doit le moderniser. En outre, l'authentification moderne doit être implémentée dans Exchange Server par Microsoft - l'authentification de base n'est pas acceptable dans l'année spatiale 2022.

Je m'attends à des attaques continues contre les organisations via Microsoft Exchange jusqu'en 2023. Et pour ceux qui disent "utilisez Exchange Online, imbéciles !", il y a encore des défis à relever : l'autorité fédérale allemande de protection des données et 17 régulateurs d'État (DSK) ont publié un rapport dans Microsoft 365 après deux ans de travail avec Microsoft, et déclare que Microsoft 365 ne respecte pas encore le RGPD en citant un large éventail de problèmes .

Le résultat est que les clients MS et les ingénieurs MS se retrouvent dans cette situation :