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 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(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 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
보고서 표시데모 예약하기
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(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.
목차
최고 경영자, 회장 겸 공동 설립자
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기Télécharger
%20(1).avif)
.avif)
