Blog & Média

22/06/2022

Teddy FERDINAND

sécurité

Quand vos certificats TLS vous trahissent

(String: <div> <h2 id="un-besoin-de-transparence">Un besoin de transparence</h2> Pour comprendre pourquoi vos certificats peuvent être un vecteur d’attaque, nous allons nous pencher sur le fonctionnement même d’un certificat TLS, du point de vue de votre navigateur. <h3 id="fonctionnement-du-tls-%C2%AB-classique-%C2%BB">Fonctionnement du TLS « classique »</h3> Sur un certificat classique, voici ce qui va se passer lorsque vous allez vous connecter à un site web exploitant une négociation chiffrée. <figure> <figcaption> Fonctionnement du TLS « classique » </figcaption> </figure> Votre navigateur se connecte à l’adresse demandée, puis récupère son certificat. Ensuite, il va se connecter à l’autorité de certification qui a délivré ledit certificat pour contrôler si le certificat est bien valide. <h3 id="fonctionnement-du-tls-avec-transparence-des-certificats"> Fonctionnement du TLS avec transparence des certificats</h3> Lorsque votre navigateur supporte la transparence des certificats, le flux de contrôle est plus complet. En effet, en plus de vérifier le certificat auprès de l’autorité de certification qui l’a émis, il va aussi le contrôler via un serveur de log tiers. Il existe plusieurs serveurs de logs, vous pouvez d’ailleurs voir <a href="https://certificate.transparency.dev/logs/">la liste actuelle</a>. Cela permet de confronter plusieurs informations afin de ne pas valider un certificat auprès d’une seule source. C’est une précaution importante dans le cas où une autorité serait compromise, mais permet aussi de mieux gérer la révocation des certificats, sur laquelle nous reviendrons plus bas. <figure> <figcaption> Fonctionnement du TLS avec transparence des certificats </figcaption> </figure> Voici d’ailleurs la description qu’en fait l’ANSSI (Autorité Nationale de la Sécurité des Systèmes d’Information) : <blockquote> Certificate Transparency vise à renforcer les contrôles sur les certificats émis par des autorités de certification, notamment ceux utilisés par HTTPS. Initié par Google, ce mécanisme est désormais standardisé par l’IETF. L’objectif de cette technologie est de faciliter la détection de certificats frauduleux ou invalides. Pour cela, les certificats émis par les autorités de certification reconnues par les navigateurs sont enregistrés dans des journaux en ajout seul. </blockquote> Les serveurs de logs obéissent à certaines règles importantes pour garantir la transparence des informations : <ul> <li>On peut uniquement pousser des nouvelles informations, jamais modifier ou supprimer une information</li> <li>Les informations doivent exploiter la cryptographie <a href="https://en.wikipedia.org/wiki/Merkle_tree">Merkle tree</a> pour leur transmission</li> <li>Tous les logs sont auditables publiquement</li> </ul> On retrouve ici certains préceptes que les amateurs de blockchain reconnaîtront, le but est le même : assurer la traçabilité des certificats. Ainsi, dans le cas où un certificat serait révoqué, il suffit de pousser l’information de sa révocation sur le registre public et votre navigateur saura que malgré le fait que le certificat soit « techniquement » valide, il n’est en réalité plus utilisable. Cela permet aussi de suivre la chronologie du certificat (création, invalidation, etc.). <h2 id="quand-la-transparence-vous-expose">Quand la transparence vous expose</h2> Si on suit le raisonnement que j’ai eu plus haut, la transparence des certificats apporte énormément d’avantages. Toutefois, de par sa nature publique, il est facile de manipuler les logs pour extraire et exploiter des informations. Il existe pour cela de nombreux outils, parmi lesquels : <ul> <li><a href="https://crt.sh/">crt.sh</a> : Un site web sur lequel on peut retrouver les certificats émis pour un domaine donné</li> <li>Les <a href="https://github.com/google/certificate-transparency">outils</a> fournis par Google</li> </ul> Le fonctionnement restera le même pour un domaine, dont on peut extraire les certificats associés. Prenons l’exemple du très populaire <a href="https://hashicorp.com/">hashicorp.com</a>, site de l’éditeur d’outils et de solutions d’automatisation et de gestion pour le cloud dont vous pouvez retrouver nombre de billets les concernant <a href="https://blog.wescale.fr/tag/hashicorp/">sur ce blog</a>. En allant sur crt.sh, on retrouve donc les certificats émis pour ce domaine : <figure> <figcaption> crt.sh </figcaption> </figure> À partir de là, un attaquant va chercher à trouver les ressources qui sont plus susceptibles d’être mal protégées, comme : <ul> <li>Des sites hors production, où la sécurité est parfois perçue comme non nécessaire</li> <li>Des applicatifs connus comme étant des portes d’entrée et avec de gros privilèges, comme les outils de CI/CD par exemple (GitLab, Jenkins, etc.)</li> <li>Des projets « confidentiels », qui sont encore en R&D ou non annoncés</li> </ul> Pour poursuivre l’exemple, sur HashiCorp, un domaine a attiré mon attention, recherchant un mot clé « staging » : <figure> <figcaption> Le résultat de la recherche sur crt.sh </figcaption> </figure> <figure> <figcaption> Le site « staging » identifié </figcaption> </figure> En essayant d’accéder au dit domaine, surprise, ça fonctionne ! Dans cet exemple, rien de grave, le site contient une authentification et les ressources présentes ne sont pas jugées critiques par Hashicorp. Il m’est arrivé cependant de trouver des serveurs Jenkins exposés publiquement par cette méthode lors d’un simple audit.   <h2 id="mes-conseils-pour-g%C3%A9rer-vos-certificats">Mes conseils pour gérer vos certificats</h2>   <h3 id="scanner-r%C3%A9guli%C3%A8rement-vos-domaines">Scanner régulièrement vos domaines</h3> Vu que ces listes sont publiques, je vous recommande fortement de scanner régulièrement vos propres domaines pour identifier rapidement les nouveaux certificats et les dangers associés.   <h3 id="ne-pas-utiliser-de-vrai-nom-ou-type-de-solutions-en-rd">Ne pas utiliser de vrai nom ou type de solutions en R&D</h3> C’est la technique utilisée par énormément de gros acteurs du web : utiliser des noms de code pour vos projets en cours de développement. En cas de divulgation, cela permet de complexifier l’identification de la solution que votre domaine cache et éviter qu’un concurrent puisse se positionner face à vous.   <h3 id="sensibiliser-les-%C3%A9quipes">Sensibiliser les équipes</h3> Comme souvent en sécurité, le point majeur est le même : sensibiliser les équipes. Si vous n’expliquez pas à vos équipes DevOps ce vecteur d’attaque, elles continueront de créer des certificats sans appréhender ce risque. Il faut aussi rappeler que les environnements hors production doivent respecter les mêmes critères de sécurité que la production (par exemple avec une authentification obligatoire, ségrégation du réseau, etc.).   <h2 id="utiliser-des-certificats-wildcard-une-bonne-id%C3%A9e">Utiliser des certificats wildcard, une bonne idée ?</h2> L’une des solutions que l’on peut voir serait aussi d’exploiter des certificats wildcard sur vos applications. Dans le cas d’HashiCorp évoqué ci-dessus, cela donnerait « *. hashicorp.com ». Sur le papier, cela limite les risques évoqués plus haut, mais en crée en réalité de nouveaux. L’un des plus importants étant qu’en cas de compromission et révocation de votre certificat, l’impact sera bien plus large et vous obligera à redéployer un certificat sur un plus grand nombre d’applications. De plus, mutualiser un certificat augmente aussi les risques que celui-ci soit exfiltré.   <h2 id="pour-finir">Pour finir</h2> Vous l’aurez compris, un attaquant cherchera toujours la moindre information disponible. Il faut garder à l’esprit que la transparence des certificats est l’un des premiers vecteurs d’attaque exploités, car il donne souvent bien trop d’informations. Il est donc important de le protéger autant que possible comme chaque information publique que vous mettez à disposition. Dans les faits, la transparence des certificats reste un outil très puissant et sécurisant pour vous et vos utilisateurs, avec les limites évoquées plus haut.   <h3 id="remerciements">Remerciements</h3> Merci à notre partenaire HashiCorp avec qui nous avançons chaque année pour échanger et partager nos expertises et solutions. La sécurité fait partie de nos valeurs communes et ils nous ont permis de les citer comme exemple pour partager cette culture. </div>)

Les certificats TLS font partie du quotidien pour n’importe qui manipule les technologies du web. Mais saviez-vous que vos certificats peuvent trahir vos projets confidentiels, vos environnements non productifs ou la topologie de votre entreprise ?

sécurité

Trivy, un scanner de sécurité couteau suisse

Comment être conforme avec PCI DSS sur AWS ?

Sécurité de la configuration des containers dans GKE

Quand vos certificats TLS vous trahissent

#WeSpeakCloud : Le podcast - Saison 2 - Episode 1 : La sécurité du point de vue de Teddy Ferdinand, DevSecOps chez Wescale

ShiftLeft Terraform avec TFsec

TFSec - Découverte : Simple, Basique

Comment appliquer de la conformité dans le Cloud avec Cloud Custodian ?

Passer et réussir la CKS