¡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 Information Disclosure. 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!
Estas vulnerabilidades las verás a cascoporro en entornos reales. Es muy común no prestarles atención ya que por lo general el impacto que tienen es muy limitado. No obstante, al combinarlas con CVEs conocidos o exploits públicos, sus consecuencias pueden ser devastadoras. Por ello, nunca le demos a los atacantes más pistas de las necesarias sobre las tecnologías y servicios que utilizamos para construir nuestros aplicativos web.
Lab1 (Apprentice) – Information disclosure in error messages
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, obtain and submit the version number of this framework.». En este laboratorio, lo que tenemos que hacer es identificar la versión del framework utilizada.
De manera muy sencilla, podemos resolver este laboratorio. Al ser la superficie de exposición muy limitada, podemos intentar enumerar un producto cualquiera. Como vemos, el parámetro «productId» recibe un valor numérico. Sin embargo, si le damos un valor aleatorio como una comilla simple, el servidor nos devuelve la traza de error completa, divulgando información del framework utilizado.
Como vemos, por tanto, la solución al laboratorio es la siguiente:
Apache Struts 2 2.3.31Lab2 (Apprentice) – Information disclosure on debug page
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, obtain and submit the SECRET_KEY environment variable.». En este laboratorio, lo que tenemos que hacer es identificar el archivo de debugging y, en él, el valor de la variable de entorno «SECRET_KEY».
Lo que haremos en este caso será, primero de todo, lanzar una petición a la raíz del sitio web e intentar extraer comentarios de la respuesta, usando para ello una extensión de Burp Suite Professional. Esta extensión es «Response Pattern Matcher», que puedes descargar de la BApp Store. Una vez descargada, loggeará ciertos patrones en las respuestas que pasan por el proxy, entre ellos comentarios HTML. Se recomienda configurar esta extensión de manera personalizada, loggeando aquello que quieras y eliminando todo lo que consideres «ruido». Es bastante intuitiva, eso sí.
Como vemos, descubrimos la ruta «/cgi-bin/phpinfo.php». Sin más que acceder a ella, enumeramos el valor de la variable de entorno pedida:
Lab3 (Apprentice) – Source code disclosure via backup files
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, identify and submit the database password, which is hard-coded in the leaked source code.». En este laboratorio, lo que tenemos que hacer es identificar un archivo de código fuente filtrado (a la vista del nombre del laboratorio, en un fichero de backup).
Comenzaremos en este caso por realizar enumeración típica de aplicaciones web, listando el fichero «robots.txt». Como vemos, nos divulga la existencia de un directorio o fichero denominado «backup»:
Accediendo a la ruta, vemos que se trata de un directorio que, además, tiene «Directory Listing», por lo que podemos observar todos los ficheros en dicha ruta:
Simplemente accediendo al fichero veremos el código fuente, dado que es un fichero «.bak» y no se interpreta. En dicho código fuente, a su vez, localizamos la contraseña pedida:
Lab4 (Apprentice) – Authentication bypass via information disclosure
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, obtain the header name then use it to bypass the lab’s authentication. Access the admin interface and delete the user carlos.». En este laboratorio, tenemos que obtener el nombre de una cabecera interna para posteriormente poder acceder al panel de administración de la web y borrar el usuario «carlos».
Empezamos, de nuevo, enumerando la aplicación con el usuario proporcionado «wiener:peter» y vemos cómo el panel de administración se encuentra en la ruta «/admin», pero no podemos acceder a él debido a que nos indica que el acceso es solo para usuarios locales. Esto, en aplicaciones en producción, también suele verse y a veces el mecanismo de defensa es el mismo que en este laboratorio: recoger el valor de una cabecera cuyo valor debe ser 127.0.0.1 o similar.
Para evaluar el comportamiento de la aplicación y sus cabeceras, si el método TRACE está habilitado, nos proporcionará un «echo» de la petición. Sin embargo, si hay sistemas intermedios que incluyen sus propias cabeceras, estas serán también visibles en las respuestas. En este caso, enviamos un TRACE con Burp Suite Professional y vemos cómo efectivamente, aparece una cabecera no incluida por nosotros:
Tal como vemos, la cabecera «X-Custom-IP-Authorization» fue añadida por el sistema intermedio y no incluida por nosotros. Esta cabecera parece ser la utilizada para controlar el acceso al panel de administración. Para hacer bypass de este check, lo que haremos será incluir el valor de la cabecera como «127.0.0.1» desde nuestro lado, con el objetivo de intentar hacer ver a la aplicación que somos usuarios locales. Intentamos acceder al panel de administración pero interceptamos la petición, añadiendo dicha cabecera:
¡¡Boom!! Vemos el panel de administración. Ahora, simplemente, nos quedará borrar el usuario de «carlos». Pero, cuidado, si no incluyes la cabecera de nuevo, el borrado debería de fallar al intentar acceder a funciones administrativas desde fuera. Realizamos la petición, por tanto, con la cabecera:
Y una vez recibida por el servidor… La procesará, borrará el usuario de «carlos» y habremos resuelto el laboratorio.
Lab5 (Practicioner) – Information disclosure in version control history
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: «Information disclosure in version control history». En este laboratorio, tenemos que acceder al versionado «.git» del proyecto web y obtener acceso como administrador a la plataforma para borrar el usuario «carlos».
El acceso a sistemas de control de versiones «.git» o «.svn» debemos probarlo siempre. En caso de obtener acceso, es posible que podamos exfiltrar muchísima información, incluyendo el código fuente al completo o fragmentos, la estructura de la web… En definitiva, siempre es algo a intentar en auditorías. En este laboratorio, como vemos, existe el directorio «.git».
Ahora, debemos obtener el contenido del directorio «.git» al completo. En este caso, al tener Directory Listing lo hace más sencillo. En otras ocasiones, no tenemos este Directory Listing, pero podremos intentar extraer los ficheros en base a otros ficheros conocidos y su información. ¿Debemos hacer todo esto a mano? Pues, lógicamente, no. Existen varias herramientas, aunque nosotros siempre solemos usar estas dos por comodidad (a veces funciona mejor una, a veces otra…):
Vamos a extraer el contenido del directorio «.git» del laboratorio con «git-dumper» en este caso:
Una vez lanzada la herramienta, vemos que tenemos el repositorio (al menos, lo que ha podido descargar) y además se hace un «checkout» para obtener el código fuente:
Los archivos obtenidos, sin embargo, no nos proporcionan la contraseña del panel de administración, tal como vemos:
Enumeramos ahora los commits, ya que si recordamos estamos en un repositorio «.git». Como vemos, tenemos dos commits y uno de ellos nos da pistas de que el desarrollador dejó la contraseña en su momento hardcodeada. Hacemos un diferencial (diff) entre los dos commits y descubrimos el cambio y, por tanto, la contraseña:
Finalmente, para resolver el laboratorio accedemos con el usuario «administrator» y la contraseña obtenida y borramos el usuario «carlos».
Este laboratorio es muy interesante y resulta muy útil manejarse con sistemas de control de versiones como GIT o SVN. Este tipo de vulnerabilidades de exfiltración de código fuente son mucho más comunes de lo que se podría pensar.
~km0xu95