FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Comment faciliter la remontée de vulnérabilités ?

31 mai 2021 à 10:30

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 : 

Enregistrement WHOIS du domaine ssi.gouv.fr
Enregistrement WHOIS du domaine ssi.gouv.fr

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 :

Indication de l'organisation propriétaire du domaine whatsapp.com
Indication de l'organisation propriétaire du domaine whatsapp.net

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 :

Fichier security.txt rempli
Fichier security.txt rempli


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 :
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000033206854/
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000033206854/

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

The post Comment faciliter la remontée de vulnérabilités ? first appeared on IT-Connect.

Guide ANSSI : focus sur les mécanismes de sécurité des navigateurs

3 mai 2021 à 07:59

L'ANSSI a publié le 28 Avril 2021 un nouveau guide portant sur la sécurité des sites web, intitulé Recommandations pour la mise en œuvre d'un site web: maîtriser les standards de sécurité côté navigateur.

Les recommandations de ce guide concernent la sécurité des contenus présentés par un navigateur web aux utilisateurs. Il existe de nombreux standards du Web qui concernent des mécanismes de sécurité activables par les serveurs web au niveau des navigateurs. En intégrant différents en-têtes (headers) au niveau de leur réponse, les serveurs vont en effet pouvoir demander aux navigateurs de leurs utilisateurs d'activer des mécanismes de protection divers afin de rendre la navigation plus sûre. En faisant le tour de ces différents mécanismes, un développeur ou un administrateur système peut donc protéger ses utilisateurs de certaines attaques, autrement qu'en intervenant directement sur le code source de l'application utilisée.

Il faut tout de même garder en tête que ces mécanismes de sécurité côté navigateur sont là pour limiter l'impact ou les possibilités d'exploitation d'une vulnérabilité, mais constituent rarement un correctif efficace à eux seuls. Ils doivent donc venir renforcer la sécurité d'une application web en utilisant tous les outils possibles au niveau du navigateur de l'utilisateur, et non se substituer à la sécurité de l'application web elle-même.

Dans ce guide est notamment rappelée la contrainte de Same Origin Policy (SOP) et son mécanisme de relâchement Cross Origin Resource Sharing (CORS). Le guide aborde ensuite certaines pratiques de protection contre le Cross Site Scripting (XSS) telles que SubResource Integrity (SRI), puis la communication inter-contextes en général, en détaillant notamment les standards Content Security Policy (CSP), Referrer-Policy, et les pratiques relatives au cloisonnement telles que le choix et le paramétrage des moyens de stockage côté client (ex. : cookies, Web Storage) et des moyens d’isolation des ressources actives (ex. : iframes, Web Workers).

Nous avons d'ailleurs publié très récemment sur IT-Connect un article sur le mécanisme du SRI : Contrôle d’intégrité des ressources web externes, mentionné dans ce guide.

Un dehors des mesures purement techniques, le chapitre 2. Menaces et types d'attaques est intéressant pour les gestionnaires de site web qui souhaitent mieux comprendre l'intérêt de s'occuper de la sécurité de leurs applications. Différents exemples de menaces et objectifs des attaquants y sont donnés (par exemple le vol de données ou l'interruption de service) ainsi que des exemples d'attaques concrètes (XSS, CSRF, SQLi, etc.), utiles pour mieux comprendre la suite du guide. Le chapitre 3. Rappel des règles d'hygiène  fait lui un rapide survol des principes de sécurité qui doivent être intégrés au niveau de l'application web elle-même.

Ce guide contient 63 recommandations qui couvrent un ensemble assez large de mesures, y sont également fournis des exemples de code HTML ou JavaScript permettant de mieux comprendre la mise en place de certaines mesures.

En complément de ce guide, je vous conseille d'étudier l'OWASP Testing Guide, qui vient lui détailler les bonnes pratiques de développement et d'audit d'une application web : OWASP Web Security Testing Guide

Si vous souhaitez consulter ce nouveau guide de l'ANSSI, c'est part ici : Recommandations pour la mise en œuvre d'un site web: maîtriser les standards de sécurité côté navigateur

Bonne lecture 🙂

The post Guide ANSSI : focus sur les mécanismes de sécurité des navigateurs first appeared on IT-Connect.
❌