¡Hola a todos! Ya que este es mi primer post en Security Garage, me presento. Soy Juan Francisco Flores y trabajo como mánager  de proyectos en el área de Estrategia de Entelgy Innotec Security. Tenía ya ganas de estrenarme aquí para hablaros de un tema que considero realmente interesante, pero que es un tanto desconocido y del que es difícil encontrar documentación. Se trata de Burp Collaborator, una funcionalidad de BurpSuite.

¿Qué es Burp Collaborator?

Burp Collaborator nos acompaña desde la versión 1.6.15 y, a simple vista, parecía un ítem más que aparecía en los escaneos, tanto activos como pasivos, que realizaba la herramienta. Sin embargo, la información al respecto no terminaba de dejar claro de qué se trataba o cuál era la prueba de concepto utilizada.

En esencia, se trata de un componente ajeno al activo que se está testeando, y al que se puede apuntar durante las pruebas que se realizan durante una revisión de seguridad y recuperar en la comodidad de nuestra consola de Burp aquellas peticiones o pruebas de concepto que hayan funcionado en el activo testeado y hayan llegado al Burp Collaborator.

Su uso puede ser de gran utilidad, principalmente, por las siguientes razones:

• En un entorno de red complejo donde no contamos ni con privilegios ni con acceso a firewalls donde configurar puertos, redirecciones o ni tan siquiera montar un servidor web, nos evita el tener que realizar todos estos cambios en infraestructura para realizar una prueba de concepto.

• Permite verificar que el servidor no solo responde a la IP del origen de la prueba, sino que es factible hacer que el activo revisado envíe información a otra IP destino, o determinar si solo es posible que dichas peticiones viajen a un servidor diferente (ataques fuera de banda).

¿Cómo puedo controlar e interaccionar con esta herramienta de Burp?

Hasta ahora, la teoría ha estado bien, pero es mejor saber cómo podemos controlar hacía qué Collaborator se están apuntando las pruebas y, de esta forma, controlar los payloads de las diferentes pruebas que se realicen. Para ello, os vamos a presentar una prueba de concepto muy sencilla con una redirección abierta (ya sabemos que esto se puede hacer hacia nuestro amigo Google, pero lo que nos interesa es demostrar el control sobre el Collaborator y las peticiones que se realicen):

1. El primer paso será “generar” el Collaborator. Tan solo tenemos que seleccionar ‘Burp Collaborator client’ en la pestaña de Burp.

Entonces, nos aparece una pantalla como la siguiente:

Al seleccionar “Copy to clipboard” tendremos en nuestro portapapeles el Collaborator que podemos usar para nuestras pruebas de concepto, las cuales tendrán un formato parecido a este: k7svo6w7zufobodjvm1sflobd2js7h.burpcollaborator.net

Una vez tenemos identificado el Collaborator, ¿cómo podemos saber que este realmente funciona? Para responder a esta pregunta, podemos hacer una sencilla prueba donde se haga una resolución DNS, que nos aparecerá dentro de la pantalla de interacciones con el Collaborator (ping, nslookup, etc).

Aquí vemos cómo la prueba de resolución DNS está llegando al Collaborator.

2. En el siguiente paso, con nuestro Collaborator identificado, vamos a incluir la herramienta en nuestra prueba de concepto. Como hemos comentado, se va a añadir en una redirección no controlada, en este caso sobre la web de pruebas Xtreme Vulnerable Web Application, con el objetivo de ver cómo se identifica la prueba en la pantalla del cliente y óomo se puede controlar la misma.

Como se puede apreciar en la imagen, la URL contiene un parámetro con el valor de la redirección que, al no estar controlado, se puede modificar por el valor que se desee, en nuestro caso, nuestro Collaborator.

Además de poder identificar desde qué IP y que tipo de peticiones se están realizando, el Collaborator responde con un token que permite identificar si el tráfico de la prueba de concepto ha ido desde nuestro Burp al activo revisado, al Collaborator donde se ha obtenido la información que se devuelve a nuestro Burp después de volver por el activo.

Además, también es posible customizar el directorio al que queremos que apunte.

Como se ha comentado, para una prueba de concepto de una redirección no controlada no es necesario disponer de esta herramienta, aunque sí nos puede ser útil para detectar la interacción de otros payloads con vulnerabilidades más jugosas: pruebas para la carga de recursos externos, apuntar la ejecución de un XXE para detectar si la máquina tiene salida directa a Internet, XXS en un panel de administración donde no se tiene acceso (Burp Collaborator permite pruebas asíncronas, por lo que puede detectarse a posteriori de haber realizado la prueba), etc.

Pero, ¿no hay una forma algo más rápida de poder hacer uso de este módulo de Burp?

Precisamente, recientemente descubrí que existe una extensión de Burp llamada “Handy Collaborator” que facilita la creación, inserción y verificación del uso de los Collaborators de Burp.

Una vez que se ha generado el Collaborator para la prueba, esta extensión hace un refresco sobre la consola del mismo de manera automática y genera un issue en la pestaña de Target de Burp con el evento, ahorrándonos bastante tiempo.

Y, tras esto, me despido de vosotros. Espero que os haya resultado de utilidad la lectura de este post y que os sirva lo que os he enseñado sobre Burp Collaborator. ¡Hasta luego!

 

Juan Francisco Flores

• Juan Francisco Flores