Shell-Shock y cómo parchearlo!

Hola, espero estén alertas con esta vulnerabilidad que se viene hablando desde el 24-09-2014.

Primero un poco de contexto, para que la gente que no sabe pueda entender. Bash es un utilitario cuya función consiste en interpretar órdenes. Está basado en la shell de Unix y es compatible con POSIX. Su nombre es un acrónimo de Bourne-Again Shell (otro shell bourne), haciendo un juego de palabras: born-again = renacimiento. Fue uno de los primeros intérpretes importantes de Unix. Listo, hasta acá la historia. A lo que vinimos:

Y ahora... cuál es el problema?

En muchos SO's las variables de entorno proporcionan una forma ágil de influir en el comportamiento de los programas instalados en este. Estas variables, por lo general, se componen de un nombre y un valor asignado. En la shell Bash se pueden ejecutar dichas variables por medio de funciones. En estos ambientes, es común que una gran cantidad de programas ejecuten shell Bash en background y a menudo, se utiliza para proporcionar acceso remoto a un usuario (a través de ssh, telnet, etcétera), proporcionar un analizador de secuencias de comandos CGI (Apache) o incluso apoyar la ejecución de comandos.

El día miércoles 24 de este mes, se anunció la vulnerabilidad y se publicó con el CVE-2014-7169 originalmente encontrada por el hacker francés Stephane Schazelas. Más tarde el experto en ciberseguridad Travis Ormandy lanzó un segundo exploit que funcionaba en sistemas ya parcheados, debido que los primeros parches eran incompletos. El Shell-Shock (como también le llaman) tiene una nota de gravedad 10, lo que significa que tiene un impacto máximo, y una calificación baja en complejidad de explotación, que significa que es relativamente fácil de utilizar por cibercriminales para lanzar ataques.

Podemos crear una función en el intérprete, exportarla e invocarla, por ejemplo:

$function prueba { echo "hola"; }
$ export –f prueba
$ bash
$ prueba
  hola

El problema radica en el mecanismo de exportación y cómo se interpreta el código que se inyecta en el entorno donde es exportada la función.

Para conseguir lo anterior, el bash recurre a un pequeño truco. No exporta la función como tal, sino que lo hace en una variable de entorno donde se interpreta su valor como el cuerpo de una función. Usando el ejemplo anterior, en vez de una función creemos una variable de entorno:

$ prueba = '() { echo "hola"; }'

Y exportamos la variable...

$ export prueba
$ bash
$ prueba
  hola

Cuando el entorno recibe esta variable y el interprete detecta la siguiente cadena "() {" entiende que está ante una función y comienza a interpretar su código. El problema (y esto es lo diabólico ja ja ja...), es que NO para de interpretar cuando termina el cuerpo de la función y continua ejecutando el código que viene detrás del cuerpo.

Un par de ejemplos:

1. DoS casero! Conocido como la fork-bomb, le pide a tu sistema ejecutar una gran cantidad de procesos hasta que el sistema se bloquea: '() {echo "hola";}; :(){:|:&};:'
2. Este comando puede formatear o eliminar todos los archivos contenidos en un dispositivo: '() {echo "hola";}; mkfs.ext3 /dev/sda'

La función debería de terminar justo cuando encuentre el "};" correspondiente pero inexplicablemente no lo hace, y peor aún, ejecuta directamente ese código anexado al cuerpo de la función.

Entonces, qué alcance tiene la vulnerabilidad?

Como resultado de esta vulnerabilidad muchos contextos están expuestos, por ejemplo:

• El ForceCommand es usado en configuraciones sshd, para proveer capacidades de ejecución de comandos a usuarios remotos. Este fallo puede ser usado para hacer bypass de comandos arbitrarios. Algunos deployments en Git o en Subversion pueden ser afectado por medio de estas inyecciones de código. 
• Los servidores Apache usan el mod_cgi o el mod_cgid, y estos pueden ser afectados con CGI scripts que sean escritos en bash.
• Otra falla se da mediante clientes DHCP, que en algunos casos ejecutan Bash scripts y utilizan variables de entorno suministradas por el servidor. Por ejemplo vean esta PoC para lograr Remote Code Execution (RCE).

OK... que hay del parche?

Debes comprender que va a arreglar sólo algunos de los aspectos de la vulnerabilidad y que al ser tan reciente, aún se desconocen los efectos secundarios del parche, además de las distintas opciones de ataques que podrían existir.

Puedes utilizar este >>>script<<< para prevenir y mitigar el impacto. En última instancia ya hay instrucciones para parchear el Bash.

Para acabar con el cuento, hay una serie de scripts para probar tanto la vulnerabilidad como el parche. Acá les dejo el post de la gente de RedHat al respecto.

Nos vemos y mucha suerte!