Le biais du survivant est une tendance à se concentrer uniquement sur les exemples qui ont survécu à un événement, en ignorant ceux qui ont échoué. En matière de cybersécurité, cela signifie que les entreprises ont souvent tendance à se baser uniquement sur les incidents de sécurité passés qui ont été résolus, sans prendre en compte ceux qui ont échappé à leur détection ou n'ont pas été correctement résolus.

L'un des exemples les plus connus est celui des avions durant la seconde guerre mondiale:

En étudiant les dommages causés à des aéronefs revenus de mission, l'étude a recommandé de blinder les endroits des appareils qui présentaient le moins de dommages. En effet, Wald a constaté que les études précédentes ne tenaient compte que des aéronefs qui avaient « survécu » à leur mission, sans tenir compte de ceux qui avaient disparu. Ainsi, les endroits endommagés des aéronefs revenus représentent les endroits où ces derniers peuvent encaisser des dommages et réussir à rentrer à la base.

Source : Wikipedia

L'idée est donc de dire que les incidents que l'on voit ne sont pas forcément les plus importants, et qu'il peut être pertinent de se focaliser sur ce que l'on ne voit pas.

Les limites de l'apprentissage à partir des incidents passés

Apprendre de ses erreurs est sans doute l'étape la plus importante d'un incident, qu'il soit lié à la sécurité ou non. Durant l'étape du post-mortem, le focus est souvent mis sur la raison de l'incident, et comment éviter sa reproduction et le monitorer.

Toutefois, les attaques et les menaces évoluent constamment, de nouvelles vulnérabilités sont découvertes et les attaquants utilisent des tactiques de plus en plus sophistiquées. Se baser uniquement sur les incidents passés peut donc conduire à des lacunes dans la préparation à de nouvelles menaces.

Par exemple, une entreprise peut se concentrer uniquement sur les types d'attaques qui ont été précédemment détectées et résolues, tandis que de nouvelles méthodes d'attaque peuvent être utilisées sans être détectées. Cela peut entraîner une fausse confiance en matière de sécurité, car les attaquants peuvent exploiter les vulnérabilités non prises en compte pour causer des dommages importants.

Détecter des attaques est une étape cruciale de la surveillance d'un système d'information, toutefois, il est aussi très important de garder en tête qu'il y a toujours la possibilité de vulnérabilité qui n'ont pas encore été identifiée.

On se rappellera par exemple de WannaCry en 2017. Le ver était resté en sommeil pendant une longue période avant de s'activer et verrouiller énormément de systèmes, provoquant même l'arrêt de certaines entreprises.

WannaCry ransomware attack - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

En se basant uniquement sur les incidents visibles, de nombreuses entreprises ont donc été durement impacté par cette attaques.

La proactivité : l'arme de la cybersécurité

Il est essentiel d'adopter une approche proactive en matière de cybersécurité, plutôt que de simplement se fier aux incidents passés pour prendre des décisions. Cela peut inclure la surveillance continue des réseaux, la détection proactive des menaces, la formation des employés à la sensibilisation à la sécurité, ainsi que la mise en œuvre de mesures de sécurité appropriées pour protéger les systèmes et les données.

Une approche proactive implique également de reconnaître les limites de l'apprentissage à partir des incidents passés et de ne pas se fier uniquement à cette approche pour évaluer les risques de cybersécurité. Il est important de rester informé des nouvelles menaces, de mettre à jour régulièrement les systèmes et les logiciels, de réaliser des évaluations de sécurité régulières et de former continuellement les employés sur les meilleures pratiques en matière de sécurité.

La cybersécurité est une veille continue qui doit permettre de rester en permanence au courant des dernières attaques, des derniers vecteurs, des dernières vulnérabilités. Regarder uniquement le passé n'est pas (ou plus) suffisant, il faut être en mesure de préparer les futures attaques, identifier les failles avant qu'elles soient activement exploitées, surveiller, monitorer.

J'en avais parlé dans le passé, mais l'arme principale d'un hacker est sa capacité à identifier rapidement des failles, mais aussi à penser différemment, à exploiter ce qui peut passer pour des détails.

Il est aussi important d'être au courant des derniers modèle d'attaques, il existe pour ca de nombreux site et flux RSS.

En France, nous avons notamment le CERT-FR, qui publie nombre de bulletin de sécurité avec énormément d'informations pertinentes.

CERT-FR – Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques

cert-fr Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

A noter qu'il existe aussi un flux RSS intégrable facilement sur des outils comme Slack par exemple.

Le site de l'ANSSI regorge aussi d'information utiles sur les bonnes pratiques pour prévenir autant que possible les incidents de sécurité.

Enfin, un détail souvent oublié : il est crucial de former ses effectifs, surtout les équipes techniques (Développeurs, Ops, etc.) afin qu'ils soient conscient des risques liés à la sécurité et puissent les prendre en compte dans leurs réalisations.

