Il était une fois … Shellshock

By | July 1, 2019

Aussi connu sous le nom de BashBug, Shellshock est le nom qui avait été donné à une famille de bugs de sécurité détectés dans le shell Bash durant l’automne de l’année 2014. Ces bugs avaient affecté des milliers de systèmes Linux/Unix sur la Toile.
Le tout premier fut découvert par Stéphane Chazelas le 24 Septembre 2014.

Bien qu’il existe au total six CVEs liés à cette famille de bugs, dans cet article, nous nous intéresserons principalement au tout premier (représentant celui découvert par Chazelas) : le CVE-2014-6271.

L’un des vecteurs d’attaque : le CGI

Le shell Bash est largement utilisé dans de nombreux systèmes de type Unix, y compris les systèmes basés sur Linux (tels que Red Hat Enterprise Linux, Fedora, CentOS, Debian et Ubuntu), * BSD (tels que FreeBSD et NetBSD), Apple MacOS X, et Cygwin (qui fonctionne sous Windows). De nombreux systèmes étaient donc potentiellement exploitables.

Un système était dit exploitable lorsqu’un attaquant trouvait un moyen de contrôler le contenu d’une variable d’environnement et de l’envoyer à travers un shell Bash affecté par la vulnérabilité Shellshock. Cette situation comprenait de nombreux systèmes exécutant des applications Web CGI invoquées via Bash, ou le démon SSHD utilisant ForceCommand (pour limiter l’accès à des actions spécifiques) et quelques clients DHCP se connectant à des serveurs DHCP subvertis, etc.

Au moment de la découverte du bug, le vecteur d’attaque le plus répandu était de toute évidence le Common Gateway Interface (CGI), une technologie Web définissant comment un serveur Web intéragit une application externe.

First things first, essayons tout d’abord de mieux comprendre le fonctionnement du CGI. 🙂

Soit le site suivant, qui retourne le résultat de l’exécution de la commande uptime sur le serveur sous-jaçent.


Ci-dessous le contenu du script exécuté au final …


… Et la config d’Apache permettant l’exécution de ce script.


Derrière le résultat affiché par le navigateur, voici toute magie qui se passe.


De cette image présentée ci-dessus, nous pouvons donc en conclure que le CGI sert en fait de passerelle entre le serveur Web et le programme installé (dans notre exemple Bash) sur le système d’exploitation sous-jaçent, sollicité pour l’exécution du script.

Démo

Dans une telle configuration, lorsqu’un serveur Web reçoit une requête d’un client, celui-ci transmet au programme CGI des détails de la requête qui seront stockés dans une liste de variables d’environnement.

Nous avons par exemple, la variable HTTP_USER_AGENT qui a une valeur identifiant le programme qui émet la requête, plus précisement l’entête User-Agent, le HTTP_REFERER qui indique le référent, ou encore le HTTP_COOKIE, représentant le cookie utilisé par le client.

La vulnérabilité Shellshock venait du fait qu’un attaquant pouvait manipuler ces variables à souhait lors de l’émission d’une requête et ainsi forcer le programme CGI (dans notre cas Bash) à exécuter des commandes de son choix.

Par exemple, la requête émise dans l’image ci-dessous, nous permet d’afficher l’id du compte utilisateur Apache …


… Ici, nous affichons le contenu du fichier /etc/passwd du serveur Web …


… Ici nous parvenons à réaliser un ping à partir de la machine sur laquelle le serveur Web est installé vers notre machine …


… Et pour finir, nous parvenons même à créer un bind shell via netcat !

NB: Notez que le paramètre A de curl permet de modifier l’entête User-Agent.

Toutes ces commandes exécutées à distance ont été possibles uniquement grâce à l’injection que nous avons insérée dans l’entête User-Agent. Une valeur qui représentera plutard celle de la variable d’envionnement HTTP_USER_AGENT.

Cette injection est composée de trois parties:

_ Le préfixe : Cette portion permet d’indiquer à Bash que la valeur qu’inclura la variable HTTP_USER_AGENT ne sera pas une variable d’environnement standard mais plutôt une fonction Bash. Les fonctions Bash sont reconnaissables notamment par leurs parenthèses. Les accolades qui suivent permettent d’insérer les instructions de la fonction.
Dans cet exemple, nous avons inséré les deux points (:) à l’intérieur des accolades, ce qui instruit Bash de ne rien faire.

_ Le rembourrage : Cette portion sert en réalité d’éviter des erreurs, et à mener Bash directement vers la portion suivante.

_ La commande à exécutée : Toutes les commandes insérées dans cette portion seront exécutées sur le système sous-djacent.

Depuis les premières détections, plusieurs patchs ont été publiés et il est désormais peu probable d’en rencontrer encore.

Voilà en gros ce qu’il faut retenir sur les bases de la faille de sécurité ShellShock.
J’espère que vous avez appris des choses nouvelles. 🙂

A très bientôt pour un prochain article !

Happy Hacking !

🙂


Source:
Image Docker utilisée dans cet article.
vulnerables/cve-2014-6271

mdestroy

Leave a Reply

Your email address will not be published. Required fields are marked *