Injeção de modelo no servidor expõe aplicações web a execução remota de comandos

Falhas de SSTI permitem que entrada controlada pelo usuário seja interpretada por mecanismos de template, com risco de execução de comandos, leitura de arquivos e tomada de controle do servidor vulnerável.

Componente	Aplicações web que passam entrada do usuário para mecanismos de template no servidor, incluindo ambientes com Jinja2, Freemarker e Twig.
Vetor	Entrada controlada pelo usuário é incorporada a um template e interpretada no servidor; ataques observados usam fuzzing, SSTI cega, consultas DNS fora de banda e payloads ofuscados.
Impacto	Execução arbitrária de comandos, leitura condicionada de arquivos locais, possível controle do ambiente do servidor e uso indevido de recursos computacionais.
Prioridade	Revisar pontos de renderização dinâmica, corrigir produtos afetados, bloquear interpretação de entrada não confiável e monitorar sinais de execução fora de banda.
Versões e produtos citados	Foram citados casos envolvendo Atlassian Confluence, CrushFTP, Rejetto HTTP File Server, CVE-2022-22954, CVE-2024-28254 e CVE-2016-4977.
Telemetria	Atenção a latência anormal induzida por funções como sleep, consultas DNS inesperadas, uso de RMI, dados codificados em Base64 e chamadas indiretas a funções como eval, exec, getFilter e Character.toString.

Resumo técnico

A injeção de modelo no servidor, conhecida como SSTI, ocorre quando uma aplicação web mistura dados controlados pelo usuário com um mecanismo de template executado no lado do servidor. O problema não está apenas na presença de conteúdo dinâmico, mas na ausência de separação segura entre valores tratados como dados e expressões tratadas como código pelo mecanismo de renderização. Quando essa fronteira é violada, a entrada enviada por um cliente pode ser avaliada como parte do template, abrindo caminho para execução de comandos, acesso a informações do ambiente e abuso de funcionalidades internas da aplicação.

A classe de falha é relevante porque aparece em diferentes pilhas de desenvolvimento, incluindo Jinja2 em Python, Freemarker em Java e Twig em PHP. Em ambientes expostos à internet, a vulnerabilidade pode ser acionada remotamente se o ponto vulnerável aceitar entrada externa e repassá-la ao template sem tratamento adequado. O impacto depende do mecanismo usado, das permissões do processo da aplicação, das bibliotecas acessíveis e das restrições do sistema operacional, mas os exemplos analisados mostram desde validação cega por tempo de resposta até cadeias com ofuscação e tentativa de obter controle interativo do servidor.

Nos três meses observados, ataques relacionados a SSTI impactaram, em média, uma em cada 16 organizações por semana. O setor de varejo e atacado apareceu com maior incidência, com média semanal de uma em cada 11 organizações afetadas. A maior exposição desse segmento é consistente com aplicações públicas, grande volume transacional, integrações de comércio eletrônico, sistemas legados e manipulação de dados de clientes. Organizações em nuvem também apareceram com frequência semanal aproximadamente 30% superior à de ambientes locais, o que reforça a importância de revisar integrações, limites de responsabilidade e cobertura de monitoramento em aplicações distribuídas.

Fluxo técnico

O fluxo de exploração começa com a identificação de pontos nos quais a aplicação reflete, transforma ou combina entrada do usuário com templates. Em uma aplicação vulnerável, campos de formulário, parâmetros de URL, cabeçalhos, rotas ou valores persistidos podem ser renderizados por um mecanismo que aceita expressões. O atacante tenta distinguir respostas normais de respostas alteradas pela avaliação do template. Essa etapa costuma usar fuzzing para enviar variações de entrada e observar diferenças no conteúdo retornado, em erros gerados, em tempos de resposta ou em interações externas produzidas pelo servidor.

Quando a saída da expressão não aparece diretamente na resposta HTTP, a exploração passa a depender de SSTI cega. Nessa condição, o atacante não vê o resultado do comando ou da expressão no corpo da resposta, mas infere execução por efeitos laterais. O uso de uma função como sleep permite medir atraso de resposta e confirmar que a expressão foi processada no servidor. Consultas DNS acionadas por utilitários como nslookup também podem ser usadas como confirmação fora de banda: apenas servidores vulneráveis fazem a requisição esperada para um domínio controlado pelo operador. O mesmo raciocínio aparece no uso de RMI em ambientes Java, quando a aplicação é induzida a iniciar uma interação remota.

