Injection d’e-mails

Qu’est-ce que l’injection d’e-mails ?

L’injection d’e-mails est une vulnérabilité qui permet à un pirate malveillant d’abuser des fonctionnalités liées aux e-mails, telles que les formulaires de contact par e-mail sur les pages Web, pour envoyer du contenu d’e-mail malveillant à des destinataires arbitraires. Étant donné que l’injection d’e-mails est basée sur l’injection de caractères de fin de ligne, elle est parfois considérée comme un type d’ attaque par injection CRLF . L’injection de courrier électronique est également appelée injection d’en-tête de courrier électronique , injection d’en-tête SMTP ou injection de commande de courrier .

Gravité:		grave
Prévalence:		découvert rarement
Portée:		uniquement dans les fonctionnalités liées aux e-mails
Impact technique :		envoyer des e-mails arbitraires à n’importe quelle adresse
Conséquences dans le pire des cas :		devenir complice d’actes criminels, d’hameçonnage
Solution rapide:		ne pas transmettre l’entrée de l’utilisateur aux fonctions de messagerie

Comment fonctionne SMTP

Pour comprendre l’injection d’en-tête SMTP, nous devons commencer par examiner SMTP – le protocole de transfert de courrier simple.

SMTP est l’un des plus anciens protocoles d’Internet, défini pour la première fois en 1981 dans la RFC 788 . Initialement, il acceptait un petit ensemble de commandes qui déclaraient l’expéditeur et les destinataires de l’e-mail. Au fur et à mesure que la communication par e-mail devenait plus complexe, des en-têtes supplémentaires ont été ajoutés.

Le premier concept SMTP crucial est la différence entre l’enveloppe et le corps de l’e-mail. L’enveloppe est la partie initiale de la communication et est définie par le protocole SMTP lui-même. Les commandes suivantes constituent l’enveloppe :

• MAIL FROM : Définit l’expéditeur de l’enveloppe.
• RCPT TO : Définit le destinataire de l’enveloppe. Cette commande peut être utilisée plusieurs fois si vous envoyez un message à plusieurs adresses.
• DATA : commence la charge utile de l’e-mail, qui se compose des en-têtes d’e-mail et du corps du message, séparés par une seule ligne vide. Le message se termine par l’envoi d’une ligne contenant uniquement un point ( . ).

Les en-têtes des e-mails ne font pas partie du protocole SMTP. Ils sont interprétés par des clients de messagerie (pour afficher correctement l’e-mail) et par des bibliothèques d’e-mails dédiées disponibles dans différents langages de programmation. Les deux en-têtes les plus courants sont :

• From : Cet en-tête définit l’expéditeur visible, qui peut être une adresse différente de celle définie à l’aide de la commande MAIL FROM . Dans la plupart des clients de messagerie, les informations sur l’expéditeur obtenues à partir de la commande MAIL FROM sont placées dans l’ en-tête Return-Path , qui est masqué par défaut pour l’utilisateur.
• To : Cet en-tête définit le destinataire visible, qui peut différer de l’adresse définie à l’aide de RCPT TO . Dans la plupart des clients de messagerie, les informations sur le destinataire de la commande RCPT TO sont placées dans l’ en-tête Delivered-To , qui est masqué par défaut pour l’utilisateur.

Voici un exemple de dialogue SMTP simple ( >= envoyé, <= reçu) :

> MAIL FROM:
  < 250 OK
> RCPT TO:
  < 250 OK
> RCPT TO:
  < 250 OK
> DATA
  < 354 Send message content; end with .
> Content-Type: text/html
> Date: Wed, 25 Dec 2019 00:00:01
> From: Santa Claus 
> Subject: Your Gifts Are Here
> To: Not Naughty 
>
> Hello!
> Your gifts are here, come to the tree!
> --
> Santa
> .
  < 250 OK

L’e-mail ci-dessus de [email protected] serait reçu par [email protected] et [email protected] . Cependant, pour les utilisateurs, il semblerait que le message ait été envoyé par le Père Noël (et non [email protected] ). Au lieu de leur propre adresse, ils verraient également que le destinataire est Not Naughty . À moins qu’Anna et Barbara n’ouvrent manuellement les en-têtes d’e-mail dans leur client de messagerie, elles ne verraient pas du tout le véritable expéditeur.

Fonctionnement de l’injection d’e-mails

