Close
  • Français
  • English

13/09/2013La gestion des failles de sécurité : la situation est loin d’être idéale [Par Eric Freyssinet, Gendarmerie nationale]

Dans un édito du mois de juin[1], Nicolas Ruff faisait le point sur les « 0day » – les vulnérabilités non encore connues des éditeurs et donc non encore corrigées. Et il a parfaitement raison de souligner qu’il ne faut pas s’attarder que sur ce type de failles de sécurité, mais bien s’intéresser à l’ensemble du problème, des failles anciennes étant souvent tout aussi pertinentes pour un ensemble de raisons assez complexe (par exemple des parcs entiers d’équipements qui ne seront jamais mis à jour), et avoir un impact concret sur la sécurité de nos systèmes d’information.

Les failles de sécurité et leur référencement

Les vulnérabilités ou failles de sécurité dans un logiciel, une composante d’un système d’exploitation ou parfois même dans le micrologiciel – ou firmware – d’un équipement sont une erreur de conception qui peut être exploitée pour prendre le contrôle sur un système ou réaliser des opérations hors du contrôle de son utilisateur. Les conséquences vont de l’événement accidentel – le système devient défaillant dans certaines circonstances – à une attaque volontaire, par exemple pour réaliser l’installation d’un virus informatique.

Elles sont normalement référencées par les organisations qui développent les logiciels, mais aussi de façon commune par la communauté de la sécurité. Il existe plusieurs référentiels communs mais celui qui s’est imposé comme le standard le plus utilisé est celui maintenu par l’association américaine MITRE : le référentiel CVE[2] pour Common vulnerabilities and exposures[3]. Chaque faille de sécurité est référencée par l’année de sa découverte et un numéro d’ordre (comme CVE-1999-0001 pour la première d’entre elles). Elles passent par différentes étapes de l’attribution d’un numéro – par MITRE ou par des organisations intermédiaires, les CNA[4] – à la publication de références plus complètes ou encore au regroupement lorsque plusieurs références correspondent en réalité au même problème (les autres références pointent alors sur une référence principale).

Pour évoquer un autre exemple, le CERTA de l’Agence nationale de la sécurité des systèmes d’information diffuse[5] des alertes et des avis sur des vulnérabilités notables par rapport à son périmètre spécifique de veille. Le travail du CERTA, comme celui des constructeurs ou d’autres intervenants de la sécurité est nécessaire pour analyser le niveau de sensibilité de la menace référencée par CVE ou encore proposer des informations permettant d’y remédier. Il faut donc voir CVE comme une référence commune, mais certainement pas comme la seule source d’information.

Enfin, tant qu’elles ne sont pas connues publiquement, elles ne font pas forcément l’objet d’un référencement public. Ou alors seule une référence interne à un éditeur de solutions de sécurité ou l’éditeur d’un produit seront connues, tant que les détails de la vulnérabilité n’auront pas été révélés ou un numéro CVE demandé.

La découverte et la notification des failles de sécurité

Plusieurs acteurs interviennent dans la découverte et la révélation des failles de sécurité. Ce sont aussi plusieurs « idéologies » qui cohabitent : des tenants de la révélation totale aux défenseurs de la divulgation responsable.

La découverte d’une faille peut-être le fait de l’éditeur, d’un simple utilisateur, de chercheurs ou de sociétés spécialisées en sécurité ou encore de personnes dont l’objectif est d’exploiter ces failles à des fins malveillantes (soit pour les revendre, soit pour les utiliser directement dans la commission d’infractions).

Parfois cette faille sera découverte successivement par plusieurs personnes avant qu’elle ne soit publiquement connue, par exemple suite à son exploitation dans des actions malveillantes ou alors suite à la publication d’informations partielles sur l’existence de cette faille. Enfin, suivant la personne qui découvre la faille et le chemin que va prendre l’information, sa résolution sera plus ou moins efficace sans qu’un véritable consensus existe encore sur le chemin idéal.