Pour terminer

Le biais du survivant peut être un piège dans le domaine de la cybersécurité, car il peut amener les entreprise à se baser uniquement sur les incidents passés résolus, en ignorant les menaces potentielles persistantes. Il est essentiel de reconnaître les limites de l'apprentissage à partir des incidents passés et d'adopter une approche proactive pour protéger les systèmes et les données.

Il est important de rester informé des nouvelles menaces, de mettre en place des mesures de sécurité appropriées et de former continuellement les employés à la sécurité. La cybersécurité est un processus continu qui nécessite une vigilance constante pour protéger les actifs numériques d'une entreprise. En adoptant une approche proactive, elles peuvent ainsi mieux se préparer aux nouvelles menaces et réduire les risques de cyberattaques.

Depuis quelques jours, suite au rachat de Twitter par Elon Musk, on entend beaucoup parler de Mastodon.
Certains se disent prêts à migrer de Twitter vers Mastodon, si nombre de billets de blog parlent de Mastodon vs Twitter du point de vue fonctionnel, on parle assez peu des aspects liés à la sécurité.
Ici, je ne vous parlerais pas de modération, de changements d'habitude, etc. simplement de mon point de vue lié à la sécurité.

Mastodon : comprendre le modèle décentralisé

Au contraire de Twitter, Mastodon utilise un modèle décentralisé.

Ce dernier permet d'avoir de multiples instances qui communiquent entre elles via un protocole commun.

Cela permet de ne pas nécessiter que l'ensemble des utilisateurs soit sur la même instance pour se suivre, réagir ou liker des "pouets" (l'équivalent des tweets).

Pour en savoir plus sur le sujet, je vous conseille l'excellent article sur le blog de Framasoft :

Mastodon, le réseau social libre qui est en train de bousculer twitter

Une alternative à Twitter, libre et décentralisée, est en train de connaître un succès aussi spontané que jubilatoire... Depuis que Twitter a changé la manière dont les réponses et conversations s’affichent, des utilisatrices et utilisateurs abondent par milliers sur cet autre réseau. Chacun·e cherc…

FramablogFramasoft

Et si on parlait de sécurité ?

Le souci du tiers de confiance

Vous l'aurez compris, nous avons déjà un premier "point faible", du a un principe que j'ai déjà abordé dans d'autres billets dans le passé : le tiers de confiance.

L'un des principaux défauts de Mastodon est aussi sa force. La décentralisation empêche une politique de sécurité commune à l'ensemble des instances.
Cela signifie donc que l'on confie des données potentiellement confidentielles et/ou sensibles à un tiers.
Tout dépend de l'importance que l'on attache aux dites informations, mais par exemple votre adresse mail peut potentiellement être exploitée par un administrateur malveillant ou une instance compromise.
Cela signifie aussi que d'une instance à l'autre, vous pouvez avoir différents niveaux de gestions de données sensibles.
Pour certains, il sera impossible aux modérateurs d'accéder aux données "personnelles", pour d'autres, ça sera open bar.

Modification du code

J'ai vu en boucle "Mastodon est open source, tu n'as qu'à voir le code si tu veux voir [choisir la feature sécurité]".
Oui et non, tout comme VSCode n'est pas l'exact contenu du repository open source, ce n'est pas parce qu'un système est basé sur de l'open source qu'il est déployé tel quel.
Au contraire, vu que le code est ouvert, il est d'autant plus facile pour quelqu'un de malveillant de le modifier pour en faire ce qu'il veut.
Ainsi, rien ne m'empêche techniquement de modifier le code de mastodon pour qu'il stocke les mots de passe en clair, m'envoie une copie de tous les MP par mails ou envoyer des messages en me faisant passer pour quelqu'un d'autre.

Phishing

Le côté décentralisé facilite aussi un autre aspect : le phishing.
En effet, étant donné qu'il n'y a pas de domaine prédéfini, rien ne m'empêche de mettre une page de création de comptes "fake".
Ainsi je peux récupérer pas mal d'informations sensibles, notamment les mots de passe.
En effet, si dans l'IT, nous sommes plus sensibilisés que d'autres sur la réutilisation de mot de passe, ce n'est pas le cas d'une grande partie de la population qui recycle ses mots de passe d'application en application.

De cette manière, je peux facilement tester un mot de passe que j'ai récupéré sur d'autres sites web pour en prendre le contrôle ou exfiltrer nombre d'informations.

L'infrastructure et le patching

Une fois de plus, étant donné que la solution est hébergée par un tiers, il est nécessaire de s'assurer que l'infrastructure qui héberge la solution est assez sécurisée.
En effet, la moindre brique non sécurisée est un vecteur d'attaque.
Tous les jours des dizaines de CVE (Common Vulnerabilities and Exposures) sont trouvées des produits, y compris des failles zéro day (faille inconnue non patchées), il est donc nécessaire d'avoir une veille de la part de l'hébergeur pour mettre à jour rapidement ses briques à chaque faille découverte, ainsi qu'une surveillance sur son infrastructure pour être à même de détecter et réagir à tout comportement anormal ou inhabituel.

