Hoy le toca a Inyección de comandos SO. Esta vulnerabilidad permite que podamos ejecutar comandos del sistema operativo y, normalmente, comprometer toda la aplicación y su información. Esta vulnerabilidad entra dentro del mismo grupo que la de inyección de SQL que explique en el post anterior.
Voy a explotar el lab basico de inyección de comandos de PortSwigger para poder explicar esta vulnerabilidad. Para poder detectar esta vulnerabilidad vamos a mirar las solicitudes que hace el navegador a servidor utilizando burp suite o ZAP (si no tienen configurado burp o zap y no saben como usarlo avisenme, los puedo ayudar). Por ejemplo, en este caso tenemos una tienda donde podemos mirar el stock de cada sucursal.
![]() |
Tienda Lab Burp |
En la siguiente imagen podemos ver lo que responde la pagina si le damos a Check stock.
![]() |
Entrada de usuario |
Vamos a ir a burp activar el intercept y volver a la pagina a darle a check stock para que nos aparezca esto en burp:
Una vez que tenemos la solicitud interceptada le vamos a dar click secundario y la vamos a mandar al repetidor. Vamos a ver algo así:
![]() |
Repetidor de Burp |
Acá lo que vamos a hacer es agregar en la parte que dice productId=18&storeId=1 el siguiente carácter | que en este caso es el que divide los comandos(Hay más caracteres para hacer esto, depende de cada sistema.) y vamos a poner whoami por lo que nos va a quedar algo asi:
![]() |
productId=1&storeId=1|whoami |
Este comando nos devuelve el usuario que está usando el sistema para hacer las solicitudes, peter-I9nDLS. Ahora sabemos que tenemos acceso a una consola, podemos por ejemplo mirar la carpeta /etc/passwd:
Perfecto, es vulnerable a inyección pero ¿Qué más podemos hacer con eso? Bueno, podríamos tratar de sacar un reverse shell con netcat para tener total acceso al servidor y usarlo como vector de ataque para todos los servicios afectados por ese servidor. Para poder ejecutar una shell remota lo que vamos a hacer es en el servidor que estamos atacando transmitir a la IP con la que estamos atacando en un puerto específico la entrada de la consola y todos los mensajes de salida. Acá pueden encontrar los scripts más fáciles para hacer una reverse shell.
Esta vulnerabilidad se suele dar porque cuando programan este tipo de cosas suelen poner en el codigo algo asi como exec() que ejecuta todo lo que está dentro de los paréntesis sin verificar, en este caso probablemente ejecutaban una búsqueda del stock del local que estaba en algún archivo y probablemente corría algún comando como cat cantidad, es una práctica muy común y que no sanitiza de ninguna manera la entrada del usuario.
Lo que les mostré anteriormente es lo que van a mostrar cuando tengan que hacer una prueba de concepto de una vulnerabilidad así ya que normalmente no vamos a tener autorización para explotar y modificar un servidor como se nos dé la gana, ya que podríamos generar algún perjuicio a nuestro cliente y esa no es nuestra intención.
Espero que este post les haya servido para entender un poco de qué trata la inyección de comandos SO. Cualquier duda que tengan me pueden hablar por mis redes sociales o postearlas en reddit para que los ayude la comunidad!