Beat the hacker : comment gérer sa veille sécurité

En 2020, 18352 CVE sont sorties : parmi celles-ci, 2708 étaient considérées comme critiques. Après un rapide calcul, cela nous donne une moyenne 7.4 vulnérabilités critiques par jour, en comptant les weekends et jours fériés 🙂
A partir de ce chiffre, on peut établir un fait simple : il est compliqué, voire impossible de faire de la veille sur chaque vulnérabilité. D’autant plus si on ajoute les 7632 vulnérabilités de niveau High qui sont presque aussi dangereuses.

Alors, comment faire pour tout suivre ? Comment gérer la veille d’un SI ? Quelles sont les informations importantes à vérifier ? Et bien c’est autant de portes ouvertes qui seront enfoncées dans cet article, mais qui peut être bon de rappeler.

Faire de la veille, c’est plusieurs choses à prendre en compte :

• Etre plus rapide que le camp adverse, donc avoir l’information au plus tôt,
• Etre capable de comprendre cette information, où tout du moins, le peu d’information qu’on trouve,
• Comprendre le risque réel.

Twitter : mon ami, mon frère

Trouver l’information est le premier défi quand on fait de la veille. Il n’est pas forcément facile de savoir où chercher des informations qui soient fiables, simples, et relativement complètes. Si on rajoute le fait de vouloir avoir l’info rapidement, une division par zéro serait plus facile à faire !

Pourquoi il ne faut jamais diviser par zéro

Alors, où chercher en priorité ? Si vous avez lu le titre du paragraphe, vous saurez que Twitter gagne haut la main. Loin des trendings sans aucun sens, des discussions politiques résumées en 280 caractères ou de la dernière coupe de cheveux d’une actrice quelconque, Twitter est une source de données incroyable pour la veille sécurité. Le problème c’est qu’il faut éviter d’être pollué par des informations inutiles. Il est donc nécessaire de suivre les bons comptes afin d’aller à l’essentiel.

• Un bon point de départ est CVEannounce. Bien que tous les tweets ne soient pas liés à des CVE, toutes les CVE annoncées sur ce compte sont à considérer comme importantes. Elles sont généralement accompagnées d’un article ou d’un bulletin du constructeur.
• Les tweets de The Hacker News peuvent également aider à récupérer certaines informations rapidement, même si certains de leurs articles ne concernent pas les dernières vulnérabilités. Le site reste cependant une référence dans l’actu sécu et les blogposts sont intéressants à lire.
• Le CERT-FR est également une bonne source d’informations -bien qu’ils devraient arrêter la francisation à outrance 🙂 – et donne souvent des liens un peu plus détaillés que le simple contenu du tweet.
• Le Project Zero de google permet également de suivre au jour le jour les découvertes de l’équipe sécu de google sur les vulnérabilités qu’ils remontent, et pas que sur les faiblesses des produits google 🙂 Attention cependant, les liens fournis sont pour le coup très techniques !
• Tous les deuxièmes mardis de chaque mois, Microsoft sort son patch tuesday, qui permet d’installer les mises à jour sécu (évidemment, à faire sans attendre…). Il n’y a pas de compte officiel -à ma connaissance- pour suivre les informations importantes, mais le hashtag #patchtuesday permet de suivre l’actu à ce niveau. Pas toujours incroyable, mais mieux que rien.

En plus de toutes ces infos « officielles », il existe de nombreux comptes qui (re)tweetent des infos. De plus, quand une grosse vulnérabilité sort, tous les twittos sécurité en parlent, et parfois mieux que les infos « officielles », il est donc intéressant de suivre quelques comptes personnels.
Chacun ici fera ici son marché, le mieux étant de donner quelques comptes en vrac afin d’avoir une base permettant de trouver au fur et à mesure d’autres comptes :

• https://twitter.com/Ivanlef0u : hacker français qui s’amusait à reverser windows il y a quelques années. Il écrit peu et fait énormément de retweets de CVE.
  

  Ivanlef0u, le maître du reverse windows

• https://twitter.com/taviso : rockstar de la sécu travaillant au Project Zero, taviso trouve des CVE critiques avant même d’avoir pris son petit déjeuner.

Tavis Ormandy, le seul, l’unique

• https://twitter.com/MalwareTechBlog : le hacker qui a trouvé le killswitch de wannacry.

MalwareTech, le sauveur de la planète

• https://twitter.com/orange_8361 : quand Orange tweete « j’ai trouvé une vulnérabilité », le risque qu’il casse Internet est grand.

Orange, qui fait trembler internet à chaque tweet

• https://twitter.com/gynvael : hacker polonais de génie qui propose (en plus de ses blogposts) Paged Out, un magazine gratuit sur des sujets techniques divers.
• 

  Petit génie du hacking !

  https://twitter.com/HackAndDo : rien ne lui échappe sur la sécurité d’un Active Directory.

  

  Hackndo, aka Pixis, cette rockstar

   

L’idée derrière ce partage de comptes et de s’ouvrir à la communauté sécu Twitter qui est plutôt active (et qui évite les dramas Twitter classiques), et non pas de « simplement » suivre ces comptes comme le saint graal. Ils sont un point de départ permettant de mettre un premier pied dans l’infosec-twitter game, et de fil en aiguille, permettront de trouver d’autres utilisateurs à suivre, en regardant qui est retweeté et les followings afin de choisir les twittos qui pourront correspondre aux besoins de chacun :).

Les rockstars de l’infosec

« Vulnérabilité de l’année » : vraiment ?

Quand une nouvelle vulnérabilité tombe sur twitter, la communauté sécu s’en empare vite et peut des fois être hypée. Il est donc important de comprendre les détails de la faiblesse, et ne pas s’arrêter à un bête tweet qui dit « RCE on <INSERT PRODUCT NAME>, patch ASAP ». Pour ça, il faut regarder un peu la littérature sur le sujet et chercher les détails en croisant les sources.

