Un saut de ligne fatal

Zimbra est un logiciel de messagerie utilisé par de nombreuses entreprises et organisations. Fin mars, l’équipe de Sonar a découvert une faille de sécurité importante dans Zimbra, permettant de récupérer le mot de passe de n’importe quel utilisateur. Derrière cette attaque très impactante se cache un type d’injection peu courant : le Memcached Poisoning.

Pour comprendre comment cette attaque est possible, il faut tout d’abord comprendre comment fonctionne Zimbra.

⚙️ Le fonctionnement de Zimbra

Lorsqu’une organisation de grande taille utilise Zimbra, les données de tous les utilisateurs ne sont pas gérées par un seul serveur. Elles sont distribuées sur plusieurs serveurs afin de tenir la charge, pour éviter les ralentissements (voire un plantage total !) si un trop grand nombre d’utilisateurs envoient ou reçoivent des mails au même moment.

Les données d’un même utilisateur, en revanche, seront toujours gérées par le même serveur.

Quand un utilisateur cherche à envoyer une requête pour envoyer ou lire le contenu d’un mail par exemple, celle-ci va passer par un premier serveur, un serveur proxy. Le but du proxy est de transmettre la requête au “bon” serveur, celui qui gère les données de l’utilisateur.

L’adresse du serveur qui gère les données d’un utilisateur est stockée dans un dernier serveur, le Zimbra Lookup Service. Le proxy demande donc au Lookup Service quel serveur gère les données de l’utilisateur, avant de transmettre sa requête à celui-ci.

Dans le cas d’une charge trop importante, c’est la requête au Lookup Service (2ème étape sur le schéma) qui devient limitante, car ce dernier n’est pas dupliqué ! Or, c’est toujours le même serveur qui gère les données d’un même utilisateur. Le proxy peut donc stocker cette donnée pour la réutiliser lors d’une prochaine requête. Pour cela, c’est Memcached, une base de données clef-valeur en mémoire, qui est utilisée. La lecture d’informations dans Memcached est extrêmement rapide, et permet de supporter une charge très importante.

Avant de demander l’information au Lookup Service, le proxy va regarder si celle-ci n’est pas déjà stockée dans Memcached. Si c’est le cas, pas besoin de demander. Sinon, après avoir demandé au Lookup Service, la réponse est stockée.

🕵️ Explication de la faille

Quand Memcached est interrogé, la commande qui lui est passée contient l’adresse mail de l’utilisateur. Un attaquant peut donc forger une requête avec une fausse “adresse mail” pour faire exécuter du code à Memcached.

En l’occurrence, l’attaquant va commencer par ajouter à l’adresse mail les caractères \r\n (qui permettent de faire un saut de ligne). Or, ce sont les sauts de ligne qui séparent les instructions dans Memcached. Après ces caractères, l’attaquant peut écrire une toute nouvelle instruction. Memcached va alors interpréter le saut de ligne et effectuer les deux instructions : la vérification de la présence de l’utilisateur en cache, et la deuxième instruction, écrite par l’attaquant.

L’attaquant peut donc rajouter une entrée dans le cache pour indiquer que le serveur responsable des données de la victime est le sien. La prochaine fois que la victime cherchera à consulter ses mails, elle saisira ses identifiants. Ceux-ci passeront par le serveur proxy, qui cherchera en cache à quel serveur transférer sa requête. Il trouvera dans le cache le serveur de l’attaquant, et transfèrera à celui-ci la requête de la victime, avec le mot de passe.

Une nouvelle version de Zimbra qui corrige la faille a été publiée en mai.

🛡 Comment se protéger ?

• Sur une application qui utilise Memcached : à l’envoi de données à Memcached, valider celles-ci, spécialement si elles sont construites dynamiquement et contiennent des données envoyées par un utilisateur de l’attaquant : il faut faire en sorte de ne pas envoyer de caractères spéciaux. Pour Memcached, il suffit par exemple de vérifier qu’il n’y a pas de sauts de ligne.
  Par exemple, Zimbra a utilisé une fonction de hachage pour transformer la clef stockée dans Memcached. Le résultat est sous forme hexadécimale, il n’y a donc pas de caractère “\”. Pas de “\”, pas de saut de ligne. Pas de saut de ligne, pas d’injection.
• En cas d’utilisation de Zimbra (Open-Source) : Assurez-vous d’utiliser la dernière version de Zimbra (nous recommandons les versions 8.8.15 patch 32 ou 9.0.0 patch 25 au moins)

🏹 Pour aller plus loin

• L’attaque présentée nécessite de connaître l’adresse de la victime. Il est en fait possible de récupérer mots de passe et adresses mail sans même connaître à l’avance une adresse mail. Un article de blog par l’équipe de Sonar décrit les deux attaques, avec encore plus de détails techniques.
• Le commit de correction dans le code de Zimbra : https://github.com/Zimbra/zm-mailbox/commit/e85775067c98eba6055a7c0d316af6abceba8f0b
• Une vidéo de 30s de l’attaque en action

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité par mail security@theodo.fr.