FortiBleed: atualizar o firewall não encerra o ciclo de uma credencial vazada

O FBI alerta que ataques ligados ao FortiBleed continuam contra firewalls FortiGate e gateways SSL VPN expostos.[5] O acesso pode usar credenciais vazadas anteriormente, dados de infostealers, senhas reutilizadas ou pulverização de senhas.[5] A consequência de engenharia é separar correção de software de recuperação da identidade. Um patch não deve ser usado como recibo de encerramento de um incidente.

O que muda para quem desenvolve

Depois do acesso, os criminosos extraem outros dados de autenticação e empregam um cluster distribuído de GPUs com Hashcat e Hashtopolis para quebrar hashes offline.[5] Em alguns incidentes, criam administradores, removem contas legítimas ou mudam suas senhas, bloqueando a gestão do equipamento pela vítima.[5]

Minha análise é que o risco atravessa três camadas: a porta de entrada, a autoridade adquirida e a capacidade de continuar operando após a recuperação aparente. Corrigir somente a primeira deixa sem resposta as outras duas. Isso importa também para quem desenvolve integrações: uma conta de serviço com privilégio excessivo pode transformar um acesso pontual em alcance maior.

O FBI recomenda restringir acesso externo, encerrar sessões VPN, impor MFA e revisar contas, configurações e atividades não autorizadas.[5] Também orienta usar PBKDF2 no armazenamento de senhas administrativas, em lugar do mecanismo legado baseado em SHA-256 descrito no alerta.[5] Essa é uma orientação específica do contexto, não uma autorização para improvisar parâmetros criptográficos.

Como aplicar

Prepare um roteiro de recuperação com etapas verificáveis. Primeiro, exporte o inventário de administradores e associe cada conta a um responsável. Compare privilégios, métodos de autenticação e alterações recentes com o estado aprovado. Investigue contas sem justificativa antes de simplesmente excluí-las e perder contexto.

Depois, coordene encerramento de sessões e substituição de credenciais. Confirme que contas legítimas continuam conseguindo administrar o equipamento por um caminho autorizado. Defina também um procedimento de recuperação de acesso que não dependa exclusivamente da mesma sessão VPN sob investigação.

Para as aplicações conectadas, revise segredos e permissões que estavam acessíveis a partir do ambiente comprometido. A proposta é reconstruir a confiança por dependência, não declarar todo o entorno seguro porque o firewall voltou a responder.

Um exercício de mesa pode validar o roteiro: suponha que o administrador principal perdeu acesso e que existe uma conta desconhecida. Verifique quem pode restaurar controle, quais evidências precisam ser preservadas e como impedir que uma sessão antiga continue válida. Não é necessário simular ransomware para descobrir falhas nesse procedimento.

Cuidados e limites

A matéria cita 73.932 URLs em 194 países no vazamento observado em junho e 86.644 dispositivos em um levantamento mais recente da SOCRadar.[5] São retratos diferentes, não um total único produzido pelo FBI.[5]

Esses números não confirmam que um equipamento específico foi invadido. Para isso, é preciso evidência do próprio ambiente. O inverso também vale: ausência de falha visível e firmware atualizado não demonstram que credenciais, sessões e privilégios voltaram ao estado esperado.

Fonte

[5] Fonte: BleepingComputer