Ayer se anunció una vulnerabilidad en GNU Bourne Again Shell (Bash) (CVE-2014-7169) originalmente encontrada por el francés Stephane Schazelas. La vulnerabilidad permite la ejecución de código arbitrario en Bash al establecer variables de entorno específicos. Más tarde Travis Ormandy lanzó un segundo exploit que funcionaba en sistemas parcheados porque los parches lanzados ayer eran incompletos.

Tod Beardsley, administrador de ingeniería en la firma de ciberseguridad Rapid7, advirtió de que el error tenía una nota de gravedad “10”, lo que significa que tiene un impacto máximo, y una calificación “baja” en complejidad de explotación, lo que significa que es relativamente fácil de utilizar por piratas informáticos para lanzar ataques.

“Al usar esta vulnerabilidad, los atacantes potencialmente pueden tomar el control del sistema operativo, acceder a información confidencial, hacer cambios, etc. Cualquiera con sistemas que ocupen Bash deben aplicar el parche inmediatamente”, dijo Beardsley.

¿Cúal el problema?

Como menciona David Garcia en Hispasec, al crear crear una función en el intérprete, exportarla e invocarla:

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

El problema está en el mecanismo que hace de exportación de esa función, la forma en la que lo hace y como interpreta el código que se inyecta en el entorno donde es exportada.

Para conseguir esa exportación de funciones bash recurre a un pequeño “truco”. No exporta la función en sí, sino en una variable de entorno donde se interpreta su valor como el cuerpo de una función. Vamos a verlo modificando el ejemplo anterior, en vez de una función vamos a crear una variable de entorno:

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

Exportamos, no una función sino una variable que es lo que haría el intérprete:

$ export test
$ bash
$ test
  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 aquí entramos en la zona peligrosa, 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.

Por ejemplo, si el intérprete tiene la siguiente variable-función exportada con código más allá de la definición de la función:

'(){ echo "hola"; }; /bin/ls'

Terminará ejecutando el ‘/bin/ls’ cuando se esté interpretando esa cadena. No hará falta invocar la función, justo cuando el interprete procese las cadenas detrás del cuerpo de la función ejecutará el comando. Idealmente, debería de terminar justo cuando encuentre el ‘};’ correspondiente pero inexplicablemente no lo hace y peor aun ejecuta directamente ese código anexado al cuerpo de la función.

El ejemplo que se propagó es la mínima expresión de definición de una función en bash “() { :;};”

El bloque de la función definida contiene el carácter “:” que en bash no hace nada, simplemente devolver cero (su correspondiente en C sería un “return 0;”). A esa cadena por supuesto se le puede adosar cualquier comando, desde un echo “yo estuve aquí” hasta un devastador “rm –Rf” o un“curl****/mi_shell.php” para depositarla en “/var/www/”.

Muchas formas de atacar

En las pocas horas que lleva In-the-Wild, ya han aparecido exploit y PoC para lograr (RCE) Remote Code Execution (RCE), ataques web que permiten subir código y shell a sitios web, y troyanos que permiten realizar ataques de DDoS, BruteForce sobre usuarios y contraseñas de la red y robo de información a distintas direcciones IP que han ido cambiando durante el día e incluso ya se han vistogusanos explotando la vulnerabilidad. Basicamente estamos hablando de un troyano ELF que permiteDDoS, Flooder, Scanner, Bot-Backdoor y Login bruter, R00ter.

En esta imagen se puede ver la lista de contraseñas que intenta el troyano:

Otro de los troyanos bautizados como ELF_BASHLITE, ELF Linux/Bash0day o Shellshock o Bashroot ha sido analizado por TrendMicro.

¿Cuál es el impacto de la vulnerabilidad?

Al principio, la vulnerabilidad no parece tan grave pero la realidad es que se puede ejecutarse código remoto simplemente establecimiento de una variable de entorno y sin que el usuario se percate de la situación.

