Articles

Injection de commande : comment les contrer avec UBIKA Cloud Protector ?

Découvrez comment UBIKA Cloud Protector contre les injections de commandes.

Qu’est qu’une injection de commande ?

Une injection de commande est une faille pouvant toucher toutes les applications ayant accès à un système

On parle d’OS command Injection lorsque l’attaque par injection de commande permet d’utiliser des commandes propres à un système d’exploitation, notamment via un shell.
Dans une application web, une injection de commande se produit lorsqu’un serveur utilise une entrée utilisateur pour exécuter une commande sur son système d’exploitation sans la filtrer.
Le système va alors utiliser cette commande dans un shell puis renvoyer sa sortie vers le serveur et donc vers l’utilisateur.

A première vue, exécuter une commande sur le Shell d’un serveur avec les entrée utilisateurs peut paraitre contre-intuitif
Le principal intérêt est d’utiliser des commandes disponibles sur le système d’exploitation qui n’ont pas d’équivalent direct sur le langage utilisé par le serveur, de plus les commandes Shell sont très flexibles et permette un grand nombre d’options.
Le gain de temps à utiliser une commande Shell plutôt que de recoder une fonction est considérable

Impact

Ayant accès au système d’exploitation du serveur, l’OS Command injection peut voir des conséquences très graves :

  • Récupération de fichier: Un hacker peut renvoyer les fichiers vers son navigateur, ce qui peut lui permettre de voir le code source du site et de découvrir d’autres failles, afficher des fichiers de données.
  • Corruption de fichier: Extension du point précédent, le hacker peut modifier et supprimer des dossiers.
  • Surcharge du système : En lançant certaines commandes, il est facile de faire planter un système (« Fork Bomb »).
  • Installation d’une porte dérobée: Le hacker peut créer des fichiers dans le serveur, il lui suffit d’y insérer un code lui permettant de se reconnecter quand il le souhaite et de rentrer des commandes beaucoup plus facilement.

Il existe énormément de possibilité d’exploitation, un shell peut exécuter un très grand nombre de commandes.
La dangerosité de cette faille est en lien direct avec la configuration du serveur, s’il est possible d’effectuer une escalade de privilège jusqu’au root, alors le hacker aura la main mise sur le serveur.

Exemple d’une injection de commande Unix

1. Utilisation normale d’un formulaire ping en php

Afin de montrer comment exploiter une injection de commande, je vais utiliser un formulaire sur une page web permettant de rentrer un nom de domaine et de récupérer des informations telles que la date de création, le mail et le téléphone du propriétaire, etc.

Loris sera notre attaquant dans cet exemple.
Il va tout d’abord rentrer « google.com » dans le formulaire.

Lorsqu’il cliquera sur le bouton, le serveur va récupérer cette information puis fera exécuter cette commande au système.

Quand le système aura fini, il retournera la sortie au serveur et ce dernier va alors l’insérer dans le code HTML de la page.

L’affichage sera le suivant :

A la vue du résultat, Loris en déduit que la commande utilisée est « whois » sous Linux grâce à la fonction system().

2. Détection de la vulnérabilité

Pour comprendre comment tester une attaque par injection de commande, il faut d’abord connaître la structure d’une commande, je prendrais l’exemple de Linux, car c’est un OS très courant pour les serveurs.

En suivant ce schéma, on peut donc en déduire la commande que le serveur a traitée :

Loris va alors ajouter un caractère à la fin de la commande pour pouvoir ajouter la sienne.
Les choix les plus judicieux ici sont le « ; » et le « | », car ils ne sont pas soumis à une condition.
Il ne lui reste plus qu’à ajouter une commande pour tester, il utilisera « echo », qui renvoie en sortie l’argument qui lui est passé.

Loris rentre son script dans le formulaire du site et retrouve bien « test » écrit en bas de la page.

3. Exploitation de l’injection

Maintenant que la vulnérabilité est confirmée, Loris va pouvoir exploiter cette dernière.
Avec cet exemple, sans aucune protection au niveau de l’entrée utilisateur, il est possible d’effectuer bon nombre d’actions, tout dépend de ce qui est recherché par l’attaquant
Je vais présenter quelques commandes utilisées par Loris pour comprendre l’environnement dans lequel il se trouve.

Loris va choisir d’utiliser la commande « wget » qui permet de télécharger un fichier depuis une url, cela va lui permettre de télécharger un script « backdoor » présent sur son site, il va également ajouter la commande donnant les droits d’exécution à son script et le lancer :

La backdoor de Loris est lancé, il n’a plus qu’à se connecter dessus grâce à netcat depuis son terminal :

Loris a maintenant accès à un terminal sur le serveur, lui permettant d’être plus rapide dans son exploitation
Si MongoDB tourne sur le serveur et est mal configurée, il suffirait de rentrer la commande suivante pour afficher les bases de données existantes

A partir de là Loris peut récupérer des données comme les noms d’utilisateurs ou les mots de passe, modifier les données déjà existantes voir même les supprimer

Recommandation de l’OWASP sur les attaques OS command Injection

Afin de prévenir les attaques par injections de commandes, l’OWASP recommande de suivre plusieurs règles :

  • Eviter d’utiliser les commandes systèmes : Il peut exister des équivalences entre certaines commandes systèmes et certaines fonctions, il est alors plus judicieux d’utiliser ces dernières
  • Filtrer les caractères malicieux : Grâce à des fonctions telles que escapeshellarg en PHP qui permette de sécuriser les entrées utilisateurs
  • Utiliser une « whitelist » de valeurs autorisées : Cela permet de restreindre au maximum les entrés des utilisateurs et éviter ainsi toute injections de commandes
  • Contrer les injections de commandes avec Cloud Protector

    Pour permettre de contrer les injections de commandes, UBIKA Cloud Protector offre plusieurs solutions :

    La détections des caractères d’échappement et des commandes :
    UBIKA Cloud Protector va parcourir les commandes entrées et bloquer celles qui contiennent les différents opérateurs permettant d’ajouter des commandes arbitraires, comme vu dans le cas pratique.

    En parallèle, UBIKA Cloud Protector va aussi chercher si un des mots de la requête est un exécutable (Windows & Linux) et le bloquera si besoin.

Dans cet exemple, le caractère « ; » et la commande « ls -la » vont être détectés, par conséquent la requête sera bloquée et redirigée.

Posted ago by Paloma

Marketing Manager @ Ubika