Entidades externas XML vulnerables – OWASP Top 4

El procesamiento de entidades externas XML se clasifica como la vulnerabilidad número cuatro en la lista de OWASP-Top 10. Esta vulnerabilidad resulta ser prevalente en sistemas online por dos razones:

  1. Cuando los desarrolladores web finalizan la funcionalidad de una aplicación, se supone que la aplicación está lista para ejecutarse. La mayoría de las veces, volver a revisar el código buscando fallas de seguridad es imposible porque hay otros proyectos esperando a ser desarrollados.
  2. Cuando la interfaz de la aplicación está en línea, los administradores del sistema dedican la mayor parte de su tiempo a crear nuevos perfiles y capacitar a los usuarios para usar la nueva interfaz. Probar la aplicación para encontrar fallas de seguridad no es una opción porque deben realizar otros procedimientos críticos en el sistema como actualizaciones de los servidores y proveer soporte a los empleados.

Con todo esto, es bastante difícil encontrar este tipo de vulnerabilidad lo cual permite que un atacante pueda modificar y subir archivos XML infectados diseñados para ejecutar comandos, enumerar nombres de usuarios, contraseñas y obtener conexiones reversas desde la aplicación infectada para entrar a la red interna.

La mejor manera de descubrir esta vulnerabilidad es a través de pruebas manuales y una comprensión clara de estos procesos.

¿Cuál es exactamente el proceso que genera la vulnerabilidad en las entidades externas XML?

Esta vulnerabilidad se genera en el analizador XML a través de la ejecución de las aplicaciones en los sitios web. Esta ocurre porque el analizador XML no se ha configurado teniendo en cuenta la seguridad. Es importante mencionar que el analizador XML es el método utilizado para convertir texto en objetos XML DOM. Estos objetos son un tipo de lenguaje neutral que permite que los programas y scripts accedan y actualicen dinámicamente el contenido, la estructura y el estilo de un documento.

¿Cuáles son los tipos de ataques que un hacker podría realizar si encuentra este tipo de vulnerabilidad en una aplicación Web y cuáles serían las consecuencias?

Hay diferentes tipos de ataques que un hacker puede ejecutar si encuentra este tipo de vulnerabilidad en una aplicación Web. Analizaremos los tres tipos de ataque más utilizados:

Ataque al procesamiento de entidades externas XML para recuperar archivos:

El propósito de este tipo de ataque es acceder a archivos del servidor en el cual reside la aplicación XML vulnerable. Los archivos críticos de los sistemas operativos Linux como “/etc/passwd” y “/etc/shadow” podrían ser vulnerados. La misma situación ocurre con el sistema operativo Windows; se podrían vulnerar archivos del sistema como “web.config” y “unattend.xml”. El espectro de ataque aumentaría exponencialmente si se encuentran credenciales de acceso internas almacenadas en esos archivos (como casi siempre ocurre).

Aquí tenemos una página de inicio de sesión simple utilizada con fines de demostración:

Si ingresamos credenciales aleatorias y hacemos clic en iniciar sesión (Login):

Recibimos una respuesta en nuestra herramienta de análisis que muestra que el sistema de inicio de sesión fue configurado usando lenguaje XML:

Examinando la aplicación desde el lado del servidor encontramos que este es el archivo que gestiona el sistema de inicio de sesión:

Como notamos en la respuesta a nuestra solicitud realizada, «Admin» es la salida constante y se imprime a través de la etiqueta “$name”. Podemos ver esta salida en la página de inicio de sesión del sitio web:

Conociendo esta información, la siguiente pregunta seria:

¿cómo puede un atacante hacer uso de esta configuración que fue escrita no teniendo un enfoque en la seguridad para atacar el sitio web vulnerable y tener un acceso no autorizado a la red interna?

Algunas herramientas de análisis permiten enviar solicitudes modificadas con el fin de interactuar con servidores donde las aplicaciones Web residen. En este caso, creamos una solicitud con configuración XML especifica que utilizará la etiqueta “$name” para obtener acceso no autorizado a los archivos del sistema.

En respuesta a nuestra solicitud obtenida a través de nuestro código XML podemos acceder al archivo “/etc/passwd” que nos permite enumerar los nombre de usuario que tienen acceso al sistema.

Como notó, usamos la entidad «&sp;» exactamente donde la etiqueta reside para tener acceso no autorizado al archivo “/etc/passwd”.

Ahora solicitaremos un archivo .php ubicado en el sistema de archivos:

Como puede ver, esta vez no tuvimos éxito en nuestra solicitud porque el lenguaje .php usa diferentes contenedores para interactuar con el código .php.

La solución para acceder al archivo “index.php” seria usar el contenedor «php://filter» en nuestro código XML.

Esta vez, el ataque también fue exitoso y nos permitió acceder al archivo “index.php”. Como puede usted ver, el archivo es mostrado codificado en Base64.

El siguiente paso sería decodificar el código:

Para finalmente tener acceso total al archivo.

Ataque al procesamiento de entidades externas XML para falsificar solicitudes desde el lado del servidor

La falsificación de solicitudes desde el lado del servidor permite a un atacante identificar servicios que funcionan en otros puertos en el servidor vulnerado con el fin de descubrir otras aplicaciones; lo ideal para el ataque seria que estas aplicaciones también fueran vulnerables. En otras palabras, este es un ataque dentro de otro ataque.

Para fines de demostración; estamos probando la conectividad al puerto cerrado 8080 y al puerto abierto 5355. Según el tiempo de respuesta, podemos confirmar el estado de esos puertos.

