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é.
首席执行官、主席和联合创始人
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有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.
点击下方链接，下载此资源的PDF文件。
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
显示报告预约演示
首席执行官、主席和联合创始人
Pieter Danhieux是全球公认的安全专家，拥有超过12年的安全顾问经验，并在SANS担任首席讲师8年，教授如何针对和评估组织、系统和个人的安全弱点的攻击性技术。2016年，他被评为澳大利亚最酷的科技人士之一（Business Insider），被授予年度网络安全专业人士（AISA - 澳大利亚信息安全协会），并持有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.
%20(1).avif)
.avif)
