CVE-2019-5591

FortiOS, em configuração padrão até a versão 6.2.0, não valida a identidade do servidor LDAP ao estabelecer conexões LDAPS usadas para autenticação de usuários/administradores. Um atacante no mesmo segmento de rede (L2) pode se passar pelo servidor LDAP e capturar as credenciais que trafegam no bind, sem precisar de autenticação prévia. É uma falha de configuração, não de código — o dano real depende de o ambiente usar LDAP para autenticação no FortiGate e de o atacante ter acesso ao mesmo subnet.

A causa é a ausência, por padrão, da verificação de identidade do servidor LDAP (server-identity-check) nas conexões LDAPS configuradas em 'config user ldap'. Sem essa checagem, o FortiOS aceita qualquer certificado apresentado pelo peer durante o handshake TLS da sessão LDAPS, desde que a conexão seja criptografada — ele não confirma que o certificado pertence de fato ao servidor LDAP legítimo configurado. Isso equivale, na prática, à ausência de autenticação mútua no nível de aplicação: o canal é cifrado, mas contra o servidor errado. A CISA classifica a falha como CWE-306 (Missing Authentication for Critical Function).

O atacante controla apenas a posição na rede: precisa conseguir se interpor entre o FortiGate e o servidor LDAP real (via ARP spoofing, envenenamento de resolução de nome, ou qualquer técnica de MITM em camada 2/3 no mesmo subnet) e responder às tentativas de bind LDAP fingindo ser o servidor de diretório. Como o FortiOS não verifica o certificado do outro lado, a sessão LDAPS se completa normalmente do ponto de vista do dispositivo, e as credenciais enviadas pelo FortiGate (ou repassadas de um usuário fazendo login) chegam ao atacante em texto que ele consegue decifrar por controlar a ponta TLS.

O impacto declarado é só confidencialidade (C:H no vetor CVSS, sem I nem A): o atacante obtém informações sensíveis — essencialmente credenciais de bind LDAP — mas não demonstra, pela descrição, capacidade direta de alterar dados ou negar serviço a partir dessa falha isolada. O uso subsequente das credenciais capturadas é outro passo, fora do escopo desta CVE.

O vetor exigido é acesso à mesma rede local (AV:A) do FortiGate ou do tráfego LDAP relevante — não é explorável pela internet. Não é necessária autenticação (PR:N) nem interação do usuário (UI:N), e a complexidade de ataque é baixa (AC:L) uma vez que o atacante já está posicionado na rede. O pré-requisito real que a manchete omite é justamente este: presença no mesmo segmento L2/subnet, o que restringe a exploração a cenários com atacante interno, dispositivo comprometido na mesma VLAN, ou rede sem segmentação adequada entre o FortiGate e o servidor de diretório.

Na prática, o ataque consiste em se interpor no caminho de rede entre FortiOS e o servidor LDAP (por exemplo, técnicas de spoofing em camada 2) e responder no lugar do LDAP legítimo durante o processo de bind, aproveitando que o FortiOS aceita qualquer certificado apresentado. O resultado final é a captura de credenciais/dados de autenticação que trafegariam para o LDAP — sem exigir engenharia social ou exploração de memória, apenas posicionamento de rede e a ausência da validação de certificado.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em 2021-11-03, prazo de correção 2022-05-03), indicando exploração confirmada em algum contexto observado pela agência, embora o próprio PSIRT da Fortinet classifique o campo 'Known Exploited' como 'No' em seu advisory original — há divergência entre a avaliação do fornecedor (2019) e a inclusão posterior no KEV (2021), que provavelmente reflete evidência de exploração obtida depois da publicação inicial.

A correção completa exige atualizar para FortiOS 6.2.1 ou superior E garantir que a opção server-identity-check esteja habilitada — instalações novas em 6.2.1+ já vêm com essa opção ativa por padrão, mas atualizações (upgrade) a partir de versões 6.0.3–6.2.0 preservam o valor anterior da configuração. Ou seja, só fazer upgrade de firmware não resolve: é necessário habilitar explicitamente server-identity-check antes ou depois do upgrade.

Para quem está em 6.0.3 até 6.2.0 e não pode atualizar imediatamente, o paliativo é habilitar manualmente a checagem via CLI dentro de 'config user ldap / edit ldap-server', o que exige que 'secure ldaps' e o certificado da CA do servidor LDAP ('ca-cert') estejam configurados — sem esses dois pré-requisitos a opção não pode ser ativada. O custo é operacional: requer ter o certificado correto do servidor LDAP disponível e importado no FortiGate, e qualquer inconsistência de certificado quebra a autenticação LDAP até ser corrigida.

Não funciona como mitigação apenas trocar a versão do FortiOS sem revisar a configuração existente, dado o comportamento de preservação de configuração no upgrade. Segmentação de rede que isole o tráfego entre FortiGate e o servidor LDAP de hosts não confiáveis reduz a superfície de ataque (já que o vetor exige mesmo subnet), mas não substitui a correção de configuração — é controle compensatório, não fix.

Não há uma assinatura de rede confiável e específica para esta falha, pois o problema é de configuração ausente, não de payload malicioso identificável. Sinais indiretos que podem indicar tentativa de exploração incluem: eventos de ARP spoofing ou envenenamento de resolução de nomes na mesma rede do FortiGate e do servidor LDAP, certificados apresentados na conexão LDAPS que não correspondem ao esperado (visível em logs de auditoria TLS, se houver captura), e falhas de autenticação LDAP inesperadas ou binds partindo de origem/IP não usual. A ausência de logging de verificação de certificado no FortiOS quando server-identity-check está desabilitado é, em si, o principal indicador de exposição — não de ataque em curso.