El escenario más problemático parece ser cuando un Bash Scripts es ejecutado mediante cgi-bin. La especificación CGI requiere que el servidor web convierta la solicitud de los headers HTTPsuministrados por el cliente y las transforme en variables de entorno.

Entonces, se puede aprovechar que Apache “transforma” las cabeceras en variables de entorno: por ejemplo el User-Agent se introducirá como valor de la variable de entorno HTTP_USER_AGENT de Apache. Si un script Bash se llama vía cgi-bin, un atacante puede utilizar estas variables para ejecutar código que el servidor web.

Otros escenarios probables involucran SSH al momento de establecer variables de entorno, pero tendrían que establecerse en el servidor en un archivo de configuración. Otra alternativa es medianteclientes DHCP que en algunos casos ejecutan scripts Bash y utilizan variables de entorno suministradas por el servidor.

Esta PoC de TrustSec muestra como se puede insertar código en la opción 114 (default-url) del servidor DHCP para explotar la vulnerabilidad. Este caso puede ser explotable si el usuario se conecta a un servidor DHCP no confiable (“cofeehouse wifi”).

En las últimas horas ya se han producido ataques basados en la vulnerabilidad a routers de particulares y controladores utilizados en la gestión de instalaciones de infraestructuras críticas, haciendo barridos aleatorios en Internet en busca de equipos con la vulnerabilidad para tomar el control de los mismos y lanzar ataques de DoS.

¿Debo aplicar el parche?

Sí pero el parche va a arreglar sólo algunos de los aspectos de la vulnerabilidad y no soluciona totalmente la vulnerabilidad. Aún se desconocen los efectos secundarios del parche y de las distintas opciones de ataques que podrían existir.

La mayoría de distribuciones Linux ya han distribuido un primer parche, aunque está incompleto y no acaba de corregir del todo la vulnerabilidad.

Por su parte los usuarios de Apple estan expuestos ya que los de Cupertino no han dado ninguna respuesta aunque estos sistemas suelen estar menos expuestos a Internet, y en última instancia ya hayinstrucciones para parchear su instalación.

Mientras se esperan las actualizaciones definitivas se puede utilizar este script para prevenir y mitigar el impacto.

¿Cuáles son mis otras opciones? ¿Qué debo hacer?

Puesto que el parche es incompleto, se debería intentar implementar medidas adicionales para proteger los sistemas. Algunos vendedores de sistema de detección de intrusiones (IDS) y Firewall de aplicaciones Web (WAF) han publicado las reglas para bloquear la explotación pero las reglas aún podrían estar incompletas porque sólo buscan la cadena “() {“ que estaba presente en la prueba inicial.

Una alternativa sería cambiar la shell por defecto para una alternativa como ksh o sh pero esto podría generar errores en algunas secuencias de comandos determinadas.

En sistemas embebidos se podría utiliza la shell alternativa como Busybox que no es vulnerable.

¿Cómo puedo encontrar sistemas vulnerables?

Si puede iniciar sesión en el sistema y se puede utilizar algunas de las cadenas de test publicadas, como la siguiente:

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

Si ya se ha aplicado el parche, se puede utilizar este comando:

env X='() { (a)=>\' sh -c "echo date";

Este comando devolverá un error en un sistema totalmente parcheado, pero creará un archivo vacío denominado “echo”.

Existen varios módulos para escáneres de vulnerabilidad que buscan sistemas vulnerables. También se puede utilizar una búsqueda en Google para encontrar servidores web vulnerables. Por ejemplo:filetype:sh inurl:cgi-bin site:[su_dominio].

Además se debe controlar los servidores web en sistemas embebidos como routers para que no pueden ejecutar secuencias de comandos bash con privilegios elevados.

Más información

Distintos medios se han hecho eco de la noticia publicando distinto tipo de información e ISC hapublicado un video al respecto y slides PDF con más información. Redhat por su parte mantiene la información permanentemente actualizada.

Además, se puede utilizar esta herramienta y esta otra para revisar los servidores propios.

FUENTE: Cristian de la Redacción de Segu-Info