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 < y > 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
Blog: www.pwntester.com
Twitter: @pwntester
Fuente:http://www.securitybydefault.com/2013/09/ataques-basados-en-entidades-xml.html
Entradas
No hay comentarios:
Publicar un comentario