<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Experto en Red Team de AWS de HackTricks)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**swag oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
[**RootedCON**](https://www.rootedcon.com) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro crucial para profesionales de tecnología y ciberseguridad en todas las disciplinas.
Una inyección de plantillas en el lado del servidor ocurre cuando un atacante es capaz de utilizar la sintaxis de plantillas nativas para inyectar un payload malicioso en una plantilla, que luego se ejecuta en el servidor.
Los **motores de plantillas** están diseñados para **generar páginas web** combinando plantillas **fijas** con datos **volátiles**. Los ataques de inyección de plantillas en el lado del servidor pueden ocurrir cuando la **entrada del usuario** se concatena directamente **en una plantilla**, en lugar de pasarse como datos. Esto permite a los atacantes **inyectar directivas de plantilla arbitrarias** para manipular el motor de plantillas, a menudo permitiéndoles tomar **control completo del servidor**.
En el ejemplo anterior **parte de la plantilla** en sí misma está siendo **generada dinámicamente** utilizando el parámetro `GET``name`. Dado que la sintaxis de la plantilla se evalúa en el servidor, esto potencialmente permite a un atacante colocar un payload de inyección de plantilla en el servidor dentro del parámetro `name` de la siguiente manera:
Al igual que con cualquier vulnerabilidad, el primer paso hacia la explotación es poder encontrarla. Quizás el enfoque inicial más simple sea intentar **fuzzear la plantilla** inyectando una secuencia de caracteres especiales comúnmente utilizados en expresiones de plantillas, como el políglota **`${{<%[%'"}}%\`.**\
Para verificar si el servidor es vulnerable, debes **detectar las diferencias** entre la respuesta con **datos regulares** en el parámetro y la **carga útil proporcionada**.\
Si se produce un **error**, será bastante fácil darse cuenta de que **el servidor es vulnerable** e incluso qué **motor está en ejecución**. Pero también podrías encontrar un servidor vulnerable si esperabas que **reflejara** la carga útil proporcionada y **no se está reflejando** o si faltan algunos **caracteres** en la respuesta.
La entrada proporcionada se está **renderizando y reflejando** en la respuesta. Esto puede ser fácilmente **confundido con una vulnerabilidad** de [**XSS**](../xss-cross-site-scripting/) simple, pero es fácil diferenciarlo si intentas establecer **operaciones matemáticas** dentro de una expresión de plantilla:
Si **cambias** el parámetro **`greeting`** por un **valor diferente**, la **respuesta no contendrá el nombre de usuario**, pero si accedes a algo como: `http://vulnerable-website.com/?greeting=data.username}}hello` entonces, **la respuesta contendrá el nombre de usuario** (si los caracteres de cierre de la expresión de plantilla fueron **`}}`**).\
Si se produce un **error** durante estas pruebas, será más fácil detectar que el servidor es vulnerable.
Aunque hay una gran cantidad de lenguajes de plantillas, muchos de ellos utilizan una sintaxis muy similar que se elige específicamente para no chocar con los caracteres HTML.
Si tienes suerte, el servidor estará **imprimiendo los errores** y podrás encontrar el **motor** utilizado **dentro** de los errores. Algunas cargas útiles posibles que pueden causar errores:
De lo contrario, deberás probar manualmente **diferentes cargas específicas del lenguaje** y estudiar cómo son interpretadas por el motor de plantillas. Una forma común de hacer esto es inyectar operaciones matemáticas arbitrarias utilizando la sintaxis de diferentes motores de plantillas. Luego puedes observar si se evalúan correctamente. Para ayudar en este proceso, puedes usar un árbol de decisiones similar al siguiente:
El primer paso después de encontrar la inyección de plantillas e identificar el motor de plantillas es leer la documentación. Áreas clave de interés son:
* Secciones 'Para autores de plantillas' que cubren la sintaxis básica.
* 'Consideraciones de seguridad' - es probable que quien desarrolló la aplicación que estás probando no haya leído esto, y puede contener algunas pistas útiles.
Suponiendo que no se han presentado exploits, el siguiente paso es **explorar el entorno** para averiguar exactamente a qué **tienes acceso**. Puedes esperar encontrar tanto **objetos predeterminados** proporcionados por el motor de plantillas, como **objetos específicos de la aplicación** pasados a la plantilla por el desarrollador. Muchos sistemas de plantillas exponen un objeto 'self' o de espacio de nombres que contiene todo en el ámbito, y una forma idiomática de listar los atributos y métodos de un objeto.
Si no hay un objeto self integrado, tendrás que probar nombres de variables por fuerza bruta utilizando [SecLists](https://github.com/danielmiessler/SecLists/blob/25d4ac447efb9e50b640649f1a09023e280e5c9c/Discovery/Web-Content/burp-parameter-names.txt) y la colección de listas de palabras de Burp Intruder.
Los objetos proporcionados por el desarrollador son particularmente propensos a contener información sensible, y pueden variar entre diferentes plantillas dentro de una aplicación, por lo que este proceso idealmente debería aplicarse a cada plantilla individualmente.
En este punto, deberías tener una **idea clara de la superficie de ataque** disponible y poder proceder con técnicas tradicionales de auditoría de seguridad, revisando cada función en busca de vulnerabilidades explotables. Es importante abordar esto en el contexto de la aplicación en general - algunas funciones pueden usarse para explotar características específicas de la aplicación. Los ejemplos a seguir utilizarán la inyección de plantillas para desencadenar la creación arbitraria de objetos, la lectura/escritura arbitraria de archivos, la inclusión remota de archivos, la divulgación de información y vulnerabilidades de escalada de privilegios.
### [Tabla de Inyección de Plantillas](https://github.com/Hackmanit/template-injection-table)
una tabla interactiva que contiene los políglotos de inyección de plantillas más eficientes junto con las respuestas esperadas de los 44 motores de plantillas más importantes.
* En la sección de FreeMarker de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* En la sección de Velocity de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
La expresión de prueba típica para SSTI es `${7*7}`. Esta expresión también funciona en Thymeleaf. Si deseas lograr la ejecución de código remoto, puedes usar una de las siguientes expresiones de prueba:
Sin embargo, como mencionamos anteriormente, las expresiones solo funcionan en atributos especiales de Thymeleaf. Si es necesario usar una expresión en una ubicación diferente en la plantilla, Thymeleaf admite _inlineado de expresiones_. Para usar esta característica, debes colocar una expresión dentro de `[[...]]` o `[(...)]` (selecciona uno u otro dependiendo de si necesitas escapar símbolos especiales). Por lo tanto, un payload de detección de SSTI simple para Thymeleaf sería `[[${7*7}]]`.
Sin embargo, las posibilidades de que el payload de detección anterior funcione son muy bajas. Las vulnerabilidades de SSTI generalmente ocurren cuando una plantilla se genera dinámicamente en el código. Thymeleaf, por defecto, no permite tales plantillas generadas dinámicamente y todas las plantillas deben crearse previamente. Por lo tanto, si un desarrollador desea crear una plantilla a partir de una cadena _sobre la marcha_, necesitaría crear su propio TemplateResolver. Esto es posible pero ocurre muy raramente.
Si nos adentramos más en la documentación del motor de plantillas Thymeleaf, encontraremos una característica interesante llamada _**preprocesamiento de expresiones**_. Las expresiones colocadas entre doble guion bajo (`__...__`) son preprocesadas y el resultado del preprocesamiento se utiliza como parte de la expresión durante el procesamiento regular. Aquí tienes un ejemplo oficial de la documentación de Thymeleaf:
* [Payloads all the things](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.md#java---retrieve-etcpasswd)
Jinjava es un motor de plantillas Java que admite la inyección de plantillas en el lado del servidor (SSTI). Permite a los atacantes ejecutar código remoto en el servidor afectado.
{% set ji='a'.getClass().forName('com.hubspot.jinjava.Jinjava').newInstance().newInterpreter() %}
{% endraw %}
{{ji.render('{{1*2}}')}}
//Here, I created a variable 'ji' with new instance of com.hubspot.jinjava.Jinjava class and obtained reference to the newInterpreter method. In the next block, I called the render method on 'ji' with expression {{1*2}}.
EL proporciona un mecanismo importante para permitir que la capa de presentación (páginas web) se comunique con la lógica de la aplicación (beans administrados). EL es utilizado por **varias tecnologías de JavaEE**, como la tecnología JavaServer Faces, la tecnología JavaServer Pages (JSP) y la Inyección de Dependencias y Contextos para Java EE (CDI).\
Consulte la siguiente página para obtener más información sobre la **explotación de intérpretes EL**:
Los siguientes bypasses del Administrador de Seguridad fueron tomados de este [**informe**](https://security.humanativaspa.it/groovy-template-engine-exploitation-notes-from-a-real-case-scenario/).
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro clave para profesionales de tecnología y ciberseguridad en todas las disciplinas.
* En la sección de Smarty de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* En la sección Twig y Twig (Sandboxed) de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
Jade, ahora conocido como Pug, es un motor de plantillas de NodeJS que permite la inyección de plantillas en el lado del servidor. Puedes explotar vulnerabilidades de inyección de plantillas en Jade para ejecutar código arbitrario en el servidor.
* En la sección de Jade de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
> [patTemplate](https://github.com/wernerwa/pat-template) es un motor de plantillas PHP que no compila, el cual utiliza etiquetas XML para dividir un documento en diferentes partes.
> Jinja2 es un motor de plantillas completo para Python. Tiene soporte completo para Unicode, un entorno de ejecución en sandbox opcional, ampliamente utilizado y con licencia BSD.
El método `System.Diagnostics.Process.Start` de .NET se puede utilizar para iniciar cualquier proceso en el servidor y así crear un webshell. Puedes encontrar un ejemplo de una aplicación web vulnerable en [https://github.com/cnotin/RazorVulnerableApp](https://github.com/cnotin/RazorVulnerableApp)
* Si los datos pasados son un objeto que contiene el atributo Password por ejemplo, el payload anterior lo filtraría, pero también podrías hacer: `{{ .Password }}`
*`{{html "ssti"}}`, `{{js "ssti"}}` = Estos son algunos otros payloads que deberían mostrar la cadena "ssti" sin las palabras finales "js" o "html". Puedes consultar más palabras clave en el motor [aquí](https://golang.org/pkg/text/template).
Si el servidor está **utilizando el paquete text/template**, XSS es muy fácil de lograr simplemente proporcionando tu **payload** como entrada. Sin embargo, eso **no es el caso con html/template** ya que codifica en HTML la respuesta: `{{"<script>alert(1)</script>"}}` --> `<script>alert(1)</script>`
La documentación tanto para el módulo html/template se puede encontrar [aquí](https://golang.org/pkg/html/template/), y la documentación para el módulo text/template se puede encontrar [aquí](https://golang.org/pkg/text/template/), y sí, varían mucho. Por ejemplo, en **text/template**, puedes **llamar directamente a cualquier función pública con el valor "call"**, sin embargo, esto no es posible con html/template.
Si deseas encontrar una RCE en Go a través de SSTI, debes saber que al poder acceder al objeto dado a la plantilla con `{{ . }}`, también puedes **llamar a los métodos de los objetos**. Entonces, imagina que el **objeto pasado tiene un método llamado System** que ejecuta el comando dado, podrías abusar de él con: `{{ .System "ls" }}`\
Por lo tanto, probablemente **necesitarás el código fuente**. Un código fuente potencial para algo así se vería así:
Consulta el resto de [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection) para más exploits. También puedes encontrar información interesante sobre etiquetas en [https://github.com/DiogoMRSilva/websitesVulnerableToSSTI](https://github.com/DiogoMRSilva/websitesVulnerableToSSTI)
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro clave para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
