This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.8.11 Injections IMAP SMTP (OTG-INPVAL-011)

From OWASP
Jump to: navigation, search 
This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Cette menace impacte toutes les applications, généralement les webmail, communiquant avec des serveurs e-mail (IMAP/SMTP). Le but du test est de vérifier si l'on peut injecter des commandes IMAP/SMTP arbitraires dans les serveurs e-mail, en profitant d'un manque de validation des entrées.


La technique d'injection IMAP/SMTP est plus efficace so le serveur e-mail n'est pas directement accessible depuis Internet. Si la communication complète avec le serveur e-mail est possible, il est recommander de faire un test direct.


Une injection IMAP/SMTP permet d'accéder à un serveur e-mail qui n'est pas directement accessible depuis Internet. Dans certains cas, ces systèmes internes n'ont pas le même niveau de sécurité et de durcissement que celui appliqué aux serveurs web frontaux. Ces serveurs e-mail peuvent être plus vulnérables aux attaques venus d'utilisateurs (voir le schéma présenté en figure 1).

Imap-smtp-injection.png
Figure 1 - Communication avec les serveurs e-mail utilisant une technique d'injection IMAP/SMTP


La figure 1 illustre le flux de trafic généralement constaté quand on utilise les technologies webmail. Les étapes 1 et 2 montrent les interactions avec le client webmail, alors que l'étape 3 montre le testeur contournant les client webmail et interagissant directement avec les serveurs e-mail.


Cette technique permet une large gamme d'actions et d'attaques. Les possibilités dépendent du type et du périmètre d'injection, et de la technologie de serveur e-mail testée.


Quelques exemples d'attaque utilisant les injection IMAP/SMTP :

  • Exploitation de vulnérabilités dans les protocols IMAP et SMTP
  • Contournement de restrictions applicatives
  • Contournement de processus d'anti-automatisation
  • Fuites d'informations
  • Relais et SPAM


Comment tester

Les schémas d'attaque standards sont :

  • Identification des paramètres vulnérables
  • Compréhension du flux de données et de la structure de déploiement du client
  • Injection de commandes IMAP/SMTP


Identification des paramètres vulnérables

Pour détecter les paramètres vulnérables, le testeur doit analyser le traitement des entrées par l'application. Pour tester la validation des entrées, le testeur doit envoyer des requêtes corrompues ou malicieuses au serveur et analyser les réponses. Dans une application sécurisée, la réponse doit être une message d'erreur avec quelques actions informant le client que quelque chose s'est mal passé. Dans une application vulnérable, la requête malicieuse sera traîtée par l'application, qui répondra avec un message "HTTP 200 OK".


Il est important de remarquer que les requêtes envoyées doivent correspondre à la technologie testée. Envoyer des chaînes d'injection SQL pour Microsoft SQL Server vers un serveur MySQL résultera en faux positifs. Dans ce cas, il faut envoyer des commandes IMAP malicieuses, puisque c'est ce protocol qui est testé.


Les paramètres spéciaux IMAP à utiliser :

Sur le serveur IMAP Sur le serveur SMTP
Authentification Emetteur d'e-mail
opérations sur les boites e-mail (list, read, create, delete, rename) Destinataire d'e-mail
operations sur les messages (read, copy, move, delete) Titre
Déconnexion Corps du message
Pièces jointes


Dans cet exemple, le paramètre "mailbox" est testé en manipulant toutes les requêtes avec le paramètre : 

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


Les exemples suivants peuvent être utilisés :

  • Affecter une valeur nulle au paramètre :
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
  • Remplacer uen valeur par 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-standards (ex.: \, ', ", @, #, !, |) :
http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
  • Supprimer le paramètre :
http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1


Le resutlat final des tests ci-dessus donne au testeur trois possibilités :
S1 - L'application retourne un code ou un message d'erreur
S2 - L'application ne retourne pas de code ou de message d'erreur, mais n'exécute pas l'opération demandée
S3 - L'application ne retourne pas de code ou de message d'erreur, et exécute normalement l'opération demandée


Les situation S1 et S2 sont des injections IMAP/SMTP réussies.

Le but d'un attaquant est de recevoir la réponse S1, puisque cela indique que l'application est vulnérable aux injections et autres manipulations.

Supposons qu'un utilisateur récupère les entêtes d'e-mail avec 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 INBOX en injectant le caractère " (%22 en ecodage 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 compliquée à tester avec succès. Le testeur doit utiliser des injections de commandes en aveugle afin de déterminer si le serveur est vulnérable.


Par contre, la situation S3 n'est pas concernée par ce paragraphe.



Resultat attendu :

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


Compréhension du flux de données et de la structure de déploiement du client

Après avoir identifié tous les paramètres vulnérables (par exemple, "passed_id"), le testeur doit déterminer quel niveau d'injection est possible et ensuite concevoir un plan de test pour exploiter l'application.


Dans ce cas, nous avons détecté que le paramètre "passed_id" de l'application est vulnérable et qu'il est utilisé dans la requête suivante : 

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


En utilisant le cas de test suivant (founissant une valeur alphanumérique quand une valeur numérique est attendue) : 

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 ainsi que ses paramètres.


Dans d'autres situations, le message d'erreur ("non contrôlé" par l'application) contient le nom de la commande exécutée, mais en lisant la RFC adéquate (voir le paragraphe "Références"), le testeur comprendra quelles autres commandes peuvent être exécutées.


Si l'application ne retourne pas de message d'erreur assez descriptif, le testeur doit analyser les fonctionnalités impactées pour déduire toutes les commandes possibles (et leurs paramètres) associées avec la fonctionnalité. Par exemple, si un paramètre vulnérable a été détecté dans la fonctionnalité de création de boite e-mail, il est logique de considérer que la commande IMAP concernée est "CREATE". D'après la RFC, la commande CREATE accepte un paramètre spécifiant le nom de la boite e-mail à créer.



Resultat attendu:

  • Liste des commandes IMAP/SMTP impactées
  • Type, valeur et nombre de paramètres attendus par les commandes IMAP/SMTP impactées


Injection de commandes IMAP/SMTP

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


Cette étape a deux issues possibles :
1. L'injection est possible dans un état non-authentifié : la fonctionnalité impactée ne nécessite pas que l'utilisateur soit authentifié. Les commandes IMAP (injectées) disponibles sont limitées à : CAPABILITY, NOOP, AUTHENTICATE, LOGIN, et LOGOUT.
2. L'injection n'est possible que dans un état authentifié : la réussite de l'exploitation 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 sera la suivante :

  • Entête : fin de la commande attendue ;
  • Corps : injection de la nouvelle commande ;
  • Pied : début de la commande attendue.


Il est important de se souvenir que, pour exécuter une commande IMAP/SMTP, la commande précédente doit être terminée par la séquence CRLF (%0d%0a).


Supposons que pandant l'étape 1 ("Identification des paramètres vulnérables"), l'attaquant détecte que le paramètre "message_id" de la requête suivante est vulnérable : 

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


Supposons que le résultat de l'analyse faite en étape 2 ("Compréhension du flux de données et de la structure de déploiement du client") a identifié la commande et les arguments associés à ce paramètre comme étant : 

FETCH 4791 BODY[HEADER]


Dans ce scénario, la structure de l'injection IMAP sera : 

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


Qui va générer les commandes : 

???? 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


Resultat attendu:

  • Injection de commandes IMAP/SMTP arbitraires


Références

Whitepapers

Retrieved from "https://wiki.owasp.org/index.php?title=4.8.11_Injections_IMAP_SMTP_(OTG-INPVAL-011)&oldid=187915"