Question:
Existe-t-il une courte commande pour tester si mon serveur est sécurisé contre le bogue shellshock bash?
kqw
2014-09-25 16:24:08 UTC
view on stackexchange narkive permalink

J'ai fait apt-get update; apt-get upgrade -y sur tous les systèmes que j'exécute. 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.

Une telle commande shell sur une ligne existe-t-elle et si oui, de quoi s'agit-il?

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

bash --version Les versions d'effets de bogue de bash jusqu'à et y compris 4.3
@raz Vérifier la version bash est inutile (sauf que les versions après 4.3, qui n'existent pas encore, ne seront pas affectées). La plupart des systèmes corrigeront le trou en corrigeant uniquement le trou (généralement en appliquant le processus de mise à jour normal de leur distribution), et non en passant à une toute nouvelle version de bash (qui, encore une fois, n'existe pas encore).
@Gilles `bash --version` rapportera un numéro de version comme` 4.3.25` (qui est le correctif qui corrige la vulnérabilité initiale, mais pas complète, de Shell Shock). Il n'y a aucune raison de penser qu'une version de niveau correctif est moins capable de corriger complètement le problème que certaines futures versions 4.4.
@chepner ... c'est exactement pourquoi la vérification du numéro de version est inutile. Sur la plupart des distributions, la mise à niveau qui corrige le trou ne change pas le numéro de version. La version vulnérable et la version fixe ont le même numéro de version. Vous ne pouvez pas l'utiliser pour dire si la vulnérabilité est présente.
Je serais un peu vexé si ma distribution corrige le code sans modifier le numéro de version * du tout *.
@chepner: pourquoi? Il y a une différence entre la version signalée par le programme et la version du package. Eh bien, il peut y en avoir, mettons les choses de cette façon.
Oui, mais le package peut indiquer une divergence par rapport à l'amont en utilisant les niveaux de révision. Si le gestionnaire de paquets décide de livrer une version de `bash` 4.3.25 avec ses propres correctifs, la version du paquet devrait être quelque chose comme 4.3.25-1.0, 4.3.25-1.1, etc, * pas * 4.3.26, 4.3.27 ou pire, 4.3.25, 4.3.25 avec * aucun * changement de version. Changer la version du package est une chose; marcher sur le schéma de versionnage de l'amont (au moins, un sens en amont) en est un autre. Le * point * entier d'un numéro de version est d'indiquer les changements dans le code sous-jacent.
Six réponses:
Eliah Kagan
2014-09-25 18:43:04 UTC
view on stackexchange narkive permalink

Mon bash est-il vulnérable?

Cette commande simple 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 signifier que la commande a effectivement été exécutée, car les versions corrigées de bash rapporteront un avertissement lorsqu'une variable à son démarrage l'environnement 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: ignorant la définition de la fonction trybash: erreur lors de l'importation de la définition de la fonction pour `x'

Pour une explication détaillée de ce que cela fait et fait pas de test, 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 n'est pas vulnérable.