L’injection d’e-mails fonctionne en insérant des caractères de nouvelle ligne dans l’entrée de l’utilisateur. Si l’entrée n’est pas filtrée, un pirate malveillant peut ajouter des en-têtes d’e-mail ou modifier le corps du message. En terminant leur charge utile malveillante avec une ligne qui ne contient qu’un point, les attaquants peuvent signaler la fin du message, incitant le serveur de messagerie à ignorer tout contenu légitime que le script back-end est censé envoyer.

La plupart des bibliothèques de messagerie dans les langages de programmation Web ne vous permettent pas d’ajouter directement des commandes d’enveloppe. Au lieu de cela, ils prennent les en-têtes de courrier électronique que vous fournissez et les convertissent souvent en commandes SMTP équivalentes. Par exemple, si vous ajoutez un en-tête BCC , votre bibliothèque de messagerie peut prendre le contenu de l’en-tête et créer des commandes RCPT TO supplémentaires . Si un attaquant est capable d’ajouter des en-têtes de courrier électronique à l’aide de cette bibliothèque spécifique, les en-têtes seront convertis en commandes SMTP équivalentes.

Exemple d’attaque par injection de courrier électronique

L’exemple PHP suivant est un formulaire de contact typique ( contact.php ) vulnérable à l’injection d’en-tête d’e-mail. Il prend le nom et l’adresse e-mail directement à partir des champs de saisie et prépare une liste d’en-têtes pour l’e-mail.

if(isset($_POST['name'])) {
$name = $_POST['name'];
$replyto = $_POST['replyTo'];
$message = $_POST['message'];
$to = 'root@localhost';
$subject = 'My Subject';
// Set SMTP headers
$headers = "From: $name \n" .
"Reply-To: $replyto";
mail($to, $subject, $message, $headers);
}
?>

Une requête POST non malveillante soumise par un utilisateur serait la suivante :

POST /contact.php HTTP/1.1
Host: www.example2.com
name=Anna [email protected]&message=Hello

Un attaquant pourrait abuser de ce formulaire de contact et injecter des données d’e-mail en envoyant la requête POST suivante :

POST /contact.php HTTP/1.1
Host: www.example2.com
name=Best Product\r\nbcc: [email protected][email protected]&message=Buy my product!

L’attaquant insère une nouvelle ligne ( \r\n – retour chariot et saut de ligne, CRLF ) et ajoute un en-tête BCC contenant des adresses e-mail supplémentaires. La bibliothèque de messagerie convertit ces adresses en commandes RCPT TO et transmet le message non seulement au destinataire prévu, mais également à ces adresses supplémentaires. Cette attaque implique également l’usurpation d’un en-tête replyTo pour faire croire au destinataire que l’e-mail provient de quelqu’un d’autre ( [email protected] ).

Conséquences potentielles d’une attaque par injection de courrier électronique

Les vulnérabilités d’injection d’e-mails sont considérées comme un grave problème de cybersécurité. Bien qu’elles ne nuisent pas directement à l’application Web présentant la faille de sécurité ou à son serveur Web, les injections d’e-mails peuvent permettre aux attaquants d’envoyer des e-mails au contenu arbitraire à des destinataires arbitraires dans une grande variété d’attaques.

Les vecteurs d’attaque par injection d’e-mails les plus courants incluent :

• Spam : Un utilisateur malveillant pourrait utiliser l’injection de courrier électronique pour envoyer des messages de spam. Une ligne de code avec une injection d’e-mail réussie pourrait leur permettre de forcer le serveur de messagerie de la victime à envoyer plusieurs e-mails avec le même contenu à de nombreux destinataires.
• Phishing : un attaquant pourrait envoyer des e-mails de phishing qui semblent provenir du serveur de messagerie, du domaine et de l’adresse IP de la victime. En tant que tel, l’agresseur serait introuvable et le blâme incomberait à la victime. Si l’application de la victime présente également une vulnérabilité de type cross-site scripting (XSS) et que les liens contenus dans l’e-mail de phishing pointent vers cette application vulnérable, l’e-mail apparaît encore plus légitime.
• Spear phishing : Pour aller plus loin, les attaquants pourraient envoyer des e-mails de spear phishing d’apparence légitime à certains employés de l’entreprise qui exécute l’application vulnérable. Par exemple, ils pourraient envoyer au service financier un e-mail convaincant qui semble provenir du directeur financier et demande de toute urgence un virement bancaire important sur le compte de l’attaquant.

