Cette menace affecte toutes les applications qui communiquent avec les serveurs de messagerie (IMAP / SMTP), et généralement des applications de messagerie Web. Le but de ce test est de vérifier la capacité d'injecter des commandes IMAP / SMTP arbitraires dans les serveurs de messagerie, si les données d'entrée ne sont pas correctement filtrées.

La technique d'injection IMAP / SMTP est plus efficace si le serveur de messagerie n'est pas directement accessible depuis Internet. Lorsque la communication complète avec le serveur de messagerie backend est possible, il est recommandé de faire un test direct.

Une Injection IMAP / SMTP permet d'accéder à un serveur de messagerie qui, autrement, ne serait pas directement accessible depuis Internet. Dans certains cas, ces systèmes internes n'ont pas le même niveau d'infrastructure de sécurité et de durcissement appliqués sur les serveurs Web frontaux. Par conséquent, les serveurs de messagerie peuvent être plus vulnérables à des attaques par des utilisateurs finaux (voir le schéma présenté dans la figure 1).

Figure 1 - La communication avec les serveurs de messagerie en utilisant la technique d'injection IMAP / SMTP.

La figure 1 illustre le flux du trafic généralement établi lors de l'utilisation des technologies de messagerie Web. Dans les étapes 1 et 2 l'utilisateur interagit avec le client webmail, alors que dans l'étape 2 le testeur contourne le client webmail et d'interagit avec les serveurs de messagerie dorsaux directement.

Cette technique permet une grande variété d'actions et d'attaques. Les possibilités dépendent du type et de la portée de l'injection et de la technologie serveur de messagerie en cours de test.

Quelques exemples d'attaques en utilisant la technique d'injection IMAP / SMTP sont les suivants:

• L'exploitation de vulnérabilités dans le protocole IMAP / SMTP
• Évasion des restrictions de l'application
• Évasion des des processus anti-automates
• Fuites d'informations
• Relais / SPAM

Les schémas d'attaque standard sont:

• Identifier les paramètres vulnérables
• Comprendre le flux de données et la structure de déploiement du client
• Injection de commandes IMAP / SMTP

Afin de détecter les paramètres vulnérables, le testeur doit analyser la capacité de l'application dans la gestion des entrées. Pour cela le testeur doit envoyer des requêtes fausses ou malveillantes au serveur et analyser la réponse. Dans une application sécurisée, la réponse doit être une erreur avec une action correspondante indiquant au client que quelque chose a mal tourné. Dans une application vulnérable, les demandes malveillantes peuvent être traitées par l'application back-end qui va répondre avec un message de réponse “HTTP 200 OK”.

Il est important de noter que les requêtes envoyées doivent correspondre à la technologie testée. L'envoi de chaînes par injection SQL pour Microsoft SQL serveur lorsque le serveur MySQL est utilisé se traduira par de fausses réponses positives. Dans ce cas, l'envoi des commandes IMAP malveillantes est le modus operandi puisque IMAP est le protocole sous-jacent.

Les paramètres IMAP spéciaux qui doivent être utilisés sont les suivants:

Dans cet exemple, le paramètre “mailbox” est testé par la manipulation de toutes les requêtes avec ce paramètre:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1

Les exemples suivants peuvent être utilisés.

• Attribuer une valeur null pour le paramètre:

http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1

• Remplacez la valeur avec une valeur aléatoire:

http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1

• Ajouter d'autres valeurs au paramètre:

http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1

