Il suffisait d’un e-mail piégé pour exécuter des commandes à distance sur certains serveurs Zimbra exposés à Internet. D’après Microsoft, des pirates ont exploité la faille CVE-2026-73570 avant sa divulgation publique, puis ont dérobé les clés d’authentification de la messagerie de leurs victimes.
En juillet, on vous rapportait que des espions russes ont piégé durablement des serveurs Exchange avec des e-mails d’apparence banale. Dans les derniers jours du mois, d’autres pirates ont commencé à viser les serveurs de Zimbra. Cette suite de messagerie et de collaboration est très répandue dans les entreprises et les administrations, en France notamment. Microsoft Threat Intelligence vient de reconstituer leur chaîne d’attaque sur son blog de sécurité, à partir d’intrusions confirmées dans plusieurs secteurs et régions du monde. Pour ses chercheurs, il ne suffit pas d’installer le correctif après coup, car les intrus ont eu le temps de poser des accès durables sur les serveurs.
La solution tout-en-un pour protéger votre entreprise
Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !
Une faille Zimbra exploitée avant sa divulgation
Les serveurs vulnérables sont ceux où le paquet optionnel zimbra-snmp est installé et où les notifications SNMP sont activées. Sur ces machines, un attaquant peut glisser des métacaractères du shell dans une requête SMTP, sans compte ni mot de passe. Lors d’un changement d’état d'un service, cette chaîne est ensuite intégrée par le module de surveillance swatchdog à une commande système, si bien que l’attaquant exécute ses propres instructions avec les privilèges du compte de service zimbra. Aucune action de l’utilisateur n’est nécessaire.
Zimbra a corrigé la faille le 20 juillet dans la version 10.1.20, mais la vulnérabilité n’a été rendue publique que le 13 août. Entre le 28 juillet et le 7 août, les équipes de Microsoft ont observé des pirates en train de sonder ce point d’injection avec deux outils de scan. Ils ont d’abord lancé de simples ping ou nslookup vers des serveurs de rappel, avec un agent utilisateur ZB73570 calqué sur le numéro de la CVE. Une fois l’exécution de leurs commandes confirmée, ils ont déposé des webshells JSP dans les répertoires web de Zimbra, en ouvrant temporairement les droits d’écriture d'un dossier public avant de les rétablir pour tromper les contrôles de permissions.
Le 19 août dernier, le CERT-FR a publié un avis de sécurité, et la CISA américaine a ajouté la faille à son catalogue des vulnérabilités activement exploitées deux jours plus tard. Entre-temps, les pirates avaient élargi leur offensive. La fondation Shadowserver scanne Internet en continu à la recherche de machines vulnérables. D’après ses relevés, il y avait 155 serveurs Zimbra compromis le 20 août, puis 274 deux jours plus tard, dont 21 en France. Plus de 8 000 instances n’étaient pas encore corrigées à cette date, mais la configuration SNMP vulnérable n’était pas activée sur toutes.
Des secrets d’authentification Zimbra dérobés
Sur les serveurs compromis, les pirates ont obtenu les droits root en détournant les outils d’administration de Zimbra. Ils ont remplacé un fichier journal du gestionnaire de boîtes aux lettres par un lien symbolique vers la configuration d’authentification de sudo, puis ont relancé ce gestionnaire avec ses privilèges élevés. Ce fichier appartenait alors au compte zimbra, et les pirates ont pu le modifier pour accorder à ce compte un accès sudo illimité et sans mot de passe, avant de restaurer la version d’origine pour effacer leurs traces. Ils ont installé, sur l’un des serveurs, un faux service de journalisation antidaté pour tromper les administrateurs.
Les pirates ont ensuite récupéré les mots de passe des services internes de Zimbra, LDAP et MySQL notamment, avec la commande zmlocalconfig, puis ont interrogé l’annuaire pour extraire la clé zimbraAuthTokenKey. Zimbra signe les jetons de session de ses utilisateurs avec cette clé. Son détenteur peut donc ouvrir une session sur n’importe quel compte sans le moindre identifiant. Les pirates peuvent en outre fabriquer des URL de connexion valides pour tout compte avec la clé de préauthentification zimbraPreAuthKey, qu’ils ont également dérobée.
Les intrus ont utilisé l’identité SSH de Zimbra pour rejoindre les autres nœuds du cluster et copier leurs webshells sur chacun d’eux. Lors d’une campagne, les chercheurs de Microsoft ont aussi relevé l’agent d’accès distant zimclient2, capable de transformer un serveur compromis en relais SOCKS5 vers le réseau interne. Ailleurs, un opérateur a archivé une sauvegarde récente des boîtes aux lettres, puis a lancé l’outil AzCopy de Microsoft pour envoyer l’archive vers un espace de stockage Azure. Microsoft ignore encore si ce transfert a abouti.
Microsoft recommande de passer à Zimbra 10.1.20 ou, à défaut, de désinstaller zimbra-snmp et de limiter l’accès SNMP et SMTP aux hôtes de confiance. Les administrateurs doivent aussi renouveler les clés zimbraPreAuthKey et inspecter chaque nœud de boîtes aux lettres à la recherche de fichiers JSP inattendus. « Ne présumez pas que la suppression d’un seul fichier JSP connu élimine l'accès », ont prévenu Mahesh Mandava et Rajesh Kumar Natarajan, chercheurs chez Microsoft Threat Intelligence. Or Microsoft ne conserve que 30 jours de données brutes dans l'outil de chasse avancée de Defender XDR, si bien que ses clients doivent fouiller leurs journaux archivés pour retrouver la reconnaissance de fin juillet et les premières intrusions.
Certains services construisent des commandes système en réutilisant des chaînes issues du réseau (paramètres, en-têtes, contenus) sans les neutraliser correctement. Les métacaractères du shell (comme ;, |, &, $(), `…`) permettent alors de « sortir » de la commande attendue et d’ajouter des instructions arbitraires. Si la chaîne injectée est ensuite exécutée par un composant ayant des droits locaux (compte de service, voire root), l’attaquant obtient une exécution de code à distance sans identifiants. Dans ce type de scénario, la gravité dépend surtout du contexte d’exécution (quel utilisateur lance la commande) et de l’absence de filtrage/échappement des caractères dangereux.
SNMP (Simple Network Management Protocol) sert à superviser des équipements et serveurs : collecte de métriques, état des services, envoi de notifications (traps) vers des outils de monitoring. Quand SNMP et ses notifications sont activés, cela ajoute des points d’entrée et des chemins de traitement supplémentaires (par exemple des scripts ou modules qui réagissent à des événements). Si un maillon de cette chaîne réutilise des données non fiables dans des commandes ou des fichiers, SNMP peut devenir un « déclencheur » d’exploitation. C’est aussi un protocole souvent exposé par erreur ou mal filtré, d’où l’intérêt de le restreindre aux hôtes de confiance et de désactiver les fonctionnalités non indispensables.
Une clé de signature de jetons (comme zimbraAuthTokenKey) sert à garantir qu’un jeton de session a bien été émis par le serveur et n’a pas été modifié. Si un attaquant récupère cette clé, il peut forger des jetons valides et se faire passer pour n’importe quel utilisateur, y compris des administrateurs, sans connaître leurs identifiants. La clé de préauthentification (zimbraPreAuthKey) sert, elle, à générer des URL ou mécanismes de connexion « pré-validés » utilisés pour des intégrations ou accès simplifiés ; la compromettre revient à pouvoir produire des liens d’authentification acceptés par le serveur. C’est pour cela qu’après une compromission, appliquer un correctif ne suffit pas : il faut aussi régénérer ces secrets et invalider les sessions associées.
