Pourquoi les CVE devraient être prioritaires en matière de résolution
J’ai déjà expliqué pourquoi la sécurité des applications est une pile . Je le répète car nous avons parfois besoin de nous rappeler que les applications modernes ne sont jamais déployées seules. Ils ne le sont pas.
Chaque application moderne est déployée sur une sorte de plate-forme. Cela pourrait être Apache ou IIS. Il peut s'agir d'un serveur d'applications Oracle ou IBM. Cela pourrait être node.js avec Express ou Python avec toutes les bibliothèques nécessaires. Tout comme nous nous appuyons sur les systèmes d’exploitation et la virtualisation/les conteneurs pour assurer la mise en réseau, les applications s’appuient sur des plateformes et des bibliothèques pour gérer des éléments tels que TCP et HTTP.
De plus, les développeurs utilisent des bibliothèques pour les fonctionnalités. Réinventer la roue est une perte de temps, et les développeurs se tournent donc vers l'open source et d'autres voies pour les analyseurs JSON, la gestion de fichiers, l'authentification et l'autorisation et le support de bases de données. Disposition et gestion de l'interface utilisateur également. Aujourd’hui, la plupart des développeurs se tournent vers les bibliothèques pour fournir ces fonctions, afin de pouvoir se concentrer sur ce qui ajoute de la valeur : la logique métier et les services.
Une inspection des applications réalisée en 2017 par Contrast Labs a révélé que « les bibliothèques de logiciels tiers représentent 79 % du code d'une application ». Pour Java, la moyenne était de 107 bibliothèques différentes. Pour .NET ? 19. Pour l'anecdote, j'utilise au moins cinq bibliothèques différentes avec node.js.
Mais ce qui devrait vous surprendre, c’est ce qu’ils ont découvert sur l’état de sécurité par rapport à cette scission.
Même si 79 % d’une application est composée de bibliothèques, elles ne représentent que 2 % des vulnérabilités connues (c’est-à-dire des CVE). Le code personnalisé représente à peu près le reste, avec 97,3 % des vulnérabilités.
Ce risque disproportionné en matière de sécurité des approvisionnements entre les bibliothèques et les vulnérabilités pourrait expliquer pourquoi une enquête SANS a révélé que « même si 23 % des répondants s'appuient fortement sur des produits et services logiciels tiers (COTS, services basés sur le cloud et logiciels open source), ils ne prennent pas suffisamment de responsabilités pour garantir la sécurité des solutions tierces. Seuls 23 % des programmes de sécurité incluent des COTS.
Hmm. Eh bien, cela pourrait expliquer le faible taux de réponse à la résolution des vulnérabilités tel que rapporté par Kenna Security. En 2015, Kenna Security a publié un rapport sur une étude menée sur un échantillon de 50 000 organisations présentant 250 millions de vulnérabilités et plus d'un milliard (MILLIARDS) d'événements de violation et a découvert deux points très intéressants concernant la correction des vulnérabilités :
- En moyenne, il faut aux entreprises 100 à 120 jours pour corriger les vulnérabilités.
- Dans un délai de 40 à 60 jours, la probabilité qu’un CVE soit exploité atteint plus de 90 %.
- L’écart entre le moment où une vulnérabilité est susceptible d’être exploitée et celui où elle est fermée est d’environ 60 jours.
En d’autres termes, la plupart des organisations ne traitent pas ces 2 % de vulnérabilités assez rapidement pour éviter d’être compromises par l’une d’entre elles. Peut-être parce qu’ils sont situés dans des bibliothèques qui ne sont pas incluses dans le programme de sécurité de l’organisation.
Quelle que soit la raison , cela doit être la priorité numéro un. Et laissez-moi vous expliquer pourquoi.
À l’époque, les attaquants devaient :
- En savoir plus sur la vulnérabilité
- Rechercher un site de victime
- Tenter d'exécuter un exploit
C'était manuel et cela prenait du temps. À moins que vous ne soyez une cible très médiatisée, personne n’allait perdre son temps avec vous.
Aujourd’hui, les vulnérabilités sont partagées à la vitesse d’Internet (qui est la vitesse de la lumière, au cas où vous vous poseriez la question). (La dorsale optique, vous savez) et la découverte des cibles sont automatisées. Les scripts et les robots sont capables de rechercher et de marquer les sites compromis beaucoup plus rapidement (et à moindre coût) que les humains. C'est de la même manière que des botnets de la taille de l'Étoile de la Mort sont construits à partir d'appareils IoT non sécurisés . L’automatisation n’améliore pas seulement la productivité des bons.
Il s’agit d’attaques non ciblées . Des attaques d’opportunité, si vous voulez, qui ne sont pas planifiées. Vous ne disposez peut-être pas de données précieuses ou intéressantes, mais vous disposez de ressources. Et les ressources peuvent être utilisées pour trouver d’autres victimes et perpétrer d’autres attaques et, eh bien, vous savez comment cela se termine.
Les attaques non ciblées sont particulièrement courantes après la publication d’un CVE. C'est parce que votre code personnalisé est unique ; même s'il contient de nombreuses vulnérabilités, il faut du temps et des efforts pour les trouver. Exploiter un CVE qui existe dans une bibliothèque ou une plateforme couramment utilisée est un jeu d'enfant. L’opportunité est trop belle pour la laisser passer, car le retour sur investissement est très, très, très élevé. En 2015, le rapport DBIR de Verizon notait que « 70 % des attaques exploitaient des vulnérabilités connues pour lesquelles des correctifs étaient disponibles ».
C'est pourquoi la mise à jour des correctifs, que ce soit par le biais de mises à jour logicielles réelles ou virtuellement via l'utilisation d'un pare-feu d'application Web , doit être la priorité numéro un lors de la divulgation d'un nouveau CVE dans l'une des 79 % des bibliothèques qui composent votre application. Si ce CVE est lié à la plateforme (pensez à Apache Killer) , il vaut mieux que ce soit la priorité « Drop Everything », car l’empreinte digitale des serveurs Web et d’applications est encore plus simple que la recherche de vulnérabilités dans les bibliothèques.
La vérité est que si vous n’êtes pas suffisamment connu pour être ciblé, vous êtes quand même en danger. Vous utilisez probablement la même pile que des organisations de premier plan, ce qui signifie que des attaques non ciblées sont susceptibles de vous trouver. Si vous pensez qu'ils ne le feront pas, sachez que je peux accéder à la base de données CVE et trouver tous les CVE publiés liés à node.js. Ensuite, je me rends sur builtwith.com et recherche des sites Web créés avec Express, un framework node.js. Non seulement je découvre que le site connaît « 230 116 sites Web en direct utilisant Express et 263 872 sites supplémentaires qui ont utilisé Express historiquement », mais il fournit également un lien pratique pour les télécharger.
Ce n’est pas vraiment le shodan.io des applications Web, mais ce n’est pas beaucoup plus difficile de mettre deux et deux ensemble et de trouver un exploit réussi.
Ne faites donc pas l’erreur de penser que parce que vous n’êtes pas « assez grand », un CVE dans une bibliothèque ou une plateforme Web peut être ignoré.
C’est ainsi que les gens finissent par devenir tendance sur Twitter. Et pas dans le bon sens du terme.
Soyez prudent. Donnez la priorité aux réponses aux CVE qui affectent l’ensemble de votre pile d’applications. De haut en bas.