Et twitter dans tout ça ?

On pourrait croire que je vais dire que Twitter est sécurisé, mais c'est faux.
Dans le passé, il y a eu de multiples hacks de Twitter, j'avais même parlé du dernier dans un billet sur ce blog.

Ce que nous apprend (ou rappelle) le hack de Twitter

Il y a quelques jours, Twitter a été la cible d’un hack invitant, via des “comptes vérifiés”, les utilisateurs à envoyer des BitCoins pour en recevoir le double. Je vous propose un petit post sur ce que nous pouvons retenir de cette attaque, du point de vue sécurité informatique. Disclaimer

TFerdinand.netTeddy FERDINAND

Toutefois, des mécanismes de protection dus au fonctionnement même d'une entreprise assurent un niveau de sécurité plus élevé, qui est potentiellement audité.
Twitter doit se conformer à de nombreux impératifs de sécurité de par sa taille et le fait qu'elle doit rassurer son public.

Ça reste tout de même une boite noire sur laquelle, de mon côté, je ne peux pas vous assurer que tout est à 100% sécurisé.

En conclusion : on oublie Mastodon ?

On pourrait croire que je dise qu'il faut donc s'enfuir loin de Mastodon avec ce que je viens de dire, mais c'est faux!
Comme à chaque fois que vous confiez vos données personnelles, il est important d'être conscient de la sécurisation de celles-ci.

Mastodon reste un outil open source très puissant qui dans certains modèles peut rivaliser avec Twitter.

Toutefois, son côté décentralisé le place aussi potentiellement en position de faiblesse quand on s'attarde sur la sécurité.

N'hésitez pas à réagir dans les commentaires pour donner votre avis!

Avertissement

Comme souvent sur ce genre de billet, je tiens à rappeler que le contenu que vous trouverez ici l'est uniquement à des fins pédagogiques.

L'intrusion non autorisée dans un système d'information est passible d'amende et/ou d'emprisonnement.

Comprendre les attaques, c'est savoir comment les éviter. Dans ce billet, je vous propose de voir un modèle d'attaque réseau courant : l'ARP poisoning.

L'ARP, c'est quoi ?

Pour comprendre l'attaque, il faut déjà comprendre sur quoi elle repose.

Pour l'ARP, nous repartirons donc du modèle OSI, décrivant les différentes couches du réseau.

L'ARP est le lien entre la couche 2 et 3, c'est ce qui va permettre à un ordinateur ou serveur de convertir une adresse IP en adresse matérielle (MAC).

Pour fonctionner, l'ARP utilise un système de broadcast. Chaque périphérique sur le réseau envoie globalement à l'ensemble dudit réseau son adresse IP associée à son adresse matérielle.

Vous pouvez facilement accéder et modifier cette table avec la commande arp -a (que ce soit sous Linux ou Windows).

La faiblesse de ce protocole

Je pense que vous avez déjà localisé le point faible : chaque nœud envoie l'information, et rien ne permet de contrôler la véracité de celle-ci.

Ainsi, je peux très bien annoncer mon adresse MAC comme correspondant à l'IP du routeur.

Chaque nœud (ou les nœuds ciblés) sur mon réseau recevra donc cette information et mettre à jour sa table ARP avec la correspondance.

Comment se passe l'attaque?

Il y a un prérequis, être sur le même réseau que sa cible.

Ensuite l'idée consiste à se mettre entre la cible et le routeur. Cela permettra donc de lancer une attaque de type "Man in the middle" pour capturer tout le trafic réseau entre ma cible et le routeur.

Pour l'exemple que je vais prendre ci-dessous, je vais partir de mon propre réseau, et je vais me mettre entre mon PC et ma Livebox.

Pour ce faire, je vais donc envoyer deux informations différentes.

Depuis mon PC attaquant, je vais indiquer à ma livebox que je suis le PC de la victime.

À ma victime, je vais dire que je suis la livebox. De cette manière, cela me permet d'avoir les deux flux d'informations qui transit au travers de mon PC d'attaque, en me positionnant de la même manière qu'un proxy.

L'attaque en détail

Prérequis

Comme je l'ai décrit plus haut, je vais donc avoir besoin de plusieurs choses pour procéder à mon attaque :

• Un accès au même réseau que ma cible
• Un PC avec différents outils (que je décrirais plus bas)
• L'IP de ma cible, même si je peux m'en passer, comme nous le verrons

Dans le cas de ce billet, je vais utiliser deux machines virtuelles "Lab" :

• Mon attaquant sera une VM utilisant Kali Linux
• Ma cible sera un VM sous Windows 10

Détecter le PC Windows

Pour effectuer mon attaque, je vais utiliser le populaire bettercap.

