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


80

¿Cómo puedo asegurarme de que mi instalación de Bash ya no sea vulnerable al error ShellShock después de las actualizaciones?



Tenga en cuenta que hay otras dos vulnerabilidades en bash aún sin parchear (CVE-2014-7186 y CVE-2014-7187).
Deer Hunter

Los parches que arreglan CVE-2014-7186 y CVE-2014-7187 están disponibles desde poco después de que Deer Hunter publicó su comentario. Si tiene un parche proporcionado por la distribución para CVE-2014-7169, es posible que ya tenga suficiente para bloquear 7186/7187, pruebe su sistema con los comandos a continuación y vea. Compruebe también si hay más actualizaciones de seguridad para su distribución.
BeowulfNode42

Respuestas:


83

Para verificar la vulnerabilidad CVE-2014-6271

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

NO debe hacer eco de la palabra vulnerable.


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

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

debería decir la palabra fecha y luego quejarse con un mensaje como cat: echo: No such file or directory. Si, en cambio, le dice cuál es la fecha y hora actual, entonces su sistema es vulnerable.


Para verificar si 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 debería devolver el texto CVE-2014-7186 vulnerable, redir_stack.


Para comprobar si 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 debería devolver el texto CVE-2014-7187 vulnerable, word_lineno.


Para verificar CVE-2014-6277. No estoy 100% seguro de esto, ya que parece depender de un sistema parcialmente parcheado 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 aprobado en este caso es que SÓLO repite el texto testing CVE-2014-6277. Si 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 verificar CVE-2014-6278. De nuevo, no estoy 100% seguro de si esta prueba ya que ya no tengo ningún sistema sin parchear.

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

Un paso para esta prueba es que SOLO debería hacer eco del texto testing CVE-2014-6278. Si el tuyo hace eco en hi momcualquier lugar, eso definitivamente es un fracaso.


1
¿Podemos agregar la prueba general foo='() { echo not patched; }' bash -c fooa esto? Hasta que las exportaciones de funciones se coloquen en un espacio de nombres separado, no dejaremos de correr 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 en algunos próximos Shellshock CVE ( lcamtuf.blogspot.com/2014/09/… ). Es su prueba sugerida para CVE-2014-6278, que aún no es pública. Sin embargo, parece que estaba equivocado acerca de la generalidad de la prueba; Ya encontré 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 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 lo usa (es decir, todas las cuentas utilizadas por demonios, como "www" o "cups" o lo que sea) están configuradas con BASH como su shell predeterminado, y ninguna de las sus códigos llaman sistema () o similar, tener la versión vulnerable puede ser menos arriesgado, pero aún así, actualice BASH lo antes posible.
DTK

32

Exporte una variable de entorno especialmente diseñada que las versiones vulnerables de Bash evaluarán automáticamente:

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

Ahora ejecute un eco simple para ver si Bash evaluará el código en $ testbug aunque no haya utilizado esa variable usted mismo:

$ bash -c "echo Hello"
VULNERABLE
Hello

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

Tenga en cuenta que las principales distribuciones de Linux han lanzado varios parches y, a veces, no corrigen la vulnerabilidad por completo. Siga revisando los avisos de seguridad y la entrada CVE para este error.


55
Además de CVE-2014-6271, la solución incompleta de Red Hat en particular tiene la suya que también vale la pena seguir: CVE-2014-7169 .
DocMax

3
One-liner que no contamina su entorno de shell y funciona incluso si está utilizando un shell de inicio de sesión alternativo (que puede no saber export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki

1
Aquí hay algunos detalles específicos de Ubuntu askubuntu.com/questions/528101/… - personalmente tuve que actualizar de Ubuntu 13.10 a 14.04 para solucionar el problema
dodgy_coder

2

ShellShock es prácticamente una conjunción de más de una vulnerabilidad de bash , y en este momento también hay malware que explota esta vulnerabilidad , por lo que ShellShock puede ser un problema que todavía está abierto, hay un hilo con actualizaciones de RedHat sobre estos problemas .

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 solución.

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-6271arreglo

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 la comprobación de ShellShock es la comprobación de vulnerabilidad CVE-2014-7169 que 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á resultados similares 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

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

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 retirada, lo siento: '(


Su enlace está muerto
SSK

@SSK Lo siento;) Mistype.
Liam Marshall

Tu enlace aún está muerto.
Mxx

Sí, lo siento, lo quité. Estaba siendo explotado en formas que no me gustaban.
Liam Marshall

1

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

http://shellshock.iecra.org


44
Es cortés dar razones para los votos negativos.
David

44
"Registramos todos los escaneos" ??? Siniestro. Descargaría el pitón y lo ejecutaría yo mismo.
Brad

1
@brad al menos te lo están diciendo. Estoy seguro de que si proporcionara un servicio de seguridad de sombrero blanco que ofreciera este servicio, podría mantener un registro (aunque solo fuera 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 intentar una prueba de penetración, sin saber mucho sobre la autenticidad del sitio que ofrece la prueba ... y querrían un registro de quién probó qué, en caso de que alguien use su servicio para encontrar sitios vulnerables que también pertenecen a otros ...
Rob Moir

-1

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


66
¿Por qué como root? Completamente innecesario.
Mat
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.