80 votes

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

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

0 votes

Veuillez noter qu'il existe deux autres vulnérabilités dans bash qui ne sont toujours pas corrigées (CVE-2014-7186 et CVE-2014-7187).

0 votes

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 disposez d'un correctif fourni par la distribution pour CVE-2014-7169, il se peut que vous en ayez déjà assez pour bloquer 7186/7187. Testez votre système avec les commandes ci-dessous et voyez. Vérifiez également s'il existe d'autres mises à jour de sécurité pour votre distribution.

83voto

BeowulfNode42 Points 2595

Pour vérifier la présence de la vulnérabilité CVE-2014-6271

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

il ne devrait PAS renvoyer le mot "vulnérable".


Pour vérifier la présence de la vulnérabilité CVE-2014-7169
(attention : 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 devrait dire le mot date puis se plaindre avec un message du genre cat: echo: No such file or directory . Si, au contraire, il vous indique l'heure actuelle, votre système est vulnérable.


Pour vérifier le 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 devrait PAS renvoyer le texte CVE-2014-7186 vulnerable, redir_stack .


Pour vérifier le 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 devrait PAS renvoyer le texte CVE-2014-7187 vulnerable, word_lineno .


Pour vérifier le CVE-2014-6277. Je ne suis pas sûr à 100% sur 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 qu'il ne fait que renvoyer 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 suis pas sûr des autres caractéristiques d'échec car je n'ai plus de systèmes non corrigés.


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

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

Un succès pour ce test est qu'il devrait SEULEMENT renvoyer le texte testing CVE-2014-6278 . Si la vôtre fait écho hi mom n'importe où, c'est définitivement un échec.

1 votes

Peut-on ajouter le test général foo='() { echo not patched; }' bash -c foo à cela ? Tant que les exportations de fonctions ne seront pas placées dans un espace de noms distinct, nous n'arrêterons pas de courir d'un bug d'analyseur à l'autre.

0 votes

Ce test a-t-il un CVE ? Avez-vous des références pour décrire ce problème ? Ce type d'information devrait également être traité dans l'une des autres questions sur shellshock, car cette question porte sur la manière de tester le succès ou l'échec des correctifs existants.

0 votes

Cela provient de l'article du blog de Michal Zalewski sur certains CVE Shellshock à venir ( lcamtuf.blogspot.com/2014/09/ ). C'est le test qu'il a suggéré pour CVE-2014-6278, qui n'est toujours pas public. Il semble que je me sois trompé sur la généralité du test, cependant ; j'ai déjà rencontré un cas où le test de Zalewski a réussi mais le test CVE-2014-7187 a échoué.

32voto

Giovanni Tirloni Points 5581

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'

Exécutez maintenant un simple écho pour voir si Bash évalue le code dans $testbug même si vous n'avez pas utilisé cette variable vous-même :

$ bash -c "echo Hello"
VULNERABLE
Hello

S'il affiche la chaîne "VULNERABLE", 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 correctifs ont été publiés par les principales distributions Linux et que, parfois, ils ne corrigent pas complètement la vulnérabilité. Continuez à consulter les avis de sécurité et le Entrée CVE pour ce bug.

5 votes

En plus de CVE-2014-6271, le correctif incomplet de Red Hat en particulier a le sien qui vaut également la peine d'être suivi : CVE-2014-7169 .

3 votes

Une seule ligne qui ne pollue pas votre Shell env et se trouve à fonctionner même si 'vous utilisez un autre login Shell (qui peut ne pas savoir sur export ): env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"

1 votes

Il y a quelques détails spécifiques à Ubuntu ici askubuntu.com/questions/528101/ - Personnellement, j'ai dû passer d'Ubuntu 13.10 à 14.04 pour résoudre ce problème.

2voto

Liam Marshall Points 121

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

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é :'(

0 votes

Votre lien est mort

0 votes

@SSK Désolé ;) Erreur de frappe.

0 votes

Votre lien est toujours mort.

2voto

Eduard Florinescu Points 831

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

Redhat recommande ce qui suit :

Exécutez 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-6271 fixer

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 de 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 fichiers. Pour tester 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 le fichier /tmp/echo sera créé.

Si votre système n'est pas vulnérable, vous verrez un message similaire à celui-ci :

$ 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

1voto

user245089 Points 47

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

http://shellshock.iecra.org

4 votes

Il est poli de fournir les raisons des downvotes.

4 votes

"Nous enregistrons tous les scans" ? ??? Flippant. Je téléchargerais le Python et l'exécuterais moi-même.

1 votes

@brad au moins ils te le disent. Je suis sûr que si je fournissais un service de sécurité de type "whitehat" qui offrait ce service, je pourrais bien tenir un journal (ne serait-ce qu'un compteur sans détails individuels) du nombre de personnes qui ont aveuglément entré les détails de leur site sur un site web qui disait qu'il allait tenter un test de pénétration, sans en savoir beaucoup sur l'authenticité du site proposant le test... et ils voudraient un journal de qui a testé quoi au cas où quelqu'un utiliserait leur service pour trouver des sites vulnérables appartenant à d'autres, aussi...

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X