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é.
Directeur général, président et cofondateur
Secure Code Warrior 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é.
Veuillez réserver une démonstration.
Directeur 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.
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.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior 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é.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Directeur 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.
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
Directeur général, président et cofondateur
Secure Code Warrior 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é.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes 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.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à 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 clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
