Bannière de contrebande SMTP
Il ya quelques jours, Les chercheurs de SEC Consult ont révélé, via un article de blog, des informations sur une nouvelle technique d'attaque appelée SMTP Smuggling, ce qui peut permettre d'envoyer de faux e-mails qui contournent les mécanismes d'authentification.
Il est mentionné que la technique d'attaque cible le protocole SMTP, dans lequel un attaquant peut exploiter les différences dans la manière dont les serveurs SMTP sortants et entrants interprètent une séquence indiquant la fin des données du message.
À propos de la contrebande SMTP
La contrebande SMTP est une nouvelle technique qui permet de diviser un message en plusieurs messages différents lors de sa transmission par le serveur SMTP original vers un autre serveur SMTP, qui interprète la séquence différemment pour séparer les lettres transmises via une connexion.
Cette permet l'injection de commandes SMTP dans les messages électroniques de manière à ce que les serveurs de réception les traitent comme deux messages distincts, dont l'un comporte des en-têtes : "À : destinataire@domaine.com", "De : expéditeur@domaine.com", "Objet : Exemple de sujet", suivis par le corps même du message.
De plus, comme l’enveloppe du message principal réussit les contrôles de sécurité tels que SPF, DKIM et DMARC, le message falsifié est envoyé dans les boîtes de réception sans avertissement.
"La contrebande SMTP est une nouvelle technique d'usurpation d'e-mails qui permet aux attaquants d'envoyer des e-mails avec de fausses adresses d'expéditeur (par exemple ceo@microsoft.com) pour usurper l'identité de quelqu'un d'autre", explique Longin à Dark Reading. "Il existe généralement certaines mesures d'atténuation dans l'infrastructure de messagerie pour limiter de telles attaques, mais avec la nouvelle approche, un e-mail usurpé sera envoyé."
La nouvelle attaque, appelée contrebande SMTP, Il a été conçu par Timo Longin, consultant senior en sécurité chez SEC Consult. Longine a emprunté le concept principal de une autre classe d'attaques connue sous le nom Contrebande de requêtes HTTP, où les attaquants trompent un équilibreur de charge frontal ou un proxy inverse pour qu'il transmette des requêtes spécialement conçues à un serveur d'applications back-end de manière à ce que le back-end du serveur final les traite comme deux requêtes distinctes au lieu d'une.
Sur cette base, SMTP Smuggling profite du fait que les serveurs SMTP interprètent différemment la fin du flux de données, ce qui peut provoquer la division d'une lettre en plusieurs au sein d'une même session sur le serveur SMTP.
Cette séquence peut être suivi de commandes pour envoyer un autre message sans rompre la connexion. Certains serveurs SMTP suivent strictement la prescription, mais d'autres, pour assurer la compatibilité avec certains clients de messagerie peu courants.
L'attaque se résume au fait qu'une lettre est envoyée au premier serveur, qui traite uniquement le délimiteur "\r\n.\r\n", dans le corps duquel se trouve un délimiteur alternatif, par exemple "\ r.\r », suivi de commandes qui envoient un deuxième message. Puisque le premier serveur suit strictement la spécification, il traite la chaîne reçue comme une seule lettre.
Si la lettre est ensuite envoyée à un serveur de transit ou à un serveur destinataire acceptant également la séquence "\r.\r" comme séparateur, elle sera traitée comme deux lettres envoyées séparément (la deuxième lettre peut être envoyée pour le compte d'un utilisateur non authentifié via "AUTH LOGIN", mais apparaît correct du côté du destinataire).
Il est mentionné que Le problème a déjà été résolu dans les dernières versions de Postfix dans lequel la configuration «smtpd_forbid_unauth_pipelining", ce qui entraîne l'échec de la connexion si les délimiteurs ne sont pas conformes aux RFC 2920 et RFC 5321. Ce paramètre est désactivé par défaut, mais ils prévoient de l'activer par défaut dans la branche Postfix 3.9, attendue en 2024.
De plus, la configuration a été ajoutée smtpd_forbid_bare_newline, désactivé par défaut, ce qui interdit l'utilisation du caractère de saut de ligne ("\n") pour séparer les lignes sans retour. J'ai également ajouté le paramètre smtpd_forbid_bare_newline_exclusions, qui permet de désactiver la restriction du support "\n" pour les clients du réseau local.
Du côté de Sendmail, il fournit une option 'ou' pour se protéger contre les attaques dans srv_features, qui permet de traiter uniquement la séquence "\r\n.\r\n".
Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.