Em junho de 2025, a Cisco divulgou a CVE-2025-20282, uma vulnerabilidade de gravidade máxima no seu Identity Services Engine. A causa principal foi a ausência de uma verificação de validação de ficheiros no ponto de carregamento, o que poderia permitir que um atacante não autenticado colocasse um ficheiro manipulado num diretório com privilégios e o executasse como root. A falha ocorreu a montante da deteção, no que o sistema aceitava antes de qualquer mecanismo de análise ser executado.
Esse padrão não se limita a um único produto. O número de motores numa pilha raramente constitui uma limitação. Um ficheiro tem de ser analisado antes de poder ser avaliado, e os formatos modernos aninham o conteúdo de formas que a análise nem sempre consegue abranger.
Por que é que o exame não revelou nada de anormal?
A análise baseada em assinaturas funciona através da correspondência de bytes. Um motor mantém uma base de dados de hashes e padrões de bytes extraídos de malware conhecido, e um ficheiro tem de apresentar bytes correspondentes para ser detetado. Existem alguns fatores que impedem que isso aconteça com conteúdo aninhado.
- A análise lê o ficheiro principal, e não os objetos que se encontram no seu interior. Uma análise considera o ficheiro que tem diante de si como um único objeto binário e compara-o com a base de dados de assinaturas. O conteúdo aninhado é mantido de forma comprimida ou codificada, pelo que um executável inserido num fluxo de documento quase não partilha qualquer sequência de bytes com o mesmo executável no disco. O padrão que a base de dados procura está ausente do ficheiro tal como está armazenado, e só se torna comparável depois de esse fluxo ser descomprimido.
- Um ficheiro que não pode ser analisado parece um ficheiro limpo. Uma estrutura malformada interrompe a análise. O motor não consegue concluir a sua avaliação, pelo que o ficheiro é ignorado em vez de bloqueado, e um resultado que significa «não foi possível avaliar» é transmitido a jusante, sendo impossível distingui-lo de um resultado que signifique «nada encontrado».
- Os formatos também podem induzir em erro por natureza. Um ficheiro poliglota cumpre duas especificações de formato ao mesmo tempo, pelo que um analisador o reconhece como tal, enquanto o ficheiro se comporta de forma completamente diferente.
- A recursão tem limites. Os contentores aninhados estão sujeitos a limites de profundidade e a tempos limite de análise, e por boas razões, uma vez que a recursão ilimitada constitui, por si só, um risco de negação de serviço. Uma carga útil colocada abaixo desse limite nunca é avaliada, e situá-la a uma profundidade que o motor não consiga alcançar requer muito menos esforço do que contorná-lo.
O resultado é um veredicto que diz menos do que parece. Um resultado «limpo» significa que não foi encontrada nenhuma correspondência com nenhum padrão conhecido na parte do ficheiro que o motor conseguiu analisar. Não implica qualquer conclusão sobre os componentes contidos no ficheiro, nem sobre as camadas que o motor nunca abriu.
Cada camada tem uma função. Faltava uma.
A análise baseada em assinaturas nunca funciona isoladamente. As pilhas modernas de segurança de ficheiros são frequentemente concebidas em camadas, e as camadas que a rodeiam existem para cobrir o que a correspondência de padrões não consegue.
A identificação do tipo de ficheiro determina o verdadeiro tipo de um ficheiro a partir do seu cabeçalho, em vez da extensão declarada. É um método rápido e superficial por definição, concebido para decidir para onde um ficheiro deve ser encaminhado, em vez de determinar o seu conteúdo. A análise dinâmica observa o comportamento do ficheiro num ambiente controlado. É a ferramenta adequada para ameaças desconhecidas e é mais eficaz quando aplicada de forma seletiva, em vez de ser aplicada a todos os ficheiros.
Cada camada desempenha a sua função, mas quando uma carga útil nunca é separada do ficheiro que a transporta, ou se encontra abaixo de um limite de profundidade, esse conteúdo nunca chega a nenhuma destas camadas, pelo que a adição de camadas adicionais não serve para compensar. O ponto cego propaga-se mais longe nos formatos que não dispõem de qualquer via de sanitização: ficheiros de bases de dados, dados SIG, ficheiros de modelos de IA. Esses formatos não podem ser reconstruídos, pelo que a camada que normalmente detetaria uma ameaça desconhecida está, por definição, indisponível.
A peça que falta é uma camada cuja única função é estabelecer, em primeiro lugar, a verdade de referência estrutural: analisar um ficheiro de acordo com a sua especificação de formato, extrair todos os componentes incorporados e disponibilizar esses componentes individualmente a todas as etapas posteriores. É esse o problema que a Validação da Estrutura do Ficheiro foi concebida para resolver.
Como a validação da estrutura dos ficheiros colmata essa lacuna
A validação da estrutura do ficheiro é executada antes de o resto da pilha entrar em ação. Esta valida um ficheiro em relação à sua especificação de formato, abrangendo mais de 160 tipos de ficheiros, incluindo formatos GIS, de bases de dados e de modelos de IA, decompõe-no nos seus componentes e aplica políticas a cada um deles.
Os objetos são encaminhados para o motor adequado para a sua análise: Metascan™ Multiscanning, Adaptive Sandbox , Tecnologia Proactive DLP™ ou OPSWAT Alin AI. O ficheiro original segue para a Tecnologia Deep CDR™ para limpeza, quando aplicável.
O que importa aqui é o efeito na análise. A comparação de assinaturas continua a ser a forma mais rápida e económica de identificar malware conhecido, e a Validação da Estrutura do Ficheiro não substitui nada desse trabalho. O que muda é o que é entregue aos motores de deteção. A carga útil chega como um ficheiro autónomo, já descompactado e já classificado, pelo que o motor compara o próprio objeto em vez de um fragmento comprimido oculto dentro de um ficheiro pai. Aos motores de deteção são fornecidos os bytes exatos que as suas bases de dados foram concebidas para reconhecer, momento em que fazem aquilo que sempre fizeram bem.
Ver num ficheiro
A forma mais clara de demonstrar isto é através de um ficheiro que passa na verificação e, mesmo assim, contém uma carga maliciosa. Criámos uma prova de conceito em que uma carga maliciosa está oculta num ficheiro PDF inofensivo. A amostra foi então submetida a uma série de motores antimalware, que apresentaram um resultado de «limpo».
No passo seguinte, analisamos este ficheiro no MetaDefender Core™ com a Validação da Estrutura do Ficheiro ativada. Após extrair os componentes aninhados do ficheiro pai, a Validação da Estrutura do Ficheiro envia os objetos resultantes para os motores a jusante, para análise posterior.
Os motores antimalware Metascan™ Multiscanning indicaram um veredicto de «Infetado». As mesmas bases de dados de assinaturas que não detetaram quaisquer ameaças indicaram uma infeção assim que a carga útil foi apresentada como um ficheiro independente.
Por onde começar
Uma verificação sem resultados é uma indicação do que um motor de análise poderia analisar. Se o ficheiro contém algo perigoso é uma questão à parte, e responder a essa questão é um problema estrutural que tem de ser resolvido antes de o primeiro motor de deteção ser executado.
O facto de isso implicar apenas a validação da estrutura dos ficheiros ou, em conjunto, com a sanitização e a análise dinâmica, depende dos tipos de ficheiros, dos fluxos de trabalho e dos requisitos de integridade. Fale connosco para saber qual a combinação mais adequada ao seu ambiente.