Ferramentas de captura de interações fora de banda, como Interactsh, e serviços de DNS usados em testes, como domínio defangado dnslog[.]cn, aparecem como mecanismos de confirmação de vulnerabilidade. A função defensiva desses artefatos é clara: eles mostram que uma requisição saiu do servidor da vítima, o que ajuda a comprovar execução sem depender de resposta visível no navegador. Para defesa, o ponto central é que esse padrão também deixa rastros: consultas DNS incomuns, conexões de saída não esperadas e correlação temporal entre requisições HTTP suspeitas e tráfego externo devem ser investigadas como possível exploração de template.

A ofuscação é parte importante do fluxo observado. Cadeias codificadas em Base64, chamadas indiretas a eval e exec, uso de getFilter em implementação PHP e construção de strings com Character.toString em Java reduzem a eficácia de bloqueios baseados apenas em palavras-chave. Em exemplos citados, a decodificação em camadas expõe ações como leitura de arquivo local, tentativa de execução de comando e preparação de conexão reversa. O detalhe operacional do payload não é necessário para a defesa; o ponto técnico é que o template pode ser usado como ponte entre entrada HTTP e execução no sistema operacional, especialmente quando a aplicação expõe funções perigosas ao contexto de renderização.

Superfície afetada

A superfície afetada inclui aplicações que geram HTML ou outro conteúdo dinâmico usando template do lado do servidor e aceitam dados externos sem isolamento adequado. O risco aumenta quando desenvolvedores concatenam trechos de template com valores de usuário, quando funcionalidades administrativas permitem editar modelos, quando integrações de terceiros populam campos renderizados sem validação, ou quando erros de configuração expõem objetos, funções e métodos além do necessário para a renderização. O problema pode estar tanto em código próprio quanto em produtos prontos implantados pela organização.

Casos envolvendo Atlassian Confluence, CrushFTP e Rejetto HTTP File Server foram citados como exemplos de plataformas visadas e exploradas em ataques reais relacionados a SSTI. Também foram mencionadas vulnerabilidades identificadas como CVE-2022-22954, CVE-2024-28254 e CVE-2016-4977, com técnicas que incluem payload Java injetado em expressão, camadas de codificação e concatenação de caracteres para ocultar comandos. A presença desses identificadores no histórico operacional indica que a revisão deve cobrir tanto aplicações internas quanto produtos de terceiros expostos à internet.

Ambientes em nuvem merecem atenção adicional porque a complexidade de integrações, a distribuição de responsabilidades e a dependência de serviços externos podem esconder lacunas entre aplicação, rede, identidade e monitoramento. SSTI não é exclusiva de nuvem, mas aplicações cloud costumam concentrar APIs públicas, pipelines frequentes, múltiplos domínios, serviços gerenciados e permissões associadas a identidades de workload. Se o processo vulnerável tiver acesso a segredos, metadados, buckets, filas ou bancos internos, a execução de comandos pode ampliar o impacto além do servidor web.

• Aplicações web que renderizam templates com entrada de usuários, parceiros, APIs ou conteúdo persistido.
• Motores de template citados: Jinja2, Freemarker e Twig.
• Produtos e plataformas citados em ataques reais: Atlassian Confluence, CrushFTP e Rejetto HTTP File Server.
• Ambientes de nuvem com integrações de terceiros, permissões amplas de workload ou cobertura parcial de logs.

Hunting e telemetria

A caça deve começar nos logs de aplicação e proxy reverso, buscando requisições com padrões incompatíveis com uso normal do sistema. Em SSTI, a entrada suspeita pode aparecer em parâmetros, cabeçalhos, corpo de requisição, campos de busca, nomes de arquivo, filtros, comentários e rotas dinâmicas. Nem todo payload aparece legível: dados codificados em Base64, fragmentos concatenados, chamadas a funções internas e sequências com sintaxe de template podem indicar tentativa de contornar validação. A correlação com códigos de erro, exceções do mecanismo de template e variação incomum no tempo de resposta ajuda a separar ruído de exploração efetiva.