Ce dernier va me fournir l'ensemble des outils dont j'ai besoin pour détecter les périphériques sur mon réseau et procéder à l'ARP poisoning.

Je vais donc le démarrer avec la commande ci-dessous :

bettercap -iface eth0

Bettercap fonctionne avec des modules, configurables et exécutables. Je ne rentrerais pas dans les détails des modules ici, et je vous invite à consulter la documentation associée pour plus de détails.

Si nécessaire vous pouvez utiliser la commande help pour voir les commandes et modules disponibles ainsi que leurs statuts.

Dans un premier temps, nous allons utiliser le module "net.probe".

Comme son nom l'indique, ce dernier va nous permettre de détecter les périphériques sur le réseau.

net.probe on
net.show

On retrouve bien ma cible ci-dessous, qui n'est autre que l'IP 192.168.109.130

Commençons à s'amuser

Maintenant nous allons lancer l'attaque sur la table ARP de la cible.

Avant de commencer, je vais juste capturer la table de ma cible.

Le plus important ici est l'IP 192.168.109.2 qui correspond à l'IP de mon routeur virtuel.

Depuis ma VM Kali, toujours dans bettercap, je vais donc passer à l'offensive!

set arp.spoof.fullduplex true          #Indique de lancer l'attaque sur la cible et sur le routeur
set arp.spoof.targets 192.168.109.130  #Indique l'IP de la cible
arp.spoof on                           #Lance l'attaque

La première ligne est importante, car elle va permettre de lancer directement l'attaque des deux côtés.

À noter que certains routeurs sont protégés contre les attaques ARP. Dans ce cas, nous ne verrons que les trames sortir de la cible, mais pas le retour, ce qui limite les attaques.

Si je regarde la table ARP de ma cible maintenant, nous verrons que l'IP du routeur n'est plus la même!

Au passage, on notera qu'elle a maintenant la même adresse MAC que ma VM Kali 192.168.109.129.

Maintenant je suis capable de voir le trafic entrant et sortant de ce PC avec un simple net.sniff on

Qu'est-ce que ça m'apporte à ce point ?

Arrivé là, je suis capable de capturer l'ensemble du trafic non chiffré sortant du PC de ma victime.

Cela signifie que je peux voir :

• Les appels en HTTP
• Les requêtes DNS non chiffrées
• Les requêtes SNI

C'est tout naze, on voit que le HTTP

Beaucoup diront que cela correspond à une faible partie du réseau. C'est vrai et faux à la fois.

Si je suis dans une entreprise, beaucoup considèrent qu'il n'est pas nécessaire de mettre du chiffrement pour les endpoints internes par exemple, cela permet donc de potentiellement capturer beaucoup de trafic.

De même savoir sur quel site un utilisateur va me permet potentiellement de cibler une attaque, que ce soit du phishing ou du social engineering.

Enfin, il faut voir cette partie comme une première étape, en effet, une fois que je suis positionné en man in the middle cela me permet aussi d'altérer le trafic pour modifier ce que voit ma victime, mais nous verrons ce point dans un autre billet!

En conclusion, méfiez-vous de TOUS les réseaux

Le but de ce billet est de rappeler qu'un attaquant n'est pas forcément externe, même dans votre réseau d'entreprise il est possible de faire pas mal de dégâts.

L'ARP spoofing fait partie des points qui sont normalement couverts par la plupart des routeurs d'entreprise, mais pas tous. Il est important de s'en protéger.

La plupart des routeurs grand public ne proposent pas de protections particulières à ce sujet, par exemple, je peux faire cette attaque sur ma Livebox.

Cela rappelle aussi l'importance de tout chiffrer sur le trafic sortant de votre PC, via un VPN par exemple, il existe aujourd'hui encore de très (trop) nombreux services communiquant en HTTP.

En entreprise, n'hésitez pas non plus à imposer le TLS partout, y compris en interne.

Si vous souhaitez en savoir plus sur ce qu'apporte un VPN, rendez-vous sur mon billet associé!

Un VPN protège-t-il réellement votre vie privée ?

Dernièrement, je vois de plus en plus de publicité indiquant que tel ou tel VPN protège votre vie privée. On m’a aussi posé plusieurs fois la question afin de comprendre si c’était vraiment le cas ou non. Aujourd’hui, j’ai donc décidé de vous parler de VPN.

TFerdinand.netTeddy FERDINAND

Je travaille sur des environnements AWS depuis plus de 6 ans maintenant. Que ce soit en tant qu'Ops, architecte, ou architecte sécurité, il y toujours une constante que je constate autour de moi : l'IAM d'AWS est très souvent mal utilisé.

Dans ce billet, je vous propose de faire un petit tour d'horizon des raisons probables.

Parce que la doc vous indique de mettre du wildcard

La documentation est censée être le pilier sur lequel s'appuyer. Toutefois, force est d'admettre que la documentation d'AWS est loin d'être un exemple en ce qui concerne l'IAM.

