DevSecOps : les vieilles failles de sécurité font toujours de nouvelles victimes

Publié initialement sur DevOps.com.

En cybersécurité, nous agissons souvent comme des chasseurs. Nos yeux sont rivés sur l'horizon, à l'affût de la prochaine faille critique (tout en cherchant les outils, techniques et tactiques pour la contrer). Pourtant, cette focalisation sur l'avenir peut avoir pour effet surprenant d'émousser notre vigilance globale, nous rendant aveugles aux dangers profondément ancrés qui nous entourent et que les attaquants exploitent avec empressement.

Je compare souvent la cybersécurité moderne à un gilet pare-balles en Kevlar. Ses propriétés quasi éthérées peuvent arrêter des projectiles à haute vitesse et toutes sortes d'armes puissantes. Cela peut même donner au porteur un sentiment d'invincibilité. Pourtant, un arc et des flèches, technologie vieille de 3 000 ans, peuvent souvent percer cette protection. Un couteau bien aiguisé, probablement la deuxième arme la plus ancienne après les pierres, peut trancher le Kevlar aussi facilement qu'un sweat-shirt en coton. Et puis, il y a le fait que le Kevlar ne peut pas protéger chaque millimètre du corps humain. Si un attaquant trouve une faille, il l'exploitera, tout comme les vulnérabilités logicielles.

En cybersécurité, de nombreuses organisations sont vulnérables à des failles sur des systèmes vieux de huit ou dix ans, ce qui, en informatique, leur donne droit à une retraite bien méritée. Mais si vous pensez que ces systèmes vieillissants sont inoffensifs, vous risquez fort de voir apparaître quelques écrans bleus de la mort.

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 manipulation de l'arborescence DOM, en passant par la création d'animations. C'est un outil robuste utilisé depuis de nombreuses années. On suppose souvent que, parce qu'elle est si bien établie, elle a été entièrement vérifiée et que toutes ses vulnérabilités ont été corrigées.

Malheureusement, ce n'est pas le cas. Par défaut, la plupart des applications reposant sur jQuery utilisent les instructions de la bibliothèque interne pour l'authentification. Avec les serveurs Apache, cela implique de vérifier les fichiers .htaccess. Peu de développeurs ont pensé à vérifier si les mises à jour d'Apache incluaient toujours le support des .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, pilier 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, vérifier les fichiers de configuration .htaccess à chaque exécution ralentissait trop le système. Cette suppression a amélioré les performances globales d'Apache, mais a créé une vulnérabilité méconnue. Si les développeurs n'ont pas vérifié si leurs applications pouvaient toujours accéder aux fichiers .htaccess, la plupart des requêtes étaient acceptées sans examen.

Récemment, des experts ont découvert cette faille, notant qu'elle permettait à des utilisateurs non autorisés de télécharger et d'exécuter des shells ou presque tout type de code sur des systèmes supposés sécurisés. Cela a conduit à l'alerte CVE-2018-9206 en octobre. Mais la facilité avec laquelle cette faille a été découverte suggère que les pirates professionnels l'avaient probablement déjà identifiée. Malgré la publicité et les correctifs, une attaque similaire a eu lieu quelques semaines plus tard, où un malware voleur de Bitcoin a été diffusé via une bibliothèque NPM populaire téléchargée par des millions d'utilisateurs.

C'est le majordome qui l'a fait

Comme jQuery, Jenkins est une solution open source très populaire. Avec son nom évoquant un serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par de nombreuses équipes de développement. Lorsqu'il fonctionne correctement, c'est un outil extrêmement utile. Cependant, des failles récentes, dont une opération de minage de cryptomonnaie d'une ampleur massive, suggèrent que Jenkins travaillait aussi pour les cybercriminels.

L'une des vulnérabilités les plus dangereuses de Jenkins est la désérialisation Java, désignée sous le nom de CVE-2017-1000353. C'est une attaque complexe, mais connue depuis longtemps. L'attaquant doit soumettre deux requêtes. La première initie un canal bidirectionnel de téléchargement, initialement rejeté par le serveur. La seconde ajoute un canal d'envoi contenant une charge utile avec les commandes souhaitées, utilisant le script payload.jar. Une fois cette seconde requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.

Même sur les serveurs corrigés, des exploits subsistent. Par exemple, sous Windows, Jenkins utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car SYSTEM dispose de permissions totales sur les serveurs Windows. Les développeurs peuvent changer ce compte, mais ils le font rarement. Leur logique repose sur le fait que Jenkins existe depuis toujours, et ils supposent que toutes les vulnérabilités ont été corrigées depuis longtemps.

Plus récemment, un pirate a utilisé ces vulnérabilités vieillissantes de Jenkins pour compromettre plusieurs serveurs. L'objectif était d'installer un programme de minage de cryptomonnaie sur chaque instance vulnérable trouvée. Ces mineurs consommaient des ressources informatiques précieuses. Jusqu'à présent, ils ont accumulé environ 10 800 Monero, d'une valeur de près de 3,5 millions de dollars.

Le vieux devient nouveau

Dans ces deux exemples, des vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes jugées sûres. Côté défense, le manque de développement axé sur la sécurité permet à ces pirates de redonner vie à de vieilles astuces. Malgré une nouvelle série de succès utilisant ces failles vieillissantes, de nombreuses organisations n'ont aucun plan pour stopper ce cercle vicieux.

Ce n'est pas parce qu'une chose est ancienne qu'elle est inoffensive. Et ce n'est pas parce que des bibliothèques courantes 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 consacrée à l'utilisation de composants avec des vulnérabilités connues). Seule une vigilance accrue et une formation continue à la sécurité nous permettront de nous protéger, non seulement des menaces à l'horizon, mais aussi de celles déjà installées dans nos propres systèmes.