• Ajouter des caractères spéciaux non standard (par exemple: \, ', “, @, #, !, |):

http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1

• Éliminer le paramètre:

http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1

Le résultat final de l'essai ci-dessus donne au testeur trois situations possibles:

• S1 - L'application renvoie un code / message d'erreur
• S2 - L'application ne retourne pas de code / message d'erreur, mais il ne réalise pas l'opération demandée
• S3 - L'application ne renvoie pas un code / message d'erreur et réalise l'opération demandée normalement

Les situations S1 et S2 représentent une injection IMAP / SMTP avec succès,

Un attaquant qui est dans la situation S1 a atteint son but, car c'est l'indicateur que l'application est vulnérable à l'injection et à la manipulation.

Supposons qu'un utilisateur récupère les en-têtes des mails en utilisant la requête HTTP suivante:

http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0

Un attaquant peut modifier la valeur du paramètre MAILBOX en injectant le caractère ” (%22 en utilisant le codage URL):

http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0

Dans ce cas, la réponse de l'application peut être:

ERROR: Bad or malformed request.
Query: SELECT "INBOX""
Server responded: Unexpected extra arguments to Select

La situation S2 est plus difficile à tester avec succès. Le testeur a besoin d'utiliser l'injection de commandes aveugle afin de déterminer si le serveur est vulnérable.

D'autre part, la dernière situation (S3) n'est pas traitée dans ce paragraphe.

Résultats attendus:

• Liste des paramètres vulnérables
• Fonctionnalités affectées
• Type d'injection possible (IMAP / SMTP)

Après avoir identifié tous les paramètres vulnérables (par exemple, “passed_id”), le testeur doit déterminer le niveau d'injection possible, puis concevoir un plan de test afin de l'exploiter davantage dans l'application.

Dans le cas testé, nous avons constaté que le paramètre “passed_id” de l'application est vulnérable et est utilisé dans la demande ci-après:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1

En utilisant le test suivant (fournir une valeur alphabétique lorsqu'une valeur numérique est requise):

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1

va générer le message d'erreur suivant:

ERROR : Bad or malformed request.
Query: FETCH test:test BODY[HEADER]
Server responded: Error in IMAP command received by server.

Dans cet exemple, le message d'erreur retourne le nom de la commande exécutée et les paramètres correspondants.

Dans d'autres cas, le message d'erreur (“non contrôlé” par l'application) contient le nom de la commande exécutée, mais la lecture de la RFC appropriée (voir paragraphe “Références”) permet au testeur de comprendre que d'autres commandes peuvent être exécutées.

Si la demande ne renvoie pas de description des messages d'erreur, le testeur a doit analyser la fonction affectée pour déduire toutes les commandes possibles, et les paramètres () associés à la fonctionnalité ci-dessus mentionnée. Par exemple, si un paramètre vulnérable a été détecté dans la fonctionnalité de création des MAILBOX, il est logique de supposer que la commande IMAP “CREATE” est affectée . Selon la RFC, la commande CREATE accepte un paramètre qui spécifie le nom de la boîte aux lettres à créer.

Résultats attendus:

• Liste des commandes IMAP / SMTP affectées
• Le type, la valeur et le nombre de paramètres attendus par les commandes IMAP / SMTP concernées

Une fois que le testeur a identifié les paramètres vulnérables et a analysé le contexte dans lequel ils sont exécutés, la prochaine étape est d'exploiter la fonctionnalité.

Cette étape comporte deux résultats possibles:

• L'injection est possible dans un état non authentifié: la fonctionnalité concernée ne nécessite pas que l'utilisateur soit authentifié. Les commandes (IMAP) disponibles pour l'injection sont limitées à: CAPABILITY, NOOP, AUTHENTICATE, LOGIN et LOGOUT.
• L'injection n'est possible que dans un état authentifié: l'exploitation réussie nécessite que l'utilisateur soit authentifié avant de pouvoir continuer les tests,

Dans tous les cas, la structure typique d'une injection IMAP / SMTP est le suivant:

**Header:** termine la commande attendue;
**Body:** injection de la nouvelle commande;
**Footer :** début de la commande attendue.

Il est important de se rappeler que, dans le but d'exécuter une commande IMAP / SMTP, la commande précédente doit être terminée par la séquence CRLF (%0d%0a). Supposons que dans l'étape 1 («Identification des paramètres vulnérables“), l'attaquant détecte que le paramètre “message_id” dans l'application est vulnérable:

http://<webmail>/read_email.php?message_id=4791

Supposons également que les résultats de l'analyse effectuée à l'étape 2 («Comprendre le flux de données et la structure de déploiement du client») a identifié la commande et les arguments associés à ce paramètre:

FETCH 4791 BODY[HEADER]

Dans ce scénario, la structure d'injection IMAP serait:

http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791

Qui génèrent les commandes suivantes:

???? FETCH 4791 BODY[HEADER]
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]

où:

Header = 4791 BODY[HEADER]
Body   = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791 

Résultat attendu:

• Injection arbitraire de commandes IMAP / SMTP

• RFC 0821 “Simple Mail Transfer Protocol”.

  • RFC 3501 “Internet Message Access Protocol - Version 4rev1”.
  • Vicente Aguilera Díaz- “MX Injection: Capturing and Exploiting Hidden Mail Servers” - http://www.webappsec.org/projects/articles/121106.pdf