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.
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é. Cependant, cette orientation tournée vers l'avenir peut avoir l'effet surprenant de modérer notre conscience globale en matière de sécurité.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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émo
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
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.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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é.
Afficher le rapportRéservez une démo
Chief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
Table des matières
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique 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émoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
