Pregunta ¿Cómo probar si mi servidor es vulnerable al error de ShellShock?


¿Cómo puedo asegurar que mi instalación Bash no sea vulnerable a la Neurosis de guerra error más después de las actualizaciones?


77
2017-09-25 14:25


origen


Ver ¿Hay un comando corto para probar si mi servidor está seguro contra el error de bash shellshock? - Martin Schröder
Tenga en cuenta que hay otras dos vulnerabilidades en bash que aún no están parcheadas (CVE-2014-7186 y CVE-2014-7187). - Deer Hunter
Los parches que corrigen CVE-2014-7186 y CVE-2014-7187 están disponibles poco después de que Deer Hunter publicó su comentario. Si tiene un parche provisto por la distribución para CVE-2014-7169, es posible que ya tenga suficiente para bloquear 7186/7187, pruebe su sistema con los siguientes comandos y vea. También revise si hay más actualizaciones de seguridad para su distribución. - BeowulfNode42


Respuestas:


Para comprobar la vulnerabilidad CVE-2014-6271

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

NO debe repetir la palabra vulnerable.


Para comprobar la vulnerabilidad CVE-2014-7169
(advertencia: si el tuyo falla, creará o sobrescribirá un archivo llamado /tmp/echo que puede eliminar después, y necesita eliminar antes de volver a probar)

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

debe decir la palabra fecha y luego quejarse con un mensaje como cat: echo: No such file or directory. Si, por el contrario, le indica cuál es la fecha actual, su sistema es vulnerable.


Para comprobar 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"

no debe repetir el texto CVE-2014-7186 vulnerable, redir_stack.


Para comprobar 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"

no debe repetir el texto CVE-2014-7187 vulnerable, word_lineno.


Para comprobar CVE-2014-6277. No estoy 100% seguro de esto, ya que parece depender de un sistema parcialmente parchado al que ya no tengo acceso.

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

Un resultado de pase en este es SÓLO hace eco del texto testing CVE-2014-6277. Si se ejecuta perl o si se queja de que perl no está instalado, definitivamente es un error. No estoy seguro de ninguna otra característica de falla ya que ya no tengo ningún sistema sin parchear.


Para comprobar CVE-2014-6278. Nuevamente, no estoy 100% seguro de si esta prueba ya no tengo ningún sistema sin parchear.

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

Un pase para esta prueba es que SOLO debería repetir el texto testing CVE-2014-6278. Si el tuyo hace eco hi mom En cualquier lugar eso es definitivamente un fracaso.


83
2017-09-26 07:49



¿Podemos añadir la prueba general? foo='() { echo not patched; }' bash -c foo ¿a esto? Hasta que las exportaciones de funciones se coloquen en un espacio de nombres diferente, no dejaremos de ejecutar de un error del analizador al siguiente. - billyw
¿Esa prueba tiene un CVE? ¿Tiene alguna referencia para describir este problema? Además, este tipo de información puede pertenecer a una de las otras preguntas sobre shellshock debido a que esta Q es sobre cómo probar el éxito o el fracaso de los parches existentes. - BeowulfNode42
Eso es de la publicación del blog de Michal Zalewski sobre algunos CVE de Shellshock que se aproximan (lcamtuf.blogspot.com/2014/09/…). Es su prueba sugerida para CVE-2014-6278, que todavía no es pública. Sin embargo, parece que estaba equivocado acerca de la generalidad de la prueba; Ya he encontrado un caso en el que la prueba de Zalewski pasó pero la prueba CVE-2014-7187 falló. - billyw
Y aquí está la divulgación completa en CVE-2014-6277 y CVE-2014-6278, junto con los comandos para verificarlos: seclists.org/fulldisclosure/2014/Oct/9 - billyw
Un punto a tener en cuenta: incluso si la versión de BASH es vulnerable, si nada la usa (es decir, todas las cuentas utilizadas por los demonios, como "www" o "cups" o lo que sea) están configuradas con BASH como su shell predeterminado y ninguna de ellas. su sistema de llamadas de códigos () o similar, tener la versión vulnerable puede ser menos riesgoso, pero aún así, actualice BASH lo antes posible. - DTK


