Quel type d'attaque est empêché par le code d'erreur Apache2 AH02032 ("Le nom d'hôte fourni via SNI et le nom d'hôte fourni via HTTP sont différents")?
J'ai vu dans mon serveur Apache2 des journaux de messages comme
[ssl:error] [pid 28482] AH02032: Hostname xxx.yyy.zzz.www:443 provided via SNI and hostname xxx.yyy.zzz.www provided via HTTP are different
L'un de ces messages d'erreur a été déclenché par une demande de researchscan367.eecs.umich.edu, donc je suppose qu'ils recherchent une vulnérabilité connue. Quel type de vulnérabilité ou de vecteur d'attaque est empêché par l'erreur?
Quel type de vulnérabilité ou de vecteur d'attaque est empêché par l'erreur?
L'attaque est appelée "confusion de l'hôte virtuel" et en 2014, plusieurs CDN ont été trouvés vulnérables contre elle . L'idée principale est qu'une discordance entre le nom cible dans la négociation TLS ( "fournie via SNI" ) et le nom cible dans le protocole HTTP ( "fourni via HTTP" ) peut être exploité. Selon la configuration du serveur, il peut être utilisé pour usurper l'identité de sites HTTPS appartenant à d'autres qui peuvent également être utilisés pour voler des cookies de session, etc.
Pour plus d'informations, lisez l'article "Attaques de confusion d'origine basées sur le réseau contre l'hébergement virtuel HTTPS" , lisez le informations sur HackerOne , regardez une vidéo de la façon dont cette attaque aide à - "utiliser Akamai pour contourner la censure sur Internet" ou voir le discours de Blackhat 2014 où cela et d'autres attaques contre TLS ont été démontrés.
Server Name Indication (SNI) est une extension TLS qui permet à un client TLS d'indiquer l'hôte qu'il tente d'atteindre. Ceci est important pour les serveurs Web avec des hôtes virtuels (c'est-à-dire plusieurs domaines hébergés dans une même boîte) afin qu'ils puissent décider quel certificat retourner. Normalement, l'hôte virtuel cible est détecté via l'en-tête HTTP Host, mais il ne peut pas être envoyé avant la construction d'un tunnel TLS. SNI permet au client TLS d'indiquer le nom afin que le certificat correct puisse être servi, avant que l'appel HTTP sous-jacent ne soit effectué. Une autre caractéristique de la plupart des serveurs TLS est que SNI peut être utilisé pour choisir entre différentes configurations TLS qui ont été configurées pour chaque hôte virtuel.
Étant donné que vous avez maintenant deux indicateurs de l'hôte que vous essayez d'atteindre (en-tête SNI et hôte), il peut y avoir des comportements étranges si vous les forcez à ne pas correspondre. Maintenant, imaginez une situation où vous avez un site qui utilise HTTPS, mais aussi un sous-domaine administratif, et ils sont tous deux hébergés sur le même serveur. Le sous-domaine administratif est verrouillé au niveau de la configuration SNI afin qu'il nécessite un certificat client. Cela signifie que l'utilisation régulière du site exécute simplement HTTPS normal, mais vous avez besoin d'un certificat client pour vous connecter au sous-domaine admin.
Cependant, si vous deviez faire une demande où le SNI pointe vers le domaine principal, mais l'en-tête Host pointe vers le sous-domaine administratif, vous pouvez construire le tunnel TLS sans le certificat client (car les règles du site principal sont utilisées) mais le web le serveur peut diffuser du contenu comme si vous vous connectiez au sous-domaine administratif. Cela pourrait vous permettre de contourner cette restriction de certificat client.
Si vous avez une configuration dans laquelle un frontal léger utilise SNI pour répartir les demandes sur différents serveurs HTTPS, la vérification supplémentaire effectuée par Apache protège contre les demandes non valides utilisées pour accéder à du contenu qui serait autrement inaccessible.
Étant donné que le champ SNI se trouve dans le message bonjour du client TLS envoyé par le client avant que quoi que ce soit ait été envoyé par le serveur, il est possible de construire un frontend léger qui ne sait rien de HTTP et très peu de TLS mais qui est toujours capable d'envoyer des connexions TLS à différents backends en fonction du nom d'hôte.
Un tel frontend aurait seulement besoin de connaître suffisamment TLS pour analyser le message bonjour du client et extraire le nom d'hôte. Une fois qu'il a cela, il peut transmettre toutes les données non modifiées à des backends HTTPS séparés. Seuls les backends ont besoin de la clé de serveur nécessaire pour établir la connexion TLS.
Dans cette configuration, le frontend ne pourra jamais savoir quel nom d'hôte a été envoyé dans l'en-tête de l'hôte HTTP car il ne peut pas décrypter le trafic. Il est donc impossible pour un tel frontend de comparer les deux noms d'hôtes.
Cette configuration permet à plusieurs domaines d'être hébergés derrière une seule adresse IP, même si les serveurs HTTPS eux-mêmes ne savent rien de SNI. Cependant, si les serveurs HTTPS ne savent rien de SNI, il est possible qu'un client envoie une demande corrompue dans laquelle frontend et backend voient deux noms d'hôtes différents pour la même demande HTTPS.
Il est possible de configurer le frontend et le backend de manière à ce qu'un certain vhost soit uniquement accessible en indiquant au frontend et au backend différents noms d'hôte.
Si un vhost est inaccessible pour chaque demande HTTPS valide, il peut raisonnablement être considéré comme une vulnérabilité si ledit vhost peut être atteint en envoyant une demande HTTPS invalide. Si le backend est une version Apache avec prise en charge SNI, la vérification que vous demandez vous protégera contre la vulnérabilité.