CVE-2025-30406

CentreStack, plataforma de compartilhamento de arquivos e EFSS da Gladinet, usa uma chave criptográfica (machineKey) fixa e idêntica em todas as instalações do produto para proteger o ViewState do ASP.NET. Como a chave é hardcoded e portanto conhecida (ou extraível), qualquer atacante pode forjar um ViewState com um payload malicioso que o servidor aceita como legítimo e deserializa, resultando em execução remota de código sem autenticação. A falha foi explorada em ataques reais em março de 2025, antes da publicação do CVE, e está no catálogo KEV da CISA.

A causa raiz é CWE-321 (uso de chave criptográfica hardcoded). O ASP.NET Web Forms usa o ViewState para persistir estado de página entre requisições, protegido por um MAC (Message Authentication Code) gerado com o machineKey configurado em web.config. Esse mecanismo existe justamente para impedir que o cliente adultere o ViewState: se a chave for secreta e única por instalação, o servidor rejeita qualquer payload cujo MAC não bata. No CentreStack, a mesma machineKey vinha embutida no portal em todas as instalações — não era gerada por instância nem randomizada na configuração padrão.

Com a chave em mãos, um atacante pode montar um ViewState arbitrário, calcular o MAC correto usando a mesma chave, e enviar essa requisição para o servidor. O ASP.NET valida o MAC, considera o ViewState íntegro, e o deserializa via LosFormatter/ObjectStateFormatter. Se o payload contiver uma cadeia de gadgets de deserialização (o tipo de técnica popularizada por ferramentas como ysoserial.net para .NET), a deserialização aciona execução de código arbitrário no contexto do processo do IIS (worker w3wp.exe), antes mesmo de qualquer lógica de autenticação da aplicação ser alcançada.

O ponto crítico é que a autenticação da aplicação não protege contra isso: o ataque ocorre na camada do framework ASP.NET, na etapa de processamento do ViewState, que acontece antes do controle de acesso do CentreStack entrar em jogo. Por isso AV:N/PR:N no CVSS — não é preciso ter credencial nenhuma, só acesso de rede ao portal e conhecimento da chave.

O pré-requisito real da exploração é conhecer a machineKey usada pelo CentreStack. Como ela é hardcoded e idêntica entre instalações, uma vez que um pesquisador ou atacante a extrai de uma cópia do software (binário, instalador, ou até de análise de tráfego/config), ela serve para qualquer outra instância exposta na internet rodando a mesma versão vulnerável — não é um segredo por instalação, é um segredo de fábrica compartilhado. Isso explica o AC:H do vetor CVSS: a complexidade não está em contornar autenticação, mas em construir corretamente o payload serializado e a cadeia de gadgets que gera RCE ao ser deserializado.

Na prática, o ataque é uma requisição HTTP(S) contra o portal CentreStack exposto, com um ViewState forjado e assinado com a chave conhecida. Não exige acesso prévio autenticado, não exige configuração fora do padrão — pelo contrário, a configuração padrão é a vulnerável, já que a chave vem fixa no web.config de fábrica. A exploração observada em março de 2025, antes da divulgação pública, indica que atores de ameaça já tinham a chave e um payload funcional circulando antes do CVE ser publicado, o que motivou a inclusão imediata no KEV da CISA com prazo de correção de 2025-04-08 a 2025-04-29.

O resultado final é execução de código arbitrário no servidor com os privilégios do processo IIS/CentreStack — o que normalmente permite escrita de webshell, criação de contas, acesso aos arquivos geridos pela plataforma (que em cenários de EFSS corporativo costumam ser dados sensíveis de clientes) e movimento lateral a partir do host comprometido.

A correção definitiva é atualizar para a versão 16.4.10315.56368 ou posterior, que substitui o uso da machineKey hardcoded por geração de chave própria por instalação. Isso deve ser tratado como prioridade máxima para qualquer instância exposta à internet — é exatamente o cenário de uso normal do CentreStack.

Para quem não pode atualizar imediatamente, a própria nota do fornecedor indica um paliativo real: um administrador do CentreStack pode remover manualmente a entrada da machineKey do arquivo portal\web.config. Ao remover a chave fixa, o ASP.NET passa a gerar uma automaticamente (comportamento padrão do framework quando o atributo não está definido), o que invalida a chave conhecida publicamente e fecha o vetor de forja de ViewState. O custo é operacional: a troca de chave invalida sessões ativas e ViewStates em trânsito, forçando reautenticação dos usuários, e precisa ser repetida corretamente após qualquer reinstalação ou restauração de configuração que reintroduza a chave original.

Restringir acesso de rede ao portal (VPN, allowlist de IP) reduz a superfície de ataque, mas não é mitigação da causa raiz — a chave permanece hardcoded e válida, e qualquer acesso que hoje é permitido (inclusive de usuários internos ou parceiros) continua explorável. Colocar um WAF na frente sem regra específica para bloquear ViewState anômalo também não resolve, já que o payload forjado tem MAC válido e passa como tráfego legítimo do ponto de vista do protocolo.

Não há uma assinatura de rede simples e confiável, porque o payload forjado carrega um MAC válido e trafega como um parâmetro __VIEWSTATE legítimo de uma requisição ASP.NET normal — não há uma anomalia de protocolo óbvia para detectar via inspeção de tráfego padrão. Sinais indiretos a procurar: logs do IIS com requisições POST para páginas .aspx do portal CentreStack contendo valores de __VIEWSTATE anormalmente grandes ou vindos de IPs sem histórico de uso legítimo da aplicação; erros de deserialização ou exceções não tratadas nos logs de eventos do Windows/aplicação por volta do horário de acessos suspeitos; e, mais concretamente, processos filhos incomuns gerados pelo worker process do IIS (w3wp.exe) — como cmd.exe, powershell.exe ou processos de rede não usuais — que é o indicador comportamental mais forte de exploração de deserialização bem-sucedida via ViewState neste tipo de falha.