web-dev-qa-db-fra.com

Existe-t-il une courte commande pour tester si mon serveur est sécurisé contre le bug bash Shellshock?

J'ai fait apt-get update; apt-get upgrade -y sur tous les systèmes que j'utilise. Je ne sais pas si mon /etc/apt/sources.list est assez bon sur tous ces systèmes. Je voudrais vérifier à nouveau rapidement chaque système, idéalement avec une commande Shell sur une ligne.

Existe-t-il une telle commande Shell sur une ligne et si oui, qu'est-ce que c'est?

Notez que cette question concerne principalement CVE-2014-6271.

shellshockbash
76
kqw

Mon bash est-il vulnérable?

Cette simple commande est un test suffisant pour voir si votre version de bash est vulnérable:

x='() { :;}; echo VULNERABLE' bash -c :

Il n'est pas nécessaire d'imprimer du texte supplémentaire pour indiquer que la commande a réellement été exécutée, car les versions corrigées de bash signaleront un avertissement lorsqu'une variable dans son environnement de démarrage contient du code d'exploitation pour la vulnérabilité corrigée.

Sur un système vulnérable:

$ x='() { :;}; echo VULNERABLE' bash -c :
VULNERABLE

Sur un système patché:

$ x='() { :;}; echo VULNERABLE' bash -c :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

Pour une explication détaillée de ce que cela fait et ne teste pas, et pourquoi, voir "Autres bogues d'analyse de fonction" ci-dessous.

Mon système est-il vulnérable?

Si votre bash n'est pas vulnérable, votre système n'est pas vulnérable.

Si votre bash est vulnérable, votre système est vulnérable dans la mesure où il utilise bash le long de vecteurs d'attaque tels que les scripts CGI, les clients DHCP et les comptes SSH restreints. Vérifiez si /bin/sh Est bash ou un autre shell. La vulnérabilité est dans une fonctionnalité spécifique à bash et les autres shells tels que dash et ksh ne sont pas affectés. Vous pouvez tester le shell par défaut en exécutant le même test que ci-dessus avec sh au lieu de bash:

