Une équipe de chercheurs de plusieurs universités allemandes a développé une nouvelle attaque MITM sur HTTPS qui peut extraire des cookies de session et d'autres données sensibles, ainsi qu'exécuter du code JavaScript arbitraire dans le contexte d'un autre site. L'attaque s'appelle ALPACA et peut être appliquée aux serveurs TLS qui implémentent différents protocoles de couche application (HTTPS, SFTP, SMTP, IMAP, POP3), mais utilisent des certificats TLS courants.
L'essence de l'attaque est que s'il contrôle 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 organiser l'établissement d'une connexion avec un serveur FTP ou de messagerie prenant en charge le cryptage TLS et utilisant un Certificat TLS commun avec le serveur HTTP, et le navigateur de l'utilisateur supposera qu'une connexion a été établie avec le serveur HTTP demandé. Étant donné que le protocole TLS est universel et n'est pas lié aux protocoles au niveau de l'application, l'établissement d'une connexion cryptée pour tous les services est identique et l'erreur d'envoi d'une demande au mauvais service ne peut être déterminée qu'après avoir établi une session cryptée lors du traitement de la demande. commandes de la requête envoyée.
Ainsi, si, par exemple, vous redirigez une connexion utilisateur initialement adressée en HTTPS vers un serveur de messagerie qui utilise un certificat partagé avec le serveur HTTPS, la connexion TLS sera établie avec succès, mais le serveur de messagerie ne pourra pas traiter le message transmis. Commandes HTTP et renverra une réponse avec un code d'erreur. Cette réponse sera traitée par le navigateur comme une réponse du site demandé, transmise au sein d'un canal de communication crypté correctement établi.
Trois options d'attaque sont proposées :
- « Upload » pour récupérer un Cookie avec des paramètres d'authentification. La méthode est applicable si le serveur FTP couvert par le certificat TLS permet de télécharger et de récupérer ses données. Dans cette variante d'attaque, l'attaquant peut conserver des parties de la requête HTTP originale de l'utilisateur, comme le contenu de l'en-tête Cookie, par exemple, si le serveur FTP interprète la requête comme un fichier de sauvegarde ou enregistre entièrement les requêtes entrantes. Pour réussir l’attaque, l’attaquant doit alors extraire d’une manière ou d’une autre le contenu stocké. L'attaque est applicable à Proftpd, Microsoft IIS, vsftpd, filezilla et serv-u.
- « Télécharger » pour organiser les scripts intersites (XSS). La méthode implique que l'attaquant, à la suite de certaines manipulations individuelles, puisse placer des données dans un service utilisant un certificat TLS commun, qui peut ensuite être émis en réponse à une demande de l'utilisateur. L'attaque est applicable aux serveurs FTP, IMAP et POP3 mentionnés ci-dessus (courier, cyrus, kerio-connect et zimbra).
- "Réflexion" pour exécuter JavaScript dans le contexte d'un autre site. La méthode repose sur le retour au client d'une partie de la requête, qui contient le code JavaScript envoyé par l'attaquant. L'attaque est applicable aux serveurs FTP mentionnés ci-dessus, aux serveurs IMAP cyrus, kerio-connect et zimbra, ainsi qu'au serveur SMTP sendmail.
Par exemple, lorsqu'un utilisateur ouvre une page contrôlée par un attaquant, cette page peut lancer une demande de ressource depuis un site sur lequel l'utilisateur possède un compte actif (par exemple, bank.com). Lors d'une attaque MITM, cette requête adressée au site bank.com peut être redirigée vers un serveur de messagerie utilisant un certificat TLS partagé avec bank.com. Étant donné que le serveur de messagerie ne termine pas la session après la première erreur, les en-têtes de service et les commandes telles que "POST / HTTP/1.1" et "Host:" seront traités comme des commandes inconnues (le serveur de messagerie renverra "500 commandes non reconnues" pour chaque en-tête).
Le serveur de messagerie ne comprend pas les fonctionnalités du protocole HTTP et pour cela, les en-têtes de service et le bloc de données de la requête POST sont traités de la même manière, donc dans le corps de la requête POST, vous pouvez spécifier une ligne avec une commande pour le serveur de messagerie. Par exemple, vous pouvez passer : MAIL FROM : alert(1); auquel le serveur de messagerie renverra un message d'erreur 501 alert(1); : adresse malformée : alert (1); peut ne pas suivre
Cette réponse sera reçue par le navigateur de l'utilisateur, qui exécutera le code JavaScript dans le contexte non pas du site Web initialement ouvert de l'attaquant, mais du site bank.com auquel la demande a été envoyée, puisque la réponse est intervenue dans une session TLS correcte. , dont le certificat a confirmé l'authenticité de la réponse de bank.com.
Une analyse du réseau mondial a montré qu'en général, environ 1.4 million de serveurs Web sont concernés par le problème, pour lesquels il est possible de mener une attaque en mélangeant des requêtes utilisant différents protocoles. La possibilité d'une véritable attaque a été déterminée pour 119 XNUMX serveurs Web, pour lesquels accompagnaient des serveurs TLS basés sur d'autres protocoles d'application.
Des exemples d'exploits ont été préparés pour les serveurs ftp pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla et serv-u, les serveurs IMAP et POP3 dovecot, courier, change, cyrus, kerio-connect et zimbra, les serveurs SMTP postfix, exim, sendmail , mailenable, mdaemon et opensmtpd. Les chercheurs ont étudié la possibilité de mener une attaque uniquement en combinaison avec des serveurs FTP, SMTP, IMAP et POP3, mais il est possible que le problème se produise également pour d'autres protocoles d'application utilisant TLS.
Pour bloquer l'attaque, il est proposé d'utiliser l'extension ALPN (Application Layer Protocol Négociation) pour négocier une session TLS prenant en compte le protocole applicatif et l'extension SNI (Server Name Indication) pour se lier au nom d'hôte en cas d'utilisation Certificats TLS couvrant plusieurs noms de domaine. Côté application, il est recommandé de limiter la limite du nombre d'erreurs lors du traitement des commandes, après quoi la connexion est terminée. Le processus d'élaboration de mesures visant à bloquer l'attaque a commencé en octobre de l'année dernière. Des mesures de sécurité similaires ont déjà été prises dans Nginx 1.21.0 (proxy de messagerie), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) et Internet Explorer.
Source: opennet.ru