Comment faciliter la remontée de vulnérabilités ?
Sommaire
I. Présentation
Dans le dernier bulletin d'actualité du CERT-FR, l'ANSSI fait un retour d'expérience sur les campagnes de signalement de vulnérabilités qu'elle mène auprès d'organisations privées ou publiques en France.
En effet, depuis qu'un texte de loi a été publié en 2018, l'ANSSI assure un service de veille active des vulnérabilités critiques. Ainsi, l'Agence effectue des scans automatisés envers des organisations françaises de tout type et peut également servir de relais entre un chercheur indépendant ayant trouvé une vulnérabilité et une organisation.
Par exemple, lors de la parution d'une nouvelle vulnérabilité critique, telle que la CVE-2019-19781 ayant impactées les services Citrix en 2019, l'ANSSI a effectué des scans réseau sur l'Internet français. Ceux-ci sont lancés sur un ensemble d'adresse IP relatives à des organisations françaises et l'ANSSI peut alerter les propriétaires des services vulnérables relevés. Pour cette vulnérabilité spécifique, par exemple, l'ANSSI fournis les chiffres suivants :
Le 3 janvier 2020, l’ANSSI avait pu identifier 870 adresses IP vulnérables à la CVE-2019-19781 affectant certains produits Citrix. En janvier 2021, 134 adresses IP étaient encore vulnérables à la CVE-2019-19781. En 2020, l’ANSSI a pu constater 15 incidents de sécurité affectant des entités publiques et privées importantes dont l’origine était attribuée à la vulnérabilité CVE-2019-19781.
II. Faciliter le contact avec l'ANSSI/les chercheurs
Il arrive cependant à l'ANSSI ou aux chercheurs indépendants que le contact avec le propriétaire d'un actif vulnérable soit difficile à établir. Ainsi, l'ANSSI dans son RETEX fournis quelques conseils afin d'être facilement joignable :
A. Informations WHOIS
Les informations d’enregistrement des noms de domaine doivent être maintenues à jour auprès du registraire.
L'une des première source d'information est en effet la base WHOIS, qui contient l'identité et les contacts des propriétaires d'un nom de domaine. La base WHOIS est consultable via la commande Linux WHOIS ou via de nombreux sites web (https://viewdns.info/whois/). Aujourd'hui, les hébergeurs proposent par défaut l'anonymisation des informations présentées dans l'enregistrement WHOIS, cela à des fins de protection de la vie privée. Si l'option est intéressante pour les personnes physiques, elle ne doit pas être utilisée par les entreprises. Dans d'autres cas, les informations présentes dans cette base sont obsolètes, par exemple : la personne ayant souscrit au nom de domaine n'est plus dans l'entreprise.
Voici en exemple le contenu d'un enregistrement WHOIS correctement rempli :
Il est donc conseillé de faire régulièrement (disons une fois par an) le tour de l'ensemble des informations WHOIS des noms de domaine appartenant à l'entreprise afin d'être certains que ces informations sont toujours valides.
B. Informations des certificats SSL
Les certificats x509 utilisés doivent mentionner les bonnes informations concernant le propriétaire (il est déconseillé d’utiliser des certificats auto-signés tout comme les certificats proposés par défaut lors de l’installation du logiciel ou du matériel).
Les informations contenues dans les certificats publics sont également utilisables pour identifier le propriétaire d'un actif. Voici un exemple avec le site whatsapp.net, dont le propriétaire est l'entreprise Facebook :
Là encore, ces informations peuvent s'avérer fausses ou obsolètes. Pour une entreprise, il est conseillé de mettre des informations à jour et correspondant à la réalité, rien ne sert de mettre une fausse organisation ou adresse, etc. Un attaquant saura multiplier les sources pour trouver des informations valides.
C. Consultation des communications
Les adresses de contact doivent être consultées régulièrement par leurs propriétaires.
De toute évidence, ces adresses mails seront publiques et donc utilisées pour du spam ou des annonces commerciales. Néanmoins, il reste important de ne pas indiquer des adresses mails "poubelles" car leur publication garde un intérêt certains : être averti et contacté facilement en cas de découverte d'une vulnérabilité (entre autre).
D. Choix des contacts indiqués
Le destinataire doit être à même de juger de l’importance de la communication.
Autrement dit, l'adresse mail, postale ou le numéro du contact indiqué dans ces différentes sources doit avoir compétence à évaluer une alerte de sécurité. Si vous indiquez l'adresse mail du PDG de la boite, il n'aura peut être pas le temps ou le savoir nécessaire pour apprécier une telle alerte. Il est préférable d'indiquer le contact du/de la DSI, RSSI ou même une mailing-list regroupant plusieurs personnes compétentes, le SOC/CERT si vous en avez un, reste la meilleur option.
Enfin, je rajoute à ces différentes propositions l'utilisation du fichier /.well-known/security.txt, il s'agit d'un standard proposé par différents chercheurs en sécurité permettant de trouver facilement les bons contacts pour un signalement de vulnérabilité. Son fonctionnement est à l'image du fichier robots.txt pour les crawlers automatisés (Bing, Google, etc.). Un générateur automatique du fichier est même proposé : https://securitytxt.org/
Voici un exemple :
Enfin, l'ANSSI dans son RETEX nous parle également de la prise en compte du signalement, le fameux "on fait quoi maintenant ?". C'est là que les procédures internes de l'entreprise doivent être utilisés, notamment concernant la gestion des alertes et des incidents, ce qui implique qu'elles soit définies à l'avance et non pas improvisées lorsqu'un signalement arrive :). Dans le cas où vous passez totalement ou partiellement par un infogérant, il faut espérer que des clauses particulières concernant la sécurité soient présentes dans votre contrat. Si ce n'est pas le cas, je vous oriente vers ce guide : Maîtriser les risques de l'infogérance
III. Signaler une vulnérabilité
Si vous êtes un chercheur en sécurité ayant découvert une vulnérabilité, je vous conseille d'essayer de faire correspondre votre situation à l'un de ces deux cas de figure :
- Si votre cible possède un fichier security.txt, une page de type hall of fame (https://unite.un.org/content/hall-fame) ou même un programme de bug bounty, utilisez ces moyens pour remonter des vulnérabilités en vous assurant de respecter les conditions indiquées (le fameux scope) et montrez dans vos interactions comme dans vos tests que vos intentions sont bienveillantes (pas besoin de dumper la base utilisateur, montrer que c'est possible suffit).
- Si ce n'est pas le cas, et que vous avez affaire à une entité française, passez par l'ANSSI, qui peut jouer le rôle d'intermédiaire tout en protégeant votre identité. Les modalités de signalement auprès de l'ANSSI sont décrites sur cette page : Alertes aux vulnérabilités et failles de sécurité . Dans ce cas précis, vous êtes protégés par la loi :
Attention, l'ANSSI ne sera surement intéressée que par des vulnérabilités conséquentes sur des entités importantes, pas la peine de leur signaler une XSS sur un blog de jardinage 🙂
Si vous ne rentrez dans aucun de ces cas de figure, mon avis est généralement de ne pas remonter de vulnérabilités, notamment lorsque l'on s'attaque à des environnement de production, en opposition à des applications que l'on peut installer en local comme un Owncloud, un Firefox, ou autre. Il m'est arrivé de croiser des chercheurs pour lesquels la poursuite pénale n'était pas loin, aussi louables étaient leurs intentions, certaines entreprises ont une philosophie encore très vintage. A vos risques et périls donc. 😉
Dernier bulletin du CERT-FR : Retour d’expérience sur les campagnes de signalement de vulnérabilités