SSTI cega exige correlação entre camadas. Atrasos de resposta próximos a padrões induzidos por sleep, consultas DNS para domínios raros, conexões de saída logo após uma requisição específica e tentativas de resolução por ferramentas como nslookup são sinais úteis. Em Java, eventos relacionados a RMI e carregamento remoto de objetos devem ser avaliados com rigor. Em PHP e Java, chamadas indiretas a exec, eval, getFilter ou construção de strings com Character.toString podem aparecer em logs de erro, telemetria de endpoint, trilhas de EDR ou registros de auditoria da aplicação.

No endpoint, a defesa deve procurar processos filhos anômalos gerados pelo serviço web, leitura de arquivos locais sensíveis, criação inesperada de conexões de saída e consumo elevado de CPU que possa indicar mineração de criptomoeda. O contexto cita uso de SSTI para mineração clandestina antes ou depois da validação da vulnerabilidade, o que torna métricas de recurso e processos desconhecidos sinais relevantes. Em cloud, logs de DNS, VPC Flow Logs, eventos de identidade, acesso a metadados e chamadas incomuns a serviços internos devem ser avaliados em conjunto com a aplicação que recebeu a requisição original.

• Requisições HTTP contendo sintaxe de template, dados em Base64, concatenação de caracteres ou chamadas a funções sensíveis.
• Latência anormal em respostas associada a testes baseados em sleep.
• Consultas DNS e conexões de saída para destinos raros após requisições suspeitas.
• Processos filhos inesperados do servidor web e uso incomum de CPU, memória ou rede.
• Erros de template, exceções de avaliação e referências a Jinja2, Freemarker, Twig, RMI, eval ou exec em logs.

Mitigação

A mitigação mais importante é impedir que entrada não confiável seja tratada como template. Valores fornecidos por usuários devem ser passados ao mecanismo de renderização como dados, nunca concatenados como expressão executável. Quando a aplicação permite templates customizados, o recurso deve operar em sandbox restrito, com lista explícita de funções permitidas, sem acesso a APIs de sistema, objetos internos, chamadas de rede ou funções de execução. Validação de entrada ajuda, mas não substitui isolamento correto do mecanismo de template.

Produtos de terceiros citados no histórico de exploração devem ser inventariados, expostos à internet ou não, e avaliados contra correções disponíveis do fornecedor. A ordem de resposta deve priorizar instâncias públicas, sistemas com autenticação fraca, aplicações que manipulam dados sensíveis e workloads com permissões amplas. Em ambientes de nuvem, a correção da aplicação deve ser acompanhada de revisão de identidades, segredos, acesso a metadados, egress de rede e permissões para serviços internos, porque a exploração pode transformar uma falha de renderização em ponto de execução dentro do ambiente.

Controles compensatórios devem reduzir tanto a chance de exploração quanto o impacto. WAF e IDS podem bloquear padrões conhecidos, mas devem ser combinados com detecção comportamental para ofuscação em Base64, consultas DNS fora de banda e processos filhos anômalos. Restringir tráfego de saída do servidor web, registrar DNS, limitar permissões do usuário do processo, separar segredos por função e ativar alertas para execução de comandos aumentam a capacidade de contenção. Após qualquer suspeita de exploração, a validação deve incluir revisão de logs, análise de processos, rotação de segredos acessíveis ao serviço e confirmação de que o ponto de renderização não interpreta mais entrada externa.

• Remover concatenação de entrada do usuário dentro de templates e tratar valores externos apenas como dados.
• Aplicar correções em produtos afetados e priorizar instâncias expostas publicamente.
• Executar mecanismos de template com sandbox, lista mínima de funções e permissões reduzidas.
• Bloquear ou registrar egress desnecessário, especialmente DNS e conexões iniciadas por servidores web.
• Correlacionar logs de aplicação, endpoint, DNS, rede e identidade após qualquer indício de SSTI.