CVE-2020-8657

O EyesOfNetwork 5.3 usa uma chave de API fixa, hardcoded em include/api_functions.php (API versão 2.4.2), idêntica em toda instalação feita a partir do pacote oficial. Como o token de acesso é derivado dessa chave, do ID do usuário e do IP do servidor — todos valores previsíveis ou descobríveis —, qualquer atacante remoto e não autenticado pode calcular o token do admin (ID sempre '1') e assumir a conta com privilégio total. É CWE-798 (Use of Hard-Coded Credentials) clássico, e está no catálogo KEV da CISA com exploração confirmada.

A falha está no esquema de geração de token da API do EyesOfNetwork (eonapi, versão 2.4.2 embutida no EON 5.3). O token não depende de segredo por instalação: ele é o resultado de duas operações de hash encadeadas sobre valores conhecidos. Primeiro calcula-se md5(API_KEY + user_id); o resultado é concatenado com o IP do servidor e submetido a sha256. A API_KEY é a mesma em toda instalação vinda do pacote oficial (hardcoded no código-fonte, não gerada nem exposta para rotação pela interface web de administração), e o user_id do administrador é sempre '1'.

O único valor variável nessa fórmula é o IP do servidor — e mesmo esse é trivialmente obtido na maioria dos casos, pois é o próprio endereço para o qual o atacante está direcionando a requisição (a menos que a instância esteja atrás de NAT, caso em que o IP interno pode não coincidir com o público). Com API_KEY, user_id e IP em mãos, o atacante reproduz os dois hashes offline e obtém o token de sessão do admin sem nunca ter se autenticado.

O relatório original (issue #17 no repositório eonapi) demonstra o cálculo passo a passo com valores de exemplo, confirmando que a chave padrão '€On@piK3Y' não é alterada por padrão em nenhuma etapa da instalação nem exposta para reconfiguração via painel web — ou seja, o operador não tem, a princípio, um caminho oficial de rotação da chave.

O vetor é de rede, sem autenticação prévia e sem interação do usuário (AV:N/AC:L/PR:N/UI:N no vetor CVSS), o que explica a nota máxima de severidade. O atacante só precisa acessar a API HTTP exposta pelo EON e enviar o token calculado como se fosse uma sessão de admin legítima; não há bypass de criptografia nem força bruta real — é cálculo direto de hash com entradas conhecidas.

A pré-condição prática relevante é o IP do servidor: em instâncias expostas diretamente à internet (o cenário mais comum de exploração observada), o IP é o mesmo endereço de destino da requisição, então não há obstáculo. Em ambientes com NAT/proxy reverso, o IP interno pode diferir do público, elevando a complexidade — mas isso não é garantia de segurança, apenas atrito adicional.

Com o token de admin obtido, o atacante herda o mesmo escopo de privilégios da API do EON, que inclui operações administrativas do sistema de monitoramento. Existe PoC pública (PacketStorm) associando essa falha a execução de comando via funcionalidade de auto-discovery de alvos da API, módulo Metasploit e template Nuclei disponíveis, e a CISA confirma exploração ativa (entrada no KEV desde novembro/2021, com prazo de correção fixado em maio/2022 para agências federais dos EUA).

As fontes analisadas não trazem uma versão do EyesOfNetwork ou da API eonapi que corrija o problema — nem o advisory do fornecedor nem a issue no GitHub confirmam um patch com número de versão específico. A ação recomendada pela CISA no KEV é genérica ('aplicar atualizações conforme instruções do fornecedor'); não há aqui base factual para citar uma versão corrigida sem especular, e especular seria pior que não informar.

Como paliativo real: alterar manualmente a chave de API hardcoded no arquivo include/api_functions.php para um valor único por instalação, gerado de forma imprevisível, interrompe o cálculo do token pela fórmula pública — mas isso exige edição direta de código-fonte, não é suportado pela interface administrativa, e qualquer atualização futura do pacote pode reverter a alteração se sobrescrever o arquivo. Outro controle compensatório é restringir o acesso de rede à API (ACL, segmentação, firewall) para que só hosts de gerenciamento confiáveis alcancem o endpoint, reduzindo a superfície mesmo com a chave padrão intacta.

O que não funciona: esconder a instância atrás de NAT não é mitigação confiável — dificulta, mas não impede, já que o atacante pode inferir ou testar o IP público de saída, e a fórmula tolera esse tipo de tentativa e erro em ambientes com poucos IPs candidatos.

Não há assinatura de rede única e confiável, já que a exploração consiste em uma chamada de API autenticada com um token matematicamente válido — do ponto de vista do servidor, indistinguível de uma sessão legítima de admin. O sinal mais útil é comportamental: requisições à API do EON partindo de IPs externos desconhecidos, sem histórico prévio de login via interface web, especialmente chamadas a endpoints administrativos ou de auto-discovery logo após o primeiro contato do IP de origem.

Verificar se o arquivo include/api_functions.php mantém a chave padrão original é um indicador direto de exposição (não é 'detecção de ataque', mas confirma se o ambiente está na condição vulnerável). Logs de acesso à API que mostrem uso do token calculável (derivado de user_id '1' e do IP do próprio servidor) sem uma sequência de autenticação via formulário web anterior são o indício mais próximo de exploração dessa falha específica.