Pourtant, il semblerait plutôt rationnel que l’éditeur soit prévenu suffisamment en amont pour qu’il soit en mesure de corriger la faille avant qu’elle soit publique, qu’il la corrige aussitôt et que, très vite, ses utilisateurs ou ses clients installent tout aussi rapidement la mise à jour. Ce parcours dit « responsable » se heurte ainsi à des écueils à chacune de ses étapes : on gagnerait beaucoup à ce que l’ensemble des acteurs travaillent à les consolider (en particulier la coordination entre le découvreur et l’éditeur pour la mise en place rapide d’une solution au profit des utilisateurs, avant de rendre publique la vulnérabilité).

Plusieurs dispositifs concrets contribuent à la divulgation responsable : la possibilité d’obtenir auprès d’un CNA un numéro de vulnérabilité CVE sans qu’il soit immédiatement publié ou encore les programmes de récompenses financières[6] mis en place par les grands éditeurs, ainsi que certains programmes qui organisent la coordination de la divulgation responsable avec les éditeurs[7].

Enfin, la mise à disposition des mises à jour pour les utilisateurs finaux rencontre de nombreux problèmes :

[list style=’check’]
[list_item]certains produits ne sont plus suivis (Microsoft a confirmé récemment la fin de vie de Windows XP encore très utilisé pour le mois d’avril 2014),[/list_item]

[list_item]les mises à jour ne sont pas automatiques ou complexes à mettre en œuvre (et parfois ce sont les outils de mise à jour qui sont détournés pour réaliser des infections virales),[/list_item]

[list_item]le nombre d’intermédiaires est trop important, comme dans l’univers des téléphones mobiles – Android en particulier – où c’est parfois le constructeur, puis l’opérateur lui-même qui doivent déployer la mise à jour personnalisée[8].[/list_item]

[/list]

L’impact concret des vulnérabilités sur la sécurité des systèmes d’information

On l’aura compris, les vulnérabilités sont exploitées par des attaquants pour détourner des informations, prendre le contrôle de systèmes d’information ou encore les rendre inopérants. Dans un article de septembre 2012[9], j’expliquais comment on attrape de nos jours un virus informatique : le plus souvent en ouvrant une pièce jointe dans un courrier électronique ou en visitant un site Web et parfois par une attaque directe de son ordinateur par un ver qui se propage par ses propres moyens. Ces logiciels malveillants exploitent tout autant la maladresse de l’utilisateur que la faible sécurité de son système d’exploitation ou des logiciels installés : ces fameuses failles de sécurité.

Si on étudie le scénario des plateformes d’exploit – des kits sous formes de serveur Web permettant d’attaquer l’ordinateur d’une victime qui y a été redirigée à son insu – on observe à la fois l’utilisation de failles anciennes toujours très efficaces et des failles récentes (les fameuses 0-day – ou presque) qui sont très rapidement incluses dans les kits d’exploit les plus « compétitifs » sur les marchés cybercriminels.

Ainsi, si l’on regarde la table des vulnérabilités disponibles sur les différents kits d’exploitation tenue à jour sur le blog Contagio[10], on observe que certaines vulnérabilités très anciennes sont très présentes :

Figure 1: Certaines vulnérabilités anciennes sont très présentes dans les kits d'exploitation (source : Contagio)

Figure 1: Certaines vulnérabilités anciennes sont très présentes dans les kits d’exploitation (source : Contagio)

