O ficheiro que passa em todas as verificações
Os fluxos de trabalho de segurança de ficheiros assentam num pressuposto raramente posto em causa: um ficheiro tem um único tipo. O detetor identifica-o e a política encaminha-o. Todos os motores a jusante analisam então o ficheiro como sendo desse tipo: antimalware, sandbox e sanitização.
Os ficheiros poliglotas contrariam essa suposição. Um único fluxo de bytes pode ser, ao mesmo tempo, um ficheiro GIF perfeitamente válido e um arquivo Java perfeitamente válido. O mesmo truque funciona com um ficheiro JPEG que também é um arquivo RAR, ou com um PDF que contém um ficheiro ZIP completo para além do seu fim lógico. Cada parte está em conformidade com as normas por si só, pelo que nenhum analisador de formato individual detecta qualquer problema.
Um poliglota numa única imagem: o clássico GIF+JAR. Dois analisadores, dois pontos de entrada, um ficheiro e cada face totalmente válida.
A consequência em termos de segurança é clara: o pipeline analisa o ficheiro de acordo com o tipo que detetou, enquanto o outro formato passa inalterado. Uma imagem que também seja um script torna-se um XSS armazenado quando uma aplicação web a apresenta ao utilizador. Um arquivo oculto por trás de uma imagem transporta a sua carga útil para além dos filtros de conteúdo. As cadeias de ataque baseadas nesta ideia, desde a clássica combinação GIF+JAR até à entrega de exploits assistida por esteganografia, são do conhecimento público há quase duas décadas. Os motores antimalware continuam, em grande parte, a não as detetar, porque cada elemento, inspecionado individualmente, é inofensivo.
Como o motor descobre uma segunda faceta
O nosso motor de validação da estrutura de ficheiros inclui a deteção de múltiplos formatos como uma etapa de pré-processamento que é executada em todos os ficheiros analisados, antes de qualquer processador de formatos. A sua conceção assenta em três princípios.
- Analisa todo o fluxo. O scanner verifica o ficheiro na íntegra, comparando-o com uma lista de assinaturas de «magic numbers» de formatos. Se for detetado um segundo formato em qualquer ponto do fluxo, este é identificado com o seu deslocamento exato, mesmo que o tipo do ficheiro já tenha sido detetado. Isto inclui assinaturas acrescentadas após o marcador de fim de ficheiro de um PDF ou ocultas por trás dos dados de píxeis de uma imagem.
- Saiba onde um formato termina efetivamente. Os formatos Container podem, legalmente, conter outros ficheiros no seu interior. Uma imagem dentro de um ZIP é considerado conteúdo normal. O detetor determina o fim efetivo de cada contentor a partir da própria estrutura do mesmo. O trailer de um PDF, o diretório central de um ZIP e a alocação de setores de um ficheiro composto OLE (Object Linking and Embedding) marcam, cada um, esse limite. A análise do PDF tem em conta as atualizações incrementais. Apenas as assinaturas fora dessa estrutura contam como um segundo limite. Este limite estrutural é o que distingue um veredicto poliglota verdadeiro de um falso alarme em qualquer arquivo comum.
- Confirme antes de acusar. O motor extrai cada «candidato» do fluxo e volta a identificá-lo de forma independente com o nosso motor «File Type» antes de o comunicar. Os «candidatos» identificados como dados não estruturados são descartados. Um veredicto significa que existe um segundo formato que é efetivamente analisado nesse deslocamento. Os bytes aleatórios, por si só, nunca produzem um veredicto.
Extraído de uma amostra real: um PDF que incorpora um JPG e um PNG, com um ZIP e um TIFF anexados após o seu fim lógico. O veredicto identifica o ZIP e o TIFF, mas não faz qualquer referência às imagens incorporadas.
O resultado apresenta cada face com o seu deslocamento. Um único ficheiro .gif carregado, por exemplo, é identificado como GIF89a no deslocamento 0 e como um arquivo ZIP mais adiante no fluxo. A política decide o resto: comunicar a descoberta ou bloquear o ficheiro de imediato, com uma explicação que enumere os resultados positivos.
Da deteção à dissecação
A deteção é apenas metade da solução, porque o truque do «polyglot» reside no facto de cada face, individualmente, parecer inofensiva. Após a deteção, o motor analisa o ficheiro. Cada face confirmada é exportada como um objeto independente (polyglot_part_1.pdf, polyglot_part_2.zip, e assim por diante) com o seu formato, deslocamento e tamanho. O motor devolve cada uma delas ao fluxo de trabalho doMetaDefender Core™ para que seja processada na íntegra como aquilo que realmente é.
Verificámos isto de ponta a ponta numa instância ativa do MetaDefender Core™.
O motor dividiu uma amostra em PDF que transportava secretamente um documento Word (um ficheiro «poliglota» PDF+JAR+DOCX) na sua camada PDF e na sua camada ZIP. Como tanto o JAR como o DOCX são contentores ZIP, uma única camada ZIP satisfaz ambas as especificações. O motor «File Type» identificou então essa camada como um DOCX, e a tecnologia Deep CDR™ sanitizou-a individualmente. A camada oculta recebe o mesmo tratamento que foi concebida para contornar.
A precisão é a parte mais difícil
Os «bytes mágicos» ocorrem naturalmente em ficheiros inofensivos, pelo que o verdadeiro investimento em engenharia consiste em não dar o alarme à toa. As fotografias tiradas com câmaras incorporam miniaturas EXIF que contêm a sua própria assinatura JPEG. Os documentos do Office incorporam imagens na sua estrutura de contenção. Os ficheiros « Media » contêm aleatoriamente sequências de bytes que se assemelham a cabeçalhos de compressão. A lógica de deteção exclui os bytes já contabilizados por uma estrutura legítima, e este reforço de segurança é continuamente alargado, formato a formato. Um detetor que sinaliza todas as fotografias tiradas com uma câmara acaba por ser desativado, e um detetor desativado não protege ninguém.
Testado com verdadeiros poliglotas
Submetemos amostras poliglotas reais a uma implementação ativa do MetaDefender Core™, utilizando o motor de validação da estrutura de ficheiros. Todas foram detetadas, com cada face identificada com o seu deslocamento exato em bytes:
Exemplo | Faces encontradas (deslocamento) | Resultado |
PDF que oculta um documento do Word (PDF+JAR+DOCX num único ficheiro) | PDF @ 0 · ZIP @ 34 016 | Faces extraídos; o ficheiro DOCX oculto foi limpo pela tecnologia Deep CDR™ |
GIF que oculta um arquivo e uma segunda imagem | GIF89a @ 0 · ZIP @ 25 214 · TIFF @ 154 270 | Detetado |
Documento do Office que oculta um PDF | OLE @ 0 · PDF @ 73 217 | Detetado |
Um ficheiro JPEG que contém um PDF | Três caras, PDF em anexo @ 26 830 | Detetado |
«PoC‖GTFO», n.º 3, a revista de investigação sobre segurança criada como um ficheiro poliglota em formato PDF+ZIP, 26 MB | PDF @ 25 · ZIP @ 12 224 072 | Detetado: a segunda face foi encontrada a 12 MB de profundidade numa análise completa |
GIF que contém um fluxo GZIP e um arquivo Java | GIF89a @ 0 · GZIP @ 427 764 · ZIP @ 937 265 | Bloqueado |
Ficheiro PDF que incorpora um JPG e um PNG, com um ZIP e um TIFF anexados | PDF @ 0 · ZIP @ 204 849 · TIFF @ 257 395 | Bloqueado; as imagens incorporadas não foram corretamente indicadas |
A última linha mostra a regra de rejeição em ação: o veredicto identifica os ficheiros ZIP e TIFF anexados e ignora as imagens contidas no PDF. O resolvedor de contentores considerou-as como parte do próprio conteúdo do PDF. Resultado JSON do MetaDefender Core™ para esse ficheiro (resumido):
A lista fsv_output_files corresponde à dissecação descrita acima, em tempo real: as três faces recortadas e devolvidas ao fluxo de trabalho como objetos independentes.
Aqui estão as capturas de ecrã de cada resultado de amostra no MetaDefender Core™:
Cobertura e configuração
Atualmente, a cobertura abrange os formatos que os atacantes realmente combinam: PDF, ZIP, ficheiros compostos OLE, PNG, GIF, JPEG, TIFF, RAR, GZIP e 7z.
A resolução estrutural de fim de contentor aplica-se aos formatos de contentor. Esta funcionalidade é fornecida com prioridade na configuração: a deteção, o bloqueio e a verificação completa de ficheiros são, cada uma, opções de política, pelo que os operadores escolhem entre visibilidade e aplicação por implementação.
A linha de fundo
Um ficheiro com duas faces válidas contorna qualquer pipeline que lhe atribua um único tipo, e a deteção de tipo único é a base sobre a qual a maioria das pilhas de análise é construída. A deteção estrutural poliglota colmata essa lacuna, identificando todas as faces e comprovando que cada uma delas é analisável. A política pode então bloquear o ficheiro antes que qualquer aplicação escolha o interpretador errado.
Atualmente, é suportada a deteção nos formatos de ataque mais comuns. A resolução do fim do contentor para os restantes formatos de arquivo está prevista no plano de desenvolvimento.
Veja como a Validação da Estrutura de Ficheiros lida com os formatos de ficheiro que circulam no seu ambiente.
