DevSecOps : les anciens bugs de sécurité continuent d'apporter de nouvelles astuces

Publié à l'origine sur DevOps.com.

Dans le domaine de la cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont rivés sur l'horizon, à la recherche de la prochaine faille de sécurité (ainsi que des outils de conception, des techniques et des tactiques appropriés pour y mettre fin). Cependant, cette approche tournée vers l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, nous rendant ainsi aveugles aux dangers profondément ancrés qui existent partout et que les attaquants ne sont que trop heureux d'exploiter.

Je compare souvent la cybersécurité moderne à une armure en kevlar. Les propriétés apparemment éthérées du kevlar peuvent bloquer les obus à haute vitesse et toutes sortes d'armes modernes et puissantes. Cela peut même donner à celui qui le porte un sentiment d'invincible. Cependant, un système d'armes à arc et à flèche relativement ancien, conçu pour la première fois vers 1000 ans avant notre ère, peut souvent pénétrer cette protection. Un couteau bien aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le kevlar aussi facilement que s'il s'agissait d'un sweat-shirt en coton. Et puis il y a le petit problème que le Kevlar n'est pas capable de protéger chaque millimètre du corps humain. Si un attaquant parvient à trouver une brèche pour infliger un coup dur, il appréciera « un peu les petites zones exploitables des logiciels ».

Dans le domaine de la cybersécurité, de nombreuses organisations sont également vulnérables aux failles de leurs systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne à peu près droit à une montre en or et à une pension de retraite. Mais si vous pensez que les défauts de ces systèmes âgés sont inoffensifs, vous aurez probablement un écran bleu ou deux de la mort dans le futur.

Une vulnérabilité pour un vétéran

L'une des bibliothèques JavaScript les plus anciennes et les plus utilisées est jQuery, une ressource open source qui facilite tout, de la gestion des événements à la traversée et à la manipulation des arbres DOM, en passant par la génération d'animations. C'est un véritable bourreau de travail qui est utilisé depuis de nombreuses années. Les gens supposent que, étant donné que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et toutes les vulnérabilités supprimées.

Malheureusement, ce n'est pas le cas. Par défaut, la plupart des applications qui s'appuient sur jQuery utilisent les instructions de la bibliothèque interne pour l'authentification. Par exemple, avec les serveurs Apache, cela signifie qu'il faut vérifier les fichiers .htaccess. Peu de développeurs concevant des programmes utilisant Apache ont probablement pensé à vérifier que les mises à jour du serveur Apache incluaient .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui est à la base de la sécurité depuis des années ?

Aussi étrange que cela puisse paraître, c'est exactement ce qu'Apache a fait dans la version 2.3.9. Apparemment, le fait de devoir vérifier les fichiers de configuration .htaccess à chaque fois qu'un programme devait s'exécuter ralentissait trop les choses. Sa suppression a amélioré les performances globales d'Apache, mais a également créé une vulnérabilité que la plupart des gens ignoraient. Si les développeurs ne prenaient pas la peine de vérifier si leurs applications pouvaient toujours accéder aux fichiers .htaccess, la plupart des demandes seraient simplement acceptées sans examen minutieux.

Récemment, des experts ont découvert cette faille et ont noté que son utilisation permettrait à des utilisateurs non autorisés de télécharger et d'exécuter des shells ou presque n'importe quel type de code sur des systèmes prétendument sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité nommée CVE-2018-9206 en octobre. Mais la facilité avec laquelle la faille a été découverte par un chercheur en sécurité implique que des pirates informatiques professionnels, dont le seul but est de rechercher de telles vulnérabilités, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les correctifs apportés par la suite, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle Malware voleur de bitcoins a été lancé sur une bibliothèque NPM populaire téléchargée par des millions de personnes chaque semaine.

Le majordome l'a fait

Comme jQuery, Jenkins est une offre open source et l'une des plus populaires du genre. Avec son nom utile semblable à un serveur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par les équipes de développement de nombreux secteurs. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, des failles récemment découvertes et une opération de minage de cryptomonnaie récemment découverte c'est vraiment énorme en termes d'échelle, suggère que Jenkins faisait également beaucoup de travail pour les méchants.

L'une des vulnérabilités les plus dangereuses de Jenkins est appelée désérialisation Java, qui est désigné comme CVE-2017-1000353. C'est une attaque complexe, mais elle existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. Le premier lance un canal bidirectionnel de téléchargement qui est initialement rejeté par le serveur. Cependant, la deuxième requête ajoute un canal de téléchargement contenant une charge utile contenant toutes les commandes souhaitées par l'attaquant, et utilise le script payload.jar. Une fois la deuxième demande envoyée, la communication est autorisée sur les serveurs Jenkins non patchés.

Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, le compte NT AUTHORITY \ SYSTEM est utilisé par défaut pour autoriser les utilisateurs. Cela est dangereux car SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ce n'est souvent pas le cas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, donc les gens pensent que toutes les vulnérabilités ont été corrigées il y a longtemps.

Plus récemment, un pirate informatique a utilisé ces vulnérabilités vieillissantes de Jenkins pour compromettre plusieurs serveurs. L'objectif était d'ajouter un programme de minage de cryptomonnaies sur chaque instance vulnérable de Jenkins qu'ils pouvaient trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de cryptomonnaies. Jusqu'à présent, ils ont trouvé environ 10 800 pièces cryptées Monero, d'une valeur de près de 3,5 millions de dollars.

Ce qui est ancien est à nouveau nouveau

Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que de nombreuses personnes considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates de redonner vie à d'anciennes astuces. Et malgré une nouvelle série de succès en utilisant les vulnérabilités liées au vieillissement, de nombreuses organisations n'ont aucun plan en place pour mettre fin à ce cercle vicieux.

Ce n'est pas parce que quelque chose est vieux qu'il est inoffensif. Et ce n'est pas parce que les bibliothèques et les ressources communes existent depuis des années qu'elles sont totalement sécurisées (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est dédiée à la gestion de Utilisation de composants présentant des vulnérabilités connues). Ce n'est que grâce à la diligence et formation constante en matière de sécurité pouvons-nous nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais également de celles qui se sont déjà installées insidieusement dans notre propre jardin.