Bien que la firme prône le least privilege, beaucoup de ses documentations en sont très loin.

De mon point de vue, la documentation est censé montrer des exemples les plus sécurisés possible pour "pousser" les utilisateurs à adopter les bons réflexes. Force est d'admettre que ce n'est pas le cas.

Parce que les APIs sont inconsistantes

Principal souci du modèle d'AWS, qui fait que chaque équipe produit est autonome : L'inconsistance des API.

Les même actions ne correspondent pas forcément au même verbes API...

Ainsi la simple action de créer un tag peut avoir plusieurs nom différents en fonction des services, comme par exemple :

• elasticloadbalancing:addTags
• ec2:createTags
• ecr:tagResource

Mais comme ce serait trop simple, toutes les API n'ont pas forcément les mêmes type de cible.

Ainsi si je veux cibler des ressources en fonction de leurs tags, j'ai encore une fois des filtres différents :

• aws:ResourceTag/${TagKey}
• aws:TagKeys
• elasticmapreduce:ResourceTag/${TagKey}

Parce que le filtrage est inégal

Lorsqu'on met en place un modèle zero trust basé sur le least privilege, on va vouloir cloisonner au mieux les droits que l'on donne pour éviter toute action non désirée.

Maintenant on arrive au vrai problème.

En fonction des ressources, on pourra (ou non) filtrer correctement, mais pas forcément au même niveau.

Certaines ressources ont des ARN prévisibles, dans ce cas il est simple filtrer en amont (avant même que la moindre ressource soit créé).

D'autres fonctionne sur des identifiants internes créés par AWS, comme les security group par exemple.

Dans ce cas, il est parfois possible de filtrer sur la présence de certains tags, mais une fois de plus, pas tout le temps!

En effet, tous les services n'appliquent pas les tags de la même manière. Certains vont l'appliquer dès la création, d'autres après. Parfois tout se fait en un seul appel API, parfois en plusieurs...

Parce qu'il y a de multiples type de policies

J'aime à dire que l'IAM d'AWS est sans doute l'un des plus complet à ce jour. Toutefois, sa complétude vient aussi avec une complexité certaine : Le nombre de policies et les différentes couches qui s'appliquent à chaque évaluation.

• Commençons par le plus simple : les policy IAM "classiques", que l'on appelle aussi "Identity based policies", ce sont les politiques que tout le monde exploite directement lorsque vous vous connectez à AWS. Ce sont aussi ces dernières qui sont utilisées quand vous utilisez des roles AWS.
• Ensuite, il y a les "resource based policies", qui au contraire des précédentes sont directement attachées à un service, comme S3, SQS ou IAM (pour les trusts)
• Puis viennent les boundaries, ces policies sont attachées à des roles ou utilisateurs pour filtrer les droits, un peu comme un tamis.
• On pourrait aussi parler des SCP, qui englobent tout un compte ou une OU du service AWS Organization, pour appliquer des boundaries globales.
• il y a enfin des policies qui peuvent être crée à la connexion avec un utilisateur fédéré : les session policies

Cinq type des policies qui peuvent toutes être utlisées en même temps lorsque vous accédez à un service, cinq!

Je ne peux que comprendre ceux qui se perdent dans ces multiples niveaux d'abstraction.

Parce qu'il y a beaucoup de limitations

Comme tous les services d'AWS, l'IAM a ses propres limitations.

Par exemple, un role IAM ne peut pas avoir plus de 10 managed policies d'attachées, et chacune de ces policies ne peut pas dépasser 6144 bytes (sans les espaces/sauts de ligne).

Un role ou un utilisateur ne peut pas avoir plus d'une boundary attachées.

Ces limitations empêchent de pouvoir composer des roles ou utilisateurs de manière optimale car si l'on veut restreindre au maximum, on est obligé de recréer des policy pour chaque ressource!

De plus quand on veut pouvoir donner des accès console + CLI, on est parfois obligé de donner plus de droit que souhaité car sinon on empêche la console de fonctionner correctement.

Parce que même le support y perd son latin

Mon dernier point et non des moindre : le support lui même s'y perd!

j'ai déjà eu à contacter le support à de multiples reprises pour des soucis d'IAM, et force est d'admettre que très souvent le support tatône pour trouver une policy fonctionnelle ou comprendre d'où peuvent venir les blocages.

Entre l'inconsistance des API, des ressources, des filtres et la complexité de certaines policies lorsqu'on veut filtrer efficacement, c'est parfois compliqué de suivre le fil.

Comment améliorer les choses ?

Malgré tout les points que j'ai cité, il est toujours possible de faire "proprement" des policies (du moins du mieux possible), toutefois, ca demande du temps et de l'outillage.

Pour ma part, voici ce que j'utilise très (très) souvent :

