Question Comment tester si mon serveur est vulnérable au bogue ShellShock?


Comment puis-je m'assurer que mon installation de Bash n'est pas vulnérable au ShellShock bug plus après les mises à jour?


77
2017-09-25 14:25


origine


Voir Existe-t-il une commande courte pour tester si mon serveur est sécurisé contre le bogue shellshock bash? - Martin Schröder
Veuillez noter qu'il existe deux autres vulnérabilités dans bash non corrigées (CVE-2014-7186 et CVE-2014-7187). - Deer Hunter
Les correctifs qui corrigent CVE-2014-7186 et CVE-2014-7187 sont disponibles peu de temps après que Deer Hunter ait posté son commentaire. Si vous avez un correctif fourni par la distribution pour CVE-2014-7169, vous en avez peut-être déjà assez pour bloquer 7186/7187, testez votre système avec les commandes ci-dessous et voyez. Recherchez également d’autres mises à jour de sécurité pour votre distribution. - BeowulfNode42


Réponses:


Pour vérifier la vulnérabilité CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

il ne devrait PAS faire écho au mot vulnérable.


Pour vérifier la vulnérabilité CVE-2014-7169
(avertissement: si le vôtre échoue, il créera ou écrasera un fichier appelé /tmp/echo que vous pouvez supprimer après et que vous devez supprimer avant de tester à nouveau)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

il faut dire le mot date puis se plaindre avec un message comme cat: echo: No such file or directory. Si au lieu de cela, il vous indique quelle est la date et l'heure actuelle, votre système est vulnérable.


Vérifier CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

il ne faut pas faire écho au texte CVE-2014-7186 vulnerable, redir_stack.


Vérifier CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

il ne faut pas faire écho au texte CVE-2014-7187 vulnerable, word_lineno.


Vérifier CVE-2014-6277. Je ne suis pas sûr à 100% de celui-ci car il semble s'appuyer sur un système partiellement patché auquel je n'ai plus accès.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Un résultat positif sur celui-ci est-il seulement l'écho du texte testing CVE-2014-6277. S'il exécute perl ou s'il se plaint que perl n'est pas installé, c'est définitivement un échec. Je ne suis pas sûr de connaître d'autres caractéristiques de défaillance, car je n'ai plus de système non corrigé.


Vérifier CVE-2014-6278. Encore une fois, je ne suis pas sûr à 100% s'il s'agit de ce test car je n'ai plus de systèmes non corrigés.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Un test réussi pour ce test est qu’il doit SEULEMENT rappeler le texte. testing CVE-2014-6278. Si le vôtre résonne hi mom n'importe où c'est certainement un échec.


83
2017-09-26 07:49



Peut-on ajouter le test général foo='() { echo not patched; }' bash -c foo pour ça? Tant que les exportations de fonctions ne sont pas placées dans un espace de noms séparé, nous ne cesserons pas de courir d’un bogue d’analyseur à un autre. - billyw
Est-ce que ce test a un CVE? Avez-vous des références pour décrire ce problème? De plus, ce type d’informations peut appartenir à l’une des autres questions sur shellshock car ce Q concerne la façon de tester le succès ou l’échec des correctifs existants. - BeowulfNode42
Ceci est tiré du billet de blog de Michal Zalewski sur certains prochains Shellshock CVE (lcamtuf.blogspot.com/2014/09/…). C'est son test suggéré pour CVE-2014-6278, qui n'est toujours pas public. Il semble que je me suis trompé quant à la généralité du test; J'ai déjà rencontré un cas où le test de Zalewski a réussi mais où le test CVE-2014-7187 a échoué. - billyw
Et voici la divulgation complète sur CVE-2014-6277 et CVE-2014-6278, ainsi que les commandes pour les vérifier: seclists.org/fulldisclosure/2014/Oct/9 - billyw
Un point à noter: même si la version de BASH est vulnérable, si rien ne l’utilise (c’est-à-dire tous les comptes utilisés par les démons, tels que "www" ou "cups" ou autre) sont configurés avec BASH comme shell par défaut et aucun vos appels de codes system () ou similaires, le fait de disposer de la version vulnérable peut présenter moins de risques, mais mettez néanmoins à niveau BASH dès que possible. - DTK