x='() { :;}; echo VULNERABLE' sh -c :
  • Si vous voyez un message d'erreur, votre système a un bash corrigé et n'est pas vulnérable.
  • Si vous voyez VULNERABLE, alors le shell par défaut de votre système est bash et tous les vecteurs d'attaque sont une préoccupation.
  • Si vous ne voyez aucune sortie, alors le shell par défaut de votre système n'est pas bash, et seules les parties de votre système qui utilisent bash sont vulnérables. Vérifier:
    • Scripts exécutés par bash (commençant par #!/bin/bash, Pas #!/bin/sh) Depuis CGI ou par un client DHCP.
    • Comptes SSH restreints dont Shell est bash.

Fonctionnement de ce test

Il exécute la commande bash -c : Avec le texte littéral () { :;}; echo VULNERABLE Défini comme la valeur de la variable d'environnement x.

  • Le programme intégré : N'effectue aucune action ; il est utilisé ici où une commande non vide est requise.

  • bash -c : Crée une instance de bash qui exécute : Et se termine.

    Même cela est suffisant pour permettre le déclenchement de la vulnérabilité. Même si bash est invoqué pour exécuter une seule commande (et que cette commande est un no-op), il lit toujours son environnement et interprète chaque variable dont le contenu commence par () { Comme une fonction (au moins celles dont les noms sont des noms de fonction valides) et l'exécute pour que la fonction soit définie.

    L'intention derrière ce comportement de bash est d'exécuter uniquement une définition de fonction, ce qui rend une fonction disponible pour une utilisation mais n'exécute pas réellement le code à l'intérieur.

  • () { :;} Est la définition d'une fonction qui n'exécute aucune action lorsqu'elle est appelée. Un espace est requis après { Pour que { Soit analysé comme un jeton distinct. Un ; Ou nouvelle ligne est requis avant } Pour qu'il soit accepté comme syntaxe correcte.

    Voir .3 Fonctions Shell dans le Bash Reference Manual pour plus d'informations sur la syntaxe de définition des fonctions Shell dans bash. Mais notez que la syntaxe utilisée (et reconnue) par bash en tant que fonction Shell exportée valide dont la définition doit être exécutée est plus restrictive:

    1. Il doit commencer par la chaîne exacte () {, Avec exactement un espace entre ) Et {.
    2. Et bien que les fonctions Shell aient parfois leur instruction composée entre ( ) Au lieu de { }, Elles sont toujours exportées dans la syntaxe { }. Les variables dont le contenu commence par () ( Au lieu de () { Ne testeront pas ou ne déclencheront pas la vulnérabilité.

  • bash devrait arrêter l'exécution du code après la fermeture }. Mais (à moins qu'il ne soit corrigé), il ne fonctionne pas! Il s'agit du mauvais comportement qui constitue CVE-2014-6271 ("Shellshock").

    ; Termine l'instruction qui définit la fonction, permettant au texte suivant d'être lu et exécuté en tant que commande distincte. Et le texte après ; N'a pas à être une autre définition de fonction - il peut être n'importe quoi du tout.

  • Dans ce test, la commande après ; Est echo VULNERABLE. L'espace de début avant echo ne fait rien et est présent juste pour la lisibilité. La commande echo écrit le texte dans sortie standard . Le comportement complet de echo est en fait quelque peu compliqué, mais ce n'est pas important ici: echo VULNERABLE Est simple. Il affiche le texte VULNERABLE.

    Étant donné que echo VULNERABLE N'est exécuté que si bash n'est pas corrigé et exécute du code après les définitions de fonction dans les variables d'environnement, ceci (et de nombreux autres tests similaires) est un test efficace pour déterminer si le bash installé ou non est vulnérable à CVE-2014-6271.

Autres bogues d'analyse des fonctions (et pourquoi ce test et ceux qui lui ressemblent ne les vérifient pas)

Le correctif qui a été publié à ce jour, et les commandes décrites et expliquées ci-dessus pour vérifier la vulnérabilité, s'appliquent au bogue très grave connu sous le nom de CVE-2014-6271. Ni ce correctif ni les commandes décrites ci-dessus pour vérifier la vulnérabilité ne s'appliquent au bogue connexe CVE-2014-7169 (et ne doivent pas non plus être supposés s'appliquer à d'autres bogues qui n'ont peut-être pas encore été découverts ou divulgués).

Le bug CVE-2014-6271 provenait d'une combinaison de deux problèmes:

  1. bash accepte les définitions de fonctions dans des variables d'environnement arbitraires, et
  2. ce faisant, bash continue d'exécuter tout code existant après l'accolade fermante (}) d'une définition de fonction.

Au moment de la rédaction de ce document, le correctif existant pour CVE-2014-6271 qui avait été publié (et déployé par de nombreux fournisseurs en aval) - c'est-à-dire le correctif que vous obtiendriez en mettant à jour votre système ou en appliquant manuellement le correctif existant - -est un correctif pour 2.

Mais en présence de autre erreurs dans le code de bash, 1 est potentiellement une source de nombreux bogues d'analyse supplémentaires. Et nous savoir au moins un autre bug de ce type existe - en particulier, CVE-2014-7169 .

La commande présentée dans cette réponse teste si un bash installé est corrigé ou non avec le correctif existant (c'est-à-dire le premier officiel) pour CVE-2014-6271. Il teste la vulnérabilité à ce bogue d'analyse spécifique : "GNU Bash à travers 4.3 traite les chaînes de fin après les définitions de fonction dans les valeurs des variables d'environnement [...]"

Ce bogue spécifique est extrêmement grave - et le correctif disponible le fait le corrige - alors que CVE-2014-7169 semble être moins grave mais est certainement toujours source de préoccupation.

Comme Stéphane Chazelas ( découvreur du bug Shellshock ) a récemment expliqué dans une réponse à Quand était le Shellshock (CVE-2014 -6271) bug introduit, et quel est le patch qui le corrige complètement? on nix.SE :

Il existe un correctif qui empêche bash d'interpréter autre chose que la définition de fonction ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081 .html ), et c'est celui qui a été appliqué dans toutes les mises à jour de sécurité des différentes distributions Linux.

Cependant, bash interprète toujours le code là-dedans et tout bogue dans l'interpréteur pourrait être exploité. Un tel bug a déjà été trouvé (CVE-2014-7169) bien que son impact soit beaucoup plus faible. Il y aura donc bientôt un autre patch.

Mais si c'est à ça que ressemble l'exploit ...

Certaines personnes, ici et ailleurs, ont demandé pourquoi x='() { :;}; echo VULNERABLE' bash -c : impression VULNERABLE (ou similaire) devrait être considéré comme alarmant. Et j'ai récemment vu une idée fausse circuler selon laquelle car vous devez déjà avoir un accès interactif à Shell pour taper cette commande particulière et appuyer sur Entrée, Shellshock ne doit en aucun cas être une vulnérabilité sérieuse.

Bien que certains des sentiments que j'ai entendus aient exprimé - que nous ne devrions pas nous précipiter pour paniquer, que les utilisateurs de bureau derrière NAT les routeurs ne devraient pas mettre leur vie en attente pour construire bash à partir du code source- -sont tout à fait correct, confondant la vulnérabilité elle-même avec la possibilité de la tester en exécutant une commande spécifique (comme la commande présentée ici) est une grave erreur.

La commande donnée dans ce post est une réponse à la question, "Existe-t-il une courte commande pour tester si mon serveur est sécurisé contre le bug bash Shellshock?" C'est pas une réponse à "À quoi ressemble Shellshock quand il est utilisé contre moi par un vrai attaquant?" et ce n'est pas une réponse à la question, "Qu'est-ce que quelqu'un doit faire pour réussir à exploiter ce bogue?" (Et c'est aussi pas une réponse à: "Existe-t-il une commande simple à déduire de tous les facteurs techniques et sociaux si je suis personnellement à haut risque?")

Cette commande est un test, pour voir si bash exécutera du code écrit, d'une manière particulière, dans des variables d'environnement arbitraires. La vulnérabilité Shellshock n'est pas x='() { :;}; echo VULNERABLE' bash -c :. Au lieu de cela, cette commande (et d'autres comme elle) est un diagnostic pour aider à déterminer si l'une est affectée par Shellshock.

  • Shellshock a des conséquences très étendues, mais il est vrai que le risque est presque certainement moindre pour les utilisateurs de bureau qui ne le sont pas exécuter des serveurs réseau accessibles à distance. (Combien moins est quelque chose que je ne pense pas que nous sachions à ce stade.)
  • En revanche, la commandex='() { :;}; echo VULNERABLE' bash -c : est entièrement sans conséquence sauf dans la mesure où il est utile pour tester pour Shellshock (en particulier, pour CVE-2014-6271).

Pour ceux qui sont intéressés, voici quelques ressources qui expliquent pourquoi ce bogue est considéré comme grave et pourquoi les variables d'environnement, en particulier sur les serveurs de réseau, peuvent contenir des données non fiables capables d'exploiter le bogue et de causer des dommages:

Pour illustrer davantage la distinction conceptuelle ici, considérons deux hypothèses:

  1. Imaginez si au lieu de suggérer x='() { :;}; echo VULNERABLE' bash -c : comme test, j'avais suggéré bash --version Comme test. (Cela ne serait en fait pas particulièrement approprié, car les fournisseurs de système d'exploitation rétroportent fréquemment les correctifs de sécurité vers les anciennes versions de logiciel. Les informations de version qu'un programme vous donne peuvent, sur certains systèmes, donner l'impression que le programme serait vulnérable, alors qu'en réalité il a été patché.)

    Si des tests en exécutant bash --version Étaient suggérés, personne ne dirait: "Mais les attaquants ne peuvent pas s'asseoir devant mon ordinateur et taper bash --version, Donc je dois aller bien!" Il s'agit de la distinction entre un test et le problème testé.

  2. Imaginez si un avis a été émis suggérant que votre voiture pourrait avoir un problème de sécurité, comme une défaillance de l'airbag ou des flammes lors d'une collision, et que des démonstrations d'usine avaient été diffusées. Personne ne dirait: "Mais je ne conduirais ou ne remorquerais jamais accidentellement ma voiture à 900 miles de l'usine et je la ferais charger d'un mannequin de crash coûteux et s'écraserait contre un mur de béton. Donc, je dois aller bien!" Il s'agit de la distinction entre un test et le problème testé.

123
Eliah Kagan

Vous pouvez vérifier si vous êtes vulnérable en exécutant les lignes suivantes dans votre shell par défaut, qui sur de nombreux systèmes sera Bash. Si vous voyez les mots "éclaté", alors vous êtes en danger. Si seule la deuxième commande affiche "éclaté", votre bash est vulnérable, mais la vulnérabilité n'affecte que les parties de votre système qui appellent explicitement bash, pas les parties qui exécutent le shell par défaut (sh). Si aucune des commandes ne s'affiche "interrompue", votre système est corrigé.

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" bash -c "echo completed"

Source

Après l'application de correctifs, votre système peut toujours être vulnérable:

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

Source et ne autre source

12
BadSkillz

Si vous avez besoin d'une méthode pour vérifier simultanément plusieurs serveurs qui se trouvent sur le même sous-réseau, vous pouvez utiliser Masscan pour envoyer une demande à chacun d'eux: https://github.com/robertdavidgraham/masscan

Un exemple de fichier de configuration se trouve à http://blog.erratasec.com/2014/09/bash-Shellshock-scan-of-internet.html :

target = 0.0.0.0/0 //CHANGE THIS TO THE PROPER SUBNET
port = 80
banners = true
http-user-agent = Shellshock-scan (http://blog.erratasec.com/2014/09/bash-Shellshock-scan-of-internet.html)
http-header[Cookie] = () { :; }; ping -c 3 209.126.230.74
http-header[Host] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
//change the above 3 Ip addresses to the IP of the machine you send it from.

Les machines vulnérables vous renverront un ping. Selon le blog de suivi de l'auteur, une configuration peut être requise.

11
Nzall

Vous pouvez essayer ShellShocker , qui est un utilitaire CLI qui peut vérifier un script CGI comme suit:

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-cgi.cgi
0
Liam Marshall

Vous pouvez vérifier que votre serveur soumet une URL CGI au test en ligne suivant:

http://Shellshock.iecra.org

0
Roger

J'ai écrit un test rapide qui affiche soit "vulnérable" soit "non vulnérable":

env x='() { :;}; echo vulnerable; exit;' bash -c 'echo not vulnerable' 2>/dev/null

Il renvoie également un code de sortie de 2 si votre version de bash est vulnérable, si vous souhaitez l'utiliser dans le cadre d'un script.

0
colevk