Vulnerabilidad Server-Side Template Injection - Hacking Avanzado.

Vulnerabilidad Server-Side Template Injection - Hacking Avanzado.

  octubre 21, 2016    Unknown

---

¿Que es Server-Side Template Injection?

 

Los motores de plantilla son ampliamente utilizados por las aplicaciones web para presentar datos dinámicos a través de páginas web y correos electrónicos. Inseguramente incorporan la entrada del usuario en las plantillas del servidor lo que permite el Server-Side Template Injection, una vulnerabilidad crítica que con frecuencia es extremadamente fácil de confundir con Cross-Site Scripting (XSS), o se pierda por completo. A diferencia de XSS, Server-Side Template Injection se puede utilizar para atacar directamente a servidores web internos y con frecuencia obtener ejecución remota de código (RCE), convirtiendo cada aplicación vulnerable en un punto pivot potencial.

Server-Side Template Injection puede surgir tanto a través de un error de desarrollo, y a través de la exposición intencional de plantillas en un intento de ofrecer una gran funcionalidad, como comúnmente se hace mediante wikis, blogs, aplicaciones de marketing y sistemas de gestión de contenidos. La expocision intencional de plantillas es un caso de uso tan común que muchos motores de plantilla ofrecen un modo "sandbox" para este propósito. Este documento define una metodología para detectar y explotar la Template Inyeccion, y la muestra se aplica a las embarcaciones zerodays RCE para dos aplicaciones web empresariales ampliamente desplegadas. Exploits genéricos se demuestran para cinco de los motores de plantilla más populares, incluyendo escapes de sandboxes, cuya finalidad es manejar toda plantillas suministradas por el usuario de una manera segura.

Introducción.

Las aplicaciones Web frecuentemente usan sistemas de plantilla como Twig y FreeMarker para incrustar contenido dinámico en páginas web y correos electrónicos. La inyección se produce cuando la entrada del usuario se está incorporado en una plantilla de manera insegura. Considere una aplicación de marketing que envía correos electrónicos masivos, y utiliza una plantilla Twig para saludar receptores por su nombre. Si el nombre no es más que pasó en la plantilla, como en el siguiente ejemplo, todo funciona bien: 

$output = $twig->render("Dear {primer_nombre},", array("primer_nombre" => $user.primer_nombre) ); 

Sin embargo, si los usuarios tienen permiso para personalizar estos mensajes de correo electrónico, surgen los problemas:

$output = $twig->render($_GET['custom_email'], array("primer_nombre" => $user.primer_nombre) ); 

En este ejemplo, el usuario controla el contenido de la plantilla en sí a través del parámetro GET custom_email, en lugar de un valor pasado en ella. Esto se traduce en una vulnerabilidad XSS que es difícil pasar por alto. Sin embargo, el XSS es sólo un síntoma de una vulnerabilidad más grave sutil. Este código en realidad expone una superficie de ataque expansiva, pero pasa por alto fácilmente. La salida de los dos mensajes de bienvenida siguientes alude a una vulnerabilidad Server-Side Template Injection:

1) custom_email={{7*7}}
    49

2) custom_email={{self}}

    Object of class                                              __TwigTemplate_7ae62e582f8a35e5ea6cc639800ecf15b96c0d6f78db3538221c1145580ca4a5    could not be converted to string

Lo que tenemos aquí es esencialmente ejecución de código en el servidor dentro de un sandbox. Dependiendo del motor de plantillas utilizado, puede ser posible para escapar del sandbox y ejecutar código arbitrario.

Esta vulnerabilidad se presenta típicamente a través de los desarrolladores permitiendo a los usuarios que creen o editen plantillas (Algunos motores de plantilla ofrecen un modo seguro para este propósito. Está lejos de ser específica para aplicaciones de marketing) y estas características que ofrecen para realizar el proceso pueden ser vulneradas, incluyendo páginas wiki, reviews, e incluso los comentarios. Server-Side Template Injection también puede surgir por accidente, cuando la entrada del usuario es simplemente concatenada directamente en una plantilla. Esto puede parecer un poco contra-intuitivo, pero es equivalente a vulnerabilidades de inyección SQL que se producen en declaraciones preparadas mal escritas, que son una ocurrencia relativamente común. Por otra parte, la Template Injection involuntaria es muy fácil pasar por alto, ya que normalmente no habrá señales visibles. Al igual que con todas las vulnerabilidades basadas en la entrada del usuario, la entrada podría proceder de codigos fuera de la banda. Por ejemplo, esto puede ocurrir como un Local File Inclusion (LFI), explotable a través de técnicas clásicas de LFI como código incrustado en los archivos de registro, archivos de sesión , o /proc/self/env para obtener acceso a modulos directos del sistema como puede ser Bash (En GNU/Linux) o CMD (Windows).

Metodología del Template Injection.

 
He definido la siguiente metodología de alto nivel para capturar un proceso de ataque eficiente, basado en mi experiencia auditar una gama de aplicaciones vulnerables y motores de plantilla:

