ShellShock, la faille qui secoue l'interpréteur Bash

Qu’est-ce que Bash ?

Bash est un shell aussi connu sous le nom d’interpréteur de commandes. Il s’agit d’un outil avec lequel un utilisateur peut interagir pour réaliser différentes actions en ligne de commande. Cet outil est intégré par défaut dans la majorité des distributions Linux existantes, et également disponible dans un grand nombre d’autres systèmes (Mac OS X, Unix, appliance, systèmes embarqués, …).

Et ShellShock, c’est quoi ?

ShellShock, c’est le surnom donné à une vulnérabilité affectant l’interpréteur Bash. Cette vulnérabilité, référencée CVE-2014-6271, est plus particulièrement liée à la gestion des variables d’environnement. Ce problème a été identifié par Stéphane Chazelas, à priori en répondant à cette question d’un internaute.

Et c’est quoi une variable d’environnement ?

Une variable d’environnement est un paramètre décrivant une partie du contexte dans lequel un processus est lancé par un utilisateur afin de s’exécuter. Par exemple, on peut retrouver dans ce type de variable le nom de l’utilisateur, le « PATH » dans lequel seront recherchés les exécutables par le système, ou encore le nom de l’interpréteur de commande. Il est possible de voir la liste des variables d’environnement en entrant la commande « env » dans un terminal.

La faille de sécurité identifiée par Stéphane Chazelas a pour origine le traitement effectué par Bash sur les variables d’environnement définissant une fonction. En effet, dès lors qu’une telle variable est utilisée, le logiciel exécute les commandes placées après la définition de la fonction.

Ce comportement n’est bien sûr pas prévu par les développeurs et n’était donc pas documenté, ni même connu. Il peut donc être exploité par des utilisateurs malveillants afin de détourner le comportement de Bash, et ainsi de prendre le contrôle de systèmes à distance.

En effet, lors de la définition d’une fonction dans l’environnement, il est possible d’y ajouter des éléments qui pourront être exécutés. Dès lors, et en fonction du contexte d’utilisation de Bash, il est possible pour un attaquant de réaliser une élévation de privilèges localement sur un système, voire d’en prendre le contrôle à distance. Il est à noter que l’élévation de privilèges s’exploite de manière indirecte, et nécessite qu’un programme soit exécuté dans le contexte d’un utilisateur disposant de plus de droits.

Le code ci-dessous permet de tester la présence de cette vulnérabilité sur un système :

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Je ne comprends pas le code, que permet-il de faire ?

Afin de mieux comprendre l’origine de la faille, nous allons décortiquer cette preuve de concept. Elle permet :

• d’assigner à la variable d’environnement x une fonction anonyme () ne réalisant rien { :; }
• de faire suivre cette assignation de la commande echo vulnerable
• de demander à l’interpréteur Bash, potentiellement vulnérable, d’exécuter la commande « echo this is a test »

Pourquoi cette vulnérabilité est considérée comme étant particulièrement dangereuse ?

Le jeu de mots (Shell vs ShellShock, qui signifie Traumatisé en anglais) ayant donné son nom à cette faille illustre bien son importance.

En effet, bien que Bash n’ait pas pour vocation à être exposé directement sur Internet, certaines solutions techniques peuvent aboutir à une telle situation, sans que l’on s’en rende forcément compte.

Or, la faille affecte toutes les versions de Bash publiées durant les 20 dernières années ; depuis la version 1.14 (publiée en 1994), jusqu’à la version 4.3 publiée en février dernier. De fait, cet interpréteur est installé par défaut sur de nombreux systèmes Linux, Unix, OS X, … De plus, ce type de système étant souvent utilisé comme socle au sein des boitiers commercialisés par les éditeurs de solutions, un très grand nombre de produits embarquent également ce composant vulnérable.

Concrètement, il est possible d’accéder à Bash de deux manières :

• localement: dans ce cas, le principal risque auquel le système est exposé est une élévation de privilèges.
  • Il est typiquement possible pour un utilisateur lambda de passer « root » sur un système OSX disposant de VMware.
• à distance: dans ce cas, le principal risque auquel le système est exposé est une prise de contrôle avec les privilèges du service exploité
  • Il est typiquement possible de forcer un serveur web exposant une interface CGI à exécuter des commandes système arbitraires.

Cependant, OSX / VMware et Apache / mod_cgi ne sont pas les seuls composants logiciels vulnérables. De nombreuses preuves de concept ont été publiées sur Internet, illustrant l’exploitation de cette faille dans de nombreuses autres configurations : FTP, DHCP, DNS, OpenVPN, SIP, Qmail et bien sûr SSH sont également concernés. Une liste régulièrement actualisée est disponible à l’adresse suivante :

