Les pirates peuvent perturber les connexions HTTPS en envoyant des données à votre serveur de messagerie

Lorsque vous visitez un site Web protégé par HTTPS, votre navigateur n’échange pas de données avec le serveur Web tant qu’il n’a pas vérifié que le certificat numérique du site est valide. Cela empêche les pirates ayant la capacité de surveiller ou de modifier les données transmises entre vous et le site d’obtenir des cookies d’authentification ou d’exécuter un code malveillant sur l’appareil visiteur.

Mais que se passerait-il si un attaquant man-in-the-middle pouvait amener le navigateur à se connecter accidentellement à un serveur de messagerie ou à un serveur FTP utilisant un certificat compatible avec celui utilisé par le site Web ?

Les dangers de parler HTTPS à un serveur de messagerie

Étant donné que le nom de domaine du site Web correspond au nom de domaine dans l’e-mail ou le certificat du serveur FTP, le navigateur établira, dans de nombreux cas, une connexion Transport Layer Security avec l’un de ces serveurs plutôt qu’avec le site Web que l’utilisateur avait l’intention de visiter.

Étant donné que le navigateur communique en HTTPS et que le serveur de messagerie ou FTP utilise SMTP, FTPS ou un autre protocole, il est possible que les choses tournent horriblement mal – un cookie d’authentification déchiffré pourrait être envoyé à l’attaquant, par exemple, ou à un attaquant pourrait exécuter un code malveillant sur la machine visiteuse.

Le scénario n’est pas aussi farfelu que certains pourraient le penser. En fait, de nouvelles recherches ont révélé qu’environ 1,4 million de serveurs Web utilisent un nom de domaine compatible avec les informations d’identification cryptographiques d’un serveur de messagerie électronique ou FTP appartenant à la même organisation. Parmi ces sites, environ 114 000 sont considérés comme exploitables car le serveur de messagerie ou FTP utilise un logiciel connu pour être vulnérable à de telles attaques.

De telles attaques sont possibles en raison de l’échec de TLS à protéger l’intégrité de la connexion TCP elle-même plutôt que l’intégrité du seul serveur parlant HTTP, SMTP ou un autre langage Internet. Les attaquants man-in-the-middle peuvent exploiter cette faiblesse pour rediriger le trafic TLS du serveur et du protocole prévus vers un autre, en remplaçant le point de terminaison et le protocole.

“Le principe de base est qu’un attaquant peut rediriger le trafic destiné à un service vers un autre, car TLS ne protège pas l’adresse IP ou le numéro de port”, m’a expliqué Marcus Brinkmann, chercheur à l’Université de la Ruhr à Bochum en Allemagne. “Dans le passé, les gens ont envisagé des attaques où l’attaquant MitM redirige un navigateur vers un serveur Web différent, mais nous envisageons le cas où l’attaquant redirige le navigateur du serveur Web vers un serveur d’applications différent tel que FTP ou e-mail.”

Fissures dans la pierre angulaire

Généralement abrégé en TLS, Transport Layer Security utilise un cryptage fort pour prouver qu’un utilisateur final est connecté à un serveur authentique appartenant à un service spécifique (comme Google ou Bank of America) et non un imposteur se faisant passer pour ce service. TLS crypte également les données lorsqu’elles circulent entre un utilisateur final et un serveur pour garantir que les personnes pouvant surveiller la connexion ne peuvent pas lire ou falsifier le contenu. Avec des millions de serveurs qui en dépendent, TLS est la pierre angulaire de la sécurité en ligne.

Dans un document de recherche publié mercredi, Brinkmann et sept autres chercheurs ont étudié la possibilité d’utiliser ce qu’ils appellent des attaques interprotocoles pour contourner les protections TLS. La technique implique un attaquant MitM qui redirige les requêtes HTTP d’origine croisée vers des serveurs qui communiquent via SMTP, IMAP, POP3 ou FTP, ou un autre protocole de communication.

Les principaux composants de l’attaque sont (1) l’application cliente utilisée par l’utilisateur final ciblé, notée C ; (2) le serveur que la cible avait l’intention de visiter, noté Sentier; et (3) le serveur de substitution, une machine qui se connecte à l’aide de SMTP, FTP ou d’un autre protocole différent du serveur uniqueentier utilise mais avec le même domaine répertorié dans son certificat TLS.

Les chercheurs ont identifié trois méthodes d’attaque que les adversaires de MitM pourraient utiliser pour compromettre la navigation sécurisée d’une cible dans ce scénario. Elles sont:

