06 septiembre 2013

Ataques basados en entidades XML

Este tipo de ataques no son ninguna novedad y, que yo sepa, se conocen al menos desde principios del 2002. Sin embargo, cada vez que realizon una auditoría de una aplicación que procesa documentos XML, me suelo encontrar que son vulnerables a inyecciones XXE (XML External Entity) y XEE (XML Entity Expansion). Estas ultimas son menos frecuentes hoy en día debido a las configuraciones por defecto de la mayoría de procesadores por lo en este articulo nos centraremos en las primeras.

Antes de describir como funcionan los ataques XXE necesitamos entender que son las entidades XML. Estas entidades son una forma sencilla de crear aliases en un documento XML que podemos referenciar a lo largo del mismo y que nos pueden ahorrar escribir bastantes líneas de texto y reducir bastante el tamaño de los ficheros XML resultantes. El concepto es el mismo que el de entidades HTML donde existen aliases predefinidos para referenciar caracteres ASCII como &lt; y &gt; para < y >. En el caso de XML, las entidades se declaran en el bloque DOCTYPE. Por ejemplo, en el siguiente documento definimos una entidad llamada “terminos” para referirnos a los términos y condiciones de un contrato y de esta forma reducir el tamaño del XML:


Del mismo modo, podemos hacer referencia a entidades externas y hacer uso de protocolos como http y file para referenciar el texto que queremos que reemplace las entidades. Por ejemplo:


Desde el punto de vista de un atacante, esta característica de XML es muy interesante ya que si una aplicación recibe algún documento XML como entrada, lo procesa; un atacante podrá enviar un documento XML en el cual defina una entidad externa referenciando a cualquier fichero del servidor o recurso de la red interna y volcar el contenido del mismo en la salida. Permitiéndole acceder a cualquier recurso que el servidor de aplicaciones tenga permiso para leer.

Me imagino que estareis pensando que tampoco hay muchas aplicaciones que tomen como entrada un documento XML (ya sea mediante una URL o upload),  sin embargo, hay un tipo de servicios muy populares que están consumiendo documentos XML constantemente; los servicios web ya sean SOAP o RESTFul.

Por centrarnos en algo, echaremos un vistazo a los servicios web de tipo REST que cada vez se usan más para crear APIs para aplicaciones móviles nativas. Si nos fijamos en Java, veremos que los dos frameworks más usados para construir este tipo de servicios son: JAX-RS y SpringMVC.

JAX-RS es un standard y admite varias implementaciones. Todas ellas con el tiempo han deshabilitado la resolución de entidades externas por defecto excepto EasyRest (la implementación de JBoss) que por defecto resolverá las entidades externas a menos que lo configuremos para no hacerlo.

SpringMVC es otro cantar. Spring usa las librerías de Spring OXM para convertir los mensajes en XML en objetos Java que pone a disposición del desarrollador. Realmente SpringOXM no es ningún unmarshaller y lo que hace realmente es hacer de wrapper de otras soluciones como JAXB, Castor, XStream, etc … El problema viene de que aunque librerías como JAXB se puedan configurar para no resolver entidades externas, el wrapper de SpringOXM no solo usa una versión insegura por defecto si no que además no expone ninguna propiedad para poder deshabilitarlo por lo que cualquier servicio web basado en SpringMVC y usando JAXB (la librería por defecto y más popular) será vulnerable a este tipo de ataques. Esta vulnerabilidad fue reportada al equipo de Spring y ha sido corregida en la ultima versión (http://www.securityfocus.com/archive/1/528177). Veamos un ejemplo de cómo funcionaría estos ataques:

Pongamos que tenemos un servicio web de tipo REST que sirve de backend para una aplicación de gestión de contactos. El controlador del servicio tendrá una pinta parecida a esto (muy simplificado):


De tal forma que cuando el servicio reciba un petición para crear un contacto como la mostrada abajo, SpringOXM automágicamente hará un unmarshal del XML y creara un objeto de tipo Contact que almacenara en la base de datos.


La próxima vez que el usuario acceda a través de su aplicación móvil  a los detalles de este contacto, se enviará una petición a “getContact” que devolverá un XML con los detalles del contacto.


La próxima vez que el atacante use su móvil para comprobar el numero de Fulanito, recibirá el contenido del fichero /etc/passwd por el mismo precio :)

Esta vulnerabilidad no se limita unicamente a poder leer ficheros arbitrarios del servidor (que no esta mal ...) tambien puede ser usada para provocar DOS en el servidor (imaginad que leeis el fichero /dev/random) y para llevar a cabo ataques SSRF (Server Side Request Forgery). En este tipo de ataques lo que buscamos es que el servidor genere peticiones por nosotros (a poder ser cualquier tipo de petición y usando cualquier protocolo). De esta forma podremos pivotar en la red interna lanzando ataques desde el propio servidor de aplicaciones y saltandonos cualquier control a nivel de red que normalmente permiten el tráfico originado en el servidor de aplicaciones. Un protocolo muy interesante para lanzar este tipo de ataques el Gopher, pero eso daría para otro post.

Algunos estareis pensando si es posible lanzar este tipo de ataques de forma "ciega", es decir, cuando no podemos observar la salida del procesador XML. Timor Yunusov y Alexey Osipovya pensaron en esto y presentaron este año en la BlackHat Europea una forma de realizar ataques XXE OOB (Out of Band) en los que el propio procesador enviará los datos a un servidor controlado por nosotros.

Dependiendo del lenguaje y los frameworks usados, los procesadores XML resolverán entidades externas por defecto o tendremos que configurarlos de tal forma que no lo hagan. Tenlo en cuenta la próxima vez que programes algo relacionado con XML o hagas una auditoría de una aplicación que lo use.


--------------------------------

Artículo cortesía de Alvaro Muñoz
Twitter: @pwntester 

2 comments :

Michb dijo...

Interesante no lo sabía, gracias por la info.

nolan0 dijo...

Great job! Thanks for sharing!
http://www.rentcarbeograd.com/