Un produit de webmail est une application web qui rend le courrier depuis un magasin IMAP et l'envoie via un relais SMTP. Tout ce qui le rend utile est aussi la surface d'attaque : il analyse et affiche du courrier HTML fourni par l'attaquant, il récupère du contenu distant, il stocke les préférences et plugins par utilisateur sur le disque, et il détient des cookies de session de longue durée vers des boîtes aux lettres. Un hôte de webmail est donc attaqué sur deux plans à la fois. Le plan web est l'application PHP ou Java elle-même : XSS stocké dans le rendu des messages qui se déclenche quand la victime ouvre votre courrier, falsification de requête côté serveur depuis les récupérations d'images distantes ou de calendrier, failles d'authentification et de traitement de jetons, et écritures de fichiers sous la racine web qui deviennent une exécution de code. Le plan courrier est le back end IMAP/SMTP vers lequel le front relaie, joignable une fois que vous disposez d'une session ou d'un identifiant de back end.
La propriété décisive est que vous délivrez la charge utile par e-mail. Contrairement à une application web normale où il vous faut que la victime visite un lien, un XSS stocké dans le rendu des messages s'exécute au moment où la cible lit un message que vous lui avez envoyé, avec sa session, à l'intérieur de l'origine de sa boîte aux lettres. Cela transforme un seul message forgé en vol de session, envoi silencieux au nom de la victime, et exfiltration de la boîte aux lettres.
Identifier quel webmail#
Identifiez le produit et la version avant toute chose : le chemin d'exploitation est entièrement spécifique au produit, et la version décide quel contournement du rendu des messages ou quelle chaîne d'écriture de fichier s'applique.
# Login-page and path fingerprints
curl -sk https://<target>/ -i | grep -iE 'server:|x-powered-by|set-cookie'
curl -sk https://<target>/?_task=login -i # Roundcube: redirects/renders its login
curl -sk https://<target>/horde/ -i # Horde: /horde/ application root
curl -sk https://<target>/zimbra/ -i # Zimbra web client
curl -sk https://<target>:7071/zimbraAdmin/ -i # Zimbra admin console (separate port)
Lisez les signaux :
- Roundcube : l'URL de connexion porte
?_task=login, le cookie de session estroundcube_sessid(etroundcube_sessauth), et le balisage référenceprogram/js/etskins/. La version est dansCHANGELOG.mdà la racine web sur beaucoup d'installations, ou dans la requête d'asset?s=<hash>. - Horde : une racine d'application à
/horde/, le cookieHorde, le formulaire de connexion postant vers/horde/login.php, et le module de webmail nommé IMP. Une<meta name="generator">ou l'arborescence/horde/services/le confirme. - Zimbra : le client sous
/zimbra/, la console d'administration sur 7071 à/zimbraAdmin/, les points de terminaison SOAP/service/soapet/service/admin/soap, les cookiesZM_AUTH_TOKENetZM_ADMIN_AUTH_TOKEN. Les chaînes de version apparaissent dans les chemins d'assets/zimbra/js/. - Favicon et generator : hachez le favicon (
curl -sk https://<target>/favicon.ico | md5sum) contre une table de produits connus, et cherchez au grep dans le HTML<meta name="generator">, que Roundcube et Horde émettent tous deux.
Une fois le produit et la version connus, allez à la page correspondante et partez de sa propre section d'identification.
Pages#
- Roundcube : XSS stocké dans le rendu des messages HTML (contournements de
rcube_washtml), traversée de chemin dans les skins et plugins, et les chaînes d'écriture de fichier vers PHP. - Horde : CSRF contre les points de terminaison admin et préférences, injection de préférences et de formulaires, et l'injection de commandes via le gestionnaire d'images vers RCE.
Sous-rubriques#
- Zimbra : la Collaboration Suite complète, de l'énumération de comptes et l'abus de jeton admin à l'écriture de web shell
mboximportet la chaîne SSRF ProxyServlet vers admin.