Detección.

Esta vulnerabilidad puede aparecer en dos contextos distintos, cada uno de los cuales requiere su propio método de detección:

1. Contexto de texto sin formato

La mayoría de los lenguajes de plantillas soportan un contexto "texto" de forma libre donde se puede introducir directamente en HTML. Por lo general aparecerá en una de las siguientes maneras:

___________________________________

smarty=Hello {user.name}
Hello user1
--------------------------------------------------------
___________________________________

freemarker=Hello ${username}
Hello newuser
-------------------------------------------------------- 
___________________________________

any=<b>Hello</b>
<b>Hello<b>
--------------------------------------------------------

Con frecuencia, esto da lugar a XSS, por lo que la presencia de XSS se puede utilizar como una señal para pruebas de Template Inhection más completas. Los lenguajes de plantillas utilizan una sintaxis explícitamente elegida para no entrar en conflicto con los caracteres utilizados en HTML normal, por lo que es fácil para una evaluación manual de seguridad de la blackbox que se pierda por completo la Template Injection. Para detectarlo, necesitamos invocar el motor de la plantilla mediante la incorporación de un comunicado. Hay un gran número de lenguajes de plantillas, pero muchos de ellos comparten características básicas de sintaxis. Podemos tomar ventaja de esto mediante el envío de cargas útiles genéricas, plantillas agnósticas utilizando las operaciones básicas para la detección de múltiples motores de plantilla con una sola petición HTTP:

___________________________
smarty=Hello ${7*7}
Hello 49
-------------------------------------------

___________________________
freemarker=Hello ${7*7}
Hello 49
-------------------------------------------

Como vemos al introducir cualquier valor a nuestra peticion obtendremos el resultado de realizar internamente las operaciones. Otra forma sencilla de detectar una vulnerabilidad de este tipo es usando Curl.

2. Contexto Código

La entrada del usuario también se puede colocar dentro de una instrucción en la plantilla, típicamente como un nombre de variable:

________________________________

personal_greeting=username
Hello user01 

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

Esta variante es aún más fácil de perder durante una evaluación, ya que no da lugar a XSS obvio y es casi indistinguible de una simple busqueda hashmap.Se puede detectarmediante una robusta verificación del parámetro, el cual no tiene XSS directo, a continuación, salir de la declaración de la plantilla e inyectando la etiqueta HTML después de que:

_______________________________________

personal_greeting=username<tag>
Hello 

--------------------------------------------------------------
_______________________________________
personal_greeting=username}}<tag>
Hello user01 <tag> 

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

Identificación

Después de detectar la inyección plantilla, el siguiente paso es identificar el motor de plantillas en uso. Este paso es a veces tan trivial como la presentación de una sintaxis no válida, los motores de plantilla pueden identificarse en los mensajes de error resultantes. Sin embargo, esta técnica produce un error cuando se suprimen mensajes de error, y no es muy adecuado para la automatización. En cambio, hemos automatizado esto en BurpSuite utilizando payloads de idiomas especificos. Las flechas verdes y rojas representan el "éxito" y "fracaso" de las respuestas, respectivamente. En algunos casos, una sola carga útil puede tener múltiples respuestas de éxito distintas - por ejemplo, la expresión {{7 * '7'}} daría lugar a 49 en Twing, en Jinja2 seria 777777. 

Explotación.

1) Leer. El primer paso después de encontrar la Template Injection e identificar el motor de plantillas es leer la documentación. La importancia de este paso no debe subestimarse; Las hazañas zero-day se derivan únicamente a partir de la lectura estudiosa de documentación. Las principales áreas de interés son:

• "Para autores de plantillas" -> Secciones que cubre la sintaxis básica.
• "Consideraciones de Seguridad '' -> lo más probable es el que desarrolló la aplicación que estás probando no quiera que leas esto, y puede contener algunos consejos útiles.
• Las listas de los métodos de ordenes internas, funciones, filtros y variables.
• Las listas de extensiones/plugins - algunos pueden ser activados por defecto.

2) Explorar. Suponiendo que no hay exploits presentes, el siguiente paso es explorar el entorno para saber exactamente a lo que usted tiene acceso. Usted puede esperar encontrar objetos predeterminados proporcionados por el motor de plantillas y objetos específicos de la aplicación que han sido pasados a la plantilla por el desarrollador. Muchos sistemas de plantilla exponen un "yo" o un objeto de espacio de nombres que contiene todo en su alcance, y una forma idiomática a la lista de atributos y métodos de un objeto.

Con esto damos por terminado este post acerca de esta nueva pero crítica vulnerabilidad que nos permitira hacer nuevos tipos de Tests y elaborar informes de Seguridad Informatica mas completos. Si te ha gustado este post y te sirvió regálanos un Like en facebook y síguenos en Twitter.

Ref: http://blog.portswigger.net/2015/08/server-side-template-injection.html