Cargando



Ataque ShellShock, Simple

Este tutorial muestra como realizar una prueba de concepto de ataque informático basado en la vulnerabilidad de Bash conocida como ShellShock, referida como CVE-2014-6271 y otras variantes


dic 06 2014 02:55
Profesional
jul 28 2016 18:18

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.

 

1.png

 

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.

 

Sistemas Involucrados
Host Víctima:
GNU/Linux con Bash 4.3
cliente DHCP isc-dhclient-4.2.4
IP 192.168.1.88 (mediante DHCP)

 

Host Atacante:
Windows XP
Servidor DHCP “tftp32” by Ph. Jounin
IP: 192.168.1.100

 

 

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”

 

3.png

 

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

 

4.png

 

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

 

5.png

 

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:

 

6.png

 

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...):

 

7.png

 

É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.

 

Consideraciones
Para esta guía se ha utilizado software común, sin variaciones sobre el sistema Víctima. Esta vulnerabilidad está presente en otros aplicativos que utilicen Bash para la ejecución de parámetros o scripts en el sistema.

 

Es imperioso aplicar las correspondientes actualizaciones al sistema para evitar este tipo de ataques.

 

Vale aclarar que el contenido aquí expuesto es útil tanto para comprender la mecánica del ataque como así también para concienciar respecto a este último punto. Tener en cuenta que este fallo ha estado presente durante al menos 20 años, por lo que es posible que haya sido aplicado mucho antes de ser difundido.


¿Te ayudó este Tutorial?


6 Comentarios

Me encanta lo bien explicado que has hecho con el hack Shellshock. Y como bien dices esto tiene mas tiempo de lo que piensa mucha gente.

Saludos.

Silvestre Figueroa
dic 08 2014 09:05
Muchas gracias Nestor. Pensar en la antigüedad de este BUG y lo simple que es de explotar realmente pone a pensar.....

David Sanz
dic 08 2014 19:10
Yo también lo conocía, no tan bien detallado como lo has hecho tu Silvestre. En seguridad te sigo. Eres muy bueno exlicando ataques. gracias por tus aportes.

Muchas gracias Nestor. Pensar en la antigüedad de este BUG y lo simple que es de explotar realmente pone a pensar.....


Gracias a ti Silvestre. Me ha venido genial para poder entenderlo bien con tu ejemplo, el Bug lo conocía pero ahora lo entiendo más. No es la primera vez que veo ataques sobre este tipo de Bug.

Cesar Ortiz
dic 09 2014 15:00

Ya te sigo todas las semanas.



Yo soy otro que le sigue, Silvestre es Crack en Seguridad IT.

Silvestre Figueroa
dic 10 2014 20:32
Gracias ! estoy armando otro que pronto subire.
Hay mucho en solvetic para aprender.
¡que buena comunidad!
No esperes más y entra en Solvetic
Deja tus comentarios y aprovecha las ventajas de la cuenta de usuario ¡Únete!

X