En général, les informations qu’on récupère rapidement sont un ID de CVE et un lien vers un article. La première chose à faire est donc bien évidemment de lire le ou les article(s) pour comprendre rapidement le problème : type de vulnérabilité, produit affecté, etc. Il est également important de faire un tour sur google en tapant l’ID de la CVE, afin de voir les premiers résultats.

Exemple de tweet utile

Par la suite, un petit tour sur CVEDetails permettra potentiellement d’avoir quelques informations pratiques, notamment le score CVSS, qui permettra d’avoir un premier indicateur fiable. Attention cependant, les CVE peuvent être révisées après publication, ou en statut « candidate », ce qui signifie qu’elle n’est pas encore validée. Dans ce cas, aucune information sur la CVE ne sera disponible avant validation.

Il est aussi très utile d’aller regarder directement sur le site de l’éditeur pour avoir quelques infos officielles. Certains constructeurs sont plus enclins à donner des détails techniques et pratiques sur les faiblesses et les MàJ à faire.
Pour citer les mauvais élèves, Microsoft ne donne presque plus de détails techniques et se contente d’informations très laconiques. On citera aussi VMWare qui n’est pas toujours clair dans ses communiqués.
Les produits Open Source, à l’inverse, auront plus tendance à donner des informations claires.

Enfin, un dernier point important est de savoir s’il existe déjà un Proof Of Concept ou un exploit complet disponible. Pour cela, un rapide tour sur twitter (oui, encore), GitHub et GitLab, avec les recherches « <ID_CVE> », « <ID_CVE> poc » « <ID_CVE> proof of concept », ou encore « <ID_CVE> exploit » permettront de savoir s’il existe déjà des scripts disponibles.

Recherche de PoC sur GitHub

En quelques minutes de recherche, on trouve rapidement plusieurs articles et communiqués qui résument plutôt correctement le risque. Avec un peu de chance, il est même possible de trouver quelques articles techniques qui détaillent en profondeur la vulnérabilité et les impacts réels.
Pour les vulnérabilités nommées, celles qui sont soit très importantes, soit là pour faire le buzz, un site dédié est en général rapidement accessible avec une FAQ permettant de cerner les détails pratiques de l’impact.

Nous voilà donc armés de plusieurs informations : la CVE-ID, sa CVSS, et quelques infos pratiques. Il faut maintenant définir le risque réel 🙂

Le bouton « Update »

On ne va pas rentrer ici dans le détail des procédures d’upgrade : ce type de procédure est propre à chaque entreprise, et il faudrait un article complet pour expliquer les cas d’usage.
Cependant, on va jeter un œil rapide sur la qualification de la vulnérabilité. Pour ça, il faut valider non pas les risques techniques, mais les risques réalistes, liés à l’entreprise.
Imaginons une vulnérabilité critique : une RCE pré-authentification sur vCenter. C’est une vulnérabilité très dangereuse car un attaquant pourrait accéder à toutes les VMs disponibles, mais le temps avant patch est différent si le vCenter est disponible sur internet ou uniquement dans un sous réseau accessible par les seuls administrateurs de la solution*.
Il est donc important de prendre en compte le contexte avant toute décision, notamment certains points :

• La fonctionnalité vulnérable est-elle sur présente sur le parc : certaines vulnérabilités sont sur des plugins ou configurations spécifiques, qui peuvent ne pas être en place dans l’environnement. Ici, il peut être intéressant d’impliquer les administrateurs des solutions en question.
• Quelle est l’exposition réelle des actifs concernés : internet, réseau local utilisateur, réseau local restreint, salle blanche ?
• Quel est le score CVSS associé à la vulnérabilité : un score CVSS n’est que le résultat d’un calcul, et doit être étudié dans le détail, il est donc important de ne pas regarder le seul score, mais les différents paramètres (complexité, authentification nécessaire, etc.).
• Quel est le risque qu’un exploit soit disponible rapidement sur internet : un buffer overflow est souvent plus complexe à exploiter qu’une injection SQL, un exploit public sera donc plus ou moins rapidement disponible.

Comment sont calculés certains scores CVSS

En fonction des réponses apportées à ces questions, une décision s’impose concernant la principale question « dois-je mettre à jour maintenant ou puis je attendre un peu ? ».
On notera qu’aucune place n’est laissée ici à un éventuel « j’accepte le risque ». Les mises à jour de sécurité DOIVENT être faites, il est simplement imaginable de ne pas les faire le jour de la sortie du patch, mais d’attendre le lendemain.

Et la suite ?

Beaucoup de portes ouvertes ont -comme prévu- été enfoncées dans cet article, mais quelques rappels ne sont jamais une mauvaise chose. Quelques petits points de dernière minute cependant, doivent être énoncés :

• Il est important que cette veille sécurité soit faite en permanence, il faut rester informé en permanence et ne pas se reposer sur ses lauriers
• Un SI change, donc la veille également. Si une nouvelle solution est intégrée dans le SI, il est important de la prendre en compte
• Twitter est un réseau qui évolue en permanence. De nouveaux comptes peuvent être intéressantes à suivre, d’autres peuvent s’avérer finalement peu utiles à suivre, etc. Il est donc utile de fréquemment rechercher de nouvelles sources fiables, et de supprimer celles qui font du bruit inutile.

Vous avez maintenant toutes les armes pour commencer une veille sécu et renforcer la sécurité globale de votre SI. Là où la veille sécu passe, les hackers trépassent !

Corto

* Attention, cela ne signifie pas qu’on peut se passer de mise à jour dans ce cas, simplement qu’elle n’est pas à faire dans la seconde même.