ALPACA — nouvelle technique d'attaque MITM sur HTTPS

Un groupe de chercheurs de plusieurs universités allemandes a développé une nouvelle méthode d'attaque MITM sur HTTPS, permettant d'extraire des cookies avec des identifiants de session et d'autres données sensibles, ainsi que d'exécuter du code JavaScript arbitraire dans le contexte d'un autre site. L'attaque, appelée ALPACA, peut être appliquée aux serveurs TLS utilisant différents protocoles de niveau applicatif (HTTPS, SFTP, SMTP, IMAP, POP3), mais utilisant des certificats TLS communs.

Le principe de l'attaque est que, en ayant le contrôle sur une passerelle réseau ou un point d'accès sans fil, l'attaquant peut rediriger le trafic web vers un autre port réseau et établir une connexion avec un serveur FTP ou de messagerie supportant le chiffrement TLS et utilisant un certificat TLS commun avec le serveur HTTP, le navigateur de l'utilisateur croyant alors qu'une connexion a été établie avec le serveur HTTP demandé. Étant donné que le protocole TLS est universel et non lié aux protocoles de niveau applicatif, l'établissement d'une connexion chiffrée pour tous les services est identique, et une erreur de redirection vers un service incorrect ne peut être détectée qu'après l'établissement de la session chiffrée lors du traitement des commandes de la requête envoyée.

Par conséquent, si, par exemple, on redirige une connexion utilisateur initialement adressée à HTTPS vers un serveur de messagerie utilisant un certificat commun avec le serveur HTTPS, la connexion TLS sera établie avec succès, mais le serveur de messagerie ne pourra pas traiter les commandes HTTP envoyées et renverra une réponse avec un code d'erreur. Cette réponse sera alors traitée par le navigateur comme une réponse du site demandé, transmise dans le canal de communication chiffré établi correctement.

Trois variantes de l'attaque ont été proposées:

• «Upload» pour extraire les cookies avec les paramètres d'authentification. Cette méthode s'applique si le serveur FTP protégé par un certificat TLS permet de télécharger et d'extraire ses données. Dans ce type d'attaque, l'attaquant peut réussir à conserver des parties de la requête HTTP d'origine de l'utilisateur, telles que le contenu de l'en-tête du cookie, par exemple, si le serveur FTP interprète la requête comme un fichier à sauvegarder ou s'il journalise complètement les requêtes entrantes. Pour réussir l'attaque, l'attaquant doit ensuite de quelque manière extraire le contenu sauvegardé. L'attaque est applicable à Proftpd, Microsoft IIS, vsftpd, filezilla et serv-u.
• «Download» pour organiser le cross-site scripting (XSS). Cette méthode implique que l'attaquant, à la suite de certaines manipulations, puisse placer des données dans un service utilisant des Certificat TLS, qui peuvent ensuite être renvoyées en réponse à la requête de l'utilisateur. L'attaque est applicable aux serveurs FTP mentionnés ci-dessus, aux serveurs IMAP et aux serveurs POP3 (courier, cyrus, kerio-connect et zimbra).
• «Reflection» pour exécuter du JavaScript dans le contexte d'un autre site. Cette méthode repose sur le renvoi au client d'une partie de la requête, contenant le code JavaScript envoyé par l'attaquant. L'attaque est applicable aux serveurs FTP mentionnés ci-dessus, aux serveurs IMAP comme cyrus, kerio-connect et zimbra, ainsi qu'au serveur SMTP sendmail.

Par exemple, lorsqu'un utilisateur ouvre une page contrôlée par l'attaquant, une requête pour une ressource peut être initiée depuis cette page vers un site où l'utilisateur a un compte actif (par exemple, bank.com). Lors d'une attaque MITM, cette requête, adressée au site web bank.com, peut être redirigée vers le serveur de messagerie utilisant un certificat TLS commun avec bank.com. Étant donné que le serveur de messagerie ne termine pas la session après la première erreur, des en-têtes et commandes tels que «POST / HTTP/1.1» et «Host:» seront traités comme des commandes inconnues (le serveur de messagerie renverra pour chaque en-tête «500 unrecognized command»).

Le serveur de messagerie ne comprend pas les spécificités du protocole HTTP et pour lui, les en-têtes de service et le bloc de données de la requête POST sont traités de manière identique, donc dans le corps de la requête POST, il est possible de spécifier une ligne avec une commande pour le serveur de messagerie. Par exemple, on peut transmettre : MAIL FROM: à quoi le serveur de messagerie renverra un message d'erreur 501 : malformed address: alert(1); may not follow

Cette réponse sera reçue par le navigateur de l'utilisateur qui exécutera le code JavaScript dans le contexte du site bank.com, et non pas du site initialement ouvert par l'attaquant, car la réponse a été reçue dans le cadre d'une session TLS valide, dont le certificat a confirmé l'authenticité de bank.com.

Le scan du réseau mondial a révélé que le problème, en termes généraux, touche environ 1,4 million de serveurs web, pour lesquels une attaque impliquant un mélange d'appels via différents protocoles est possible. La possibilité de réaliser une attaque a été identifiée pour 119 000 serveurs web, qui avaient des serveurs TLS associés s'appuyant sur d'autres protocoles applicatifs.

Des exemples d'exploits ont été préparés pour les serveurs FTP tels que pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla et serv-u, ainsi que pour les serveurs IMAP et POP3 comme dovecot, courier, exchange, cyrus, kerio-connect et zimbra, et les serveurs SMTP comme postfix, exim, sendmail, mailenable, mdaemon et opensmtpd. Les chercheurs ont examiné la possibilité d'attaques uniquement en combinaison avec les serveurs FTP, SMTP, IMAP et POP3, sans exclure que le problème puisse également se manifester pour d'autres protocoles applicatifs utilisant TLS.

Pour bloquer l'attaque, il est proposé d'utiliser l'extension ALPN (Application Layer Protocol Negotiation) pour la négociation de la session TLS en fonction du protocole applicatif et l'extension SNI (Server Name Indication) pour se lier au nom d'hôte lors de l'utilisation de certificats TLS couvrant plusieurs adresses. completsDu côté des applications, il est recommandé de limiter le nombre d'erreurs lors du traitement des commandes, et au-delà d'un certain seuil, de rompre la connexion. Le processus d'élaboration de mesures pour bloquer l'attaque a commencé dès octobre de l'année dernière. Des mesures similaires pour la protection ont déjà été prises dans Nginx 1.21.0 (mail proxy), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) et Internet Explorer.

Source : opennet.ru