Connexion Premium

[Édito] Cybersécurité : ne tirez pas sur le messager… et mettez en place security.txt !

Sinon il y a le pare-feu d’OpenOffice

[Édito] Cybersécurité : ne tirez pas sur le messager… et mettez en place security.txt !

Des failles, ça peut arriver à tout le monde même en prenant un maximum de précautions. Aujourd’hui nous parlons de ce qui se passe après : la manière de réagir face à un signalement. Au lieu de vouloir faire peur et de tirer sur le messager, la bonne pratique est d’écouter, remercier, corriger. Rappelons qu’il existe un moyen d’expliquer comment contacter les équipes de manière sure et responsable.

Imaginez, vous êtes un expert en cybersécurité et vous trouvez une faille sur un site. Quatre choix (pour simplifier) s’offrent à vous.

Le premier est l’appat du gain en essayant de vendre votre découverte à des personnes malveillantes ou sur des forums. Le second est d’en profiter directement en récupérant des données, pour ensuite les revendre, les exploiter, faire chanter l’entreprise… Le troisième est de signaler de manière responsable la faille aux responsables du site.

Il est également possible de saisir l’ANSSI en tant que lanceur d’alerte « en cas de non-respect d’une disposition issue d’un cadre réglementaire en matière de sécurité des systèmes d’information susceptible de faire l’objet d’une sanction », et donc si la faille est particulièrement grave.

L’ANSSI sera « susceptible de demander au lanceur d’alerte tout élément qu’elle jugerait nécessaire à l’appréciation de l’exactitude des allégations formulées », mais s’engage à garantir la confidentialité de son identité.

50 nuances de chapeaux

Les « white hats » sont les « gentils » hackeurs avec une éthique et un sens des responsabilités ; ils ne font pas n’importe quoi et n’exploitent pas ni ne mettent en danger les données des utilisateurs. Ils sont à l’opposé des « black hats », ces « méchants » qui exploitent les vulnérabilités. On retrouve aussi des « grey hats » qui sont un peu entre les deux (ou les deux à la fois suivant les cas).

L’éthique des « white hats » ne les empêche pas de fixer des limites, par exemple lorsqu’une faille béante est découverte et que rien n’est fait malgré des signalements à répétition. L’équipe Project Zero de Google, par exemple, attend maximum 120 jours pour publier les détails d’une faille, qu’elle soit bouchée ou non. Il y a une dizaine d’années, Microsoft et Google s’étaient publiquement écharpées sur la question des délais stricts de publication avec un patch prévu le lendemain de la publication des détails de la faille.

Google n’est pas la seule à avoir un calendrier de publication, bon nombre de sociétés et de « hackers » font de même… Ce qui n’empêche pas les choses de parfois trainer en longueur, parfois à cause d’un flagrant manque de volonté des responsables.

C’est pour signaler une fuite… Allo… Allo ?! Allloooooooo…

Prenons un exemple : un hackeur découvre qu’il peut accéder sans authentification à une API et récupérer des données telles que des noms d’utilisateur et des mots de passe, en clair (non chiffrés, cela ne devrait pas être possible, mais passons…). Dans les données, notamment, des identifiants (en clair donc) d’un compte administrateur de la plateforme. Imaginons que ce soit une plateforme logistique, vous avez maintenant une idée des dégâts possibles.

À ce niveau, ce n’est pas une petite faille, c’est une brèche béante, de quoi rejouer le Titanic en version 2.0. Coup de chance, notre gentil hackeur du jour est un « white hat ». Il ne publie ni ne monétise sa découverte, et contacte plutôt l’entreprise comme il peut : messages LinkedIn aux responsables, messages sur les téléphones de l’entreprise… Pas de réponse, le lendemain rebelote avec en plus un message sur l’e-mail de contact indiqué par l’entreprise sur son site.

Il reste 70% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (22)

votre avatar
Je suis dev, j‘ai fait plein de petits sites. Tous ceux que je monitore ont un security.txt mais ils ne m'ont jamais servis. Une bonne chose, j‘imagine.
votre avatar
C’est à vous : qui a déjà utilisé security.txt ?
Je dois avouer que je ne connaissais pas, donc ça me semble plutôt méconnu puisque je n'ai jamais vu ça passer dans les référentiels sécurité durant mes missions.

Sinon, par rapport aux options de signalement de failles, il existe un entre deux pour l'avoir déjà vu en entreprise : le lanceur d'alerte peut demander une récompense. Je ne met pas ça dans la case du chantage, car pour moi c'est similaire à du "bug bounty" et il n'y a pas eu d'intention malveillante derrière (et, de mémoire, les sommes n'étaient pas exagérées).
votre avatar
Sous-titre approuvé par Albanel.
votre avatar
C'est marrant de voir le security.txt d'Orange et Bouygues pointer vers leurs offres d'emploi :D
votre avatar
Celui d'Infomaniak le fait aussi et pointe aussi vers un programme de Bug Bounty.
votre avatar
Pareil chez Proton, on dirait que c'est courant comme pratique.
Par contre, je vois que la date d'expiration de leur fichier est dépassée. C'est pas sérieux tout ça :non:
votre avatar
Il se passe quoi après l'expiration ?
Rien, d'où l'intérêt de ne pas en mettre ?

