ShellShock FAQ – Como saber si tu servidor está afectado por ShellShock

0

Os presentamos la guía paso a paso definitiva para saber si vuestro servidor Linux está afectado por el temible ShellShock.

Shellshock ha supuesto un duro varapalo para la seguridad de millones de servidores basados en Linux, como hemos cubierto en noticias previas la pasada semana. A pesar de que proporcionamos alguna que otra pauta para detectar la vulnerabilidad y debido a que han aparecido otras variantes posteriormente, hemos decidido realizar una guía en profundidad basándonos en informaciones publicadas por RedHat, foros de soporte de distintas distribuciones y publicaciones espcializadas del sector.

Qué es Bash

Bash es la consola de comandos interactiva  por defecto en múltiples versiones de Linux. Cuando estamos interactuando con un terminal (ya sea desde un emulador de terminal o bien desde tty o ssh) estamos habitualmente enviando comandos que Bash leerá y ejecutará. Bash es algo que existe siempre en el sistema aunque no se utilice.

En sistemas Ubuntu, conviene no confundir Bash con Dash (/bin/sh), pues Dash no está afectado.

Versiones de Unix y Linux afectadas que debemos actualizar

  • Debian: todas, incluyendo versiones antiguas como Woody, Sarge, Lenny, Etch y Squeeze.
  • Ubuntu: todas.
  • Mac OS X: Lion, Mountain Lion y Mavericks.
  • RedHat en versiones:
    • Enterprise 4: corregido en paquete bash-3.0-27.el4.4
    • Enterprise 5: corregido en paquetes bash-3.2-33.el5_11.4, bash-3.2-33.el5_11.1.sjis.2, bash-3.2-24.el5_6.2 y bash-3.2-32.el5_9.3
    • Enterprise 6: corregido en paquetes bash-4.1.2-15.el6_5.2, bash-4.1.2-15.el6_5.1.sjis.2, bash-4.1.2-9.el6_2.2 y bash-4.1.2-15.el6_4.2
    • Enterprise 7: corregido en el paquete bash-4.2.45-5.el7_0.4

¿Por qué tanta alarma en torno a Bash?

Debido a la ubicuidad de esta herramienta. El Bash Shell lleva existiendo desde 1989 de forma predefinida, no solo en Mac OS X, sino en múltiples distribuciones de Linux. Linux, como sabréis, es la base de la mayor parte de servidores web a nivel mundial (en torno al 80% del total)

Bash controla servicios en segundo plano, como Telnet o SSH, entre otras muchas cosas. Apache también utiliza bash como intérprete de scripts CGI -Common Gateway Interface-. Tengamos en cuenta que Apache es la base, a su vez, del 60% de los servidores web mundiales. Podría, incluso, afectar a servidores de Microsoft, pero no sería de forma directa sino dependiendo de configuraciones específicas que incluyan negociación con servidores Unix/Linux.

Vulnerabilidades

ShellShock es el nombre común que ha recibido el gran fallo de seguridad encontrado en Bash, el intérprete de comandos más extendido en Unix y Linux. La primera vulnerabilidad detectada recibe el nombre de CVE-2014-7169 (detalles en el enlace). Dicha vulnerabilidad ya ha recibido actualización correctiva por parte de las distintas distribuciones de Linux/Unix.

Posteriormente, han ido apareciendo nuevos boletines de vulnerabilidad: CVE-2014-6271 y finalmente CVE-2014-6271. Existe malware que ya está aprovechando acceso a estos fallos de seguridad en Bash. La última de las vulenrabilidades podría provocar que, en ciertos servicios y aplicaciones, se termine cediendo permisos a un atacante para utilizar variables de entorno a través de las que explotar el fallo.

Soy usuario de Windows ¿estoy seguro?

En general, sí. Por el momento no tenemos conocimiento de un vector de ataque directo sobre sistemas Windows. Técnicamente, aunque es posible instalar Bash en Windows, requeriría un conjunto específico de ajustes y aplicaciones (normalmente WAMP o Cygwin) para crear la situación que permita un vector de ataque para esta vulnerabilidad de Bash.

Pasos para determinar si estamos afectados por ShellShock

  1. Los usuarios de RedHat en cualquiera de sus variantes pueden utilizar un script expresamente diseñado para realizar esta comprobación. Para ello deberéis antes iniciar sesión con vuestra cuenta RedHat.
  2. La segunda opción consiste en ejecutar una serie de comandos de forma manual. Los comandos están en colornaranja y la salida producida aparece en cursiva.
    • Empezaremos introduciendo la siguiente línea:

$ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”

    • Si en el resultado del comando anterior existe una linea que contiene únicamente la palabra vulnerable, es porque estamos utilizando una versión vulnerable de Bash. Esto es así porque el último parche lanzado se encarga de impedir que cualquier código sea permitido al final de una función Bash. Hay que tener en cuenta que las diferentes versiones de Bash producirán resultados diferentes al ejecutar el comando anterior. Una versión de Bash que no haya sido actualizada en absoluto (no contiene ningun parche correctivo) producirá la siguiente salida:

$ 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

    • Las versiones que solo están afectadas por la CVE-2014-6271 original producirán la siguiente respuesta:

$ 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

$ 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

Comandos de comprobación de estado para Bash

La diferencia en la salida producida se debe a cambios adicionales en el procesamiento de funciones.

    • El parche para CVE-2014-7169 se asegura de de que el sistema está protegido de este fallo al crear el fichero. Para comprobar si vuestra versión de Bash es vulnerable al CVE-2014-7169, utilizad el comando siguiente:

$ 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’
Mon Sep 29 10:01:46 GMT 2014

    • Si el sistema es vulnerable, la información con fecha y hora actuales aparecerá en pantalla al final de la orden, mientras se crea un fichero en /tmp/echo.
    • Si el sistema no es vulnerable, veréis algo como esto:

$ 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

Actualizar Bash manualmente

Si vuestro sistema ha resultado vulnerable en alguna de las pruebas anteriores, podéis reparar estas vulnerabilidades actualizando a la versión más reciente del paquete Bash mediante la siguiente orden:

Mac OS X

  • Ejecutad una búsqueda de actualizaciones de seguridad:

RedHat:

# yum update bash

Ubuntu:

sudo apt-get update && sudo apt-get install bash

El primer comando en Ubuntu se asegura de que tenemos el último “listado de paquetes” que incluye la versión corregida, mientras que el segundo comando instala dicha versión de Bash en el sistema.

Debian

Mismo procedimiento que en Ubuntu, con la salvedad de que sistemas operativos antiguos como Squeeze o Etch, entre otros,  requieren algún paso adicional:

  • Añadir repositorios de Squeeze-LTS (por ejemplo) en nuestro archivo sources.list. Para ello editaremos edit /etc/apt/sources.list y añadiremos la línea inferior al final del fichero:

deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib

*Script unificado para versiones legacy en Debian

NOTA: En todos los casos es muy recomendable reiniciar el equipo tras la actualización. Para más información podéis visitar este hilo.

Solución global

DeShellShock

Se trata de un script global que sirve para actualizar diferentes sistemas de los anteriormente comentados. Comprobad las versiones soportadas en su página web. Tened en cuenta que aún está en fase de pruebas, así que podría no ser 100% estable.

* Para versiones muy antiguas de Debian como woody (3.0), sarge (3.1), etch (4.0) y lenny (5.0)

Compartir.

Sobre el Autor

Alejandro es técnico micro-informático, experto en seguridad de las TIC y apasionado de la tecnología. Colabora habitualmente en diferentes publicaciones de seguridad, software y análisis de hardware entusiasta.

Dejar una Respuesta

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR