DevSecOps : Les vieux bogues de sécurité font encore de nouveaux tours de passe-passe
Publié à l'origine sur DevOps.com.
En matière de cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à l'affût de la prochaine faille (ainsi que des outils, techniques et tactiques de conception adéquats pour l'éliminer). Toutefois, cette focalisation sur l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, en nous empêchant de voir les dangers profonds qui existent tout autour 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 balles à grande vitesse et toutes sortes d'armes modernes et puissantes. Il peut même donner à son porteur un sentiment d'invincibilité. Cependant, un système d'armement relativement ancien (arc et flèches), fabriqué pour la première fois vers l'an 1000 avant J.-C., peut souvent pénétrer cette protection. Un couteau aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le Kevlar aussi facilement que s'il déchiquetait un sweat-shirt en coton. Enfin, le Kevlar n'est pas en mesure de protéger chaque millimètre du corps humain. Si un attaquant peut trouver une faille pour porter un coup préjudiciable, il le fera "un peu comme les petites zones exploitables dans les logiciels".
En matière de cybersécurité, de nombreuses organisations sont également vulnérables aux failles des systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne droit à une montre en or et à une pension de retraite. Mais si vous pensez que les failles de ces systèmes anciens sont inoffensives, alors vous avez probablement un ou deux écrans bleus de la mort dans votre avenir.
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 permet de tout faire, de la gestion des événements à la traversée et à la manipulation de l'arbre DOM, en passant par la génération d'animations. C'est une véritable bête de somme, utilisée depuis de nombreuses années. Les gens supposent que parce que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et que toutes les vulnérabilités ont été éliminé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 le fichier .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui a été un pilier de la sécurité pendant 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 être exécuté ralentissait trop les choses. La suppression de ce fichier 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 étaient simplement acceptées sans examen.
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 censés être sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité appelé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 les pirates professionnels, dont le seul but est de rechercher des vulnérabilités comme celle-ci, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les corrections apportés dans la foulée, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle un logiciel malveillant voleur de bitcoins s 'est déchaîné sur une librairie NPM populaire, téléchargée par des millions de personnes chaque semaine.
Le majordome l'a fait
Comme jQuery, Jenkins est un logiciel libre, et l'un des plus populaires de son genre. Avec son nom de serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par des équipes de développement dans de nombreux secteurs d'activité. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, les failles récemment découvertes, ainsi qu'une opération de minage de crypto-monnaie d'une ampleur réellement massive, suggèrent que Jenkins faisait aussi beaucoup de travail pour les méchants.
L'une des vulnérabilités Jenkins les plus dangereuses s'appelle Java deserialization et est désignée sous le nom de CVE-2017-1000353. Il s'agit d'une attaque complexe, mais qui existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. La première démarre un canal bidirectionnel pour le téléchargement qui est initialement rejeté par le serveur. Cependant, la seconde demande ajoute un canal de téléchargement qui contient une charge utile avec les commandes souhaitées par l'attaquant et utilise le script payload.jar. Une fois la deuxième requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.
Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, il utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car le compte SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ne le font souvent pas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, et que les gens pensent donc 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'ajouter un programme de minage de crypto-monnaie sur chaque instance vulnérable de Jenkins qu'il pouvait trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de crypto-monnaie. Jusqu'à présent, ils ont trouvé environ 10 800 pièces de monnaie Monero, d'une valeur de près de 3,5 millions de dollars.
Ce qui est ancien est à nouveau nouveau nouveau
Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que beaucoup considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates d'insuffler une nouvelle vie à de vieilles astuces. Et malgré un nouveau cycle de succès utilisant des vulnérabilités anciennes, de nombreuses organisations n'ont pas de plan en place pour arrêter 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 et des ressources courantes existent depuis des années qu'elles sont totalement sûres (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est consacrée à l'utilisation de composants présentant des vulnérabilités connues). Ce n'est qu'en faisant preuve de diligence et en suivant une formation constante en matière de sécurité que nous pourrons nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais aussi de celles qui se sont déjà installées insidieusement dans nos propres jardins.
Dans le domaine de la cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à la recherche de la prochaine faille. Toutefois, ce regard tourné vers l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité.
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Publié à l'origine sur DevOps.com.
En matière de cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à l'affût de la prochaine faille (ainsi que des outils, techniques et tactiques de conception adéquats pour l'éliminer). Toutefois, cette focalisation sur l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, en nous empêchant de voir les dangers profonds qui existent tout autour 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 balles à grande vitesse et toutes sortes d'armes modernes et puissantes. Il peut même donner à son porteur un sentiment d'invincibilité. Cependant, un système d'armement relativement ancien (arc et flèches), fabriqué pour la première fois vers l'an 1000 avant J.-C., peut souvent pénétrer cette protection. Un couteau aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le Kevlar aussi facilement que s'il déchiquetait un sweat-shirt en coton. Enfin, le Kevlar n'est pas en mesure de protéger chaque millimètre du corps humain. Si un attaquant peut trouver une faille pour porter un coup préjudiciable, il le fera "un peu comme les petites zones exploitables dans les logiciels".
En matière de cybersécurité, de nombreuses organisations sont également vulnérables aux failles des systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne droit à une montre en or et à une pension de retraite. Mais si vous pensez que les failles de ces systèmes anciens sont inoffensives, alors vous avez probablement un ou deux écrans bleus de la mort dans votre avenir.
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 permet de tout faire, de la gestion des événements à la traversée et à la manipulation de l'arbre DOM, en passant par la génération d'animations. C'est une véritable bête de somme, utilisée depuis de nombreuses années. Les gens supposent que parce que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et que toutes les vulnérabilités ont été éliminé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 le fichier .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui a été un pilier de la sécurité pendant 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 être exécuté ralentissait trop les choses. La suppression de ce fichier 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 étaient simplement acceptées sans examen.
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 censés être sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité appelé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 les pirates professionnels, dont le seul but est de rechercher des vulnérabilités comme celle-ci, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les corrections apportés dans la foulée, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle un logiciel malveillant voleur de bitcoins s 'est déchaîné sur une librairie NPM populaire, téléchargée par des millions de personnes chaque semaine.
Le majordome l'a fait
Comme jQuery, Jenkins est un logiciel libre, et l'un des plus populaires de son genre. Avec son nom de serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par des équipes de développement dans de nombreux secteurs d'activité. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, les failles récemment découvertes, ainsi qu'une opération de minage de crypto-monnaie d'une ampleur réellement massive, suggèrent que Jenkins faisait aussi beaucoup de travail pour les méchants.
L'une des vulnérabilités Jenkins les plus dangereuses s'appelle Java deserialization et est désignée sous le nom de CVE-2017-1000353. Il s'agit d'une attaque complexe, mais qui existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. La première démarre un canal bidirectionnel pour le téléchargement qui est initialement rejeté par le serveur. Cependant, la seconde demande ajoute un canal de téléchargement qui contient une charge utile avec les commandes souhaitées par l'attaquant et utilise le script payload.jar. Une fois la deuxième requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.
Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, il utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car le compte SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ne le font souvent pas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, et que les gens pensent donc 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'ajouter un programme de minage de crypto-monnaie sur chaque instance vulnérable de Jenkins qu'il pouvait trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de crypto-monnaie. Jusqu'à présent, ils ont trouvé environ 10 800 pièces de monnaie Monero, d'une valeur de près de 3,5 millions de dollars.
Ce qui est ancien est à nouveau nouveau nouveau
Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que beaucoup considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates d'insuffler une nouvelle vie à de vieilles astuces. Et malgré un nouveau cycle de succès utilisant des vulnérabilités anciennes, de nombreuses organisations n'ont pas de plan en place pour arrêter 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 et des ressources courantes existent depuis des années qu'elles sont totalement sûres (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est consacrée à l'utilisation de composants présentant des vulnérabilités connues). Ce n'est qu'en faisant preuve de diligence et en suivant une formation constante en matière de sécurité que nous pourrons nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais aussi de celles qui se sont déjà installées insidieusement dans nos propres jardins.
Publié à l'origine sur DevOps.com.
En matière de cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à l'affût de la prochaine faille (ainsi que des outils, techniques et tactiques de conception adéquats pour l'éliminer). Toutefois, cette focalisation sur l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, en nous empêchant de voir les dangers profonds qui existent tout autour 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 balles à grande vitesse et toutes sortes d'armes modernes et puissantes. Il peut même donner à son porteur un sentiment d'invincibilité. Cependant, un système d'armement relativement ancien (arc et flèches), fabriqué pour la première fois vers l'an 1000 avant J.-C., peut souvent pénétrer cette protection. Un couteau aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le Kevlar aussi facilement que s'il déchiquetait un sweat-shirt en coton. Enfin, le Kevlar n'est pas en mesure de protéger chaque millimètre du corps humain. Si un attaquant peut trouver une faille pour porter un coup préjudiciable, il le fera "un peu comme les petites zones exploitables dans les logiciels".
En matière de cybersécurité, de nombreuses organisations sont également vulnérables aux failles des systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne droit à une montre en or et à une pension de retraite. Mais si vous pensez que les failles de ces systèmes anciens sont inoffensives, alors vous avez probablement un ou deux écrans bleus de la mort dans votre avenir.
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 permet de tout faire, de la gestion des événements à la traversée et à la manipulation de l'arbre DOM, en passant par la génération d'animations. C'est une véritable bête de somme, utilisée depuis de nombreuses années. Les gens supposent que parce que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et que toutes les vulnérabilités ont été éliminé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 le fichier .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui a été un pilier de la sécurité pendant 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 être exécuté ralentissait trop les choses. La suppression de ce fichier 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 étaient simplement acceptées sans examen.
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 censés être sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité appelé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 les pirates professionnels, dont le seul but est de rechercher des vulnérabilités comme celle-ci, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les corrections apportés dans la foulée, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle un logiciel malveillant voleur de bitcoins s 'est déchaîné sur une librairie NPM populaire, téléchargée par des millions de personnes chaque semaine.
Le majordome l'a fait
Comme jQuery, Jenkins est un logiciel libre, et l'un des plus populaires de son genre. Avec son nom de serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par des équipes de développement dans de nombreux secteurs d'activité. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, les failles récemment découvertes, ainsi qu'une opération de minage de crypto-monnaie d'une ampleur réellement massive, suggèrent que Jenkins faisait aussi beaucoup de travail pour les méchants.
L'une des vulnérabilités Jenkins les plus dangereuses s'appelle Java deserialization et est désignée sous le nom de CVE-2017-1000353. Il s'agit d'une attaque complexe, mais qui existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. La première démarre un canal bidirectionnel pour le téléchargement qui est initialement rejeté par le serveur. Cependant, la seconde demande ajoute un canal de téléchargement qui contient une charge utile avec les commandes souhaitées par l'attaquant et utilise le script payload.jar. Une fois la deuxième requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.
Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, il utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car le compte SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ne le font souvent pas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, et que les gens pensent donc 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'ajouter un programme de minage de crypto-monnaie sur chaque instance vulnérable de Jenkins qu'il pouvait trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de crypto-monnaie. Jusqu'à présent, ils ont trouvé environ 10 800 pièces de monnaie Monero, d'une valeur de près de 3,5 millions de dollars.
Ce qui est ancien est à nouveau nouveau nouveau
Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que beaucoup considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates d'insuffler une nouvelle vie à de vieilles astuces. Et malgré un nouveau cycle de succès utilisant des vulnérabilités anciennes, de nombreuses organisations n'ont pas de plan en place pour arrêter 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 et des ressources courantes existent depuis des années qu'elles sont totalement sûres (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est consacrée à l'utilisation de composants présentant des vulnérabilités connues). Ce n'est qu'en faisant preuve de diligence et en suivant une formation constante en matière de sécurité que nous pourrons nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais aussi de celles qui se sont déjà installées insidieusement dans nos propres jardins.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationDirecteur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Publié à l'origine sur DevOps.com.
En matière de cybersécurité, nous sommes souvent comme des chasseurs. Nos yeux sont fermement rivés sur l'horizon, à l'affût de la prochaine faille (ainsi que des outils, techniques et tactiques de conception adéquats pour l'éliminer). Toutefois, cette focalisation sur l'avenir peut avoir l'effet surprenant d'affaiblir notre conscience globale de la sécurité, en nous empêchant de voir les dangers profonds qui existent tout autour 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 balles à grande vitesse et toutes sortes d'armes modernes et puissantes. Il peut même donner à son porteur un sentiment d'invincibilité. Cependant, un système d'armement relativement ancien (arc et flèches), fabriqué pour la première fois vers l'an 1000 avant J.-C., peut souvent pénétrer cette protection. Un couteau aiguisé, probablement la deuxième arme la plus ancienne au monde après les pierres, peut trancher le Kevlar aussi facilement que s'il déchiquetait un sweat-shirt en coton. Enfin, le Kevlar n'est pas en mesure de protéger chaque millimètre du corps humain. Si un attaquant peut trouver une faille pour porter un coup préjudiciable, il le fera "un peu comme les petites zones exploitables dans les logiciels".
En matière de cybersécurité, de nombreuses organisations sont également vulnérables aux failles des systèmes vieux de huit ou dix ans, ce qui, en termes informatiques modernes, leur donne droit à une montre en or et à une pension de retraite. Mais si vous pensez que les failles de ces systèmes anciens sont inoffensives, alors vous avez probablement un ou deux écrans bleus de la mort dans votre avenir.
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 permet de tout faire, de la gestion des événements à la traversée et à la manipulation de l'arbre DOM, en passant par la génération d'animations. C'est une véritable bête de somme, utilisée depuis de nombreuses années. Les gens supposent que parce que la bibliothèque est si bien établie à ce stade, elle doit avoir été complètement vérifiée et que toutes les vulnérabilités ont été éliminé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 le fichier .htaccess. Après tout, pourquoi Apache supprimerait-il ce composant essentiel, qui a été un pilier de la sécurité pendant 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 être exécuté ralentissait trop les choses. La suppression de ce fichier 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 étaient simplement acceptées sans examen.
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 censés être sécurisés. Cela a conduit à la création d'une alerte de vulnérabilité appelé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 les pirates professionnels, dont le seul but est de rechercher des vulnérabilités comme celle-ci, l'ont probablement déjà découverte. Après tout, malgré la publicité, les correctifs et les corrections apportés dans la foulée, une attaque similaire à fort impact s'est produite quelques semaines plus tard, au cours de laquelle un logiciel malveillant voleur de bitcoins s 'est déchaîné sur une librairie NPM populaire, téléchargée par des millions de personnes chaque semaine.
Le majordome l'a fait
Comme jQuery, Jenkins est un logiciel libre, et l'un des plus populaires de son genre. Avec son nom de serviteur, il est logique que Jenkins soit utilisé comme serveur d'automatisation par des équipes de développement dans de nombreux secteurs d'activité. Lorsque Jenkins fonctionne correctement, c'est un outil extrêmement utile. Cependant, les failles récemment découvertes, ainsi qu'une opération de minage de crypto-monnaie d'une ampleur réellement massive, suggèrent que Jenkins faisait aussi beaucoup de travail pour les méchants.
L'une des vulnérabilités Jenkins les plus dangereuses s'appelle Java deserialization et est désignée sous le nom de CVE-2017-1000353. Il s'agit d'une attaque complexe, mais qui existe depuis un certain temps. Un attaquant doit soumettre deux requêtes. La première démarre un canal bidirectionnel pour le téléchargement qui est initialement rejeté par le serveur. Cependant, la seconde demande ajoute un canal de téléchargement qui contient une charge utile avec les commandes souhaitées par l'attaquant et utilise le script payload.jar. Une fois la deuxième requête envoyée, la communication est autorisée sur les serveurs Jenkins non corrigés.
Même sur les serveurs patchés, des exploits existent. Par exemple, lorsque Jenkins est exécuté dans un environnement Windows, il utilise par défaut le compte NT AUTHORITY\SYSTEM pour autoriser les utilisateurs. C'est dangereux car le compte SYSTEM dispose de toutes les autorisations sur les serveurs Windows. Les développeurs peuvent modifier le compte d'autorité, mais ne le font souvent pas. Leur logique de ne pas le faire est basée sur le fait que Jenkins existe depuis toujours, et que les gens pensent donc 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'ajouter un programme de minage de crypto-monnaie sur chaque instance vulnérable de Jenkins qu'il pouvait trouver. Les mineurs ont utilisé de précieuses ressources informatiques dans leur recherche constante de crypto-monnaie. Jusqu'à présent, ils ont trouvé environ 10 800 pièces de monnaie Monero, d'une valeur de près de 3,5 millions de dollars.
Ce qui est ancien est à nouveau nouveau nouveau
Dans ces deux exemples, les vulnérabilités sont exploitées par des attaquants opportunistes sur des plateformes que beaucoup considèrent comme sûres. Sur le plan défensif, l'absence de développement axé sur la sécurité permet à ces pirates d'insuffler une nouvelle vie à de vieilles astuces. Et malgré un nouveau cycle de succès utilisant des vulnérabilités anciennes, de nombreuses organisations n'ont pas de plan en place pour arrêter 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 et des ressources courantes existent depuis des années qu'elles sont totalement sûres (par exemple, l'entrée n° 9 du top 10 actuel de l'OWASP est consacrée à l'utilisation de composants présentant des vulnérabilités connues). Ce n'est qu'en faisant preuve de diligence et en suivant une formation constante en matière de sécurité que nous pourrons nous protéger non seulement des menaces dangereuses qui se profilent à l'horizon, mais aussi de celles qui se sont déjà installées insidieusement dans nos propres jardins.
Table des matières
Directeur général, président et cofondateur
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.