Rejetto HTTP File Server 2.3m Unauthenticated RCE

Falha de Server-Side Template Injection (SSTI) no motor de templates proprietário do Rejetto HTTP File Server (HFS) 2.x, que permite a um atacante remoto e não autenticado executar comandos arbitrários no sistema com uma única requisição HTTP. É explorada ativamente (está no catálogo KEV da CISA) e tem módulo Metasploit e template Nuclei públicos, mas o HFS 2.x está descontinuado — não haverá patch para essa linha, só migração para a reescrita HFS 3.

O HFS 2.x implementa seu próprio parser de templates, escrito em Delphi, usado para renderizar páginas de listagem de arquivos. Esse parser reconhece macros internas (documentadas publicamente desde falhas antigas em versões como 2.1.2, ex.: sintaxe '{.exec|comando.}') que podem disparar execução de comando no host. A CISA classifica a falha como CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine, ou seja, entrada controlada pelo atacante chega ao parser sem sanitização suficiente para impedir a injeção de diretivas de execução.

O pesquisador que descobriu a falha (Arseniy Sharoglazov) relata que a versão 2.3m era divulgada publicamente como sem vulnerabilidades conhecidas, mas levou menos de 10 minutos para contornar as restrições existentes e chegar a execução de código. O detalhe técnico central, segundo o autor, é que o valor do header Host é manipulado e é essa manipulação, combinada com a requisição, que é decisiva para a injeção funcionar — o parser aparentemente usa/reflete esse valor de forma insegura ao montar o contexto do template. O PoC completo não foi publicado (foi divulgado de forma redigida), então o payload exato de bypass usado contra 2.3m não é público.

O atacante controla efetivamente a entrada da requisição HTTP (incluindo o header Host) que alimenta o parser de templates; a saída é execução de comando com os privilégios do processo do HFS no Windows, que em muitos deployments é executado com privilégios elevados por conveniência (self-hosting local).

O vetor é uma única requisição HTTP para o servidor exposto, sem necessidade de autenticação, sem interação do usuário e sem pré-condição de configuração — basta o serviço HFS 2.x estar acessível na rede. Isso está refletido no vetor CVSS (AV:N/AC:L/PR:N/UI:N). O módulo Metasploit 'exploit/windows/http/rejetto_hfs_rce_cve_2024_23692' automatiza a exploração e foi testado com sucesso contra 2.3m e também contra builds de pré-lançamento 2.4.0 RC6 e RC7 — ou seja, testes de terceiros (Rapid7) encontraram a falha em versões além do range oficial 'até 2.3m', embora isso não seja uma confirmação formal do fornecedor.

Após a execução da requisição maliciosa, o atacante obtém execução arbitrária de comando no sistema; nos testes documentados isso foi usado para baixar e executar um payload (via certutil, curl ou tftp, conforme opções do módulo) e abrir uma sessão Meterpreter com o usuário do processo do HFS. O pesquisador original também demonstrou uma técnica para ocultar a requisição de exploração dos logs do servidor usando um byte nulo, o que significa que evidências de exploração podem não aparecer em logs padrão.

A presença no catálogo KEV da CISA confirma exploração ativa em campo. O EPSS próximo de 1.0 (0.99485) indica probabilidade muito alta de tentativas de exploração automatizada e massiva contra instâncias expostas — consistente com scanners de internet buscando instâncias antigas de HFS.

Não existe patch para a linha 2.x: o fornecedor confirmou que o HFS 2.3m está fora de suporte desde a data de atribuição do CVE, e nenhuma correção será lançada para essa branch (nem mesmo builds de pré-lançamento 2.4.0 testados por terceiros se mostraram imunes). A recomendação do próprio fornecedor, repassada pelo pesquisador e pela CISA, é migrar para o HFS 3, que é uma reescrita separada, não uma atualização incremental do 2.x — a migração implica revisão de configuração, scripts de template e integrações, já que a arquitetura mudou.

Se a migração não for viável no curto prazo, a orientação da CISA é 'aplicar mitigações conforme instruções do fornecedor ou descontinuar o uso do produto caso não existam mitigações disponíveis'. Nenhuma das fontes analisadas documenta uma flag de configuração, opção de linha de comando ou regra de WAF oficialmente validada como mitigação para a versão 2.x — na prática, o controle compensatório real é isolar o serviço: não expor a interface HTTP do HFS 2.x diretamente à internet, restringir acesso por firewall/VPN a IPs confiáveis, e monitorar/desligar o serviço se não houver necessidade operacional imediata.

Atualizar dentro da própria linha 2.x (por exemplo, para builds RC do 2.4.0) não é mitigação eficaz — testes de terceiros indicam que esses builds também foram vulneráveis ao mesmo módulo de exploração.

Verificar o banner/resposta HTTP do serviço para identificar a string de versão do HFS (2.3m ou builds 2.4.0 RCx) é o primeiro passo de triagem — o módulo Metasploit e o template Nuclei fazem essa checagem de forma não invasiva. Como o payload exato de bypass usado contra 2.3m não foi divulgado publicamente pelo pesquisador original, não há assinatura de payload confiável e pública para grep em logs de acesso; além disso, o próprio autor demonstrou uma técnica para esconder a requisição de exploração dos logs via byte nulo, então ausência de evidência nos logs não prova ausência de exploração.

Como sinal complementar, monitorar execução de processos no host Windows que hospeda o HFS: lançamento de cmd.exe, certutil.exe com '-urlcache', ou powershell/curl/tftp a partir do processo do HFS é forte indicativo de exploração pós-RCE, já que ferramentas de exploração pública (Metasploit) usam esses mecanismos para entregar o payload de segundo estágio.