• La documentation officielle de toutes les API, avec leurs filtres : Cette documentation est relativement bien tenue à jour et vous permet d'avoir déjà une bonne vision d'ensemble
• Le simulateur de policy d'AWS : qui vous permet de tester une policy sur une action particulière, très utile quand on veut filtrer sur des ARN ou tags par exemple.
• Des linter de policy, que ce soit celui intégré dans AWS Access Analyzer ou des outils tiers comme Parliament par exemple

Il faut garder en tête que l'IAM d'AWS reste complexe de part sa puissance. Pour ma part, même après des années à en faire quotidiennement, je suis très loin d'en maîtriser 100% de ses aspects...

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 ?

Un besoin de transparence

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.

Fonctionnement du TLS « classique »

...

La suite sur le blog de WeScale

Je vois souvent passer des communications indiquant qu'il faut faire des mots de passe avec beaucoup de caractères, car cela les sécurise, avec de jolis graphes qui expliquent qu'il ne faut que quelques secondes pour casser un mot de passe à 8 caractères.

C'est à la fois vrai et faux.

Aujourd'hui, je vais vous partager mon avis sur ce sujet.

Avoir un mot de passe fort est important...

...mais ce n'est pas la seule chose importante

Il est évident qu'il est indispensable d'avoir un mot de passe fort pour sécuriser ses différents accès.

Par mot de passe fort, j'entends :

• Minimum 12 caractères
• Mélange de majuscules et minuscule
• Présence de chiffres et caractères spéciaux
• Unique pour chaque site

J'ajouterais aussi qu'il est important que ce mot de passe ne reprenne pas quelques informations "personnelles", telle que :

• Nom des animaux de compagnie
• Date de naissance
• Prénom des enfants, conjoint etc.

Pourquoi? Car cela permet de vous protéger des attaques par dictionnaire.

En effet, l'un des modèles d'attaque courant consiste à se renseigner un minimum sur sa cible, avec les réseaux sociaux par exemple, pour construire un dictionnaire, permettant de créer des combinaisons de mot de passe possibles.

A chaque site son mot de passe

Plus important encore que la complexité du mot de passe, son unicité est un critère primordial.

Pourquoi ? Tout simplement parce que des sites se font pirater tous les jours et toutes les entreprises sont ciblées.

L'intérêt est donc en cas de compromission d'un site de réduire énormément le blast radius et éviter que l'ensemble de vos comptes soit compromis en un coup.

A ce titre, je vous invite fortement à vous inscrire sur HaveIBeenPwned.com afin de voir si votre adresse mail s'est retrouvée dans un leak.

Exploiter autant que possible l'authentification à facteur multiple

L'authentification à facteur multiple, ou MFA (Multiple Factor Authentication), permet de complexifier une attaque en demandant une information supplémentaire à l'utilisateur pour l'identifier.

Cela peut être, sans être exhaustif :

• Une clé physique, comme les célèbres YubiKeys
• Un code unique, avec des applications comme Authy, ou un générateur physique
• Un code envoyé par mail, SMS, appel téléphonique, etc.

Responsabilité du développement

Limiter la communication à indiquer qu'il faut créer un mot de passe sécurisé est insuffisant.

Il est aussi indispensable de mettre en place de bonne pratiques de développement, petit tour d'horizon.

Exponential backoff

Derrière ce terme barbare se cache l'un des concept qu'on retrouve souvent dans les webservices.

L'idée ici est qu'a chaque mot de passe erronné, on interdit à l'utilisateur de se connecter pendant un certain laps de temps, de plus en plus grand.

C'est ce que font la plupart des systèmes Linux par exemple.

Cela permet de réduire grandement la facilité avec laquelle on va pouvoir "brute force" un compte, c'est à dire tenter de casser le mot de passe en essayant beaucoup de combinaisons.

Ainsi, même avec un mot de passe plus faible, les possibilités restent réduites.

Toutefois, pour que ce modèle soit efficace, il est important de prendre en compte les points suivants :

• Toutes les attaques ne ciblent pas forcément un seul compte, certains attaquant vont cibler une liste de compte et tourner entre les comptes pour attaquer et être moins visible, sur ce point, on filtre souvent en exploitant les adresses IP, en interdisant les tentatives d'affilées depuis la même adresse.
• Empêcher les tentatives d'affillée sur le même compte, même depuis plusieurs IP. Cela permet par exemple de se protéger contre les attaques effectuées par des botnets.

Ces protections vont être pertinentes avec des modèles d'attaques courants.

De plus, il faut aussi se méfier des attaques slow rate. Ces attaques vont utiliser les mêmes modèles que précédemment, mais avec une fréquence faible, pour essayer de passer sous les radars. D'où l'importance de bien surveiller les tentatives d'accès!

On peut aussi aller plus loin en implémentant en plus une solution antibot, comme j'en ai parlé par le passé :

La difficulté de la lutte antibot sur le web

