CVE-2025-31161
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
Falha de bypass de autenticação no componente HTTP do CrushFTP que permite a um atacante não autenticado se autenticar como qualquer usuário conhecido ou adivinhável — tipicamente 'crushadmin' — através de um header Authorization no formato AWS4-HMAC-SHA256 (compatível com S3) mal formado. Foi explorada em massa entre março e abril de 2025, antes da divulgação pública completa, e está no catálogo KEV da CISA. Não afeta instalações que ficam atrás de uma instância DMZ proxy do próprio CrushFTP, o que é a principal ressalva à gravidade do CVSS 9.8.
Detalhamento técnico
A falha está no método loginCheckHeaderAuth() da classe ServerSessionHTTP.java, que processa requisições HTTP com header Authorization no estilo S3/AWS4-HMAC. O servidor extrai o nome de usuário fazendo parsing puro de string a partir do campo Credential (ex.: 'Credential=crushadmin/'), sem exigir nem validar SignedHeaders ou Signature nesse ponto do fluxo. O código usa uma variável booleana, lookup_user_pass, para dois propósitos distintos: originalmente ela deveria indicar se a senha do usuário devia ser buscada no armazenamento; mas o mesmo valor é passado como parâmetro anyPass para login_user_pass(). Como lookup_user_pass é true por padrão sempre que o username não contém um caractere til (~), a chamada login_user_pass(true, false, user_name, "") autentica a sessão sem exigir senha alguma — corresponde ao CWE-305 (Authentication Bypass by Primitive Result).
A descrição oficial do fornecedor acrescenta uma segunda camada: existe uma condição de corrida entre a autenticação 'anypass' bem-sucedida e a segunda verificação de usuário que o servidor faz antes de fechar a sessão. Essa corrida pode ser difícil de vencer de forma confiável, mas o próprio fornecedor descreve uma técnica para estabilizar o ataque sem depender de timing: enviar um header AWS4-HMAC mangled contendo apenas o username seguido de uma barra ('/'), sem o restante da estrutura esperada (SignedHeaders etc.). Isso faz o parser localizar o username normalmente, disparar o fluxo de autenticação anypass, mas falhar ao procurar a entrada SignedHeaders esperada — gerando um erro de index-out-of-bounds que interrompe a execução antes da limpeza da sessão (session cleanup), deixando a sessão autenticada de pé.
O atacante controla integralmente o valor do header Authorization e, na prática relatada por pesquisadores, também um cookie CrushAuth (que não precisa corresponder a uma sessão previamente válida) e um parâmetro auxiliar que deve casar com os últimos caracteres desse cookie. Nenhuma credencial real é necessária; o único dado que o atacante precisa conhecer ou adivinhar é um nome de usuário válido no servidor, sendo 'crushadmin' o alvo natural por ser o administrador padrão.
Como é explorada
O vetor é uma única requisição HTTP(S) ao componente web do CrushFTP, sem qualquer autenticação prévia — pré-requisito de rede é apenas alcançar a porta HTTP(S) exposta do serviço. Pesquisadores (Huntress, ProjectDiscovery, Outpost24) reproduziram a exploração com uma requisição a um endpoint administrativo (ex.: listagem de usuários) contendo um header Authorization iniciado por 'AWS4-HMAC-SHA256' e um campo Credential com o nome do usuário-alvo seguido de barra, acompanhado de um cookie CrushAuth arbitrário (não precisa ser válido) e um parâmetro que deve corresponder aos últimos caracteres desse cookie. A exploração é trivial e de baixa complexidade — não exige força bruta de senha, apenas conhecimento ou tentativa de um username plausível.
O resultado prático, segundo o fornecedor e confirmado por pesquisadores, é impersonação completa da conta alvo, incluindo ações administrativas e recuperação de dados quando o alvo é 'crushadmin'. A partir daí, atacantes observados em campanhas reais criaram contas de backdoor, obtiveram execução de código e instalaram ferramentas de acesso remoto (incluindo agentes MeshCentral e outras RMM, legítimas e maliciosas) para persistência e movimento lateral.
Houve exploração ativa em escala antes da divulgação pública completa: a Shadowserver Foundation identificou cerca de 1.500 instâncias vulneráveis expostas na internet em 30/31 de março de 2025, e a Huntress observou atividade de exploração já em 30 de março, com exploração confirmada em massa a partir de 3 de abril. A instância só é protegida se estiver atrás de um proxy DMZ do próprio CrushFTP — sem esse componente, qualquer servidor exposto nas versões vulneráveis está sujeito ao ataque.
Versões
Como se proteger
A correção do fornecedor é atualizar para CrushFTP 10.8.4 ou superior (ramo 10) e 11.3.1 ou superior (ramo 11); o próprio fornecedor recomenda atualmente ir direto para 10.8.5+ ou 11.3.4_23+ nas releases mais recentes disponíveis. Huntress validou que o bypass é bloqueado nessas versões corrigidas.
Como paliativo, quando a atualização imediata não é viável, o único controle compensatório citado pelo fornecedor é colocar a instância atrás de uma instância DMZ proxy do próprio CrushFTP — o fornecedor afirma que o exploit não funciona nesse cenário. Isso não é uma mitigação genérica de WAF/rede qualquer; é uma arquitetura específica do produto, com custo de implantação e manutenção de um componente adicional. Restringir exposição da porta HTTP(S) à internet reduz a superfície, mas não elimina o risco para quem depende de acesso externo ao serviço.
Não há mitigação por configuração de senha, MFA de conta ou política de complexidade de credenciais — a falha ocorre antes de qualquer verificação de senha, então esses controles não têm efeito. Desabilitar apenas o header Authorization AWS4-HMAC/S3 não é uma opção documentada pelo fornecedor; a única correção efetiva sem DMZ é a atualização de versão.
Como detectar
Nos logs HTTP do CrushFTP, procurar requisições com header Authorization iniciado por 'AWS4-HMAC-SHA256' e campo Credential contendo um username conhecido (especialmente 'crushadmin') seguido diretamente de uma barra, sem os campos SignedHeaders/Signature completos ou válidos — esse padrão mal formado é a assinatura da exploração estabilizada descrita pelo próprio fornecedor. Também vale observar requisições para endpoints administrativos (como listagem de usuários) acompanhadas de cookies CrushAuth que não correspondem a sessões legítimas previamente emitidas pelo servidor, e a criação inesperada de contas de usuário ou instalação de agentes de RMM (incluindo MeshCentral) logo após acesso administrativo não explicado.
A Shadowserver Foundation e a Huntress relatam atividade de sondagem já em 30 de março de 2025 e exploração confirmada em massa a partir de 3 de abril; instâncias expostas publicamente entre essas datas e a aplicação do patch devem ser tratadas como potencialmente comprometidas mesmo sem evidência explícita nos logs, já que os requisitos de exploração são mínimos e a atividade pode ter sido superficial (apenas leitura, sem processos externos gerados).