Celui de mon boulot a expiré en 2024 :transpi:
Il y a aussi un lien vers la page d'emploi. Faut-il négocier le salaire avant de leur expliquer la faille ? :-D
votre avatar
J'utilise le security.txt mais certains en profitent en envoyant des mails disant qu'une faille de sécurité avait été trouvée sur le site sans en préciser la nature et qu'il faut les recontacter. Après quelques vérifications via des recherches dans Google, c'était des margoulins (même contenu de mail envoyé à plusieurs sites).
Donc méfiez-vous !
votre avatar
L'équipe sécurité a fait ajouter ce fichier statique.
votre avatar
le souci de security.txt, c'est que des idiots l'utilisent pour t'envoyer des """rapports de sécurité""" faits par IA avec des """""failles""""" comme "ftp public accessible sans mot de passe" et autres conneries du genre...
votre avatar
« ftp public accessible sans mot de passe ». C’est pas mal ça :D
C’est dans le même genre que attention, fuite de donnée sur le port 80 quand on fait une demande :o
votre avatar
rigole pas, le dernier mail que j'ai reçu le 12/01 parlait de la faille de sécurité béante du module mod_negotiation d'apache.
à cause de lui, il avait révélé l'existence d'une page /index.php en tapant /index, l'horreur ! :stress:
votre avatar
En soit, ce genre de phishing / spam / faux / whatever est déjà présent même sans puisque les coordonnées de contact sont souvent affichées sur les sites.

Voire quand on est inscrit automatiquement à des newsletters grâce à des scrappings de sites comme linkedin.

Donc ça ne change rien de l'avoir ou pas. Perso je reçois plein de pubs par l'adresse que j'ai implémentée pour le TDM.

C'est même encore plus drôle d'en recevoir sur cette adresse puisqu'elle n'est dispo que via un fichier de policies. La vraie adresse mail dans les mentions légales ne l'est pas !
votre avatar
J'ai fais mettre en place depuis des années (2019 d'après la PR), pour le moment je n'ai que des chercheurs en sécu qui me demande si il existe un programme de bounty ou autre. Remonte des pseudo faille et pas plus.

Donc ça fonctionne, l'email utilisé est systématiquement celui dans le security.txt
votre avatar
Merci pour cet article. On en apprend tous les jours.
votre avatar
Je ne connaissais pas ce security.txt, je vais de ce pas l'implémenter sur tous mes sites à côté de humans.txt, merci 👍🏼
votre avatar
...humans.txt ? Was ist das?
(...Eine fenêtre? :francais: )
votre avatar
Il y a aussi ads.txt 😅
votre avatar
Je viens de trouver, intéressant, merci @Muzikals !
votre avatar
J'ai mis plus d'un mois et demi à trouver comment contacter ameli fr à propos d'un défaut de configuration SSL sur un sous domaine !

Je crois me souvenir que c'est ce fichier qui a fini par me donner le bon contact, et j'ai eu une réponse attentive dans la journée !

En revanche même les adresses mails déclarées chez les Registrars ne fonctionnaient pas ..
votre avatar
Puisqu'il s'agit d'une volonté de communiquer des informations textuelles supplémentaires relatives à un domaine, je m'interroge sur la sur-utilisation systématique de HTTP.

Par ailleurs, des informations de contact sont historiquement présentes dans les informations relatives à un domaine auprès du bureau d'enregistrement, et sont au cœur d'attention depuis des années regardant leur traitement automatisé, notamment parce qu'elles sont disponibles en clair. Cela a d'ailleurs progressivement amené à leur protection d'un accès public…
Il y a 3 types de contact : propriétaire, administrateur & responsable technique. Ne pourraient-ils pas convenir/suffire ?
On repose exactement la même question & recrée exactement les même problèmes via un autre mécanisme… des dizaines d'années plus tard.

Si on tient toujours à inventer créer quelque chose de nouveau, quid de DNS ?
Le champ SOA contient déjà un courriel censé être celui de l'administrateur du domaine.
D'ailleurs, le champ TXT est prévu et largement déjà utilisé pour des informations textuelles supplémentaires, par exemple en remplacement de l'ancien type SPF dédié.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
votre avatar
La personnalisation du DNS n'est pas accessible pour tout le monde. Je pense notamment aux sous-domaines plus ou moins gratuits liés à des hébergements.

Mais le HTTP oblige de son côté à avoir un site.

La solution idéal, c'est une combinaison des deux à mon sens.