XML INJECTION

XML INJECTION BÁSICO

En este primer ataque llamado XML Injection intentaremos alterar la estructura del documento XML, inyectando tanto XML data como XML tags. Para iniciar la explotación dejaremos el proxy de BurpSuite a la escucha, para ir captando las peticiones tanto de registro, como de login, para ver el comportamiento de la página web.
En primer lugar vemos una pantalla bastante simple de registro, por lo tanto procedemos a registrarnos:

pantalla login.png

Una vez registrados logueamos en la aplicación y nos dice que no somos elite y que por lo tanto no podemos acceder.

no eres elite member lol.png

Nos dirigimos a BurpSuite y vemos en el archivo core.js tenemos la función WSresgiter_old() donde observamos que está el código XML. Así a primera vista podemos ver que cualquier usuario que se registre entra accediendo a la aplicación con role 2 (que debe ser el más bajo), por lo tanto imagino que logueando con rol 1, accederemos como miembro elite.

funcionWSregisterOld y rol2.png
Un detalle que a priori hemos pasado por alto es que cuando registramos un usuario la aplicación nos devuelve el nombre de usuario reflejado en la pantalla de login concretamente en el mensaje de bienvenida. Esto quiere decir que si intentamos inyectar alguna etiqueta y la aplicación sigue funcionando y registra al nuevo usuario, sabremos que el parámetro no es vulnerable a XML Injection.

nombredecueltoenlapantalladelogin.png
Comenzamos testeando los parametros con el primero que es el <name>, procedemos a registrar un nuevo usuario y en el campo name insertamos el tag o etiqueta <hola> y como podemos observar en las dos imágenes inferiores el proceso de login continua y registramos el usuario sin problemas, por lo tanto sabemos que este parámetro no es vulnerable.

parametroname.pngresponseparametroNameNovulnerable.png

Seguimos con el parámetro <username> y realizamos el mismo procedimiento anterior, registramos un usuario nuevo y en el campo de username insertamos la etiqueta o tag <hola>. Como vemos en la imagen inferior forzamos un error el cual podemos deducir que este paramétro puede ser vulnerable a XML Injection.

parametroUserNameError.png

Para proceder a la explotación tendremos que armar nuestro payload, registrar un usuario con nivel de rol 1 y logarnos como élite. Para ello habrá que tener en cuenta la estructura XML de la pantalla de registro:

var xml = ‘<?xml version=”1.0″ encoding=”utf-8″?> ‘;
xml += ‘<user> ‘;
xml += ‘ <rule>2</rule> ‘;
xml += ‘ <name>’ + name + ‘</name> ‘;
xml += ‘ <username>’ + username + ‘</username> ‘;
xml += ‘ <password>’ + password + ‘</password> ‘;
xml += ‘</user>

Empezamos creando nuestro payload de esta manera:
En primer lugar cerramos las etiquetas tanto de </username> como de </user> y a partir de aquí creamos nuestra estructura XML abriendo una nueva etiqueta <user> con <rule>1 para loguearnos como miembro elite, le añadimos nuestro <nombre> y como estamos explotando el parámetro username finalizamos con nuestro <username>.

Quedaría así:

name: loganayalaan
username:loganayalaan</username></user><user><rule>1</rule><name>loganayalaan</name<username>loganayalaan
password:logan123

REGISTERPREEXPLOTATION.pngELITEMEMBERDONE.png

XML INJECTION CON RESTRICCIÓN DE LONGITUD DE CADENA.

En este segundo ejercicio haremos lo mismo que con el primero, primero testear parámetro por parámetro cual puede ser vulnerable, posteriormente dirigirnos al código XML, crear nuestro payload y proceder a la explotación. En el camino nos encontraremos esta vez con algún inconveniente que veremos como bypassearlo.

Empezamos con el testeo de parámetros y observamos que tanto el <name> como el <username> son vulnerables ya que ambos nos arrojan errores.
errorName2.png

errorusername2.png
Una vez hemos verificado que la estructura XML es la misma, procederemos con el mismo payload del ejercicio anterior para ver si vulneramos la aplicación.

Payload:loganayalaan</username></user><user><rule>1</rule><name>loganayalaan</name><username>loganayalaan

Observando en la imagen inferior que el payload fue infructuoso y ahora veremos el porqué..

errorexplotacióncampousername.png
Mirando el código HTML de la página no he visto ninguna restricción de tamaño, por lo tanto lo probaré manualmente en los dos parametros vulnerables y como podemos observar en la imagen inferior, el parámetro name tiene una restriccion de 35 carácteres, ya que refleja los 35 primeros en el mensaje de bienvenida.

foto35caractereslimitacioncampouser.png

Esta vez armaremos nuestro payload ocupando los dos campos y comentando la salida del campo name, con el inicio del campo username, de tal manera que usando los dos campos podamos bypassear el login como miembro elite. La carga útil quedaría de esta manera:

name: </name></user><user><rule>1<!–
username: –></rule><name>a</name><username>a
password: logan123

logueofinal.png

elite2.png

Deja un comentario