Ataque ShellShock, Simple

Recientemente se ha reportado una familia de vulnerabilidades relacionadas a un BUG de Bash, el intérprete más común en GNU/Linux, MAC OS y algunos Unix, y ha sido denominada ShellShock o Bashdoor (CVE-2014-6271). El asunto más importante y alarmante al respecto, tiene que ver con que dicho BUG ha estado presente en Bash durante los últimos 20 años, por lo que se estima que la gravedad del asunto es incluso mayor a Heartbleed.

 

El Bash BUG o ShellShock no es en si mismo un código malicioso (como si lo son los virus informáticos, spywares, malwares,etc.) por lo que no puede ser detectado y bloqueado mediante sistemas antivirus o similares, sino que debe ser corregido en la implementación misma del software que lo “padece”.

 

Se recomienda aplicar este tutorial en ambientes controlados, con fines relativos a la investigación y estudio de la informática, tal como se expone aquí mismo.

 

¿En qué consiste el Bash BUG ShellShock?

Básicamente el problema radica en la posibilidad que tiene Bash de almacenar en variables de entorno definición de funciones de scripting, más precisamente en cómo son éstas funciones cargadas por Bash.

 

El BUG se manifiesta cuando en una variable de entorno, a continuación de la definición de función, se añade código adicional que Bash seguirá parseando y ejecutando tras cargar la función.

 

Con el siguiente comando, se ha cargado en la variable “x” una definición de función vacía, código arbitrario y luego se ha llamado a Bash.

 

 

Lo que sucede es que antes de llamar a Bash, se ha cargado la variable de entorno y se ha ejecutado el código inyectado que simplemente muestra la cadena “vulnerable” en la consola (podría haber sido peor claro!). Luego Bash ha sido ejecutado y se ha llamado al comando echo a modo de ejemplo. Una variante más sencilla del comando para realizar el test:

$ env x='() { :;}; echo vulnerable' bash

Éste último comando, mostrará en la pantalla la cadena “vulnerable” si la versión de Bash tiene el BUG o bien no se mostrará nada si se trata de una versión parchada.

 

Como se indica en la introducción, este BUG determina una familia de vulnerabilidades que pudieran ser utilizadas por un atacante para controlar equipos remotamente. Dentro de estas variantes, hay algunas un poco más complejas, otras muy simples y algunas más o menos complejas. Existen variantes relacionadas con Apache y los módulos de CGI, otras para el cliente de DHCP, y algunas un poco más rebuscadas que otras.

 

Para esta guía se utilizará uno de los casos más simples, ataque shellShock al cliente DHCP de GNU/Linux.

 

 

 

Para la prueba de concepto, suponemos una LAN en la que se encuentran conectado tanto la Víctima como el Atacante.
Dado que el software cliente DHCP es ejecutado con permisos de administración, el Atacante intentará incluir en la configuración DHCP asignada a la víctima, código malicioso en algún parámetro de opción DHCP.

 

 

Procedimiento

 

1) El atacante ejecuta el software de servicio DHCP {Para esta guía se utilizó (ftp32” by Ph. Jounin)}

 

1.1) Seleccionar la interfaz de red a utilizar y presionar el boton “Settings”

 

 

1.2) Configurar las opciones para solamente se ejecute el servicio DHCP.

 

 

1.3) Ir a la pestaña "DHCP" y configurar de la siguiente manera:

 

 

1.4) Nótese el campo “Addiotional Option” se ha especificado la opción 114 (utilizada en VOIP) y en el campo de detalle de opción se ha introducido la definición de función de Bash y el código malicioso:

() { ignored;}; echo ‘CODIGO INYECTADO’; /bin/cat /etc/passwd

1.5) Presionar "OK", el servicio DHCP está listo.

 

2) En la terminal del sistema de la víctima, ejecutar el siguiente comando para dejar “a la vista” el Syslog del sistema para cuando ejecutemos la solicitud DHCP:

# tail -f /var/log/syslog &

3) Suponiendo que eth1 es la interfáz de red de la víctima, ejecutar el cliente DHCP:

# dhclient eth1

4) El comando realizará la solicitud DHCP y el Atacante la correspondiente asignación:

 

 

5) En la terminal de la víctima, gracias al comando tail que quedó en background mostrando el Syslog del sistema, se visualizará la ejecución del código inyectado, en este caso, se motrará la cadena “CODIGO INYECTADO” y luego se listará el contenido del fichero /etc/passwd de la víctima (podría haber sido mucho peor...):

 

 

Ésta última parte, es gracias al comando “/bin/cat /etc/passwd” que es parte del string especificado como opción 114.

 

El atacante podría haber ejecutado otros comandos y realizar cualquier acción dado que cuenta con permisos de “root” dado que el cliente DHCP de la Víctima se ejecuta con dichos privilegios.