Aunque los ataques XXE (XML External Entity) son bastante conocidos, hay ciertas limitaciones que se nos suelen presentar a la hora de explotarlos, y cuyas técnicas para salir airoso, a día de hoy no están tan extendidas. Por esta razón, me ha parecido interesante escribir un post sobre algunas de estas limitaciones y cómo superarlas.
Un fallo de seguridad XXE es uno de esos fallos que te hacen saltar de la silla cuando te encuentras con él. No es para menos, ya que permite maldades tales como acceso al sistema de ficheros, escaneo de la Intranet, denegaciones de servicio o, incluso, ejecución remota de código. Para entender básicamente cómo funciona, antes de seguir leyendo puedes hacer click en este post de nuestros amigos de Security by default.
Para que después de saltar de la silla no te acabes dando con la lámpara en la cabeza, aquí te presentamos un resumen de los problemas más comunes y cómo abordarlos. En los ejemplos, el objetivo del atacante será leer el fichero /etc/passwd del servidor.
Si intentamos explotar un XXE de la forma habitual dentro de un atributo XML, veremos que el ataque no tendrá éxito, ya que las entidades no son procesadas directamente en este contexto.
- Lo que NO funciona:
- Lo que funciona:
Donde el contenido del fichero evil.xml es el siguiente:
Por suerte, los parámetros XML acuden al rescate. Estos parámetros cumplen la misma función que las entidades, pero se usan en la definición del documento (DTD). En el ejemplo anterior, definimos la entidad "xxe" de manera indirecta haciendo uso de un parámetro que se resuelve hacia una URL externa controlada por nosotros en nuestro "evilserver", y que a su vez hace uso de parámetros que resuelven el contenido del fichero que queremos leer del servidor.
Otro problema habitual es que una vez que se expande una entidad XML con el contenido de un fichero que contiene caracteres como <, >, ", etc., el XML original puede acabar mal formado, por lo que el parser no podrá completar su proceso y nuestro ataque no funcionará. Una solución es intentar que el contenido del fichero quede dentro de un bloque <![CDATA[...]]>. Sin embargo, no podemos incluir este bloque directamente, ni siquiera con entidades definidas en el XML.
- Lo que NO funciona:
- Lo que funciona:
Como vemos, finalmente logramos construir nuestro bloque CDATA haciendo uso, de nuevo, de parámetros XML, y apoyándonos en una web externa controlada por nosotros que compone las partes definidas en el XML original. Aunque esta técnica funcionará en la mayoría de los casos, puede que falle si el fichero que queremos leer del servidor contiene los caracteres & o % o si intentamos leer ficheros binarios.
En ocasiones, aunque tenemos indicios de que la aplicación es vulnerable a ataques XXE, ningún dato del XML que enviamos es finalmente devuelto al usuario tras el parseo. Al igual que ocurre con la explotación de otro tipo de vulnerabilidades como SQL inyection, también existen técnicas OOB para hacer que el servidor víctima envíe el contenido hacia un servidor controlado por el atacante:
Donde el contenido del fichero send.dtd es el siguiente:
Como en esta ocasión construimos una URL externa dinámicamente con el contenido del fichero extraído, es posible que tengamos problemas si el parser es delicado y no acepta todos los caracteres del contenido que se van a incluir automáticamente en la URL. Pero incluso en esta situación nos quedan algunas cartas bajo la manga por jugar. Haciendo uso del protocolo FTP y de un servidor falso, probablemente podamos acabar leyendo el fichero siguiendo los estupendos ejemplos que detalla Ivan Novikov en este enlace.
Aparte de las técnicas anteriores, existe un abanico de posibilidades de explotación bastante interesante dependiendo de los protocolos disponibles en el servidor. gopher://, jar://, php:// o expect:// por ejemplo, nos abrirían las puertas para poder leer ficheros binarios sin restricción de caracteres, incluso poder directamente subir ficheros al servidor o ejecutar código arbitrario.
Para más información sobre estas y otras técnicas, podéis consultar las fuentes de documentación que os dejo al final del post.
¡Un saludo!
Fuentes:
- Black Hat EU 2013 - XML Out-of-Band Data Retrieval by Alexey Osipov & Timur Yunusov
- AppSec USA 2013 - What You Didn't Know About XML External Entities Attacks by Timothy Morgan
- XML Schema, DTD, and Entity Attacks by Timothy Morgan & Omar Al Ibrahim
- XXE OOB exploitation at Java 1.7+
Un fallo de seguridad XXE es uno de esos fallos que te hacen saltar de la silla cuando te encuentras con él. No es para menos, ya que permite maldades tales como acceso al sistema de ficheros, escaneo de la Intranet, denegaciones de servicio o, incluso, ejecución remota de código. Para entender básicamente cómo funciona, antes de seguir leyendo puedes hacer click en este post de nuestros amigos de Security by default.
Para que después de saltar de la silla no te acabes dando con la lámpara en la cabeza, aquí te presentamos un resumen de los problemas más comunes y cómo abordarlos. En los ejemplos, el objetivo del atacante será leer el fichero /etc/passwd del servidor.
[ Explotación en atributos ]
Si intentamos explotar un XXE de la forma habitual dentro de un atributo XML, veremos que el ataque no tendrá éxito, ya que las entidades no son procesadas directamente en este contexto.
- Lo que NO funciona:
- Lo que funciona:
Donde el contenido del fichero evil.xml es el siguiente:
Por suerte, los parámetros XML acuden al rescate. Estos parámetros cumplen la misma función que las entidades, pero se usan en la definición del documento (DTD). En el ejemplo anterior, definimos la entidad "xxe" de manera indirecta haciendo uso de un parámetro que se resuelve hacia una URL externa controlada por nosotros en nuestro "evilserver", y que a su vez hace uso de parámetros que resuelven el contenido del fichero que queremos leer del servidor.
[ Ficheros mal formados ]
Otro problema habitual es que una vez que se expande una entidad XML con el contenido de un fichero que contiene caracteres como <, >, ", etc., el XML original puede acabar mal formado, por lo que el parser no podrá completar su proceso y nuestro ataque no funcionará. Una solución es intentar que el contenido del fichero quede dentro de un bloque <![CDATA[...]]>. Sin embargo, no podemos incluir este bloque directamente, ni siquiera con entidades definidas en el XML.
- Lo que NO funciona:
- Lo que funciona:
Donde el contenido del fichero join.dtd es el siguiente:
Como vemos, finalmente logramos construir nuestro bloque CDATA haciendo uso, de nuevo, de parámetros XML, y apoyándonos en una web externa controlada por nosotros que compone las partes definidas en el XML original. Aunque esta técnica funcionará en la mayoría de los casos, puede que falle si el fichero que queremos leer del servidor contiene los caracteres & o % o si intentamos leer ficheros binarios.
[ Técnicas OOB (Out of Band) ]
En ocasiones, aunque tenemos indicios de que la aplicación es vulnerable a ataques XXE, ningún dato del XML que enviamos es finalmente devuelto al usuario tras el parseo. Al igual que ocurre con la explotación de otro tipo de vulnerabilidades como SQL inyection, también existen técnicas OOB para hacer que el servidor víctima envíe el contenido hacia un servidor controlado por el atacante:
Donde el contenido del fichero send.dtd es el siguiente:
Como en esta ocasión construimos una URL externa dinámicamente con el contenido del fichero extraído, es posible que tengamos problemas si el parser es delicado y no acepta todos los caracteres del contenido que se van a incluir automáticamente en la URL. Pero incluso en esta situación nos quedan algunas cartas bajo la manga por jugar. Haciendo uso del protocolo FTP y de un servidor falso, probablemente podamos acabar leyendo el fichero siguiendo los estupendos ejemplos que detalla Ivan Novikov en este enlace.
Aparte de las técnicas anteriores, existe un abanico de posibilidades de explotación bastante interesante dependiendo de los protocolos disponibles en el servidor. gopher://, jar://, php:// o expect:// por ejemplo, nos abrirían las puertas para poder leer ficheros binarios sin restricción de caracteres, incluso poder directamente subir ficheros al servidor o ejecutar código arbitrario.
Para más información sobre estas y otras técnicas, podéis consultar las fuentes de documentación que os dejo al final del post.
¡Un saludo!
Fuentes:
- Black Hat EU 2013 - XML Out-of-Band Data Retrieval by Alexey Osipov & Timur Yunusov
- AppSec USA 2013 - What You Didn't Know About XML External Entities Attacks by Timothy Morgan
- XML Schema, DTD, and Entity Attacks by Timothy Morgan & Omar Al Ibrahim
- XXE OOB exploitation at Java 1.7+
Muy interesante!!, enhorabuena :)
ResponderEliminarGracias!! :D
Eliminar