Télécharger l’attaque. Pour cette attaque, nous supposons que l’attaquant a une certaine capacité à télécharger des données vers Ssous et le récupérer plus tard. Dans une attaque par téléchargement, l’attaquant essaie de stocker des parties de la requête HTTP du navigateur (en particulier l’en-tête Cookie) sur Ssous. Cela peut, par exemple, se produire si le serveur interprète la demande comme un téléchargement de fichier ou si le serveur enregistre les demandes entrantes de manière détaillée. En cas d’attaque réussie, l’attaquant peut alors récupérer le contenu sur le serveur indépendamment de la connexion de C vers Ssous et récupérer le cookie de session HTTPS.

Attaque de téléchargement – XSS stocké. Pour cette attaque, nous supposons que l’attaquant a une certaine capacité à préparer les données stockées sur Ssous et téléchargez-le. Dans une attaque de téléchargement, l’attaquant exploite des fonctionnalités de protocole bénignes pour « télécharger » des données précédemment stockées (et spécifiquement conçues) à partir de Ssous à C. Ceci est similaire à une vulnérabilité XSS stockée. Cependant, étant donné qu’un protocole différent de HTTP est utilisé, même des mécanismes de défense sophistiqués contre XSS, comme le Content-Security-Policy
(CSP), peut être contourné. Très probablement, Ssous n’enverra aucun CSP par lui-même, et une grande partie de la réponse est sous le contrôle de l’attaquant.

Attaque par réflexion : XSS réfléchi. Dans une attaque par réflexion, l’attaquant essaie de tromper le serveur Ssous en reflétant des parties de la requête de C dans sa réponse à C. En cas de succès, l’attaquant envoie du code JavaScript malveillant dans la requête qui est reflété par Ssous. Le client analysera ensuite la réponse du serveur, ce qui à son tour peut conduire à l’exécution de JavaScript dans le contexte du serveur Web ciblé.

L’adversaire MitM ne peut pas déchiffrer le trafic TLS, mais il y a encore d’autres choses que l’adversaire peut faire. Forcer le navigateur de la cible à se connecter à un serveur de messagerie ou FTP au lieu du serveur Web prévu, par exemple, peut amener le navigateur à écrire un cookie d’authentification sur le serveur FTP. Ou cela pourrait permettre des attaques de scripts intersites qui amènent le navigateur à télécharger et à exécuter du JavaScript malveillant hébergé sur le serveur FTP ou de messagerie.

Application des protections ALPN et SNI

Pour prévenir les attaques interprotocoles, les chercheurs ont proposé une application plus stricte de deux protections existantes. La première est connue sous le nom de négociation de protocole de couche d’application, une extension TLS qui permet à une couche d’application telle qu’un navigateur de négocier quel protocole doit être utilisé dans une connexion sécurisée. ALPN, comme il est généralement abrégé, est utilisé pour établir des connexions à l’aide du protocole HTTP/2 le plus performant sans allers-retours supplémentaires.

En appliquant strictement ALPN tel qu’il est défini dans la norme formelle, les connexions créées par les navigateurs ou d’autres couches d’application qui envoient l’extension ne sont pas vulnérables aux attaques interprotocoles.

De même, l’utilisation d’une extension TLS distincte appelée indication de nom de serveur peut protéger contre les attaques de nom d’hôte croisé si elle est configurée pour mettre fin à la connexion lorsqu’aucun hôte correspondant n’est trouvé. “Cela peut protéger contre les attaques interprotocoles où le serveur prévu et le serveur de remplacement ont des noms d’hôte différents, mais aussi contre certaines attaques du même protocole telles que les attaques de confusion d’hôte virtuel HTTPS ou les attaques de confusion de contexte”, ont écrit les chercheurs.

Les chercheurs appellent leurs attaques interprotocoles ALPACA, abréviation de « protocoles de couche d’application permettant des attaques interprotocoles ». À l’heure actuelle, l’ALPAGA ne constitue pas une menace majeure pour la plupart des gens. Mais le risque posé pourrait augmenter à mesure que de nouvelles attaques et vulnérabilités sont découvertes ou que TLS est utilisé pour protéger des canaux de communication supplémentaires.

“Dans l’ensemble, l’attaque est très situationnelle et cible des utilisateurs individuels”, a déclaré Brinkmann. « Donc, le risque individuel pour les utilisateurs n’est probablement pas très élevé. Mais au fil du temps, de plus en plus de services et de protocoles sont protégés par TLS, et de plus en plus d’opportunités pour de nouvelles attaques qui suivent le même modèle se présentent. Nous pensons qu’il est opportun et important d’atténuer ces problèmes au niveau de la normalisation avant que cela ne devienne un problème plus important.”

Lire aussi  Le patron de Fauci répondra-t-il aux questions sur le laboratoire de Wuhan?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recent News

Editor's Pick