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

80

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

Giovanni Tirloni
la source
Voir Existe
Réintégrer Monica - M. Schröder le
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:

83

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/echoque 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 doit 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 doit 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"

Le résultat de cette opération est qu’il renvoie UNIQUEMENT le 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 connais aucune autre caractéristique 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% si ce test est correct, car je n’ai plus de système non corrigé.

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 fait écho hi momn'importe où, c'est un échec.

BeowulfNode42
la source
1
Pouvons-nous ajouter le test général foo='() { echo not patched; }' bash -c fooà cela? 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
C'est ce qui est écrit dans le blog de Michal Zalewski sur des événements à venir de 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 Le
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 similaire, le fait de disposer de la version vulnérable présente peut-être moins de risques, mais mettez néanmoins à niveau BASH dès que possible.
DTK
32

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 l' entrée CVE pour ce bogue.

Giovanni Tirloni
la source
5
En plus de CVE-2014-6271, le correctif incomplet de Red Hat a notamment le sien: CVE-2014-7169 .
DocMax
3
One-Liner qui ne pollue pas votre shell et fonctionne même si vous utilisez un shell de connexion alternatif (que vous ne connaissez peut-être pas export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki
1
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 le
2

Shellshock est pratiquement une conjonction de plus d'une vulnérabilité de bash , et à ce moment il y a aussi MalAware qui exploite cette vulnérabilité , donc Shellshock peut être une question qui est encore ouvert, il y a un fil avec des mises à jour de RedHat sur ces questions .

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

vous avez CVE-2014-6271fix

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 la 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
Eduard Florinescu
la source
2

J'ai écrit un utilitaire CLI appelé ShellShocker pour tester votre serveur Web à la recherche de vulnérabilités dans 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é: '(

Liam Marshall
la source
Votre lien est mort
SSK le
@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
1

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

http://shellshock.iecra.org

utilisateur245089
la source
4
Il est poli de motiver les votes négatifs.
David
4
"Nous enregistrons tous les scans" ??? Terrifiant. Je téléchargerais le python et le lancerais moi-même.
Brad
1
@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
-1

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 vers la dernière version de bash.

Hen-Al
la source
6
Pourquoi en tant que root? Complètement inutile.
Mat le