La respuesta de 10.747 mills nos confirma que el puerto 5355 está abierto. Si esta vulnerabilidad hubiese sido parchada, seria imposible para un atacante encontrar este tipo de información.

Ataque al procesamiento de entidades externas XML para filtrar datos fuera de banda:

Este es un tipo de ataque muy interesante; la técnica fuera de banda requiere alojar un archivo DTD (Definición de tipo de documento) malicioso controlado por el hacker (proceso fuera de banda) en un servidor Web; luego, llamar al archivo DTD malicioso desde la aplicación vulnerable. Cuando se ejecuta este proceso, el DTD diseñado fuera de banda entrará en el proceso con conjunto de acciones previamente determinada por el atacante que serán ejecutadas en el sistema vulnerable. Esas acciones pueden transferir datos específicos al entorno del atacante, escanear otra red interna o realizar procedimientos de enumeración en otros computadores.

Veamos cómo podemos extraer el archivo “/etc/passwd” usando el ataque fuera de banda:

Alojamos un archivo malicioso llamado evil.dtd en la máquina atacante con un código diseñado para leer y exfiltrar el archivo /etc/passwd” al servido con IP 192.168.106.128

Y conectamos nuestro servidor al Internet abriendo el puerto 8000:

Para llamar al archivo evil.dtd, se debe reconfigurar el código XML previamente creado. De esta forma, el archivo malicioso se ejecutara como proceso de respuesta en el sitio web vulnerable:

Cuando, la solicitud se envía al servidor, se procesa el archivo evil.dtd y obtenemos el contenido del archivo “/etc/passwd” que se muestra codificado como base64.

Y finalmente el archivo después de ser decodificado:

¿Es este tipo de vulnerabilidad frecuente en algunos sistemas?

Si. Hemos visto este tipo de vulnerabilidades en servidores web, bases de datos como MySQL y PostgreSQL, plataformas de imágenes y navegadores web. Cada sitio web que ejecuta algún tipo de código XML debe ser analizado.

¿Cómo puedo descubrir si mis aplicaciones Web están afectadas por esta vulnerabilidad?

Para saber si las aplicaciones de su sitio web son vulnerables, se requiere una revisión de las aplicaciones junto a otros tipos de análisis para descubrir otras vulnerabilidades aún más peligrosas como la inclusión remota o local de archivos, servidores con opción PUT configurada, autenticación vía token, POODLE, XSS, y SSRF, entre otras.

¿Cómo puede ayudarme Seguridad-Ofensiva a mantener mi sitio web corporativo seguro?

Seguridad-Ofensiva pondrá a prueba sus sitios web corporativos y sus bases de datos. Utilizamos escáneres avanzados, pruebas de penetración manual y diferentes técnicas y procedimientos que pueden incluir rastreo, forzamiento bruto, revisión de código y permisos de carpeta. Hacemos todo esto en coordinación con su personal interno encargado de sus sistemas de información. Estos procedimientos son necesarios para averiguar si las posibles vulnerabilidades son falsos positivos o vulnerabilidades reales. Si son vulnerabilidades reales, le proporcionaremos métodos efectivos para parchar, actualizar o eliminar la vulnerabilidad de acuerdo con la situación para mantener su entorno seguro.

SOLUCIÓN Y PREVENCIÓN

https://seguridad-ofensiva.com/evaluaciones-de-vulnerabilidades

https://seguridad-ofensiva.com/pruebas-de-penetracion-externas

https://seguridad-ofensiva.com/pruebas-de-penetracion-en-sitios-web

Recursos adicionales con relación a este tipo de ataque:

https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A4-XML_External_Entities_(XXE).html

https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html

https://owasp.org/www-community/Source_Code_Analysis_Tools

https://cwe.mitre.org/data/definitions/611.html

https://en.wikipedia.org/wiki/Billion_laughs_attack

https://secretsofappsecurity.blogspot.com/2017/01/saml-security-xml-external-entity-attack.html

https://web-in-security.blogspot.com/2014/11/detecting-and-exploiting-xxe-in-saml.html

Otras vulnerabilidades pertenecientes a OWASP

Uso de componentes con vulnerabilidades conocidashttps://seguridad-ofensiva.com/blog/owasp-top-10/uso-de-componentes-con-vulnerabilidades-conocidas-owasp-top-9/

Deserialización insegurahttps://seguridad-ofensiva.com/blog/owasp-top-10/deserializacion-insegura-owasp-top-8/

Seguridad no configuradahttps://seguridad-ofensiva.com/blog/owasp-top-10/seguridad-no-configurada-owasp-top-6/

Control de acceso vulnerable: https://seguridad-ofensiva.com/blog/owasp-top-10/control-de-acceso-vulnerable-owasp-top-5/

Exposición de datos confidencialeshttps://seguridad-ofensiva.com/blog/owasp-top-10/exposicion-de-datos-confidenciales-owasp-top-3/

Ataques en sistemas de autenticaciónhttps://seguridad-ofensiva.com/blog/owasp-top-10/ataques-en-los-sistemas-de-autenticacion/

Ataques por Inyección SQLhttps://seguridad-ofensiva.com/blog/owasp-top-10/ataques-por-inyeccion-sql/

Registro y monitoreo insuficiente: https://seguridad-ofensiva.com/blog/owasp-top-10/registro-y-monitoreo-insuficiente-owasp-top-10/

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *