InduSoft Web Studio Path Traversal

Path traversal no NTWebServer, o servidor web de demonstração/treinamento que acompanha o InduSoft Web Studio 7.1. Um atacante remoto sem autenticação consegue ler arquivos fora do webroot, inclusive arquivos .APP do projeto SCADA que armazenam a senha administrativa da aplicação. Com essa senha em mãos, é possível logar remotamente no Web Studio e fazer deploy de código controlado pelo atacante — path traversal virando RCE via um segundo passo de abuso de funcionalidade legítima.

A falha é um CWE-22 clássico: o NTWebServer não sanitiza sequências de "../" no caminho requisitado, permitindo que uma requisição HTTP GET escape do diretório raiz do servidor web e acesse qualquer arquivo legível pelo processo no sistema de arquivos Windows subjacente. O módulo de exploração público monta o payload concatenando múltiplos "../" (a implementação de referência usa profundidade configurável, tipicamente 8-10 níveis) seguidos do caminho do arquivo desejado.

O impacto real não é a leitura de arquivo genérica — é o alvo específico: arquivos .APP do projeto InduSoft, que contêm a senha administrativa configurada para a aplicação SCADA/HMI. O ICS-CERT descreve explicitamente essa cadeia: ler o .APP via traversal, extrair a credencial, e então usar essa credencial para autenticar na interface administrativa do Web Studio e fazer deploy de código server-side controlado pelo atacante. Ou seja, a CVE cobre a etapa de disclosure (CWE-22); a execução de código é uma consequência de segunda ordem que depende de a senha exposta ser reutilizável para administração remota da instância — o que na prática costuma ser o caso, já que é a mesma senha do runtime.

Ponto relevante do próprio fornecedor: o NTWebServer nunca foi projetado para uso em produção. Segundo o advisory do ICS-CERT, os manuais do InduSoft já indicavam que esse componente era apenas para fins de demonstração e treinamento — mas ele era instalado por padrão junto com o Web Studio 7.1, e frequentemente ficava exposto em ambientes reais de integradores e usuários finais que não sabiam disso.

O vetor é uma única requisição HTTP GET não autenticada contra a porta onde o NTWebServer está escutando (padrão TCP 80). Não há pré-requisito de autenticação, configuração não padrão nem interação do usuário — basta acesso de rede ao serviço. Isso é coerente com o vetor CVSS AV:N/AC:L/PR:N/UI:N. A dificuldade técnica é baixa: o próprio ICS-CERT classificou o exploit como acessível a atacante de baixo skill.

Existe módulo público para Metasploit (EDB-ID 42699, autor James Fitts) que automatiza a leitura de arquivo arbitrário via o traversal, com profundidade de diretórios e nome de arquivo parametrizáveis. Descoberto originalmente pelo pesquisador John Leitch e reportado via Zero Day Initiative (ZDI-14-118). Na publicação original do advisory (2014), o ICS-CERT afirmou não haver exploit público conhecido — isso mudou; o módulo Metasploit disponível é de 2017, e a CVE está no catálogo KEV da CISA (adicionada em 2022-04-15) como vulnerabilidade com exploração confirmada em ambiente real, não apenas PoC de laboratório.

O resultado final depende do arquivo que o atacante consegue direcionar: exfiltrar arquivos .APP do projeto rende a senha administrativa do Web Studio, viabilizando login remoto e deploy de lógica/scripts controlados pelo atacante no runtime SCADA/HMI — o que, em ambientes de manufatura, energia ou água/esgoto (setores citados pelo próprio ICS-CERT como usuários do produto), significa controle sobre a camada de supervisão do processo industrial.

O fornecedor corrigiu a falha na versão InduSoft Web Studio 7.1 + Service Pack 2 + Patch 4, disponível para download em http://download.indusoft.com/71.2.4/IWS71.2.4.zip (requer login na conta InduSoft). Aplicar esse patch é a mitigação definitiva — ele corrige a sanitização de caminho no NTWebServer.

Como o próprio fornecedor deixa claro que o NTWebServer é um componente de demonstração/treinamento e não deveria estar exposto em produção, o paliativo real para quem não pode atualizar imediatamente é desativar ou remover esse serviço web de teste dos ambientes produtivos, e nunca expô-lo à Internet ou a redes não confiáveis. O ICS-CERT reforça as recomendações genéricas de defesa em profundidade para ICS: minimizar exposição de rede de dispositivos de controle, isolar redes de controle detrás de firewall e segregadas da rede corporativa, e usar VPN com atualização própria quando acesso remoto for necessário.

Não existe mitigação eficaz baseada apenas em ocultar a porta por NAT sem controle de acesso — como a falha não exige autenticação, qualquer alcance de rede até o serviço é suficiente para exploração. Regra de WAF genérica contra sequências "../" pode reduzir o risco como controle compensatório temporário, mas não substitui a atualização nem a remoção do componente vulnerável.

Em logs de acesso do NTWebServer, procurar requisições GET com sequências repetidas de "../" ou "..\" no caminho, especialmente direcionadas a extensões .APP ou a arquivos de sistema fora do webroot (ex.: tentativas de acesso a boot.ini, usadas como teste de prova-de-conceito no módulo público). Requisições com padrões de profundidade de diretório anormalmente altos (múltiplos níveis de traversal) na mesma origem são o sinal mais direto de tentativa de exploração.

Não há assinatura única confiável além do padrão de path traversal em si, porque a técnica é genérica e pode ser mascarada com codificação de URL (%2e%2e%2f) ou variações de separador. Monitoramento de rede que capture tráfego HTTP não criptografado para a porta do NTWebServer e regras de IDS/IPS específicas para CVE-2014-0780 (a maioria dos motores de assinatura já cobre o padrão do módulo Metasploit público) são o caminho prático de detecção.