Le certificat qui l'a nommé : Certificate Transparency comme surface d'attaque
Le défi
Caldera Freight possède une application dont son équipe sécurité est certaine qu'elle n'est pas sur Internet. Aucun enregistrement DNS public que quiconque se souvienne d'avoir créé, aucun lien depuis le site, absente de tout index de recherche, et le README dit noir sur blanc qu'elle est interne. On vous demande de vérifier cette affirmation depuis l'extérieur, avec pour seules armes des registres publics. Il existe une porte d'entrée, et ce n'est pas une liste de mots. Chaque fois qu'un certificat est émis pour un nom, ce nom est inscrit dans un journal public, permanent et à ajout seul, et personne chez Caldera ne pensait à ce journal le jour où deux hôtes ont été regroupés sur un même certificat pour économiser un renouvellement. Parcourez les sources, écartez les noms morts ou qui appartiennent à quelqu'un d'autre, et soumettez le nom d'hôte interne réellement vivant sur Internet.
Ce que tu vas apprendre
- Utiliser Certificate Transparency comme source primaire pour la découverte de sous-domaines
- Lire les noms alternatifs du sujet plutôt que le seul nom commun
- Distinguer un certificat actif d'un hôte actif grâce au DNS
- Écarter comme injoignables les noms qui résolvent vers un espace RFC 1918
- Utiliser la propriété du bloc d'adresses pour distinguer ses propres actifs de ceux d'un prestataire
Compétences testées
Prérequis
- Ce qu'est un certificat TLS et un sous-domaine
- Lecture de la sortie de dig et d'une réponse NXDOMAIN
Comment ça marche
Certificate Transparency a été conçu pour repérer les certificats mal émis, et il le fait. L'effet de bord, c'est qu'il constitue aussi un index permanent, public et à ajout seul des noms d'hôtes, alimenté gratuitement par chaque autorité de certification, sans aucun moyen de retirer une entrée. Si un nom a un jour eu un certificat, ce nom est public, quoi qu'en dise la zone DNS ou le README.
L'habitude que cet exercice entraîne, c'est de lire le certificat en entier. Un certificat a un sujet et une liste de noms alternatifs du sujet, et les clients modernes ignorent complètement le nom commun : c'est la liste SAN qui est réellement validée. L'enregistrement d'id 9501338 est émis pour status.caldera.example, et enfoui en troisième position dans sa liste SAN se trouve ops-console.caldera.example. Parcourez la colonne CN et la console reste invisible. Le journal des changements explique pourquoi il est là : le ticket OPS-4471 a renouvelé la console dans le même lot que la page de statut, parce que cela faisait un renouvellement de moins à retenir.
La découverte n'est pas la ligne d'arrivée, car un certificat prouve qu'un nom a existé, pas qu'un hôte répond. vpn.caldera.example possède le certificat le plus récent de tout l'ensemble, émis la veille du retrait de l'équipement, et il est en NXDOMAIN. Cet écart entre le certificat et la réalité est exactement la raison pour laquelle la passe d'élimination compte.
Deux filtres supplémentaires terminent le travail. internal.caldera.example résout vers 10.40.7.15, un espace RFC 1918 non routable depuis Internet : le nom fuit, mais pas l'hôte. status et uptime pointent en CNAME vers 203.0.113.77, que le registre de bloc d'adresses attribue à un hébergeur, pas à Caldera. Joignable, mais ni l'actif de Caldera ni le problème de Caldera.
Une seule adresse reste à l'intérieur de l'attribution propre de Caldera, répondant sur le port 443 avec un formulaire de connexion. Le README décrit une intention que l'infrastructure n'a jamais fait respecter.
Erreurs fréquentes
- Ne lire que la ligne CN. La console n'apparaît jamais comme sujet, seulement comme troisième nom alternatif sur le certificat d'un voisin.
- Répondre vpn.caldera.example. Le certificat le plus récent de l'ensemble, et pourtant NXDOMAIN. Un certificat survit à l'hôte.
- Répondre internal.caldera.example. Il résout, mais vers un espace RFC 1918 injoignable.
- Répondre status ou uptime. Les deux pointent vers un bloc d'adresses d'un prestataire que Caldera ne possède pas.
- Deviner admin ou portal. Les deux sont en NXDOMAIN, et le journal des changements indique qu'admin n'a jamais été provisionné.
Comment s'en protéger
Vous ne pouvez pas dépublier une entrée Certificate Transparency, donc le contrôle consiste à composer avec le journal plutôt qu'à espérer que personne ne le lise.
- Ne jamais regrouper un hôte interne sur un certificat public pour économiser un renouvellement. Automatisez plutôt le renouvellement, pour que la commodité cesse d'être une raison.
- Utilisez une autorité de certification privée pour les noms internes, ou émettez pour un nom qui n'a de sens qu'à l'intérieur du réseau.
- Surveillez Certificate Transparency pour vos propres domaines et alertez sur tout nom inattendu. Le même journal qui révèle cela à un attaquant peut vous le révéler en premier.
- Arrêtez de traiter l'obscurité comme un contrôle. Placez la console derrière le VPN ou un proxy tenant compte de l'identité, pour que connaître le nom ne serve à rien.
- Réconciliez régulièrement le DNS avec l'inventaire des actifs. Retirez les enregistrements et les certificats ensemble, et n'oubliez pas que le cas inverse, un enregistrement retiré avec un certificat actif, est celui qui trompe les défenseurs.