Exportez une variable d'environnement spécialement conçue qui sera évaluée automatiquement par les versions vulnérables de Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Maintenant, exécutez un simple écho pour voir si Bash évaluera le code dans $ testbug même si vous n'avez pas utilisé cette variable vous-même:

$ bash -c "echo Hello"
VULNERABLE
Hello

Si la chaîne "VULNERABLE" est affichée, la réponse est évidente. Sinon, vous n'avez pas à vous inquiéter et votre version corrigée de Bash est OK.

Veuillez noter que plusieurs versions de correctifs ont été publiées par les principales distributions Linux et qu’elles ne résolvent parfois pas complètement la vulnérabilité. Continuez à vérifier les avis de sécurité et les Entrée CVE pour ce bug.


32
2017-09-25 14:25



Outre le correctif logiciel CVE-2014-6271, le correctif incomplet de Red Hat mérite également d’être suivi: CVE-2014-7169. - DocMax
One-Liner qui ne pollue pas l’environnement de votre shell et fonctionne même si vous utilisez un shell de connexion alternatif export): env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello" - Lloeki
Il y a quelques détails spécifiques Ubuntu ici askubuntu.com/questions/528101/… - personnellement, je devais passer de Ubuntu 13.10 à 14.04 pour résoudre le problème - dodgy_coder


ShellShock est pratiquement une conjonction de plusieurs vulnérabilités de bash, et à ce moment il y a aussi malaware qui exploite cette vulnérabilité, ShellShock peut donc être un problème qui reste ouvert, il existe un fil avec des mises à jour de RedHat à ce sujet.

Redhat recommande ce qui suit: 

Exécuter la commande:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Si la sortie est:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

vous n'avez pas de solution.

Si la sortie est:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

tu as CVE-2014-6271 réparer

Si votre sortie est:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

vous n'êtes pas vulnérable.

L’autre partie de la vérification ShellShock est la vérification de vulnérabilité CVE-2014-7169 qui garantit que le système est protégé contre le problème de création de fichier. Pour vérifier si votre version de Bash est vulnérable à CVE-2014-7169, exécutez la commande suivante:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Si votre système est vulnérable, l'heure et la date s'afficheront et / tmp / echo sera créé.

Si votre système n'est pas vulnérable, vous verrez une sortie semblable à:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

2
2017-09-29 14:43





J'ai écrit un utilitaire de CLI appelé ShellShocker pour tester votre serveur Web pour les vulnérabilités sur les scripts CGI. Pour tester votre site, vous exécutez:

python shellshocker.py <your-server-address>/<cgi-script-path>

c'est à dire

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDIT: cet utilitaire a été supprimé, désolé: '(


2
2017-09-26 17:24



Votre lien est mort - SSK
@SSK Désolé;) Mistype. - Liam Marshall
Votre lien est toujours mort. - Mxx
Oui, désolé, je l'ai pris. C'était exploité d'une manière que je n'aimais pas. - Liam Marshall


Vous pouvez soumettre votre URL CGI à ce test en ligne:

http://shellshock.iecra.org


1
2017-09-25 20:46



Il est poli de motiver les votes négatifs. - David
"Nous enregistrons tous les scans" ??? Terrifiant. Je téléchargerais le python et le lancerais moi-même. - Brad
@rad au moins ils te le disent. Je suis sûr que si je fournissais un service de sécurité Whitehat offrant ce service, je pourrais peut-être tenir un journal (si seulement un compteur ne contenait aucun détail individuel) du nombre de personnes ayant entré aveuglément les détails de leur site sur un site Web qui indiquait qu'il allait pour tenter un test d'intrusion, sans trop en savoir sur l'authenticité du site proposant le test ... et ils voudraient un journal de ceux qui ont testé quoi au cas où quelqu'un utiliserait leurs services pour trouver des sites vulnérables appartenant à d'autres également ... - Rob Moir


tapez env x = '() {:;}; echo vulnérable 'bash -c "echo this est un test" et si cela renvoie vulnérable et qu'il s'agit d'un test, cela signifie que votre ordinateur OSX / Linux est affecté. Le remède consiste à mettre à jour la dernière version de bash.


-1
2017-09-27 11:33



Pourquoi en tant que root? Complètement inutile. - Mat