GitLab, le service de stockage et d'automatisation de code source a encore une fois procédé à l’analyse du code source hébergé sur sa plateforme et a constaté que la majorité contenait des vulnérabilités, l’entreprise a fait le même constat en avril dernier. Ce deuxième rapport sur les tendances en matière de sécurité a aussi révélé une augmentation des projets intégrant des bibliothèques de codes vulnérables. Cette analyse a permis d'identifier des tendances et des modèles que les responsables de la sécurité peuvent utiliser pour évaluer leur organisation.En avril, GitLab a analysé le code hébergé pour détecter les problèmes de sécurité. Il a récemment repris son examen et a remarqué qu'il restait du travail à faire pour réduire les vulnérabilités des logiciels. Voici ci-dessous ce que vous devez savoir.
Tendances par CWE (Common Weakness Enumeration)
Ici, GitLab a mis toutes les vulnérabilités détectées sur tous les scanners en correspondance avec leur CWE primaire. Les CVE pertinents (Common Vulnerabilities and Exposures) sont inclus avec chaque bibliothèque ou composant vulnérable. Ainsi, il a remarqué que les trois principales CWE, des erreurs de programmation capables de conduire à des failles exploitables, sont les suivantes :
- CWE-20 : validation d'entrée incorrecte. Cette forme d’erreur peut donner lieu à des attaques par injection (SQL, code...). Les principaux résultats ont été obtenus grâce au scanner de conteneurs qui a permis de détecter des problèmes liés à des logiciels obsolètes, notamment pour glibc (CVE-2016-10228 et CVE-2018-19591) et apt (CVE-2020-3810). Le scanner de dépendances a aussi trouvé des problèmes pour les bibliothèques en service, notamment : ajv, sockjs, minimist et yargs-parser ;
- CWE-787 : écriture hors limites du tampon prévu. C’est une faille qui permet l'exécution potentielle de codes à distance. Les principaux résultats sont dus au scanner de conteneurs qui a permis de voir que les logiciels suivants étaient obsolètes et vulnérables : glibc (CVE-2020-1751, CVE-2018-11237), openexr (CVE-2020-15306) et ghostscript (CVE-2020-16287, CVE-2020-16292, CVE-2020-16291, et 8 autres). Par ailleurs, le scanner de dépendance a également trouvé des problèmes pour les bibliothèques dépendantes en service, le premier étant “execa” ;
- CWE-400 : consommation incontrôlée de ressources. C’est une faille pouvant permettre d'éventuelles attaques par déni de service contre des logiciels spécifiques. Les principaux résultats proviennent du scanner de dépendances de la bibliothèque Mixin-deep. Le scanner de conteneurs a également relevé des problèmes avec mysql-5.7 (CVE-2020-14547, CVE-2020-14540, CVE-2020-14576, et 4 autres) et nghttp2 (CVE-2019-9513 et CVE-2019-9511).
Les bibliothèques les plus vulnérables
« Le pourcentage de projets ayant des problèmes avec des bibliothèques dépendantes en cours d'utilisation a considérablement augmenté au cours de l'année 2019, passant de 26 à 69 % », a déclaré Wayne Haber, directeur de l'ingénierie, dans le rapport. « Cette situation vient confirmer le fait que la mise à jour des bibliothèques dépendantes doit en effet être priorisée en fonction des risques que ces bibliothèques présentent », a-t-il ajouté. Dans l’analyse, Lodash et JQuery ont tous deux tendance à figurer en bonne place dans les rapports de sécurité comme source de vulnérabilités.
Le fait qu'ils soient tous deux largement utilisés et qu'ils aient été longtemps sans mise à jour n'aide pas. Au mois d'août, les bibliothèques les plus vulnérables (toutes distribuées via npm) étaient :
- Lodash : pollution des prototypes d'objets ;
- Execa : injection de commande OS ;
- Mixin-deep : pollution des prototypes d'objets ;
- Kind-of : vérification du type ;
- Sockjs : cross-site scripting ;
- Ajv : validation incorrecte des entrées ;
- Minimist : validation incorrecte des entrées ;
- Yargs-parser : validation incorrecte des entrées ;
- JQuery : une requête SCRO tierce peut être exécutée ;
- Dot-prop : demande directe de navigation forcée.
Selon GitLab, à mesure que de nouvelles vulnérabilités sont découvertes dans les bibliothèques et que les projets qui les utilisent font l'objet d'une analyse de leurs dépendances, la prévalence des bibliothèques augmente. De même, au fur et à mesure que les dépendances sont mises à jour, leur prévalence diminue. Cependant, toutes les équipes ne peuvent pas établir des priorités et résoudre les problèmes de manière fiable, de sorte que de nombreuses bibliothèques dépendantes vulnérables continuent d'être utilisées pendant une longue période.
Autrement dit, GitLab estime que l'habitude de créer des applications avec des bibliothèques qui dépendent de bibliothèques plus petites a rendu la gestion de la sécurité des logiciels modernes pour le moins difficile, car un bogue présent dans une dépendance commune peut devenir un problème généralisé dans de multiples projets. Selon l’analyse le rapport, le problème est particulièrement grave dans l'écosystème Node.js. Toutefois, GitLab a mentionné quelques points positifs, où “positif” signifie que la situation ne s'aggrave pas ou qu'elle ne s'améliore que de façon marginale.
Par exemple, le pourcentage de projets ayant des problèmes avec les conteneurs a diminué l'année dernière, passant de 52 % à 41 %. Bien que l’analyse ait révélé une légère diminution, il est encore relativement élevé. Il est toujours essentiel de tenir à jour les registres des conteneurs et de reconstruire/redéployer les conteneurs qui les utilisent pour réduire les risques en matière de sécurité.
En outre, le pourcentage de projets ayant trouvé des vulnérabilités par le biais d'une analyse statique au cours de l'année dernière est resté presque inchangé (de 49 % à 52 %). Cela montre que l'analyse statique continue à être assez efficace pour identifier les vulnérabilités de sécurité. Graphe 7
Analyse statistique des vulnérabilités non secrètes
Dans le même temps, les types de failles identifiées par l'analyse statique semblent avoir été traités depuis longtemps, comme les mots de passe exposés dans les URL, les permissions incorrectes pour les fichiers, le manque de vérification de l'intégrité du chiffrement, etc. Les principales vulnérabilités dans cette catégorie sont :
- mot de passe dans l'URL : les mots de passe sont envoyés dans l'URL, ce qui permet de stocker plus facilement le mot de passe dans le cache du navigateur local et dans tout serveur proxy entre le navigateur et le serveur Web. Les mots de passe doivent être envoyés via des méthodes sécurisées telles que la méthode POST (par opposition à l'utilisation de GET, qui place le mot de passe dans l'URL) ;
- utilisation non sécurisée d'un fichier ou d'un répertoire temporaire : un fichier temporaire n'a pas les autorisations appropriées, ce qui permet d'exposer des données et éventuellement d'exécuter du code à distance ;
- générateur de nombres pseudo-aléatoires prévisibles (PRNG) : si une séquence prévisible est utilisée pour le chiffrement, il est plus facile de le faire échouer. Un PRNG sécurisé cryptographiquement devrait être utilisé à la place ;
- chiffrement sans intégrité : le code ne permet pas de valider que lors du déchiffrement des données, celles-ci n'ont pas été altérées. Une solution pour cela consiste à ajouter un hachage chiffré au message ;
- aucune extension de fichier trouvée dans un include : cela permet d’exécuter potentiellement du code à distance.
Analyse statistique des vulnérabilités liées aux secrets
Selon GitLab, pour des raisons de sécurité, les secrets (tels que les clés, les mots de passe...) ne doivent jamais être stockés dans la base de données du code. Cependant, il est très pratique pour les développeurs de le faire, ce qui en fait un anti-modèle de sécurité commun. Les secrets doivent être stockés dans un mécanisme de stockage conçu pour la sécurité, tel qu'un coffre-fort. Les principaux types de secrets/clés identifiés étaient :
- PKCS : norme de chiffrement à clé publique ;
- Clé RSA ;
- API AWS.
Vulnérabilités trouvées grâce à une analyse dynamique
- En-tête “X-frame-options” non défini : permet à une application Web d'être intégrée dans une autre application Web (malveillante) ;
- tabnabbing inversé : permet à une page liée à la page cible de pouvoir réécrire la page (par exemple pour la remplacer par un site de phishing) ;
- mauvaise configuration entre domaines : le chargement des données du navigateur Web peut être possible, en raison d'une mauvaise configuration du partage de ressources d'origine croisée (CORS) sur le serveur Web ;
- divulgation d'informations personnelles identifiables (IPI) : les scanners de sécurité ont des difficultés à déterminer avec précision si les données sont réellement des IPI. Les règles relatives aux IIP doivent être adaptées à chaque organisation ;
- directive sur la protection des sites de contenu (CSP) : il y a un manque de protection adéquate des sites de contenu, ce qui pourrait permettre des attaques de type “cross-site scripting” et autres attaques similaires ;
- divulgation des erreurs d'une application : lorsque des applications accessibles à un attaquant exposent des messages d'erreur, elles donnent à l'attaquant des indices significatifs sur la manière d'attaquer l'application. Ne permettre l'affichage de ces erreurs que dans les environnements de non-production.
Source : GitLab
Et vous ?
Qu'en pensez-vous ?Voir aussi
Le Top 10 des nouvelles vulnérabilités de sécurité de l'open source en 2019, avec des failles dans des projets écrits dans des langages populaires comme JavaScript, Java, Go, selon un rapport Le nombre de vulnérabilités rapportées sur des logiciels open source a augmenté de près de 50% en 2019, selon un rapport Le nombre de vulnérabilités rapportées sur des logiciels open source a doublé en 2019, selon un rapport de RiskSense Les hackers éthiques détectent une vulnérabilité logicielle toutes les 2,5 minutes, selon HackerOne