Les robots, appelés plus couramment bots, pullulent aujourd’hui sur Internet. Il représente une part du trafic Internet global non négligeable. Aujourd’hui, je vous propose de découvrir le monde des bots de l’Internet. Des bots… mais pour quoi faire ?La première question que l’on pourrait se poser

TFerdinand.netTeddy FERDINAND

Ne pas donner trop d'informations en cas d'erreur

Je l'ai déjà dit : l'information, c'est le pouvoir.

Même si un utilisateur légitime sera heureux de savoir s'il s'est trompé sur son login, son mot de passe, si son compte est verrouillé etc., cela reste une informations pertinente pour un attaquant, lui permettant de savoir comment orienter son attaque.

L'un des exemples est d'utiliser les formulaires de login pour faire de l'énumération d'adresse mail, quand le formulaire réponds gentiment "je ne connais pas ton adresse mail".

Ainsi, quelque soit le problème d'authentification, il est conseillé de toujours répondre le même message, le plus générique possible.

Ajouter du sel à la recette

La sécurisation des mots de passes passe aussi par leur stockage.

En cas de compromission d'une base de donnée, le but est de complexifier autant que possible le boulot du hacker.

Pour cela, la technique la plus commune (et simple) reste le basique, mais efficace salt + hash.

Cette technique consiste à ajouter un chaine de caractères en supplément du mot de passe, si possible unique pour chaque utiliteur.

Cela permet d'avoir des hash moins facilement reversible (par dictionnaire).

Auth0 a publié un bon article sur le sujet, que je vous invite à lire si vous voulez en savoir plus.

Adding Salt to Hashing: A Better Way to Store Passwords

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and to ...

Auth0 - BlogDan Arias

Pour finir

Les points que je cite ici ne sont pas exhaustifs, mais consiste pour moi dans le socle solide qui permet de sécuriser un peu plus vos comptes.

La meilleure manière de générer un mot de passe unique et sécurisé pour chaque site reste l'utilisation d'un password manager, comme keepass, bitwarden, etc.

Pour ma part, j'exploite bitwarden, qui me permet de générer et stocker des mots de passe forts et uniques, comme vous pouvez le voir ci dessous.

N'hésitez pas à rajouter en commentaires les points qui vous semblent indispensables.

À moins de vivre dans une grotte, vous n’avez pas pu passer ces derniers jours à côté des failles découvertes sur la librairie Java log4j.

Je ne vais pas vous faire un énième post pour parler de cette faille, mais plutôt parler de mon expérience sur le terrain sur l’impact de cette dernière au niveau opérationnel.

L’importance d’avoir un inventaire à jour

J’en ai parlé sur Twitter, mais pour moi, cette faille met en exergue le fait que beaucoup d’entreprises manquent d’un inventaire à jour de leurs ressources.

Lorsqu’une faille comme celle-ci se déclare, il est important d’être en mesure d’identifier rapidement quelles sont les ressources en risques. Mais avoir un inventaire à jour ne se limite pas aux machines, mais aussi à leur contenu.

C’est d’autant plus important lorsqu’on exploite la puissance du cloud, avoir des machines volatiles rend d’autant plus complexe leur gestion.

Pour ça il existe plusieurs solutions.

Faire uniquement de l’infra as code

Ce point va sembler trivial à beaucoup d’entre vous, mais faire uniquement de l’infra as code simplifie énormément les choses pour visualiser rapidement ce qu’on déploie, sur quel projet, quelle machine, quel compte, etc.

Dans un pipeline CI/CD c’est le rôle d’un SAST (Static application security testing) de repérer les failles courantes au moment de la compilation des nouveaux projets, toutefois, il faut de l’outillage pour les projets déjà compilés, par exemple, sur GitHub, Dependabot m’a indiqué assez rapidement les projets dans lesquels il avait identifié l’utilisation de la librairie.

Toutefois, ce point n’est clairement pas suffisant. Ce n’est pas parce que je ne définis pas explicitement une librairie qu’elle n’est pas utilisée.

Scanner les artefacts déjà créés

Si vos applications sont déjà compilées, il existe souvent sur vos gestionnaires de librairies des solutions pour scanner ces derniers.

Par exemple, Docker Hub vous permet de scanner vos images à la recherche de la librairie.

Toutefois, ce n’est toujours pas suffisant. Sur vos serveurs, vous n’utilisez pas forcément que des packages que vous maitrisez et référencez vous-même.

Par exemple, vous pouvez exploiter une image AWS d’un éditeur sur le marketplace, ou avoir des applications tierces déployées dans votre infrastructure.

Scanner en continu vos serveurs

C’est là qu’entre en jeu le troisième niveau de scan : vous pouvez scanner en continu vos machines pour identifier rapidement les serveurs en danger.

Il existe pour cela des outils comme Nessus Tenable ou encore Rapid7 InsightVM. Le rôle de ces outils va être de scanner vos serveurs et vous remonter les machines en risque.

