Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique
Le correctif était pourtant là
Illustration : Flock
Le 01 octobre à 09h36
Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.
Les serveurs e-mail Zimbra visés par l’exploitation très active d’une faille critique
Le correctif était pourtant là
Illustration : Flock
Les personnes et organisations disposant de serveurs équipés de Zimbra pour la gestion de leurs e-mails doivent mettre à jour aussi rapidement que possible les composants logiciels. Une faille est exploitée depuis plus de deux mois, alors que le correctif existe depuis le 20 juillet.
Sécurité
Sécurité
4 min
Dans un long billet publié le 30 septembre, Microsoft Threat Intelligence a fourni une analyse de l’exploitation de CVE-2026-73570, une faille de type « injection de commandes système non authentifiée » dans Zimbra Collaboration Suite (ZCS), une solution e-mail très populaire.
Cette faille, présente dans toutes les versions antérieures à la 10.1.20, est en fait corrigée depuis juillet. Cependant, les systèmes non mis à jour seraient encore nombreux, Microsoft indique que la faille – critique, avec un score CVSS de 8,9 – est exploitée depuis fin juillet au moins. L’éditeur évoque un minimum de plusieurs centaines de serveurs compromis par l’exploitation de cette faille.
Cette vulnérabilité est présente dans le traitement des notifications SNMP de Zimbra. Elle peut être exploitée dès lors que le paquet optionnel zimbra-snmp est installé et que les notifications sont activées. Un attaquant non authentifié peut alors envoyer des requêtes SMTP spécialement conçues pour provoquer une erreur, lui permettant après coup d’exécuter des commandes système arbitraires avec les droits de l’utilisateur zimbra.
Des attaques rondement menées
Dans son billet, Microsoft dit avoir observé deux outils de balayage le 28 juillet et le 7 août, donc après le correctif mais avant la divulgation, intervenue le 13 août avec la publication des informations dans la base NVD. « Les sondes incluaient des requêtes HTTP et des vérifications d’identité DNS, ICMP et en bande, utilisant des commandes telles que curl, wget, ping, nslookup et id », vers des services d’interaction comme oast[.]fun ou requestrepo[.]com, ou vers une infrastructure propre à la campagne d’attaque sous bypass[.]eu[.]org. Les requêtes HTTP portaient un User-Agent spécifique, ZB73570, suggérant selon Microsoft que des acteurs ont analysé le correctif avant la publication des détails du bulletin CVE.
Les attaquants ont ensuite déposé des pages JSP malveillantes (webshells) dans les répertoires Jetty et mailboxd, puis les ont recopiées sur les autres nœuds de boîtes aux lettres. Ils allaient parfois jusqu’à ouvrir temporairement les droits d’écriture du répertoire public avant de les rétablir. Ils ont aussi installé un service systemd déguisé, zimlog.service, dont les horodatages avaient été modifiés pour imiter sshd.service.

L’exploitation se faisait au moyen du journal zmmailboxd.out remplacé par un lien symbolique vers /etc/pam.d/sudo, qui invoquait alors zmmailboxdmgr, exécuté avec des privilèges élevés. Les pirates étaient ensuite capables de voler des secrets, de se déplacer latéralement dans l’infrastructure et d’exfiltrer des contenus. Microsoft n’attribue cette activité à aucun acteur nommé, le rapport mentionnant des victimes dans plusieurs régions et secteurs, et un mélange d’opérations automatisées et manuelles.
Du pain sur la planche
Selon le rapport, toute instance Zimbra qui n’a pas été mise à jour avant fin juillet doit être considérée comme potentiellement compromise. L’installation de la mise à jour est la mesure la plus urgente à entreprendre. À défaut, si l’opération est impossible dans l’immédiat, Microsoft recommande la désinstallation du paquet zimbra-snmp, la désactivation des notifications SNMP et la restriction de l’accès SNMP et SMTP aux seuls hôtes de confiance.
Une fois la mise à jour effectuée, plusieurs actions sont encore nécessaires :
- Renouveler toutes les clés zimbraPreAuthKey et zimbraAuthTokenKey
- Inspecter /etc/sudoers.d/ (notamment 81_metric), /etc/pam.d/ et les unités systemd (zimlog.service, chronyd-helper.service, syslog_init.service)
- Chercher les JSP et fichiers *_jsp.java inattendus sur la totalité des nœuds
Commentaires (16)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 1er octobre à 11h51
Le 1er octobre à 13h23
Zimbra 7.2.0-GA2598 (version 20160107134148)
Copyright (c) 2005-2011 VMware Inc.
Tous droits réservés.
No comments
Le 1er octobre à 13h34
Le 1er octobre à 14h34
(à une époque je faisais tourner un WordPress sur les pages perso, aujourd'hui ce n'est plus possible !)
Le 1er octobre à 15h56
Le 1er octobre à 16h28
Roundcube Webmail 1.6.19
Copyright © 2005-2025, The Roundcube Dev Team
Vendredi à 13h38
Le 1er octobre à 16h41
Le 1er octobre à 13h23
J'espère que cela été mis à jour.
Le 1er octobre à 19h39
Le 1er octobre à 16h13
Tout dépend de la manière dont le relais normalise et retransmet l'enveloppe SMTP.
Le 1er octobre à 18h13
Vu que la faille risque d'être corrigée que d'ici les prochaines grandes vacances (ou pas).
Le 1er octobre à 18h42
Le 1er octobre à 20h24
Le 1er octobre à 23h29
Modifié le 2 octobre à 09h28
Le protocole SNMP c'est du flux d'admin. C'est rarement (jamais ?) exposé et dans un réseau a part. Et encore faut-il l'utiliser, SNMP n'est pas du tout la norme pour des services applicatifs.
Bref, la faille est là et l'exploit aussi, mais le nombre d'instances vulnérables depuis les internets doit être sacrément bas et celui depuis le réseau interne ne doit pas représenter la majorité des instances.
Quant au déplacement latéral, je vois pas bien le rapport avec Zimbra.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?