* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**RootedCON**](https://www.rootedcon.com) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
Uma injeção de modelo do lado do servidor ocorre quando um invasor é capaz de usar a sintaxe nativa do modelo para injetar uma carga maliciosa em um modelo, que é então executado no lado do servidor.
Os **motores de modelo** são projetados para **gerar páginas da web** combinando modelos **fixos** com dados **voláteis**. Os ataques de injeção de modelo do lado do servidor podem ocorrer quando a **entrada do usuário** é concatenada diretamente **em um modelo**, em vez de ser passada como dados. Isso permite que os invasores **injetem diretivas de modelo arbitrárias** para manipular o motor de modelo, muitas vezes permitindo que eles assumam **o controle completo do servidor**.
No exemplo anterior, **parte do modelo** em si está sendo **gerada dinamicamente** usando o parâmetro `name` do método `GET`. Como a sintaxe do modelo é avaliada no lado do servidor, isso potencialmente permite que um invasor coloque uma carga útil de injeção de modelo do lado do servidor dentro do parâmetro `name` da seguinte forma:
Assim como em qualquer vulnerabilidade, o primeiro passo para a exploração é ser capaz de encontrá-la. Talvez a abordagem inicial mais simples seja tentar **fuzzing do modelo** injetando uma sequência de caracteres especiais comumente usados em expressões de modelo, como o poliglota **`${{<%[%'"}}%\`.**\
Para verificar se o servidor é vulnerável, você deve **observar as diferenças** entre a resposta com **dados regulares** no parâmetro e a **carga útil fornecida**.\
Se um **erro for lançado**, será bastante fácil descobrir que **o servidor é vulnerável** e até mesmo qual **motor está sendo executado**. Mas você também pode encontrar um servidor vulnerável se estiver **esperando** que ele **reflita** a carga útil fornecida e ela **não estiver sendo refletida** ou se houver alguns **caracteres ausentes** na resposta.
A entrada fornecida está sendo **renderizada e refletida** na resposta. Isso é facilmente **confundido com uma vulnerabilidade simples** [**XSS**](../xss-cross-site-scripting/), mas é fácil diferenciar se você tentar definir **operações matemáticas** dentro de uma expressão de modelo:
Se você **alterar** o parâmetro **`greeting`** para um **valor diferente**, a **resposta não conterá o nome de usuário**, mas se você acessar algo como: `http://vulnerable-website.com/?greeting=data.username}}hello`, então **a resposta conterá o nome de usuário** (se os caracteres de fechamento da expressão do modelo forem **`}}`**).\
Se ocorrer um **erro** durante esses testes, será mais fácil descobrir que o servidor é vulnerável.
Depois de detectar o potencial de injeção de modelo, o próximo passo é identificar o mecanismo de modelo.\
Embora existam muitas linguagens de modelo, muitas delas usam uma sintaxe muito semelhante que é escolhida especificamente para não entrar em conflito com os caracteres HTML.
Se você tiver sorte, o servidor estará **imprimindo os erros** e você poderá encontrar o **mecanismo** usado **dentro** dos erros. Alguns payloads possíveis que podem causar erros:
Caso contrário, você precisará testar manualmente **diferentes payloads específicos da linguagem** e estudar como eles são interpretados pelo mecanismo de modelo. Uma maneira comum de fazer isso é injetar operações matemáticas arbitrárias usando sintaxe de diferentes mecanismos de modelo. Você pode então observar se eles são avaliados com sucesso. Para ajudar nesse processo, você pode usar uma árvore de decisão semelhante à seguinte:
* Seções 'Para autores de modelos' que cobrem a sintaxe básica.
* 'Considerações de segurança' - é provável que quem desenvolveu o aplicativo que você está testando não tenha lido isso, e pode conter algumas dicas úteis.
* Listas de métodos, funções, filtros e variáveis integrados.
* Listas de extensões/plugins - alguns podem estar habilitados por padrão.
Assumindo que nenhum exploit tenha se apresentado, o próximo passo é **explorar o ambiente** para descobrir exatamente o que **você tem acesso**. Você pode esperar encontrar tanto **objetos padrão** fornecidos pelo mecanismo de modelo, quanto **objetos específicos do aplicativo** passados para o modelo pelo desenvolvedor. Muitos sistemas de modelo expõem um objeto 'self' ou namespace contendo tudo em escopo, e uma maneira idiomática de listar os atributos e métodos de um objeto.
Se não houver um objeto self integrado, você terá que forçar o nome das variáveis usando [SecLists](https://github.com/danielmiessler/SecLists/blob/25d4ac447efb9e50b640649f1a09023e280e5c9c/Discovery/Web-Content/burp-parameter-names.txt) e a coleção de wordlists do Burp Intruder.
Os objetos fornecidos pelo desenvolvedor são particularmente propensos a conter informações sensíveis e podem variar entre diferentes modelos dentro de um aplicativo, portanto, esse processo deve ser aplicado idealmente a cada modelo distinto individualmente.
Neste ponto, você deve ter uma **ideia clara da superfície de ataque disponível** e ser capaz de prosseguir com técnicas tradicionais de auditoria de segurança, revisando cada função em busca de vulnerabilidades exploráveis. É importante abordar isso no contexto do aplicativo mais amplo - algumas funções podem ser usadas para explorar recursos específicos do aplicativo. Os exemplos a seguir usarão a injeção de modelo para acionar a criação arbitrária de objetos, leitura/gravação arbitrária de arquivos, inclusão remota de arquivos, divulgação de informações e vulnerabilidades de escalonamento de privilégios.
**Java - Recuperar as variáveis de ambiente do sistema**
Para recuperar as variáveis de ambiente do sistema em Java, podemos usar a classe `System` e o método `getenv()`. Este método retorna um objeto `Map` que contém todas as variáveis de ambiente do sistema e seus valores.
* Na seção FreeMarker de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* Na seção Velocity de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
A expressão de teste típica para SSTI é `${7*7}`. Essa expressão também funciona no Thymeleaf. Se você quiser obter execução remota de código, pode usar uma das seguintes expressões de teste:
No entanto, como mencionamos antes, as expressões só funcionam em atributos especiais do Thymeleaf. Se for necessário usar uma expressão em uma localização diferente no modelo, o Thymeleaf suporta _inline de expressão_. Para usar esse recurso, você deve colocar uma expressão dentro de `[[...]]` ou `[(...)]` (selecione um ou outro dependendo se você precisa escapar símbolos especiais). Portanto, uma carga útil de detecção SSTI simples para Thymeleaf seria `[[${7*7}]]`.
No entanto, as chances de que a carga útil de detecção acima funcione são muito baixas. As vulnerabilidades SSTI geralmente ocorrem quando um modelo é gerado dinamicamente no código. O Thymeleaf, por padrão, não permite modelos gerados dinamicamente e todos os modelos devem ser criados anteriormente. Portanto, se um desenvolvedor quiser criar um modelo a partir de uma string _on the fly_, eles precisariam criar seu próprio TemplateResolver. Isso é possível, mas acontece muito raramente.
Se olharmos mais profundamente na documentação do mecanismo de modelo Thymeleaf, encontraremos um recurso interessante chamado _**pré-processamento de expressão**_. As expressões colocadas entre dois sublinhados (`__...__`) são pré-processadas e o resultado do pré-processamento é usado como parte da expressão durante o processamento regular. Aqui está um exemplo oficial da documentação do Thymeleaf:
* [Payloads all the things](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.md#java---retrieve-etcpasswd)
Jinjava é uma linguagem de modelo Java segura para o sandbox que é usada para renderizar modelos. Ele fornece uma ampla gama de recursos, incluindo herança de modelos, macros, filtros e muito mais. No entanto, ele também é vulnerável a ataques de injeção de modelo do lado do servidor (SSTI) se não for usado corretamente.
Para explorar uma vulnerabilidade de SSTI no Jinjava, você pode tentar injetar código malicioso em uma variável de modelo. Isso pode ser feito usando a sintaxe `{{ <code> }}`, onde `<code>` é o código que você deseja injetar. Por exemplo, se você quiser executar o comando `ls` no servidor, pode tentar injetar o seguinte código:
Isso deve listar o conteúdo do diretório atual no servidor. No entanto, tenha em mente que a execução de código malicioso em um servidor sem permissão é ilegal e pode resultar em consequências graves. Portanto, use essas técnicas apenas para fins educacionais e éticos.
Jinjava é um projeto de código aberto desenvolvido pela Hubspot, disponível em [https://github.com/HubSpot/jinjava/](https://github.com/HubSpot/jinjava/)
//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 fornece um mecanismo importante para permitir que a camada de apresentação (páginas da web) se comunique com a lógica da aplicação (beans gerenciados). O EL é usado por **várias tecnologias JavaEE**, como a tecnologia JavaServer Faces, a tecnologia JavaServer Pages (JSP) e a Injeção de Dependência e Contextos para Java EE (CDI).\
Verifique a seguinte página para aprender mais sobre a **exploração dos interpretadores EL**:
Este bypass do Security Manager foi retirado deste [**writeup**](https://security.humanativaspa.it/groovy-template-engine-exploitation-notes-from-a-real-case-scenario/).
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com a missão de promover o conhecimento técnico, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
* Na seção Smarty de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
Twig é um mecanismo de template moderno para PHP. É uma biblioteca poderosa e flexível que permite injetar dados dinamicamente em modelos de página da web. O Twig é usado em muitos sistemas de gerenciamento de conteúdo, como o Drupal e o Symfony, e é uma das bibliotecas de template mais populares para PHP.
O Twig usa uma sintaxe simples e fácil de entender que permite aos desenvolvedores criar modelos de página da web complexos com facilidade. Ele também inclui recursos avançados, como herança de modelo, macros e filtros, que permitem que os desenvolvedores criem modelos de página da web altamente personalizados e reutilizáveis.
No entanto, o Twig também é vulnerável a ataques de injeção de modelo do lado do servidor (SSTI). Os atacantes podem explorar essas vulnerabilidades para injetar código malicioso nos modelos de página da web e executá-lo no servidor. É importante que os desenvolvedores estejam cientes dessas vulnerabilidades e tomem medidas para proteger seus aplicativos contra elas.
* Na seção Twig e Twig (Sandboxed) de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
A Injeção de modelo do lado do servidor (SSTI) é uma vulnerabilidade de segurança que permite que um invasor execute código do lado do servidor em um aplicativo da web. Isso ocorre quando um aplicativo da web permite que o usuário insira dados que são usados para construir um modelo do lado do servidor. Se o aplicativo não validar adequadamente esses dados, um invasor pode inserir código malicioso que será executado pelo servidor.
A SSTI ocorre quando um aplicativo da web usa um mecanismo de modelo que permite que o usuário insira dados que são usados para construir um modelo do lado do servidor. O modelo é então renderizado pelo servidor e enviado ao navegador do usuário. Se o aplicativo não validar adequadamente esses dados, um invasor pode inserir código malicioso que será executado pelo servidor.
A exploração da SSTI geralmente envolve a inserção de código malicioso em um modelo do lado do servidor. Isso pode ser feito de várias maneiras, dependendo do mecanismo de modelo usado pelo aplicativo da web. Alguns mecanismos de modelo populares incluem Jinja2, Twig, Freemarker e Velocity.
Para explorar a SSTI, um invasor pode inserir código malicioso em um modelo do lado do servidor e enviar a solicitação para o aplicativo da web. O servidor renderizará o modelo e executará o código malicioso, permitindo que o invasor execute comandos no servidor.
## Como prevenir a SSTI?
A prevenção da SSTI envolve a validação adequada dos dados de entrada do usuário. Os aplicativos da web devem validar todos os dados de entrada do usuário e garantir que eles não possam ser usados para injetar código malicioso em modelos do lado do servidor.
Além disso, os aplicativos da web devem usar mecanismos de modelo seguros que não permitem a execução de código malicioso. Alguns mecanismos de modelo seguros incluem Mustache e Handlebars.
## Conclusão
A SSTI é uma vulnerabilidade de segurança séria que pode permitir que um invasor execute código do lado do servidor em um aplicativo da web. Os desenvolvedores de aplicativos da web devem estar cientes dessa vulnerabilidade e tomar medidas para preveni-la em seus aplicativos.
A Injeção de modelo do lado do servidor (SSTI) é uma vulnerabilidade de segurança que ocorre quando um aplicativo da web permite que os usuários insiram código em um modelo que é posteriormente executado no servidor. Isso pode permitir que um invasor execute código malicioso no servidor, o que pode levar a uma série de problemas de segurança, incluindo vazamento de informações confidenciais.
## Técnicas de exploração
Existem várias técnicas que podem ser usadas para explorar vulnerabilidades SSTI, incluindo:
- Inserção de código malicioso em um modelo que é posteriormente executado no servidor.
- Exploração de falhas de validação de entrada para inserir código malicioso em um modelo.
- Aproveitamento de recursos do servidor para executar código malicioso em um modelo.
## Prevenção
Para prevenir vulnerabilidades SSTI, é importante seguir as práticas recomendadas de segurança da web, incluindo:
- Validar todas as entradas do usuário antes de usá-las em um modelo.
- Usar bibliotecas de modelo seguras que não permitem a execução de código malicioso.
- Limitar o acesso do usuário a recursos do servidor que podem ser usados para executar código malicioso.
- Manter o software do servidor atualizado com as últimas correções de segurança.
## Exemplos de exploração
Os exemplos de exploração de vulnerabilidades SSTI podem variar dependendo do aplicativo da web específico e da tecnologia subjacente. Alguns exemplos comuns incluem:
A Injeção de modelo do lado do servidor (SSTI) é uma vulnerabilidade de segurança séria que pode levar a uma série de problemas de segurança, incluindo vazamento de informações confidenciais e comprometimento do servidor. É importante seguir as práticas recomendadas de segurança da web e manter o software do servidor atualizado para prevenir vulnerabilidades SSTI.
Este arquivo é um exemplo de como a injeção de modelo do lado do servidor (SSTI) pode ser explorada em um site. A vulnerabilidade SSTI ocorre quando um aplicativo da web permite que o usuário insira dados que são posteriormente processados como um modelo. Se o aplicativo não validar adequadamente os dados de entrada, um invasor pode inserir código malicioso que será executado no servidor.
Neste exemplo, o arquivo `authors.php` é vulnerável a uma injeção SSTI porque ele usa o mecanismo de modelo Smarty e não valida adequadamente a entrada do usuário. Um invasor pode explorar essa vulnerabilidade para executar código arbitrário no servidor e, potencialmente, obter acesso não autorizado a dados confidenciais.
Jade é um mecanismo de modelo de servidor que permite a injeção de código no lado do servidor. Ele é usado para gerar HTML dinamicamente no servidor e é comumente usado em aplicativos NodeJS. A injeção de modelo do lado do servidor (SSTI) pode ocorrer quando o aplicativo usa o Jade para renderizar modelos sem sanitizar adequadamente a entrada do usuário. Isso pode permitir que um invasor injete código malicioso no modelo, que é então executado no servidor. Para explorar essa vulnerabilidade, um invasor pode enviar uma carga útil maliciosa como entrada do usuário, que é então injetada no modelo e executada no servidor.
> [patTemplate](https://github.com/wernerwa/pat-template) é um mecanismo de modelagem PHP não compilado que usa tags XML para dividir um documento em diferentes partes.
> Jinja2 é um motor de template completo para Python. Ele tem suporte total a unicode, um ambiente de execução integrado opcionalmente isolado, amplamente utilizado e licenciado sob BSD.
O Jinja2 é um mecanismo de template para Python muito poderoso e flexível. Ele é amplamente utilizado em muitos frameworks web, como o Flask, e é uma das opções mais populares para a renderização de templates em Python.
Os templates do Jinja2 são escritos em arquivos de texto simples com extensão `.html` ou `.j2`. Eles contêm marcações especiais que permitem a inserção de variáveis, estruturas de controle e outras funcionalidades.
As marcações do Jinja2 são delimitadas por chaves duplas `{{ }}` para expressões e `{% %}` para comandos. Por exemplo, para exibir o valor de uma variável `nome` em um template, podemos usar a seguinte marcação:
O Jinja2 também suporta herança de templates, filtros, macros e outras funcionalidades avançadas que podem ser úteis na criação de templates complexos e reutilizáveis.
O Mako é um mecanismo de modelo de renderização de texto para Python. Ele é usado para gerar HTML, XML, e-mails, código-fonte e outros formatos de texto a partir de modelos. O Mako é semelhante ao Jinja em muitos aspectos, mas tem uma sintaxe diferente. Para explorar vulnerabilidades de injeção de modelo no Mako, você pode usar as mesmas técnicas que no Jinja.
O método `System.Diagnostics.Process.Start` do .NET pode ser usado para iniciar qualquer processo no servidor e, assim, criar um webshell. Você pode encontrar um exemplo de aplicativo da web vulnerável em [https://github.com/cnotin/RazorVulnerableApp](https://github.com/cnotin/RazorVulnerableApp)
*`{{ . }}` = estrutura de dados sendo passada como entrada para o modelo
* Se os dados passados forem um objeto que contém o atributo Password, por exemplo, o payload anterior vazaria, mas você também poderia fazer: `{{ .Password }}`
*`{{printf "%s" "ssti" }}` = deve produzir a string ssti na resposta
*`{{html "ssti"}}`, `{{js "ssti"}}` = Esses são alguns outros payloads que devem produzir a string "ssti" sem as palavras finais "js" ou "html". Você pode se referir a mais palavras-chave no mecanismo [aqui](https://golang.org/pkg/text/template).
Se o servidor estiver **usando o pacote text/template**, o XSS é muito fácil de alcançar **simplesmente** fornecendo seu **payload** como entrada. No entanto, isso **não é o caso com html/template** pois ele codifica a resposta em HTML: `{{"<script>alert(1)</script>"}}` --> `<script>alert(1)</script>`
A documentação para ambos os módulos html/template pode ser encontrada [aqui](https://golang.org/pkg/html/template/), e a documentação para o módulo text/template pode ser encontrada [aqui](https://golang.org/pkg/text/template/), e sim, elas variam, muito. Por exemplo, em **text/template**, você pode **chamar diretamente qualquer função pública com o valor "call"**, no entanto, esse não é o caso com html/template.
Se você quiser encontrar um RCE em Go via SSTI, você deve saber que, assim como você pode acessar o objeto fornecido ao modelo com `{{ . }}`, você também pode **chamar os métodos dos objetos**. Então, imagine que o **objeto passado tenha um método chamado System** que execute o comando fornecido, você poderia abusar dele com: `{{ .System "ls" }}`\
Portanto, você provavelmente **precisará do código-fonte**. Um código-fonte potencial para algo assim seria:
Confira o restante em [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection). Você também pode encontrar informações interessantes em tags em [https://github.com/DiogoMRSilva/websitesVulnerableToSSTI](https://github.com/DiogoMRSilva/websitesVulnerableToSSTI)
[**RootedCON**](https://www.rootedcon.com/) é o evento de cibersegurança mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover o conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e cibersegurança em todas as disciplinas.
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