Une simple recherche avec l’identifiant d’une CVE vous permet d’identifier rapidement les serveurs impactés.

Comment j’ai vécu cette étape

Comme beaucoup dans l’infosec ces derniers jours, cette première étape a été compliquée. Même avec de l’outillage, on prend toujours le risque de passer à côté de certaines ressources.

Je travaille dans une petite équipe et nous avons réagi au mieux, mais vu le risque encouru avec cette vulnérabilité, nous refaisons plusieurs contrôles. Ce point est épuisant, car nous devons faire nombre d’actions manuelles, tout n’est pas forcément simplement automatisable.

C’est une étape laborieuse, épuisante (mentalement), mais indispensable et critique.

Une fois les serveurs identifiés je fais quoi ?

Maintenant que je sais quelles sont mes ressources touchées par la vulnérabilité log4j, je fais quoi ?

Première chose qu’on oublie souvent : on ne panique pas !

C’est un comportement que je vois souvent lors d’incidents de sécurité, pourtant il est d’autant plus important de garder la tête froide qu’une erreur peut couter cher !

Patcher, patcher, patcher…

La solution sera souvent la même ici : patcher ou mettre à jour l’applicatif. Néanmoins, à ce jeu, tous les éditeurs ne sont pas aussi sérieux.

Sur ce point, j’ai vu plusieurs comportements :

• Les éditeurs très réactifs et transparents sur les risques
• Les éditeurs qui indiquent qu’ils ne savent pas (ce qui n’est pas forcément pour me rassurer soit dit en passant).
• Les éditeurs qui disent être impactés, mais mettent plusieurs jours à sortir une version avec le fix nécessaire
• Ceux qui disent qu’ils ne sont pas impactés pour finalement indiquer le contraire
• Ceux qui préfèrent indiquer qu’ils ne sont pas impactés alors qu’ils sont loin de java (par exemple HashiCorp et ses outils écrits en GoLang)

Dépendre d’autres équipes

À mon poste, je ne suis pas celui qui patche, mais dans l’équipe qui va identifier les risques, les mesurer et demander les actions nécessaires aux autres équipes (Dev, Ops, DataOps, etc.)

C’est une posture qui peut être frustrante, car on dépend de gens sur lesquels on n’a aucun pouvoir de priorisation et tout le monde ne perçoit pas forcément les risques de ces failles.

C’est pourquoi il est important d’avoir (une fois de plus) une posture pédagogue, et de bien expliquer les risques et pourquoi il est important de réagir vite.

Et c’est aussi à cette étape qu’il est important de bien tracer toutes les demandes et faire le suivi associé.

L’une des solutions temporaires peut parfois être de mitiguer le risque pour réduire autant que possible l’impact de la lenteur de tiers, cela peut passer : par des règles sur un WAF, des modifications de packages directement sur les machines (même si je ne suis pas fan de cette solution), changer l’exposition de certaines machines (passer des machines derrière un VPN par exemple) ou encore interrompre certains services temporairement.

La solution temporaire dépendant bien entendu de l’évaluation du risque associé.

Comment j’ai vécu cette étape

Comme je l’ai évoqué, j’ai eu un peu de frustration devant la non-réponse de certaines équipes, ou l’impression qu’on s’en f... . Pour certaines équipes, je suis un incident parmi d’autres déjà en cours, et je ne fais que rajouter une pièce dans la machine.

Cette étape n’est pas forcément simple, mais je trouve que cela reste plus simple qu’avoir l’inventaire.

L’après log4j

Pour l’instant la tempête log4j n’est pas encore finie, avec une faille découverte avant-hier à l’heure où j’écris ces lignes.

Investir dans la sécurité

Cette tempête comme d’autres avant elles (Spectre, Meltdown, Heartbleed, etc.) est l’occasion pour les équipes sécurité de rappeler l’importance de certains investissements :

• Avoir une équipe sécurité qui se tient à jour
• Avoir de l’outillage pour identifier rapidement les failles
• Avoir un inventaire à jour
• Sensibiliser les équipes à l’importance des bonnes pratiques de sécurité

J’ai même rappelé ce point (sur Twitter une fois de plus) dernièrement :

Combattre le comportement prédateur des big Tech

Cette faille rappelle la dure réalité des projets open source : beaucoup de projets sont clairement exploités par de nombreuses énormes sociétés qui reposent dessus sans jamais contribuer que ce soit au code ou au moins financièrement.

Log4j est une librairie exploitée par des millions d’applications dans le monde, pourtant elle est maintenue par peu de personnes.

De nombreux Tech gravitant dans l’univers open source ont fait le même constat :

Cela n’est pas sans rappeler des batailles récentes :

• Elastic.co VS AWS
• MongoDB VS AWS

Faute de trouver une solution viable, la solution est souvent de passer par la case légale en mettant des clauses empêchant l’utilisation par ces entreprises, car elles exploitent la richesse de ces projets sans jamais rien donner en contrepartie.