* Você trabalha em uma **empresa de segurança cibernética**? 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** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**RootedCON**](https://www.rootedcon.com) é o evento de segurança cibernética mais relevante na **Espanha** e um dos mais importantes na **Europa**. Com **a missão de promover conhecimento técnico**, este congresso é um ponto de encontro fervilhante para profissionais de tecnologia e segurança cibernética em todas as disciplinas.
Uma injeção de modelo no 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.
**Motores de modelo** são projetados para **gerar páginas da web** combinando **modelos fixos** com **dados voláteis**. Ataques de injeção de modelo no 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 **controle completo do servidor**.
No exemplo anterior, **parte do template** em si está sendo **gerada dinamicamente** usando o parâmetro `GET` chamado `name`. Como a sintaxe do template é avaliada no servidor, isso potencialmente permite que um atacante insira uma carga útil de injeção de template no lado do servidor dentro do parâmetro `name`, da seguinte forma:
Assim como qualquer vulnerabilidade, o primeiro passo para a exploração é ser capaz de encontrá-la. Talvez a abordagem inicial mais simples seja tentar **fuzzar o 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 pode ser facilmente **confundido com uma vulnerabilidade** [**XSS**](../xss-cross-site-scripting/) simples, 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`, **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 identificar que o servidor é vulnerável.
Depois de detectar o potencial de injeção de modelo, o próximo passo é identificar o mecanismo de modelo utilizado.\
Embora existam muitas linguagens de modelo, muitas delas usam uma sintaxe muito semelhante, 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** utilizado **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 a sintaxe de diferentes mecanismos de modelo. Em seguida, você pode 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 Modelo' que abordam 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 internas.
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 no escopo, e uma maneira idiomática de listar os atributos e métodos de um objeto.
Se não houver um objeto self incorporado, você terá que forçar nomes de 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.
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 como um todo - 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 escalonamento de privilégios.
Neste exemplo, vamos explorar como recuperar as variáveis de ambiente do sistema usando Java. Isso pode ser útil durante um teste de penetração para obter informações sobre o ambiente de execução do servidor.
O código acima usa a classe `System` do Java para acessar as variáveis de ambiente do sistema. A função `getenv()` retorna um mapa contendo todas as variáveis de ambiente e seus respectivos valores. Em seguida, percorremos o mapa e imprimimos cada chave e valor correspondente.
Ao executar esse código, você verá a lista completa das variáveis de ambiente do sistema, incluindo informações sensíveis, como senhas e chaves de API. É importante ter cuidado ao lidar com essas informações e garantir que elas não sejam expostas indevidamente.
A injeção de modelo no lado do servidor (SSTI - Server-Side Template Injection) é uma vulnerabilidade que permite a um invasor executar código arbitrário no servidor. Neste exemplo, vamos explorar uma vulnerabilidade de SSTI em um aplicativo Java para recuperar o arquivo /etc/passwd.
1. Identifique a vulnerabilidade de SSTI no aplicativo Java. Isso pode ser feito por meio de análise de código ou testes de penetração.
2. Localize o ponto de injeção de modelo no código-fonte do aplicativo. Isso geralmente ocorre quando o aplicativo usa um mecanismo de modelo que permite a inserção de código dinâmico.
3. Crie um payload que execute o comando para recuperar o arquivo /etc/passwd. Por exemplo, em um mecanismo de modelo baseado em expressões, o payload pode ser algo como `${7*7}`.
4. Injete o payload no ponto de injeção de modelo no aplicativo. Isso pode ser feito por meio de entradas de usuário ou manipulação de solicitações.
5. Execute o aplicativo e observe a resposta. Se o payload for executado com sucesso, você verá o conteúdo do arquivo /etc/passwd na resposta.
Lembre-se de que a exploração de vulnerabilidades sem permissão é ilegal e deve ser realizada apenas em sistemas autorizados para fins de teste de penetração.
* 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ê deseja obter execução de código remoto, 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 _inlining 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 de símbolos especiais). Portanto, uma carga útil simples de detecção de SSTI para o Thymeleaf seria `[[${7*7}]]`.
No entanto, as chances de que a carga útil de detecção acima funcione são muito baixas. As vulnerabilidades de SSTI geralmente ocorrem quando um modelo é gerado dinamicamente no código. O Thymeleaf, por padrão, não permite a criação de modelos dinamicamente gerados e todos os modelos devem ser criados antecipadamente. Portanto, se um desenvolvedor quiser criar um modelo a partir de uma string _na hora_, eles precisariam criar seu próprio TemplateResolver. Isso é possível, mas acontece muito raramente.
Se olharmos mais a fundo na documentação do mecanismo de modelo do Thymeleaf, encontraremos um recurso interessante chamado _**pré-processamento de expressão**_. As expressões colocadas entre dois sublinhados duplos (`__...__`) 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)
O Jinjava é um mecanismo de modelo de servidor-side escrito em Java. Ele é usado para renderizar modelos de texto com base em expressões e lógica condicional. O Jinjava suporta a injeção de modelo do lado do servidor (SSTI), que é uma vulnerabilidade que permite a execução de código arbitrário no servidor.
A injeção de modelo do lado do servidor ocorre quando um aplicativo web permite que os usuários insiram código de modelo em campos de entrada, que são posteriormente renderizados pelo servidor. Se o servidor não validar ou escapar corretamente esses campos de entrada, um atacante pode inserir código malicioso que será executado pelo servidor.
Para explorar a injeção de modelo do lado do servidor usando o Jinjava, você precisa encontrar um campo de entrada que seja renderizado pelo servidor sem validação ou escape adequados. Em seguida, você pode inserir código de modelo malicioso para executar comandos no servidor.
Para prevenir a injeção de modelo do lado do servidor, é importante validar e escapar corretamente todos os campos de entrada que são renderizados pelo servidor. Além disso, é recomendável usar uma biblioteca de modelo segura que tenha recursos de segurança embutidos para evitar a execução de código malicioso.
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 Contextos e Dependências para Java EE (CDI).\
Verifique a seguinte página para aprender mais sobre a **exploração de interpretadores EL**:
Este desvio do Security Manager foi retirado deste [**artigo**](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 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 popular usado em várias linguagens de programação, incluindo PHP. Ele fornece uma sintaxe simples e poderosa para criar templates dinâmicos. Neste guia, exploraremos a injeção de template do lado do servidor (SSTI) usando o Twig.
A injeção de template do lado do servidor (SSTI) é uma vulnerabilidade que ocorre quando um aplicativo web permite que um usuário insira código de template que é executado no servidor. Isso pode levar a ataques de execução remota de código (RCE), permitindo que um invasor execute comandos arbitrários no servidor.
A injeção de template do lado do servidor (SSTI) com o Twig ocorre quando um aplicativo web usa o Twig para renderizar templates e permite que os usuários insiram código de template arbitrário. Isso geralmente acontece quando o aplicativo não valida ou filtra adequadamente as entradas do usuário antes de passá-las para o mecanismo de template.
Um exemplo comum de injeção de template do lado do servidor (SSTI) com o Twig é quando um aplicativo permite que os usuários insiram um nome de template que é usado para carregar e renderizar um arquivo de template. Se o aplicativo não validar ou filtrar corretamente o nome do template, um invasor pode inserir um nome de template malicioso que contém código de template malicioso. Esse código será executado no servidor, permitindo que o invasor execute comandos arbitrários.
Para explorar a injeção de template do lado do servidor (SSTI) com o Twig, você precisa identificar pontos de entrada onde o código de template é inserido no aplicativo. Isso pode ser feito examinando o código-fonte do aplicativo ou usando ferramentas de análise de segurança.
Depois de identificar os pontos de entrada, você pode tentar inserir código de template malicioso para explorar a vulnerabilidade. Isso pode incluir a execução de comandos do sistema, acesso a arquivos sensíveis ou até mesmo a execução de código remoto.
Além disso, manter o Twig atualizado com as versões mais recentes também é importante, pois as atualizações podem corrigir vulnerabilidades conhecidas.
A injeção de template do lado do servidor (SSTI) com o Twig é uma vulnerabilidade séria que pode levar a ataques de execução remota de código (RCE). É importante entender como essa vulnerabilidade funciona e como preveni-la para garantir a segurança de seus aplicativos web.
* Na seção Twig e Twig (Sandboxed) de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
Este diretório contém um exemplo de aplicação web vulnerável a ataques de Injeção de Template do Lado do Servidor (SSTI). A vulnerabilidade ocorre quando um aplicativo web permite que o usuário insira código de template que é executado no servidor.
O arquivo `authors.php` é um exemplo de página que exibe informações sobre autores de livros. Ele usa um mecanismo de template para renderizar os dados na página. No entanto, o aplicativo não valida ou filtra adequadamente as entradas do usuário, o que permite a injeção de código de template malicioso.
Para explorar essa vulnerabilidade, você pode inserir código de template malicioso na entrada do parâmetro `author` na URL. O código de template será executado no servidor e poderá ser usado para executar comandos arbitrários, ler arquivos sensíveis ou realizar outras ações indesejadas.
Por exemplo, você pode tentar inserir o seguinte código de template na URL:
```
http://localhost/authors.php?author={{7*7}}
```
Isso resultará na exibição do resultado da expressão `7*7` na página.
Para mitigar essa vulnerabilidade, é importante validar e filtrar adequadamente as entradas do usuário antes de usá-las em um mecanismo de template. Isso pode ser feito usando bibliotecas ou frameworks que possuem recursos de segurança embutidos para evitar a execução de código malicioso.
Além disso, é recomendável manter todos os componentes do aplicativo web atualizados com as versões mais recentes, pois as atualizações frequentemente corrigem vulnerabilidades conhecidas.
O Jade é um mecanismo de modelo de servidor-side para NodeJS que permite a injeção de código no lado do servidor. Ele é usado para gerar HTML dinamicamente com base em modelos. No entanto, a injeção de modelo no lado do servidor pode levar a vulnerabilidades de injeção de código, como a injeção de modelo no lado do servidor (SSTI).
A injeção de modelo no lado do servidor ocorre quando um invasor consegue inserir código malicioso em um modelo que é posteriormente processado pelo servidor. Isso pode permitir que o invasor execute código arbitrário no servidor, o que pode levar a uma série de problemas de segurança, como vazamento de informações confidenciais, execução remota de código e comprometimento do servidor.
Para explorar uma vulnerabilidade de SSTI no Jade, um invasor precisa encontrar um ponto de injeção no modelo e inserir código malicioso. Isso pode ser feito através da manipulação de entradas do usuário ou da exploração de falhas de validação de entrada no código do aplicativo.
Para mitigar o risco de SSTI no Jade, é importante seguir as práticas recomendadas de segurança, como:
Ao realizar testes de penetração em um aplicativo que usa o Jade como mecanismo de modelo, é importante verificar se existem pontos de injeção de modelo no lado do servidor e tentar explorar essas vulnerabilidades para identificar possíveis riscos de segurança.
> [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 mecanismo de template completo para Python. Possui suporte completo a unicode, um ambiente de execução integrado opcionalmente isolado, amplamente utilizado e licenciado sob a BSD.
Jinja2 é um mecanismo de template popular para Python. Ele permite a criação de templates dinâmicos, onde é possível inserir variáveis, estruturas de controle e expressões dentro do código HTML. Os templates Jinja2 são salvos com a extensão `.html` e podem ser renderizados pelo servidor web.
**Injeção de Template do Lado do Servidor (SSTI)**
A Injeção de Template do Lado do Servidor (SSTI) é uma vulnerabilidade que ocorre quando um aplicativo web permite que o usuário insira código malicioso em um template. Isso pode levar à execução de código arbitrário no servidor, permitindo que um invasor comprometa o sistema.
Para explorar a SSTI, é necessário identificar onde o código injetado é processado e renderizado pelo servidor. Em muitos casos, os aplicativos web usam o mecanismo de template Jinja2 para renderizar os templates. Portanto, é importante entender a sintaxe e as funcionalidades do Jinja2 para explorar essa vulnerabilidade.
**Sintaxe do Jinja2**
O Jinja2 usa uma sintaxe semelhante ao Python para inserir variáveis e expressões nos templates. As variáveis são colocadas entre chaves duplas `{{ }}`, enquanto as estruturas de controle são colocadas entre chaves percentuais `{% %}`. Além disso, é possível usar filtros para modificar os valores das variáveis.
**Exemplo de Template Jinja2**
Aqui está um exemplo de um template Jinja2 básico:
```html
<!DOCTYPE html>
<html>
<head>
<title>Exemplo de Template Jinja2</title>
</head>
<body>
<h1>Bem-vindo(a), {{ nome }}!</h1>
<p>Seu saldo atual é de R$ {{ saldo | floatformat(2) }}.</p>
</body>
</html>
```
Neste exemplo, o template exibe uma mensagem de boas-vindas com o nome do usuário e o saldo atual formatado com duas casas decimais.
**Prevenção da Injeção de Template do Lado do Servidor**
Para prevenir a SSTI, é importante validar e sanitizar todas as entradas do usuário antes de processá-las nos templates. Além disso, é recomendado desabilitar recursos perigosos do Jinja2, como a execução de código Python.
**Conclusão**
A Injeção de Template do Lado do Servidor é uma vulnerabilidade séria que pode permitir a execução de código arbitrário no servidor. Ao entender a sintaxe e as funcionalidades do Jinja2, é possível explorar essa vulnerabilidade e tomar medidas para preveni-la.
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 template
* Se os dados passados forem um objeto que contém o atributo Password, por exemplo, o payload anterior vazaria isso, mas você também poderia fazer: `{{ .Password }}`
*`{{printf "%s" "ssti" }}` = deve exibir a string ssti na resposta
*`{{html "ssti"}}`, `{{js "ssti"}}` = Esses são alguns outros payloads que devem exibir a string "ssti" sem as palavras "js" ou "html" no final. Você pode consultar mais palavras-chave no mecanismo [aqui](https://golang.org/pkg/text/template).
Se o servidor estiver **usando o pacote text/template**, é muito fácil alcançar o XSS **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 o módulo 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 são diferentes, muito diferentes. 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ê deseja encontrar um RCE em Go via SSTI, saiba que, assim como você pode acessar o objeto fornecido ao template com `{{ . }}`, você também pode **chamar os métodos do objeto**. Portanto, imagine que o **objeto passado tenha um método chamado System** que executa o comando fornecido, você pode abusar dele com: `{{ .System "ls" }}`\
Portanto, provavelmente você **precisará do código-fonte**. Um código-fonte potencial para algo assim seria:
Verifique 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) para mais exploits. Você também pode encontrar informações interessantes sobre 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)!
* 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 seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