Comment détecter les vulnérabilités d’injection d’email ?

La meilleure façon de détecter les vulnérabilités d’injection d’e-mails dépend de si elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, il peut suffire d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est susceptible d’être injectée par courrier électronique, vous pouvez supposer que votre logiciel est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) pour les applications Web ou un analyseur de réseau pour les systèmes et applications en réseau.Si vous développez votre propre logiciel ou si vous souhaitez avoir la possibilité de trouver des vulnérabilités d’injection d’e-mails jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité d’injection d’e-mails pour être certain qu’elle existe. Cela nécessite soit d’effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité, soit d’utiliser un outil d’analyse des vulnérabilités capable d’exploiter automatiquement les vulnérabilités Web. 

Notez que l’injection d’e-mails est une vulnérabilité hors bande, ce qui signifie que l’attaquant ne reçoit pas de réponse directe à ses actions. Pour détecter automatiquement les vulnérabilités hors bande, le scanner de vulnérabilité a besoin d’un service intermédiaire. Les produits Cycuri utilisent des services intermédiaires dédiés pour détecter les vulnérabilités hors bande, y compris les injections d’en-tête de courrier électronique.

Comment prévenir les vulnérabilités d’injection d’e-mails ?

Pour empêcher l’injection d’e-mails, les développeurs doivent suivre les meilleures pratiques de sécurité des applications consistant à traiter toutes les entrées utilisateur comme non fiables et à les nettoyer à l’aide de la filtration des entrées et/ou de l’encodage des sorties. Ce conseil s’applique non seulement à l’injection d’e-mails, mais également à la plupart des autres vulnérabilités de sécurité Web, y compris les scripts intersites, l’injection HTML et l’injection SQL . Les pratiques recommandées pour l’injection d’e-mails sont :

• Assurez-vous que votre code n’utilise jamais directement le contenu fourni par l’utilisateur lors de la spécification des paramètres de commande pour les fonctions utilisées pour envoyer des e-mails, telles que mail() en PHP.

• Désinfectez automatiquement les entrées de l’utilisateur et supprimez tous les caractères de retour à la ligne avant de transmettre le contenu aux fonctions de messagerie. Pour la validation des entrées, utilisez une liste blanche de caractères autorisés et supprimez ceux qui ne figurent pas sur la liste.
• Encode toutes les données transmises aux fonctions de messagerie. Cela brouillera tous les codes CR et LF que les attaquants tentent d’injecter.

Comment atténuer les attaques par injection d’e-mail ?

Vous pouvez atténuer les attaques par injection d’e-mails à plusieurs niveaux, même si des vulnérabilités d’injection d’en-tête d’e-mail existent dans vos applications Web :

• Atténuation au niveau de l’environnement de développement : autorisez vos programmeurs à n’utiliser que des environnements de développement, des bibliothèques et des fonctions sûrs. Certaines bibliothèques de messagerie sont naturellement résistantes à l’injection de courrier électronique. Par exemple, SMTPLIB en Python est sûr car SMTP.sendmail() vous oblige à spécifier une liste explicite de destinataires. Si un attaquant ajoute des en-têtes, cela ne changera que la façon dont l’e-mail apparaît.
• Atténuation au niveau du serveur Web : bloquez complètement les fonctions de messagerie non sécurisées et créez une API de messagerie sécurisée que vos développeurs sont tenus d’utiliser. Par exemple, vous pouvez désactiver la fonction non sécurisée PHP mail() en utilisant la directive disable_functions dans php.ini . Une autre option consiste à bloquer complètement la fonctionnalité de messagerie côté serveur et à obliger vos développeurs à envoyer des e-mails via des services spécialisés, comme AWS Amazon Simple Email Service (SES).
• Atténuation au niveau du serveur SMTP : utilisez un serveur SMTP distinct pour les applications Web personnalisées. Sur ce serveur, vous pouvez limiter le débit de vos e-mails et bloquer les e-mails qui ont, par exemple, plus de 10 destinataires. Configurez des alertes pour avertir l’administrateur des tentatives bloquées et de toute autre condition inhabituelle. Supprimez ces limites uniquement pour les applications approuvées. Bien que cela ne vous protège pas contre le spear phishing via l’injection d’e-mails, cela éliminera le risque d’injections d’e-mails conduisant à des attaques par publipostage de masse, telles que le spam ou le phishing.