Blog | WeScale | sécurité (3)

27/06/2022
Alexandre KOLACZ

sécurité
Sécurité de la configuration des containers dans GKE
(String: La nouvelle fonctionnalité de sécurité s’appelle “Protect pour GKE” et inclut actuellement une solution de scan automatique des problèmes de configuration des charges de travail. Cette solution n’a pas de coût supplémentaire et les scans n'utilisent pas de ressources de calcul de vos nœuds.)
Google vient de mettre à disposition en pre-GA (General Availability) un nouveau moyen de sécuriser et de contrôler les conteneurs qui tournent dans vos clusters Google Kubernetes Engine (GKE).

Attention ! Les fonctionnalités proposées avant la mise à disposition générale peuvent être limitées, et les modifications apportées à ces fonctionnalités peuvent ne pas être compatibles avec d'autres versions pré-disponibles).

Lire la suite
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 ?

Lire la suite
20/05/2022
WeScale

sécurité
#WeSpeakCloud : Le podcast - Saison 2 - Episode 1 : La sécurité du point de vue de Teddy Ferdinand, DevSecOps chez Wescale
(String: )
Dans ce nouveau format, nous abordons des problématiques de l'informatique en observant comment plusieurs métiers y répondent et tentent de relever les nouveaux défis que celles-ci apportent.

Lire la suite
02/05/2022
Guillaume GUÉRARD

sécurité
ShiftLeft Terraform avec TFsec
(String: <h2 id="shiftleft-avec-tfsec">ShiftLeft avec TFSec</h2> Le ShiftLeft ou “décalage à gauche” dans la langue de Zizou est un concept qui veut que l’on apporte la sécurité au plus tôt dans le cycle de développement (DLC). Sur une trame temporelle qui va de gauche à droite, cette sécurité “au plus tôt” se positionnera sur le côté gauche, d’où ce nom de “ShiftLeft”.)
ShiftLeft avec TFSec Le ShiftLeft ou “décalage à gauche” dans la langue de Zizou est un concept qui veut que l’on apporte la sécurité au plus tôt dans le cycle de développement (DLC). Sur une trame temporelle qui va de gauche à droite, cette sécurité “au plus tôt” se positionnera sur le côté gauche, d’où ce nom de “ShiftLeft”.

Lire la suite
13/04/2022
Guillaume GUÉRARD

sécurité
TFSec - Découverte : Simple, Basique
(String: <h2 id="tfsec-qu%E2%80%99est-ce">TFSec, qu’est-ce ?</h2>)
Comme son nom l’indique, l’Infrastructure as Code (IaC), décrit l’infrastructure au format code. Cette qualité intrinsèque lui accorde un avantage certain. En partant de ce constat on peut définir que si le code décrit l’infrastructure, alors on peut auditer le code pour auditer l’infrastructure.

Lire la suite
24/11/2021
Ismael HOMMANI

sécurité
Comment appliquer de la conformité dans le Cloud avec Cloud Custodian ?
(String: <h2 id="introduction">Introduction</h2> L’usage du cloud dans les entreprises ne fait plus débat. Bien utilisé, il devient moteur d’avantages concurrentiels et ouvre la voie à de nouvelles perspectives de marché.)
Introduction L’usage du cloud dans les entreprises ne fait plus débat. Bien utilisé, il devient moteur d’avantages concurrentiels et ouvre la voie à de nouvelles perspectives de marché.

Lire la suite
07/09/2021
Thomas GERARDIN

sécurité
WeSpeakCloud le podcast, découvrez comment la sécurité se ré-invente
(String: L’on peut retenir de ces dernières années que la sécurité est plus que jamais primordiale, entre la multiplication des attaques notamment ransomwares et la multiplication des surfaces d’attaque. La sécurité se prévoyant à différents niveaux, il existe plusieurs manières de la concevoir et de la mettre en place. Néanmoins, il n’est pas toujours facile d’identifier le rôle de chacun dans la sécurité informatique.)
L’on peut retenir de ces dernières années que la sécurité est plus que jamais primordiale, entre la multiplication des attaques notamment ransomwares et la multiplication des surfaces d’attaque. La sécurité se prévoyant à différents niveaux, il existe plusieurs manières de la concevoir et de la mettre en place. Néanmoins, il n’est pas toujours facile d’identifier le rôle de chacun dans la sécurité informatique.

Lire la suite
23/07/2021
Guillaume GUÉRARD

sécurité
Analyse du code - Sécurisation du cycle de développement applicatif
(String: )
Bienvenue dans ce nouvel article sur la sécurité applicative qui fait suite à notre épisode sur l’analyse des dépendances. Cette fois-ci, nous traiterons du sujet de la sécurisation du code en lui-même au travers des analyseurs de code.

Lire la suite
06/07/2021
Tanguy COMBE

sécurité
La sécurité opérationnelle dans le cloud en 2 mots : Trust & Control
(String:  )
Dans un précédent billet vous avez découvert ou redécouvert Cloud Custodian, un outil de conformité qui permet d’écrire des policies en yaml pour identifier des ressources ou des évènements sur votre environnement. Dans cet article nous allons voir qu’en nous appuyant sur le RBAC (Role-Based Access Control) des cloud providers et sur Cloud Custodian, nous pouvons facilement mettre en place un framework de sécurité adaptable à vos problématiques SSI.

Lire la suite