• https://github.com/mubix/shellshocker-pocs

Des codes d’exploitations ont-ils été publiés ?

Plusieurs codes d’exploitation ont en effet été publiés sur Internet ; à commencer par Apache / mod_cgi et OSX / VMware. L’exploitation de cette faille est donc encore plus triviale qu’elle ne l’était… La plupart de ces codes permettent de prendre le contrôle de systèmes hébergeant des serveurs Apache disposant du module mod_cgi. Il existe par ailleurs plusieurs codes ciblant le client DHCP « dhclient » ou encore les serveurs SIP.

De nombreux internautes ont ainsi publié de simples commandes permettant de tirer parti de cette faille : curl -i -X HEAD "http://<SERVER>/" -A '() { :;}; echo "vulnerable"’ nmap --script http-enum --script-args http.useragent="() { :; }; <COMMANDE>" <SERVER>

Seul prérequis, identifier au préalable les ressources CGI hébergées sur un serveur. Google et ces dorks peuvent être utilisés à cette fin.

Un script NSE baptisé http-shellshock.nse a même été publié pour Nmap, permettant de parcourir l’arborescence d’un site afin d’identifier au moins partiellement les ressources CGI vulnérables ; ce qui permet de se dispenser du prérequis précédemment évoqué…

ShellShock est-elle exploitée sur Internet ?

Cette faille étant particulièrement simple à exploiter, les pirates en tout genre ont sauté sur l’occasion. On peut observer dans les journaux d’évènements des serveurs web des traces caractéristiques de tentatives d’exploitation de la faille.

Les premières traces observées ont ainsi été divulguées dès le 25 septembre, alors que la faille avait été révélée le 24 en fin de journée… D’après les informations alors disponibles, le pirate exploitait la faille en déposant un binaire malveillant sur le système vulnérable, avant de l’exécuter. La lecture du rapport disponible sur VirusTotal laisse peu de doute quant au caractère malveillant du logiciel ainsi déposé…

Suis-je concerné par ShellShock ?

Comme nous l’expliquions précédemment, Bash est présent par défaut sur un très grand nombre de systèmes. Il y a donc fort à parier que vous êtes concernés ! Pour le savoir, rien de plus simple ; il suffit de :

• télécharger le script bashcheck
• puis de l’exécuter avec la commande suivante ./bashcheck

$ wget -O bashcheck.sh https://raw.githubusercontent.com/hannob/bashcheck/master/bashcheck

$ chmod u+x bashcheck.sh

$ ./bashcheck.sh

La sortie de ce script est relativement simple à interpréter. Ce script va rechercher la présence de la vulnérabilité ShellShock et de toutes les vulnérabilités qu’elle a induites : CVE-2014-7169, CVE-2014-7186, CVE-2014-7187 et CVE-2014-6277. Pour chacune de celles-ci, le script va tester des preuves de concept et afficher le cas échéant un message indiquant la présence de la vulnérabilité.

J’ai entendu parler des vulnérabilités CVE-2014-7169, CVE-2014-7186, CVE-2014-7187 et CVE-2014-6277. En quoi sont-elles liées à ShellShock ?

Les premiers correctifs de la vulnérabilité ShellShock se sont révélés partiellement efficaces, et ont fait apparaitre d’autres failles de sécurité. Le MITRE, en charge de l’assignation des CVE, a donc publié ces nouvelles références.

Comment se prémunir de cette vulnérabilité ?

Après plusieurs tentatives, des patchs permettant de corriger tous les problèmes identifiés ont finalement été proposés. Ces derniers ont été intégrés dans les principales Distributions Linux. L’utilisation des gestionnaires de paquets permet donc l’application des correctifs.

• Pour les systèmes Ubuntu et Debian, il s’agit des commandes « apt-get update; apt-get upgrade bash; ».
• Pour RedHat, CentOS, Oracle Linux : « yum update bash ».

Un correctif a également été publié pour Mac OS X.

Quant à Windows, il n’est pas affecté par cette vulnérabilité dans son installation de base. La plupart des services Microsoft (IIS, Active Directory, etc.) ne reposent pas sur bash et ne sont donc pas concernés.

Pour les autres systèmes, il sera nécessaire d’attendre un retour de la part de leurs éditeurs respectifs. Dans un premier temps, il est recommandé de restreindre l’accès aux systèmes exposés sur Internet en réalisant du filtrage par IP source.

Enfin, pour les utilisateurs souhaitant mettre à jour leur système manuellement, un script est disponible pour cela. Ce script permet de télécharger la dernière version de Bash, ainsi que les différents fichiers de *.patch permettant de corriger les failles affectant cette version, de l’interpréter.