Et lorsque certains chercheurs arrivent à obtenir des informations statistiques sur l’efficacité de ces vulnérabilités, elles se montrent parfois très pertinentes[11] (ce qui tendrait à confirmer que les applications ou systèmes d’exploitation anciens sont de toutes façons tenus à jour de façon moins régulière :

Figure 2: Dans ce tableau de statistiques du kit d'exploit Phoenix on voit que des logiciels et systèmes d'exploitation moins récents sont frappés de façon très efficace

Figure 2: Dans ce tableau de statistiques du kit d’exploit Phoenix on voit que des logiciels et systèmes d’exploitation moins récents sont frappés de façon très efficace

Lorsque des vulnérabilités plus récentes sont déployées dans des plateformes d’exploit, elles peuvent se révéler particulièrement efficaces, notamment lorsqu’elles concernent des applications courantes comme Flash, Acrobat ou Java. Ainsi, dans plusieurs articles[12] j’ai démontré que l’enchaînement de la révélation de failles nouvelles sur ce type d’applications et de leur prise en compte trop peu rapide par les éditeurs est mis à profit par les gestionnaires de plateformes d’exploits malveillantes pour mieux vendre leurs produits. Plus récemment vers le 14 août 2013, la faille CVE-2013-2471 et d’autres tout aussi nouvelles ont rapidement intégré les plateformes d’exploit[13], alors qu’elles viennent à peine d’être corrigées, et donc sont loin d’être empêchées chez les utilisateurs.

La prise en compte des mises à jour dans les réseaux des organisations

Partant de ce constat, j’ai entrepris un modeste sondage auprès des RSSI et DSI, pour mieux connaître les difficultés qu’ils rencontrent éventuellement dans la gestion de ces mises à jour. Avec 112 réponses reçues à ce jour[14], les premiers résultats sont assez intéressants (attention, ce sont des résultats partiels, qui devront être affinés au regard de la répartition des répondants dans les différentes catégories et secteurs d’activité, et de nouvelles réponses éventuelles). Ainsi, si 82 % des répondants ont une politique de mise à jour, beaucoup ne gèrent pas de façon automatisée les mises à jour des navigateurs Web (24%) ou des extensions de navigateurs (36%). Dans énormément de cas (76%), si une passerelle d’accès à Internet est mise en place, elle ne contrôle pas que le navigateur Web utilisé est un logiciel autorisé et à jour.

Pourtant, comme nous venons de le voir, il est indispensable aujourd’hui de gérer un parc informatique qui soit parfaitement à jour pour le protéger du mieux possible contre les attaques qui utilisent de plus en plus des vecteurs particulièrement difficiles à filtrer parce que nécessaires au fonctionnement quotidien des organisations (le Web ou le courrier électronique). Les difficultés sont évidentes – en termes de moyens, mais aussi très souvent en termes de contraintes imposées par les éditeurs des différents progiciels qui contraignent les organisations à vivre avec des versions obsolètes des navigateurs ou de leurs extensions.

Conclusion

Nous avons collectivement de gros progrès à faire dans la gestion des vulnérabilités, qu’il s’agisse des professionnels de la sécurité qui doivent trouver des meilleures solutions pour qu’elles soient plus efficacement prises en compte et corrigées, des gestionnaires de parcs informatiques et des utilisateurs finaux qui doivent tenir leurs systèmes à jour, mais aussi les éditeurs de progiciels qui doivent être plus réactifs pour prendre en compte la nécessité qu’ont leurs clients de se sécuriser rapidement.

 


[3]Ils distinguent vulnérabilité et exposition, cette dernière permettant uniquement de compromettre l’intégrité du système – par exemple d’accéder à des données confidentielles – sans toutefois pouvoir autoriser la prise de contrôle.

[4]CNA, CVE numbering authorities, http://cve.mitre.org/cve/cna.html

[6]Ou « bug bounty programmes », comme celui de Facebook (https://www.facebook.com/whitehat), Google (http://www.google.com/about/appsecurity/reward-program/) ou encore Microsoft (http://www.microsoft.com/security/msrc/report/bountyprograms.aspx ) une liste plus complète était déjà mentionnée par Nicolas Ruff : https://bugcrowd.com/list-of-bug-bounty-programs/ .

[7]Il s’agit de programmes organisés par des sociétés spécialisées en sécurité comme Zero Day Initiative (http://www.zerodayinitiative.com/) ou Exodus Intelligence (https://www.exodusintel.com/eip/ ), qui partagent ces informations avec les éditeurs pour que les défauts soient corrigés, mais aussi avec leurs clients pour mieux garantir leur sécurité.

[11]Exemple provenant du site de Malware Intelligence : http://malwareint.blogspot.fr/2011/10/inside-phoenix-exploits-kit-28-mini.html