Les chercheurs ont révélé un nouveau type d’attaque qui exploite les erreurs de configuration des serveurs de sécurité de la couche de transport (TLS) pour rediriger le trafic HTTPS du navigateur Web d’une victime vers un autre point de terminaison de service TLS situé sur une autre adresse IP afin de voler des informations sensibles.

Les attaques ont été surnommées ALPAGA, abréviation de « Application Layer Protocol Confusion – Analyzing and mitigating Cracks in tls Authentication », par un groupe d’universitaires de l’Université de la Ruhr à Bochum, de l’Université des sciences appliquées de Münster et de l’Université de Paderborn.

« Les attaquants peuvent rediriger le trafic d’un sous-domaine vers un autre, résultant en une session TLS valide », indique l’étude. « Cela interrompt l’authentification de TLS et des attaques interprotocoles peuvent être possibles lorsque le comportement d’un service de protocole peut compromettre l’autre au niveau de la couche d’application. »

TLS est un protocole cryptographique qui sous-tend plusieurs protocoles de couche d’application tels que HTTPS, SMTP, IMAP, POP3 et FTP pour sécuriser les communications sur un réseau dans le but d’ajouter une couche d’authentification et de préserver l’intégrité des données échangées pendant le transit.

Les attaques ALPACA sont possibles car TLS ne lie pas une connexion TCP au protocole de couche d’application prévu, ont expliqué les chercheurs. L’échec de TLS à protéger l’intégrité de la connexion TCP pourrait donc être utilisé à mauvais escient pour « rediriger le trafic TLS pour le point d’extrémité et le protocole du service TLS vers un autre, substituer le point d’extrémité et le protocole du service TLS ».

Étant donné un client (c’est-à-dire un navigateur Web) et deux serveurs d’applications (c’est-à-dire le prévu et le remplaçant), l’objectif est de tromper le serveur de remplacement en lui faisant accepter les données d’application du client, ou vice versa. Étant donné que le client utilise un protocole spécifique pour ouvrir un canal sécurisé avec le serveur prévu (par exemple, HTTPS) tandis que le serveur de substitution utilise un protocole de couche d’application différent (par exemple, FTP) et s’exécute sur un point de terminaison TCP distinct, la confusion aboutit à ce qu’on appelle une attaque interprotocole.

Au moins trois scénarios d’attaques interprotocoles hypothétiques ont été découverts, qui peuvent être exploités par un adversaire pour contourner les protections TLS et cibler les serveurs FTP et de messagerie. Les attaques, cependant, reposent sur la condition préalable que l’auteur peut intercepter et détourner le trafic de la victime au niveau de la couche TCP/IP.

En termes simples, les attaques prennent la forme d’un schéma man-in-the-middle (MitM) dans lequel l’acteur malveillant incite une victime à ouvrir un site Web sous son contrôle pour déclencher une requête HTTPS d’origine croisée avec une charge utile FTP spécialement conçue. Cette demande est ensuite redirigée vers un serveur FTP qui utilise un certificat compatible avec celui du site Web, aboutissant à une session TLS valide.

Par conséquent, la mauvaise configuration des services TLS peut être exploitée pour exfiltrer des cookies d’authentification ou d’autres données privées vers le serveur FTP (Upload Attack), récupérer une charge utile JavaScript malveillante du serveur FTP dans une attaque XSS stockée (Download Attack), ou même exécuter une XSS reflété dans le cadre du site Web de la victime (Reflection Attack).

Tous les serveurs TLS dotés de certificats compatibles avec d’autres services TLS devraient être affectés. Dans une configuration expérimentale, les chercheurs ont découvert qu’au moins 1,4 million de serveurs Web étaient vulnérables aux attaques interprotocoles, 114 197 des serveurs étant considérés comme sujets aux attaques utilisant un serveur SMTP, IMAP, POP3 ou FTP exploitable avec un certificat fiable et compatible. .

Pour contrer les attaques interprotocoles, les chercheurs proposent d’utiliser la négociation de protocole de couche d’application (ALPN) et l’indication du nom du serveur (SNI) extensions à TLS qui peuvent être utilisées par un client pour informer le serveur du protocole prévu à utiliser sur une connexion sécurisée et du nom d’hôte auquel il tente de se connecter au début de la poignée de main traiter.

Les résultats devraient être présentés à Black Hat USA 2021 et au USENIX Security Symposium 2021. Des artefacts supplémentaires relatifs à l’attaque ALPACA sont accessibles via GitHub. ici.