Si votre bash est vulnérable, alors votre système est vulnérable dans la mesure où il utilise des vecteurs d'attaque bash along tels que des scripts CGI, des clients DHCP et des 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, cela signifie que votre système a un patch corrigé et n'est pas vulnérable.
  • Si vous voir VULNERABLE , alors le shell par défaut de votre système est bash et tous les vecteurs d'attaque sont un problème.
  • Si vous ne voyez aucune sortie, alors le shell par défaut de votre système n'est pas bash, et seulement des parties de votre système qui utilisent bash sont vulnérables. Recherchez:
    • Scripts exécutés par bash (commençant par #! / Bin / bash , et non par #! / Bin / sh ) depuis CGI ou par un Client DHCP.
    • Comptes SSH restreints dont le 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.

  • L'intégré : fonctionne aucune action; il est utilisé ici lorsqu'une commande non vide est requise.

  • bash -c: crée une instance de bash qui exécute : et quitte.

    Même cela est suffisant pour permettre le déclenchement de la vulnérabilité. Même si bash est appelé 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 (à moins ceux 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 ne le fait pas ne pas exécuter le code à l'intérieur.

  • () {:;} est la définition d'une fonction qui n'effectue aucune action lorsqu'elle est appelée. Un espace est requis après { pour que { soit analysé comme un jeton distinct. Un ; ou newline est requis avant } pour qu'il soit accepté comme syntaxe correcte.

    Voir 3.3 Fonctions Shell dans le Manuel de référence Bash 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 comme une fonction shell exportée valide dont il doit exécuter la définition est plus restrictive:

    1. Elle doit commencer par la chaîne exacte () { , avec exactement un espace entre ) et {.
    2. Et si les fonctions shell ont 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 ni ne déclenchent la vulnérabilité.

  • bash devrait arrêter d'exécuter le code après la fermeture } . Mais (à moins d'être corrigé) ce n'est pas le cas! C'est le mauvais comportement qui constitue la CVE -2014-6271 ("Shellshock").

    ; termine l'instruction qui définit la fonction, permettant au texte suivant d'être lu et exécuté comme une commande séparée. Et le texte après ; n'a pas à être une autre définition de fonction - il peut être n'importe quoi.

  • Dans ce test, la commande après ; est echo VULNERABLE . L'espace avant echo ne fait rien et est présent uniquement pour la lisibilité. code> echo écrit du texte dans la sortie standard. Le comportement complet de echo est en fait quelque peu compliqué, mais c'est sans importance ici: echo VULNERABLE est simple . Il affiche le texte VULNERABLE.

    Puisque echo VULNERABLE n'est exécuté que si bash n'est pas corrigé et exécute le 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 savoir si le bash installé est vulnérable à CVE-2014-6271.

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

Le correctif qui a été publié au moment de la rédaction de cet article, 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ées s'appliquer à d'autres bogues qui n'ont pas encore été découverts ou divulgués).

Le bogue CVE-2014-6271 est né 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 qui existe après l'accolade fermante (} ) d'une définition de fonction.

Au moment d'écrire ces lignes, le correctif existant pour CVE-2014-6271 qui a é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 le correctif existant manuellement - est un correctif pour 2

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

La commande présentée dans cette réponse teste si ou non, un bash installé est corrigé avec le correctif existant (c'est-à-dire le premier correctif officiel) pour CVE-2014-6271. Il teste la vulnérabilité à ce bogue d'analyse spécifique: "GNU Bash via 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 sévère - et le correctif disponible le corrige - alors que CVE-2014-7169 semble être moins sévère mais reste certainement préoccupant.

Comme Stéphane Chazelas ( découvreur du bogue Shellshock) l'a récemment expliqué dans une réponse à Quand le shellshock (CVE -2014-6271) introduit un bug, et quel est le correctif qui le corrige complètement? sur Unix.SE:

Il y a un correctif qui empêche bash d'interpréter autre chose que la définition de fonction qui s'y trouve ( 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 de ces bogues a déjà été trouvé (CVE-2014-7169) bien que son impact soit beaucoup plus faible. Donc, il y aura bientôt un autre patch à venir.

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

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

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

La commande donnée dans cet article est une réponse à la question, "Y a-t-il une courte commande pour tester si mon serveur est sécurisé contre le bogue shellshock bash?" Ce n'est pas une réponse à "À quoi ressemble le shellshock lorsqu'il est utilisé contre moi par un vrai attaquant?" et ce n'est pas une réponse à la question "Que doit faire quelqu'un pour réussir à exploiter ce bogue?" (Et ce n'est pas non plus une réponse à "Est-ce que y a-t-il une commande simple pour 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'un d'entre eux est affecté par Shellshock.

  • Shellshock a des conséquences très diverses, même s'il est vrai que le risque est presque certainement moindre pour les utilisateurs de bureau qui n'exécutent pas de serveurs réseau accessibles à distance. (Je ne pense pas que nous sachions combien de moins pour le moment.)
  • En revanche, la commande x = ' () {:;}; echo VULNERABLE 'bash -c: est totalement sans conséquence sauf dans la mesure où il est utile pour tester Shellshock (en particulier, pour CVE-2014-6271).

Pour ceux qui le sont intéressé, voici quelques ressources avec des informations sur les raisons pour lesquelles ce bogue est considéré comme grave et pourquoi les variables d'environnement, en particulier sur les serveurs 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. (Ce ne serait en fait pas particulièrement approprié, car les éditeurs de systèmes d'exploitation rétroportent fréquemment les correctifs de sécurité vers d'anciennes versions de logiciels. 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 fait, il a été corrigé.)

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

  2. Imaginez si un avis était émis suggérant que votre voiture pourrait avoir un problème de sécurité, comme une défaillance ou une explosion de l'airbag en flammes lors d'une collision, et que les démonstrations d'usine avaient été diffusées. Personne ne dirait: "Mais je ne conduirais jamais accidentellement ou ne remorquerais jamais ma voiture à 900 miles jusqu'à l'usine et la ferais charger avec un mannequin de collision coûteux et claquer dans un mur de béton. Alors ça doit aller!" C'est la distinction entre un test et le problème testé.

Hmm, mais si je peux exécuter bash, ne puis-je pas déjà exécuter des commandes arbitraires sur un système? En quoi est-ce une vulnérabilité?
@Ajedi32 `x = '() {:;}; echo VULNERABLE 'bash -c: `est un test pour voir si votre bash est patché. La raison pour laquelle CVE-2014-6271 est un vuln du tout est qu'il donne le pouvoir d'exécuter des commandes arbitraires à quiconque peut définir la valeur d'une variable d'environnement (dans des conditions où un bash s'exécutera alors avec cet ensemble de variables). Les variables d'environnement sont couramment utilisées pour transmettre des données non contrôlées et fournies par l'utilisateur entre les processus. Par exemple, * ceci est souvent exploitable via HTTP. * Voir http://seclists.org/oss-sec/2014/q3/650 sous "Jusqu'à présent, les requêtes HTTP aux scripts CGI ont été identifiées comme le principal vecteur d'attaque."
@Ajedi32 `/ bin / sh -c` est largement utilisé pour démarrer les processus enfants. Si l'environnement peut être contrôlé par un attaquant, alors il y a un problème - le cas le plus courant est un serveur Web utilisant l'environnement comme une forme de [IPC] (http://en.wikipedia.org/wiki/Inter-process_communication) lorsque exécuter des scripts CGI.
@mr.spuratic Votre exemple est `/ bin / sh -c` qui n'est pas` bash` mais juste le processus de base du shell vanilla. Je ne prends donc toujours pas le vrai risque ici. Certes, c'est tout usage non intentionnel. Mais si l'utilisateur ne peut pas obtenir des privilèges élevés au-delà de ce que possède le processus parent, le risque est quoi exactement?
Si bash n'est pas le shell par défaut, ne serait-il pas plus facile d'utiliser le: bash -c "env x = '() {:;}; echo vulnérable' bash -c echo c'est un test" oneliner?
@JakeGould La pire chose à propos de cette vulnérabilité est que pour l'exploiter, vous n'avez pas du tout besoin d'avoir un compte. Même si (par exemple) votre serveur Web fonctionne sous un compte d'utilisateur strictement limité, il serait très mauvais pour un attaquant de pouvoir exécuter des commandes arbitraires en tant qu'utilisateur limité, contrôlant complètement votre serveur Web (et plus). Voir [l'explication ici] (http://seclists.org/oss-sec/2014/q3/650). Les moyens les plus pratiques de * tester * une vulnérabilité ne sont pas toujours de la même forme que les moyens les plus dévastateurs de * l'exploiter dans la nature. *
@JakeGould C'est vrai que `sh` n'est que parfois` bash`. On peut s'attendre à ce que cela atténue quelque peu le risque / préjudice. Mais même si ce n'est pas le système sh, bash est largement utilisé pour les scripts, de sorte que l'exécution de code arbitraire est toujours possible. Les commandes après une définition de fonction dans une variable d'environnement sont exécutées lorsqu'un script bash est exécuté (comme exécuter un script bash, en particulier à partir d'un shell ou d'un autre processus qui n'est pas bash, implique d'exécuter l'exécutable bash pour l'interpréter). Le degré de risque pour les utilisateurs de bureau est inconnu, mais les données malveillantes (par exemple, des fichiers spécialement conçus) traitées via bash sont toujours un risque.
@somelooser28533 L'appelant n'a pas besoin d'être bash pour `env x = '() {:;}; echo vulnérable 'bash -c' echo ... '`, n'importe quel [shell de type Bourne (POSIX)] (https://en.wikipedia.org/wiki/Unix_shell#Bourne_shell_compatible) ou un autre shell qui accepte` VARIABLE = syntaxe de commande de valeur. Avec `env`, le shell pourrait être à peu près n'importe quoi, c'est peut-être pourquoi [le test BadSkillz cite] (http://security.stackexchange.com/a/68169) l'utilise. `sh -c" env x = '() {:;}; echo vulnérable' bash -c 'echo ...' "`, que sh soit ou non bash, fonctionne également. Même dans un shell non - style Bourne, vous n'avez pas besoin à la fois de `env` et de` sh -c`.
@EliahKagan Je vois le risque pour les serveurs dans certaines conditions, mais si vous regardez les forums d'utilisateurs Mac, par exemple, il y a cette panique absolue que Mac OS X au niveau du client est en danger. Et honnêtement, je ne vois pas cela. Mais appréciez votre POV.
@EliahKagan «C'est vrai que sh n'est que parfois bash.» «Non, ce n'est pas un problème« parfois ». `bash` est bash et` sh` est le shell Unix standard. Si vous ne comprenez pas ce fait incroyablement simple, vous ne devriez vraiment informer personne des problèmes de sécurité.
@JakeGould Il n'y a pas un seul programme qui soit "le shell Unix standard". Différents OS utilisent différents shells pour `/ bin / sh`. Sous GNU / Linux, `sh` est généralement un lien vers, ou une copie, d'un autre shell. [Dans Ubuntu et Debian, `dash` fournit` sh`, bien que `bash` l'ait fait il y a quelques années.] (Https://wiki.ubuntu.com/DashAsBinSh) Sur certains OS,` sh` reste `bash`. (Je pense que Slackware est un exemple, même si je ne l'ai pas utilisé récemment.) Une recherche rapide sur le Web, [ou Wikipedia] (https://en.wikipedia.org/wiki/Bourne_shell#Usage), vous aurait sauvé de votre idée fausse et m'a sauvé de votre fausse accusation d'ignorance.
@EliahKagan Je suis corrigé. Mais `dash` n'est tout simplement pas` bash` et je pense honnêtement que la panique autour de "shellshock" causera plus de problèmes que l'exploit lui-même.
Je viens de patcher mon serveur et maintenant j'obtiens l'erreur après avoir exécuté la commande ci-dessus. Cela signifie-t-il que je suis toujours vulnérable à la CVE-2014-7169 qui prétend que le correctif pour le choc du shell 6271 est incomplet?
@user53029 Le correctif publié pour CVE-2014-6271 ne corrige pas le défaut de conception sous-jacent qui fait que bash doit analyser les définitions de fonction de l'environnement * juste comme il faut * ou souffrir de bogues de sécurité potentiels. En ce sens, le correctif est incomplet. Mais cela corrige (pour autant que l'on sache) complètement le bogue de l'exécution du code de fin après une définition de fonction. Il est donc logique de considérer CVE-2014-7169 comme une vulnérabilité distincte. ** Le correctif pour 6271 et le test dans cette réponse pour déterminer si ce correctif est effectivement appliqué ne testent pas pour 7169. ** J'ai développé cette réponse avec des détails.
@Eliah Kagan -Pour avoir une idée du degré de sécurité qui a été atténué avec le patch, que peut faire un attaquant en exploitant le bogue de 7169 qu'il ne pouvait plus faire sur un système 6271 patché?
@user53029 Exactement. Un arbre est fixé. Mais la forêt est-elle en danger concret?
Suggestion pour une petite amélioration. Si vous préfixez la commande de test avec `env`, cela fonctionnera également à partir de csh / tcsh.
J'utilise mac os x, et il apparaît comme vulnérable - mais je ne peux rien y faire pour le moment, non?
Avec le dernier patch (qui évite les `eval`s sur des variables d'environnement aléatoires), le test original devrait bien se passer, n'imprimant rien sur un système complètement patché.
Je n'obtiens rien quand je tape ceci
BadSkillz
2014-09-25 16:34:03 UTC
view on stackexchange narkive permalink

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é», vous courez un risque. Si seule la deuxième commande affiche «busted», alors votre bash est vulnérable, mais la vulnérabilité affecte uniquement les parties de votre système qui invoquent explicitement bash, pas les parties qui exécutent le shell par défaut ( sh ). Si aucune des commandes n'imprime «busted», 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 le patch, votre système peut être toujours vulnérable: 

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

Source et une autre source

Je ne suis pas sûr de ce que `\` which bash \ `` est censé accomplir que `bash` ne ferait pas: les deux exécutent celui qui apparaît en premier dans` PATH`, et ce n'est pas comme si `env` avait besoin d'être pleinement qualifié des noms. (De plus, vous n'avez pas du tout besoin de `env` pour cela.)
@BadSkillz, pouvez-vous ajouter quelques précisions à `env X = '() {(a) => \' sh -c" echo date "; chat écho »? Qu'est-ce que c'est censé me faire ou me montrer?
@Eliah, ce serait formidable si vous pouviez trouver une meilleure réponse.
`which bash` pourrait vous faire passer une entrée filtrée limitant les littéraux de chemin de commande shell.
@KasperSouren, Je pense que cela démontre juste un bogue dans l'analyse de la fonction bash comme mentionné [ici] (https://twitter.com/taviso/status/514910129557610496) ... donc ce n'est pas une syntaxe bash valide.
X reste-t-il pour toujours dans mon environnement? et si j'ai déjà une variable d'environnement appelée X?
@NateKerkhofs Non, cela ne restera pas, et vous pouvez utiliser une autre variable si vous le souhaitez
Les variables d'environnement @NateKerkhofs sont par processus. `VAR = value some-command` (ou` env VAR = value some-command`) exécute `some-command` avec` VAR` mis à `value` dans * son * environnement. Le «x» appartenant au shell dans lequel vous exécutez cette commande [n'est lui-même pas affecté] (http://paste.ubuntu.com/8425978/), même si [la variable est définie dans l'environnement du processus enfant] (http: //paste.ubuntu.com/8425989/). Quoi qu'il en soit, même si vous l'avez défini pour l'environnement du shell actuel, comme BadSkillz le dit, il serait non persistant et ne causerait aucun dommage, et vous pouvez choisir un nom de variable différent si vous le souhaitez.
«Qui» est-il sûr? Qu'est-ce qu'il faut arrêter: `export which = '() {echo / bin / bash;}`? (Un complet testerait l'argument). Bash exécute les fonctions avant les fonctions intégrées. Vous pouvez également utiliser `declare -f` et` env` de la même manière pour masquer les fonctions.
Nzall
2014-09-25 19:47:04 UTC
view on stackexchange narkive permalink

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

Un exemple de fichier de configuration est disponible sur http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html: 

  target = 0.0.0.0/0 // CHANGER CECI AU BON SUBNETport = 80banners = truehttp-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.74http-header [Hôte] = () {:; }; ping -c 3 209.126.230.74http-header [Référent] = () {:; }; ping -c 3 209.126.230.74//change les 3 adresses IP ci-dessus en IP de la machine à partir de laquelle vous l'envoyez.

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

Comment puis-je vérifier un seul serveur?
@CharlesB se connecte simplement à distance au serveur et exécute l'un des oneliners de cette page. ou entrez l'adresse IP complète du serveur avec le masque de sous-réseau / 32.
Merci; n'a pas pu le modifier, mais il doit s'agir de `target-ip` au lieu de` target`. Si je teste mon routeur, la commande ping n'est pas détectable ... Y a-t-il une autre commande pour prouver cet exploit
Connectez-vous en SSH au routeur et faites ce qu'Eliah Khan recommande dans sa réponse. Vous devez le faire directement via le terminal du routeur.
Je n'y ai pas accès SSH, c'est une boîte fermée de notre FAI. Donc pas moyen de le vérifier?
S'il s'agit d'une boîte fermée, qu'allez-vous faire lorsqu'il s'avère que l'exploit est actif? Je doute que vous puissiez le réparer, car vous ne pouvez pas mettre à niveau Bash.
Bien sûr, je ne pourrai pas le réparer, mais c'est juste pour le savoir et demander à mon FAI à ce sujet.
Liam Marshall
2014-09-26 23:12:10 UTC
view on stackexchange narkive permalink

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

  python shellshocker.py http://example.com /cgi-bin/possably-vulnerable-cgi.cgi
Roger
2014-09-27 04:27:13 UTC
view on stackexchange narkive permalink

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

http://shellshock.iecra.org

colevk
2014-09-27 05:10:59 UTC
view on stackexchange narkive permalink

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

  env x = '() {:;}; écho vulnérable; sortie;' bash -c 'echo non vulnérable' 2> / dev / null

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

Testé avec les versions `3.2.51 (1) -release (x86_64-apple-darwin13)` et `3.2.53 (1) -release (x86_64-apple-darwin13)`.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...