Bounce : l’attaque par rebond de mail

En matière de stratégie antispam, on peut penser que les bounces constituent un moyen pratique pour rejeter les mails adressés à un utilisateur inexistant  dans un domaine. Cette technique présente cependant de sérieux risques pour vos serveurs de mails.

Lorsque votre serveur mail détecte un problème insurmontable dans la délivrance d’un courrier électronique, il émet un bounce, un mail automatisé envoyé à l’expéditeur du message original pour lui signifier qu’il n’a pu effectuer la livraison. Dans le cas qui nous intéresse (la lutte antispam), le problème insurmontable est l’inexistence d’un compte utilisateur destinataire du mail dans notre domaine. L’inverse est également vrai : beaucoup de titulaires d’un nom de domaine voient une croissance importante du nombre de messages électroniques qu’ils reçoivent. Après analyse, ils constatent qu’ils reçoivent un très grand nombre de bounces en provenance d’autres serveurs de mails. C’est le signe qu’un spammeur a usurpé leur nom de domaine pour inonder des milliers d’adresses prises au hasard.

Examinons quel serveur a la responsabilité d’envoyer les bounces en cas d’erreur, d’après la RFC du SMTP :
– si le serveur destinataire accepte tous les destinataires, et qu’il détecte ensuite un problème (ex : il doit rediriger le message vers un autre serveur et ce second serveur annonce que l’utilisateur n’existe pas ; ou qu’il envoie l’adresse vers une boîte et que la boîte est pleine), il a la charge d’envoyer un NDN (Non Delivery Notification) à l’expéditeur.
– si le serveur destinataire accepte au moins un destinataire et refuse tous les autres, il a la responsabilité d’éventuels bounces pour celui qu’il accepte tandis que c’est le serveur émetteur qui doit bouncer les expéditeurs refusés.
– si le serveur destinataire refuse tous les messages, c’est le serveur émetteur qui doit envoyer tous les NDN.

En environnement d’entreprise, il est courant d’utiliser plusieurs serveurs de mails pour traiter le courrier, pour des raisons de sécurité, de traitement, de répartition de charges, de routage … Dans ce cas, un serveur sert le plus souvent de passerelle : il accepte tous les mails en provenance de l’Internet et les envoie ensuite soit vers un serveur interne, soit vers un antivirus ou un antispam. Cette passerelle est rarement configurée pour vérifier l’existence des utilisateurs : elle est là pour accepter tous les mails à destination du domaine et les router. A charge pour les serveurs internes d’effectuer la vérification. Tout cela nous amène aux problèmes suivants :
– on peut usurper l’dentité du destinataire du bounce avec un faux reply-to, ou même un faux émetteur. Le destinataire recevra alors un NDN pour un message qu’il n’a jamais reçu. Le NDN contenant une copie du mail original, l’attaquant pourra y joindre aisément un virus, trojan ou une bombe de compression.
– si le serveur envoie un bounce individuellement à chaque destinataire invalide, on peut l’utiliser pour attaquer une adresse mail. Imaginons que l’attaquant envoie un seul mail à 100 destinataires invalides avec un faux reply-to. Le reply-to usurpé recevra en retour une centaine de bounces, soit un excellent rapport de 1 contre 100 pour le spammeur (et le chiffre peut s’élever davantage).

Tout est donc en place pour des manœuvres de plus grande envergure. Un attaquant envoie un unique mail au domaine d’une organisation, avec les caractéristiques suivantes : une pièce jointe d’une certaine taille, envoyée en Cc : à un grand nombre de destinataires invalides du domaine, et avec un faux reply-to. La passerelle du domaine accepte tous les mails puisqu’ils sont tous de son domaine. Elle effectue divers traitements (anti-virus, antispam) et le transmet à un serveur de mails interne. Ce serveur interne découvre que les destinataires sont invalides, et envoie un bounce pour chaque destinataire invalide au faux reply-to. Le serveur de mails du reply-to se retrouve alors à traiter un immense nombre de messages alors qu’il n’a jamais envoyé un mail au domaine.
L’attaquant se retrouve ainsi à disposer d’une force multiplicatrice importante même sans disposer de la ressource équivalente. Il peut ainsi soit envoyer du spam en tout anonymat et sans consommer des ressources, ou se servir de serveurs sans limite de nombre de destinataires en Cc : pour flooder un serveur tiers au point de générer un DoS.

Les solutions ?
–    Isolez vos serveurs de mails de l’Internet en plaçant un tiers qui dispose des compétences nécessaires pour traiter les bounces , pour vous protèger ainsi de l’utilisation de vos serveurs pour envoyer des bounces-spams (ce qui risque de vous faire blacklister), pour vous éviter de recevoir des faux bounces résultant de l’utilisation de votre domaine en reply-to et enfin pour économiser vos précieuses ressources.
–    Utilisez un relais capable de gérer des call-out.

Afin d’éviter tous ces risques, nous vous conseillons de configurer votre serveur de mails pour qu’il fasse du filtrage destinataire dans le protocole SMTP plutôt que du Bounce.