Hé, ce n'est pas mon serveur !

Nous sommes souvent contactés par des clients et des chercheurs qui nous demandent pourquoi des certificats légitimes et fiables sont soudainement utilisés par des hôtes situés dans un pays lointain. Presque tous les cas que nous avons examinés étaient dus au fait que les principaux fournisseurs de réseaux de diffusion de contenu (CDN), tels que Cloudflare et Akamai, n'étaient pas intentionnels lorsqu'ils traitaient des demandes d'indication de nom de serveur (SNI) nulles.

Lorsque vous demandez"https://example.com", votre client, généralement un navigateur web, initie une poignée de main TLS. Dans le cadre de ce processus, le client informe le serveur distant du nom d'hôte auquel il souhaite se connecter(exemple.com). Cette étape permet au serveur d'associer le nom d'hôte demandé au certificat SSL approprié avant d'établir une connexion sécurisée.

Un serveur bien implémenté renvoie généralement un certificat factice/par défaut si la requête SNI est nulle. Cependant, de nombreuses implémentations servent plutôt un certificat valide pour d'autres domaines (légitimes) qui se trouvent correspondre à cette recherche nulle.

Pourquoi cela se produit-il ?

Lorsqu'un certificat est vu sur un hôte en dehors des plages prévues, il s'agit d'une indication forte que l'hôte agit comme un proxy, redirigeant vers une plage CDN ou un serveur légitime.

Étant donné que les certificats TLS sont émis au niveau du domaine et non liés à des adresses IP spécifiques, un administrateur peut configurer un proxy pour relayer de manière transparente le trafic entre le client et le service TLS légitime. Tant que le client fournit le SNI correct, le proxy peut transmettre les données sans modification, en préservant l'intégrité de la poignée de main TLS. Le proxy ne peut donc pas être distingué du serveur TLS légitime.

Par exemple, dans les deux captures d'écran suivantes, à gauche, nous voyons un hôte en Russie exécutant le serveur multijoueur Sliver C2 sur le port 31337, ce qui en soi est suspect, mais à droite, si nous faisons défiler l'écran jusqu'au port 443, nous voyons un service HTTP(s) exécutant un certificat légitime (et de confiance) pour microsoft.com.

Le certificat est authentique, mais l'hôte qui le présente n'appartient absolument pas à Microsoft - il s'agit simplement d'une astuce - un serveur proxy vers l'un des nombreux hôtes d'Akamai diffusant le certificat TLS Microsoft.com lorsqu'un client ne fournit pas de SNI. Dans ce cas, il est possible que l'acteur ait configuré le port 443 pour qu'il soit transmis à Microsoft afin de faire apparaître l'hôte comme légitime lors d'une inspection rapide.

Vous pouvez essayer vous-même en recherchant des adresses IP qui délivrent des certificats TLS valides sans exiger de SNI. Akamai et CloudFlare sont de bons points de départ, car ils gèrent une part importante du trafic HTTPS de l'internet et ne répondent souvent pas avec des certificats factices. Une fois que vous avez trouvé un serveur avec un certificat TLS que vous souhaitez répliquer, vous pouvez utiliser un outil comme socat:

Cela crée un tuyau entre le port 443 local et le port 443 du serveur distant - maintenant, votre serveur semble faire autorité pour n'importe quel certificat TLS servi à partir de l'adresse IP nue du serveur distant. Ci-dessous, j'ai déjà établi un tunnel entre localhost et 184.24.14.218, qui sert actuellement un certificat pour "intel.com". Nous avons ensuite exécuté un curl contre localhost avec le domaine intel.com comme SNI. Notez qu'il n'y a pas eu d'avertissement concernant le certificat lors de cette requête.

Mais est-ce une mauvaise chose ? Difficile à dire. Vous ne serez pas en mesure de voir ou d'altérer les données transférées entre le client et le serveur mandaté, mais quelqu'un pourrait utiliser cela pour paraître "plus légitime" aux yeux d'une personne extérieure. En réalité, il peut s'agir de n'importe quoi, d'un acteur malveillant essayant d'avoir l'air légitime ou simplement d'une configuration de routage/proxy étrange. L'important est de savoir comment fonctionne TLS lorsque vous voyez des certificats apparaître dans des endroits inconnus, afin d'éviter de s'enfoncer dans trop de trous de lapin.

Pour une analyse rapide, nous avons examiné tous les certificats découverts sur des adresses IP nues au sein de l'AS16625 (AKAMAI-AS), l'un des systèmes autonomes d'Akamai. Nous avons ensuite recherché ces certificats en double sur des réseaux autres que celui d'Akamai, en particulier sur des ports différents de ceux utilisés par Akamai. Par exemple, si un certificat était trouvé sur le port 443 d'Akamai mais apparaissait sur le port 4444 d'un hôte n'appartenant pas à Akamai, il a été comptabilisé. En outre, nous n'avons pris en compte que les hôtes non-Akamai qui diffusaient le certificat correspondant tout en renvoyant l'en-tête de serveur " Akamai Ghost ".

Avec ces règles en place, nous avons trouvé un peu moins de 7 000 hôtes distincts sur Internet qui effectuent des proxies 1:1 vers divers hôtes Akamai diffusant des certificats TLS légitimes sur l'IP nue.

La perspective de Censys

Si la présence de certificats légitimes sur des systèmes distants inattendus justifie une enquête, elle n'est pas toujours le signe d'une activité malveillante. Avec des milliers d'hôtes agissant comme des proxys et vus par des scanners avec des certificats TLS légitimes, ce comportement est l'une des excentricités uniques de l'Internet. Si certains de ces serveurs mandataires ont probablement été déployés intentionnellement pour faire passer un serveur de contrôle de logiciels malveillants pour un système tiers légitime, d'autres sont probablement le résultat de serveurs mandataires non entretenus redirigeant vers des adresses IP qui ont changé de propriétaire.