XML INJECTION

Hola a todos!, en esta ocasión os presento otra nueva inyección llamada XML Injection o XML Tag Injection.

Para introducirnos en el mundo XML realizaremos una breve introducción para aquellos que desconozcan esta lenguaje de estructura de datos “Extensible Markup Language”.
Hay muchos campos que aprovechan XML, estos incluyen PDF, RSS, OOXML, SVG y también protocolos de redes como pueden ser XMLRPC, SOAP, WEBDAV etc..
Este lenguaje es muy parecido al HTML pero con una implementación mucho más ligera.

EL Document Type Definition (DTD) define la utilización correcta de los bloques en un documento XML. Estos bloques son los siguientes:
*Elementos *Etiquetas *Atributos *Entidades *PCDATA *CDATA

Una cosa muy importante al proceder con los ataques XML, es que el DTD lo podemos definir tanto externamente como internamente, eso quiere decir que tenemos la opción de importar externamente el DTD si internamente no es posible y asi bypassear según que tipo de protecciones.
Después de esta breve introducción os dejo los primeros ejemplos, espero que sean de vuestro agrado 😀

XML INJECTION (TAG INJECTION)

Missing Functional Level Access Control: RFI & PATH TRAVERSAL

Seguimos con Bugcrowd University 😀

En este post realizaremos la siguiente tanda de ejercicios de Broken Access Control Testing, concretamente los relacionados con las vulnerabilidades Missing Functional Level Access Control de los laboratorios de BWapp.

Missing Functional Level Access Control

Documentación e información de la vulnerabilidad:

A7-Missing Function Level Access Control

Insecure Direct Object References -IDOR-

Inauguramos Bugcrowd University 😀

En este post realizaremos los primeros ejercicios de Broken Access Control Testing más concretamente los relacionados con la vulnerabilidad IDOR y para ello utilizaremos los labs de BWapp.

IDOR

Documentación e información de la vulnerabilidad:

Insecure Direct Object References

 

CSRF -Resumen-

Hola a todos, después de haber realizado todos los ejercicios del CourseWork de HackerOne, iremos haciendo un breve resumen de las vulnerabilidades encontradas y de como facilitar la localización y explotación.

CSRF

En estos ataques, el atacante crea un código HTML que obliga al navegador del usuario a realizar una acción directa a la aplicación vulnerable, pudiendo ser agregar, eliminar usuarios, autenticarse con otro usuario, cambiar opciones en la aplicación vulnerable, etc..

Para identificar una aplicación vulnerable a CSRF lo primero que debemos tener en cuenta es que el 90% de las aplicaciones que simplemente tienen HTTP cookies para trackear las sesiones pueden ser vulnerables.

Normalmente, para realizar un ataque CSRF hay que tener en cuenta que:

  • En primer lugar, fijarse en la petición y si a través de esta se puede realizar una acción con supuestos privilegios.
  • En segundo lugar y de los más a tener en cuenta es si la aplicación solamente sigue las sesiones con HTTP cookies y si no existen tokens adicionales de protección.
  • En tercer lugar, si mediante la petición se pueden observar todos los parámetros necesarios para realizar el ataque.

Si se cumplen los tres requisitos anteriormente mencionados, significa que tenemos vía libre para construir nuestro código HTML y vulnerar la aplicación.

Ya solamente nos faltaría crear el código HTML y modificar los parámetros. Yo utilizo la herramiente en BurpSuite que esta en Engagement Tools que se llama Generate CSRF POC. Esta herramienta te crea el código HTML y luego simplemente tenemos que pasarlo a nuestro editor de textos y modificar los parámetros que queramos, para luego ejecutar la petición.

PERO… no todo es de color de rosa..

Hoy en día, existen pocas aplicaciones web que no utilizan tokens adicionales anti-CSRF, envíados por hidden fields mediante HTML forms. Cabe la posibilidad que el atacante no sepa el camino para determinar el valor del token y por este motivo no podría ejecutar el ataque satisfactoriamente.

Cuando nos encontramos ante este tipo de situaciones, tenemos las mismas opciones de bypass que con los tokens de sesión normales:

  • En primer lugar, si un atacante puede predecir los valores de los tokens que son enviados a otros usuarios, puede determinar todos los parámetros requeridos para un ataque CSRF.
  • En segundo lugar, si los tokens anti-CSRF no están vinculados a la sesión del usuario al que se emitieron, un atacante puede obtener un token válido en su sesión y utilizarlo en un ataque CSRF, en una sesión de un usuario diferente.

A continuación os dejo un video de ejemplo:

Hasta la próxima 😀

XSS -Resumen-

Hola a todos, después de haber realizado todos los ejercicios del CourseWork de HackerOne, iremos haciendo un breve resumen de las vulnerabilidades encontradas y de como facilitar la localización y explotación.

xss

En primera instancia tendremos que realizar con BurpSuite un “Spider this Host” para encontrar todas las URL’s con sus respectivos parámetros.

Procederemos a detectar todos esos parámetros de entrada, los cuales podamos manipular a nuestro antojo. Si una vez cambiamos el valor del parámetro y este es reflejado en el código fuente sea cual sea el lugar, probablemente al 90% sea vulnerable a XSS. Para realizar este paso lo que yo hago es cambiar el nombre de todos los parámetros por ejemplo por vuln1, vuln2, vulnn, etc.. y mediante el Repeater de BurpSuite veo cual de ellos se ha reflejado.

Una vez tenemos el parámetro de entrada que probablemente sea vulnerable a XSS, intentamos inyectar y  ejecutar código Javascript, si este se ejecuta ya tenemos nuestra vulnerabilidad explotada. Una opción para ahorrarnos tiempo es usar el Intruder de BurpSuite, el cual configuramos los parámetros de entrada que queramos explotar y podemos incluir una lista de payloads para ahorrarnos mucho tiempo. Usando Intruder tened en cuenta la longitud (length) del caso base con los de la lista de payloads, como más longitud obtengamos más probable sea de que haya sido fructuoso el ataque.

Los lugares más probables donde injectar serían en URL’s como pueden ser un formulario de contacto, una búsqueda, una zona de comentarios, foros, pagínas de autenticación y de firmas.

PROOF OF CONCEPT -VIDEO-

Hacker101 Level 6: Student Center

Séptima entrada del CourseWork de HackerOne -Hacker101-. En este nivel explotamos varios XSS tanto Reflected como Stored, una vulnerabilidad SQLI y un Cross Site Request Forgery.

Student Center

Documentación e información de las vulnerabilidades:

XSS Reflected

XSS Stored

CSRF

SQL INJECTION