CVE-2021-26828

Falha de upload irrestrito de arquivo (CWE-434) no ScadaBR, um SCADA web baseado em Java popular no Brasil, que permite a um usuário autenticado com qualquer privilégio enviar um arquivo .jsp através do endpoint view_edit.shtm e executá-lo no contexto do servidor de aplicação — resultando em execução remota de código completa sobre o host que roda o SCADA. Importa porque o projeto ScadaBR original foi descontinuado pelos desenvolvedores brasileiros; não há patch oficial para o ScadaBR propriamente, só para o fork que o sucedeu (Scada-LTS), o que deixa instalações legadas permanentemente vulneráveis a menos que sejam migradas ou isoladas.

A falha está no endpoint view_edit.shtm, usado pela interface web do ScadaBR para upload de imagens/gráficos associados às telas de supervisão (views) do SCADA. O componente de upload não valida adequadamente extensão nem conteúdo do arquivo enviado — aceita qualquer payload, incluindo arquivos .jsp — e grava o resultado em um diretório servido pelo container de aplicação Java (tipicamente Tomcat) subjacente ao ScadaBR. Isso é um Unrestricted Upload of File with Dangerous Type (CWE-434) clássico: o atacante controla tanto o conteúdo quanto, na prática, o caminho onde o arquivo fica acessível via HTTP.

Como o arquivo gravado é um JSP dentro de uma árvore de webapp Java, basta uma requisição HTTP subsequente para o caminho onde ele foi salvo para o container compilar e executar o código a cada acesso, com os privilégios do processo do servidor de aplicação — não do usuário ScadaBR que fez o upload. Isso eleva uma falha de upload para RCE irrestrita no host.

O CVSS 3.1 (8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflete que a exploração não exige interação do usuário nem condições de rede exóticas, mas exige privilégio baixo (PR:L) — ou seja, autenticação válida na aplicação, mesmo que de conta com poucos direitos. Não há indicação nas fontes analisadas de que a falha seja explorável sem autenticação.

O fork que deu sequência ao projeto, Scada-LTS, tratou o mesmo problema estrutural no seu próprio código de upload (ViewEditController, ZIPProjectManager, ViewGraphicLoader) restringindo os tipos aceitos a bitmap/SVG e adicionando validação de conteúdo — não apenas de extensão — além de mitigação para SSRF relacionada ao mesmo fluxo de importação de projeto.

O vetor é uma requisição de upload de arquivo autenticada contra view_edit.shtm, substituindo o payload de imagem esperado por um arquivo .jsp com código Java arbitrário, seguida de uma requisição HTTP ao caminho onde esse arquivo foi persistido para forçar sua compilação e execução pelo container. Existe PoC pública documentando o fluxo (repositório hevox/CVE-2021-26828_ScadaBR_RCE, referenciado pelo próprio pesquisador que reportou a falha no fórum oficial do ScadaBR), e a CVE está no catálogo KEV da CISA, o que indica exploração confirmada em ambiente real — não apenas teórica.

O único pré-requisito relevante é uma sessão autenticada no ScadaBR; as fontes não indicam necessidade de privilégio administrativo, apenas de uma conta válida (PR:L no vetor CVSS). Em ambientes SCADA, contas de operador com credenciais fracas ou padrão são historicamente comuns, o que reduz na prática a barreira de autenticação — mas isso não está confirmado especificamente para o ScadaBR nas fontes consultadas, é um fator de risco geral de ICS, não uma característica documentada desta CVE.

O resultado final é execução de código arbitrário com os privilégios do processo do servidor de aplicação Java que hospeda o ScadaBR — em muitas instalações industriais, esse host tem acesso direto ou indireto a equipamentos de controle (PLCs, RTUs), então RCE no SCADA pode significar pivô para a rede de operação, não só comprometimento do servidor web.

Não existe versão corrigida do ScadaBR original: o projeto foi descontinuado pelos desenvolvedores brasileiros após a versão 1.1, segundo relato dos próprios mantenedores no fórum oficial. A correção conhecida foi implementada no fork que deu continuidade ao projeto, Scada-LTS (pull request #2174, milestone 2.7.1), que passou a filtrar tipos de arquivo permitidos em upload (restringindo a bitmap e SVG) e validar conteúdo, não apenas extensão. Quem roda ScadaBR e precisa de correção oficial precisa migrar para o Scada-LTS na versão que incorpora essa PR ou posterior — as fontes não especificam um número de versão de release do Scada-LTS que já contenha a correção fora do milestone 2.7.1.

Se a migração não for viável no curto prazo, o paliativo real é restringir o acesso à interface web do ScadaBR (view_edit.shtm e demais endpoints administrativos) a rede de gerência isolada, sem exposição direta à internet ou a redes de usuário geral, e revisar/eliminar contas com credenciais padrão ou fracas — já que a exploração exige apenas autenticação de baixo privilégio. Bloquear upload de arquivos com extensão .jsp via proxy reverso ou WAF na frente da aplicação reduz a superfície, mas é um controle compensatório, não uma correção: qualquer falha de normalização de path ou de extensão dupla pode contornar filtro superficial.

O que não funciona: apenas trocar senhas de administrador não elimina o risco, porque a falha não exige privilégio administrativo — qualquer conta autenticada válida basta segundo o vetor CVSS (PR:L). Também não há indicação de que atualizar o ScadaBR para uma versão mais recente do próprio ScadaBR resolva o problema, porque o projeto não recebeu mais releases após a descontinuação relatada pelos mantenedores.

Nos logs do servidor web/aplicação, procurar requisições POST para view_edit.shtm com corpo multipart contendo arquivos com extensão .jsp (ou variações de extensão/duplo encoding) em vez dos tipos de imagem esperados. No sistema de arquivos, procurar arquivos .jsp recém-criados dentro dos diretórios de upload/gráficos da webapp do ScadaBR, especialmente fora do padrão de nomes/pastas usados por uploads legítimos de imagem. Não há assinatura de exploração publicamente confirmada além da PoC referenciada (hevox/CVE-2021-26828_ScadaBR_RCE); ambientes que não retêm logs de upload ou não têm monitoração de integridade de arquivos na árvore da webapp não terão sinal confiável de tentativa passada.