Exporte una variable de entorno especialmente diseñada que será evaluada automáticamente por versiones vulnerables de Bash:

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

Ahora ejecuta un eco simple para ver si Bash evaluará el código en $ testbug aunque no hayas usado esa variable por ti mismo:

$ bash -c "echo Hello"
VULNERABLE
Hello

Si muestra la cadena "VULNERABLE", la respuesta es obvia. De lo contrario, no debe preocuparse y su versión parcheada de Bash está bien.

Tenga en cuenta que las principales distribuciones de Linux han lanzado varios parches y que a veces no solucionan la vulnerabilidad por completo. Sigue revisando los avisos de seguridad y el Entrada de CVE para este error.


32
2017-09-25 14:25



Además de CVE-2014-6271, la solución incompleta de Red Hat en particular tiene su propia razón que también vale la pena seguir: CVE-2014-7169. - DocMax
Una sola línea que no contamina su env de shell y funciona incluso si está usando una shell de inicio de sesión alternativa (que puede no conocer) export): env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello" - Lloeki
Hay algunos detalles específicos de Ubuntu aquí askubuntu.com/questions/528101/… - personalmente tuve que actualizar de Ubuntu 13.10 a 14.04 para solucionar el problema - dodgy_coder


ShellShock es prácticamente una conjunción de más de una vulnerabilidad de bashy En este momento también hay un software malicioso que explota esta vulnerabilidad., por lo que ShellShock puede ser un problema que aún está abierto, hay un hilo con actualizaciones de RedHat sobre estos temas.

Redhat recomienda lo siguiente: 

Ejecutar comando:

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

Si la salida es:

$ 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

no tienes ninguna solucion

Si la salida es:

$ 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

tienes CVE-2014-6271 fijar

Si su salida es:

$ 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

No eres vulnerable.

La otra parte de ShellShock Check es que la verificación de vulnerabilidad CVE-2014-7169 garantiza que el sistema esté protegido contra el problema de creación de archivos. Para probar si su versión de Bash es vulnerable a CVE-2014-7169, ejecute el siguiente comando:

$ 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 su sistema es vulnerable, se mostrarán la hora y la fecha y se creará / tmp / echo.

Si su sistema no es vulnerable, verá una salida similar a:

$ 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





Escribí una utilidad de CLI llamada ShellShocker para probar su servidor web en busca de vulnerabilidades en scripts CGI. Para probar tu sitio, ejecutarías:

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

es decir

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

EDITAR: esta utilidad ha sido eliminada, lo siento: '(


2
2017-09-26 17:24



Tu enlace esta muerto - SSK
@SSK Lo siento;) Mistype. - Liam Marshall
Tu enlace todavía está muerto. - Mxx
Sí, lo siento, lo bajé. Estaba siendo explotado de una manera que no me gustaba. - Liam Marshall


Puede enviar su URL de CGI a esta prueba en línea:

http://shellshock.iecra.org


1
2017-09-25 20:46



Es educado proporcionar razones para los votos negativos. - David
"Registramos todos los escaneos" ??? Horripilante. Descargaría el pitón y lo ejecutaría yo mismo. - Brad
@brad al menos te lo están diciendo. Estoy seguro de que si estuviera proporcionando un servicio de seguridad de whitehat que ofrecía este servicio, podría mantener un registro (aunque solo sea un contador sin detalles individuales) de cuántas personas ingresaron ciegamente los detalles de su sitio en un sitio web que decía que iba a funcionar. para intentar una prueba de penetración, sin saber mucho acerca de la autenticidad del sitio que ofrece la prueba ... y querrían saber quién probó en caso de que alguien usara su servicio para encontrar sitios vulnerables pertenecientes a otros, también ... - Rob Moir


escriba env x = '() {:;}; echo vulnerable 'bash -c "echo esto es una prueba" y si se vuelve vulnerable y esto es una prueba, significa que su máquina OSX / Linux está afectada. El remedio es actualizar a la última versión de bash.


-1
2017-09-27 11:33



¿Por qué como raíz? Completamente innecesario. - Mat