SMTP Smuggling
Last updated
Last updated
Ce type de vulnérabilité a été découvert à l'origine dans ce post où il est expliqué qu'il est possible d'exploiter les divergences dans la façon dont le protocole SMTP est interprété lors de la finalisation d'un e-mail, permettant à un attaquant de faire passer plus d'e-mails dans le corps de l'e-mail légitime, permettant d'usurper d'autres utilisateurs du domaine affecté (comme admin@outlook.com) en contournant les défenses telles que SPF.
Cela est dû au fait que dans le protocole SMTP, les données du message à envoyer dans l'e-mail sont contrôlées par un utilisateur (attaquant) qui pourrait envoyer des données spécialement conçues en abusant des différences dans les analyseurs qui feront passer des e-mails supplémentaires dans le récepteur. Jetez un œil à cet exemple illustré du post original :
Pour exploiter cette vulnérabilité, un attaquant doit envoyer des données que le serveur SMTP sortant pense être juste 1 e-mail mais que le serveur SMTP entrant pense être plusieurs e-mails.
Les chercheurs ont découvert que différents serveurs entrants considèrent différentes caractères comme la fin des données du message e-mail que les serveurs sortants ne considèrent pas.
Par exemple, une fin régulière des données est \r\n.\r. Mais si le serveur SMTP entrant prend également en charge \n., un attaquant pourrait simplement ajouter ces données dans son e-mail et commencer à indiquer les commandes SMTP de nouveaux pour les faire passer comme dans l'image précédente.
Bien sûr, cela ne fonctionnerait que si le serveur SMTP sortant ne traite pas non plus ces données comme la fin des données du message, car dans ce cas, il verrait 2 e-mails au lieu d'un seul, donc à la fin, c'est la désynchronisation qui est exploitée dans cette vulnérabilité.
Données potentielles de désynchronisation :
\n.
\n.\r
Notez également que le SPF est contourné car si vous faites passer un e-mail de admin@outlook.com pour un e-mail de user@outlook.com, l'expéditeur reste outlook.com.
