Zimbra : Microsoft dévoile comment des pirates ont exploité une faille avant sa révélation au public

Microsoft détaille une intrusion contre des serveurs Zimbra, menée avant la révélation publique de la faille. Les pirates ont obtenu les droits root, volé des clés capables d’ouvrir des sessions et propagé leurs outils dans des clusters. Pour les administrateurs, appliquer le correctif ne suffit pas : il faut aussi vérifier chaque nœud et renouveler les secrets exposés.

Zimbra : une faille exploitée avant sa divulgation publique

Les attaquants ont détourné un outil d’administration du gestionnaire de boîtes aux lettres pour élever leurs privilèges. Ils ont remplacé un fichier journal par un lien symbolique pointant vers la configuration de sudo, puis relancé le service avec les droits du compte Zimbra.

Le fichier étant alors modifiable par ce compte, ils lui ont accordé un accès sudo illimité, sans mot de passe. Après l’opération, ils ont remis le fichier d’origine en place pour réduire les traces visibles. Sur un serveur, un faux service de journalisation antidaté devait aussi tromper les administrateurs.

Des identifiants Zimbra transformés en accès aux comptes

Les intrus ont récupéré des mots de passe de services internes, notamment LDAP et MySQL, à l’aide de la commande zmlocalconfig. Ils ont ensuite interrogé l’annuaire pour extraire la clé zimbraAuthTokenKey, utilisée pour signer les jetons de session.

Avec cette clé, un pirate peut fabriquer un jeton valide et accéder à n’importe quel compte, sans en connaître le mot de passe. La clé zimbraPreAuthKey a également été dérobée ; elle permet de produire des URL de préauthentification valides pour les comptes visés. Une compromission de serveur peut donc devenir une compromission des identités.

Webshells et relais réseau : l’intrusion s’étend au cluster

Les pirates ont utilisé l’identité SSH du compte Zimbra pour rejoindre les autres nœuds du cluster et y copier leurs webshells. Supprimer un seul fichier suspect ne garantit donc pas que l’accès soit neutralisé.

Microsoft a aussi observé l’outil d’accès distant zimclient2, capable de transformer un serveur compromis en relais SOCKS5 vers le réseau interne. Dans une autre opération, un intrus a préparé une sauvegarde récente de boîtes aux lettres avant de lancer AzCopy pour l’envoyer vers un stockage Azure. Microsoft n’a pas confirmé que le transfert avait abouti.

Correctif Zimbra et vérifications après compromission

Microsoft recommande de passer à Zimbra 10.1.20. Si la mise à jour n’est pas immédiatement possible, l’éditeur préconise de désinstaller zimbra-snmp et de limiter les accès SNMP et SMTP aux hôtes de confiance.

Les équipes doivent renouveler la clé de préauthentification, examiner chaque nœud de boîtes aux lettres et rechercher des fichiers JSP inattendus. Il faut aussi traiter comme exposées les clés d’authentification volées. « Ne présumez pas que la suppression d’un seul fichier JSP connu élimine l’accès », avertissent les chercheurs Mahesh Mandava et Rajesh Kumar Natarajan.

La fenêtre d’investigation est un autre point de vigilance : Microsoft Defender XDR ne conserve que 30 jours de données brutes dans son outil de chasse avancée. Pour retrouver les opérations de reconnaissance de fin juillet et les premières intrusions, les organisations doivent donc consulter leurs journaux archivés. Un correctif protège contre la faille ; seule une vérification complète permet d’évaluer si le serveur est déjà compromis.

Source: www.clubic.com