As aplicações Web que facilitam o carregamento de ficheiros tornaram-se essenciais para muitas organizações, actuando como portais para clientes, parceiros e funcionários partilharem vários tipos de documentos e ficheiros. Por exemplo, uma empresa de RH pode permitir que os utilizadores carreguem currículos, ou uma empresa pode facilitar a partilha de ficheiros entre parceiros através de uma plataforma Web especializada.
Mesmo com medidas de segurança reforçadas e processos de validação mais rigorosos, os atacantes continuam a explorar as vulnerabilidades utilizando métodos sofisticados. Os ficheiros que parecem benignos, como as imagens, podem ser manipulados para comprometer a segurança de um servidor Web.
Os ficheiros poliglotas são ficheiros que podem ser válidos como vários tipos simultaneamente, permitindo aos atacantes contornar as medidas de segurança baseadas no tipo de ficheiro. Os exemplos incluem o GIFAR, que funciona como um ficheiro GIF e RAR, os poliglotas JavaScript/JPEG que são interpretados como JavaScript e JPEG, e os ficheiros Phar-JPEG, reconhecidos como um arquivo Phar e uma imagem JPEG. Estes ficheiros poliglotas podem passar despercebidos com extensões enganadoras ou vazias que "enganam" os sistemas, fazendo-os pensar que são um tipo de ficheiro benigno (como uma imagem ou um PDF), mas que contêm código malicioso não detectado.
Validação do carregamento de ficheiros
Permitir o carregamento de ficheiros por parte dos utilizadores sem uma validação adequada ou abrangente representa uma ameaça significativa para as aplicações Web. Se um atacante carregar com êxito um ficheiro malicioso, como um shell da Web, pode potencialmente obter controlo sobre o servidor, comprometendo tanto o sistema como os dados sensíveis. Para mitigar estes riscos, foram estabelecidas as melhores práticas para orientar os programadores na aplicação de medidas de validação eficazes. Estas práticas ajudam a garantir o processamento seguro de carregamentos de ficheiros, minimizando assim o risco de exploração.
As principais áreas de interesse para proteger os carregamentos de ficheiros incluem:
- Validação de extensão: Implementar uma lista de bloqueio ou uma lista de permissões de extensões de ficheiros para garantir que apenas são aceites os tipos de ficheiros permitidos.
- Sanitização de nomes de ficheiros: Gera cadeias aleatórias para nomes de ficheiros após o upload.
- Validação do tipo de conteúdo: Verificar o tipo MIME do ficheiro carregado para garantir que corresponde ao formato esperado.
- Validação do cabeçalho da imagem: Para carregamentos de imagens, podem ser utilizadas funções como getimagesize() em PHP para confirmar a validade do ficheiro, verificando o seu cabeçalho.
Contorno do filtro de carregamento de ficheiros
Apesar da implementação destas medidas de proteção, os atacantes aperfeiçoam continuamente os seus métodos para contornar os mecanismos de validação. Técnicas como a injeção de caracteres nulos, extensões duplas e extensões vazias podem minar a validação da extensão: um ficheiro pode aparecer com um nome como "file.php.jpg", "file.php%00.jpg", "file.PhP" ou "file.php/" para evitar a deteção. A validação do tipo MIME pode ser contornada modificando os bytes mágicos iniciais do ficheiro, como por exemplo, alterando-os para GIF89a, o cabeçalho associado aos ficheiros GIF, o que pode induzir o sistema a identificar o ficheiro como um formato legítimo. Além disso, um ficheiro .htaccess malicioso pode ser carregado para manipular as configurações do servidor, permitindo a execução de ficheiros com extensões não autorizadas.
Ataques a ficheiros poliglotas
Mesmo com a implementação de processos de validação rigorosos que combinam várias medidas de segurança para impedir a técnica de desvio do filtro de carregamento de ficheiros, os ataques sofisticados que visam ficheiros poliglotas, ou imagens poliglotas, continuam a ser uma ameaça significativa à segurança. Este método permite que os atacantes criem ficheiros - como imagens - que estejam em conformidade com a estrutura binária esperada para ficheiros de imagem, mas que possam simultaneamente executar código malicioso quando interpretados num contexto diferente. A natureza dupla destes ficheiros permite-lhes contornar os mecanismos de validação tradicionais e explorar vulnerabilidades em cenários específicos.
Ficheiro poliglota simples com ExifTool
Uma técnica simples para gerar uma imagem poliglota é utilizar o ExifTool. Esta poderosa aplicação foi concebida para ler, escrever e modificar vários formatos de metadados, tais como EXIF, XMP, JFIF e Photoshop IRB. No entanto, indivíduos mal intencionados podem tirar partido do ExifTool para executar acções prejudiciais, incluindo a criação de uma imagem poliglota com intenções maliciosas. Ao utilizar a ExifTool para incorporar código malicioso nos metadados EXIF de uma imagem - particularmente em campos como UserComment e ImageDescription - os atacantes podem gerar uma imagem poliglota e aumentar as suas hipóteses de exploração bem sucedida.
O seguinte apresenta os metadados EXIF da imagem, que fornecem informações abrangentes relacionadas com a mesma.
Ao utilizar o ExifTool, um agente de ameaça pode incorporar código malicioso nos metadados EXIF de uma imagem, criando assim um ficheiro poliglota que pode contornar os mecanismos de validação.
Embora a validação do tipo MIME possa restringir o carregamento de ficheiros básicos da shell web, esta imagem poliglota pode contornar estas restrições, permitindo a um atacante carregar uma shell web poliglota.
O atacante pode subsequentemente explorar a shell web poliglota para assumir o controlo do servidor web.
Ficheiro poliglota Javascript/JPEG
Um ficheiro poliglota JavaScript/JPEG está estruturado para ser válido tanto como uma imagem JPEG como um script JavaScript. Para o conseguir, um agente malicioso deve ter um conhecimento abrangente da estrutura interna de um ficheiro JPEG. Este conhecimento permite a incorporação precisa de dados binários maliciosos na imagem, garantindo que esta pode ser processada por um motor JavaScript sem afetar a sua validade como imagem JPEG.
Uma imagem JPEG tem a seguinte estrutura:
| Bytes | Nome |
| 0xFF, 0xD8 | Início da imagem |
| 0xFF, 0xE0, 0x00, 0x10, ... | Cabeçalho por defeito |
| 0XFF, 0XFE, ... | Comentário de imagem |
| 0xFF, 0xDB, ... | Tabela de Quantização |
| 0xFF, 0xC0, ... | Início do quadro |
| 0xFF, 0xC4, ... | Tabela de Huffman |
| 0xFF, 0xDA, ... | Início da digitalização |
| 0xFF, 0xD9 | Fim da imagem |
Formato JPEG - fonte: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
Numa estrutura de imagem JPEG, o cabeçalho é seguido pela informação de comprimento. Como mostrado no exemplo anterior, o cabeçalho começa com a sequência 0xFF 0xE0 0x00 0x10, em que 0x00 0x10 representa especificamente o comprimento do segmento, indicando 16 bytes. O marcador 0xFF 0xD9 marca o fim da imagem.
Para criar um ficheiro poliglota JavaScript/JPEG, é necessário modificar os valores hexadecimais da imagem para garantir que o motor JavaScript os reconhece e processa.
Em primeiro lugar, em JavaScript, a sequência 0xFF 0xD8 0xFF 0xE0 pode ser interpretada como valores não-ASCII, mas 0x00 0x10 é inválida e deve ser alterada. A substituição adequada para estes valores hexadecimais é 0x2F 0x2A, que é a representação hexadecimal de /*, uma sintaxe utilizada para abrir um comentário em JavaScript. Esta substituição permite que os restantes dados binários sejam ignorados como parte do comentário.
No entanto, uma vez que 0x00 0x10 representa originalmente o comprimento do cabeçalho JPEG, alterá-lo para 0x2F 0x2A, que em decimal é igual a 12074, requer a redefinição do cabeçalho JPEG para manter a sua validade. Para tal, é necessário adicionar bytes nulos e a carga útil do JavaScript deve ser colocada após o marcador 0xFF 0xFE, que indica um comentário de imagem na estrutura JPEG.
Por exemplo, se a carga útil for */=alert(document.domain);/*, que tem 28 bytes de comprimento, os bytes nulos necessários serão calculados da seguinte forma: 12074 (novo comprimento) - 16 (comprimento original do cabeçalho) - 2 (para o marcador 0xFF 0xFE ) - 28 (comprimento do payload) = 12.028 bytes nulos.
Consequentemente, o código JavaScript dentro da imagem JPEG seria semelhante ao seguinte:
Por fim, a sequência 0x2A 0x2F 0x2F 0x2F (correspondente a *///) deve ser colocada imediatamente antes do marcador de fim de ficheiro JPEG 0xFF 0xD9. Este passo fecha o comentário JavaScript e assegura que o payload é corretamente executado sem perturbar a estrutura do ficheiro JPEG.
Após esta modificação, a imagem pode ainda ser interpretada como uma imagem válida e, simultaneamente, conter código JavaScript executável.
Quando um ficheiro HTML carrega esta imagem como um código-fonte JavaScript, permanece válido e pode executar o código JavaScript incorporado:
Os ficheiros de imagem poliglotas apresentam riscos não só para a exploração do lado do cliente, mas também para ataques do lado do servidor em determinadas circunstâncias. Um exemplo disto é o ficheiro poliglota Phar/JPEG, que pode ser interpretado como um arquivo PHP (Phar) e como uma imagem JPEG. A estrutura do ficheiro Phar permite a incorporação de dados serializados em metadados, o que representa um risco potencial para vulnerabilidades de desserialização, especialmente em determinadas versões do PHP. Como resultado, os ficheiros poliglotas Phar/JPEG podem ser aproveitados para contornar a validação do carregamento de ficheiros e explorar servidores vulneráveis.
O formato de ficheiro Phar é apresentado como stub/manifest/contents/signature, e armazena a informação crucial do que está incluído no arquivo Phar no seu manifesto:
- Stub: O stub é um pedaço de código PHP que é executado quando o arquivo é acessado em um contexto executável. Não há restrições no conteúdo do stub, exceto pelo requisito de que ele termine com __HALT_COMPILER();.
- Manifesto: Esta secção contém metadados sobre o arquivo e o seu conteúdo, que podem incluir metadados Phar serializados armazenados no formato serialize().
- Conteúdo do ficheiro: Os ficheiros originais que estão incluídos no arquivo.
- Assinatura (opcional): Contém informações sobre a assinatura para verificação da integridade.
Uma vez que o stub não impõe quaisquer restrições de conteúdo para além da estipulação do __HALT_COMPILER(), um agente da ameaça pode injetar os valores hexadecimais de uma imagem no stub. Ao colocar estes valores no início do ficheiro PHAR, este pode ser identificado como uma imagem válida. Consequentemente, um poliglota PHAR/JPEG pode ser facilmente construído anexando os bytes hexadecimais de uma imagem JPEG no início, como demonstrado no exemplo seguinte:
Através deste método, o ficheiro poliglota gerado funciona tanto como uma imagem válida como um ficheiro PHAR legítimo e pode, portanto, ser utilizado para contornar certos mecanismos de validação de carregamento de ficheiros.
Embora este ficheiro poliglota possa contornar os filtros de carregamento de ficheiros, não é atualmente capaz de explorar o servidor Web. Para explorar e comprometer com sucesso um servidor Web utilizando um ficheiro PHAR ou um ficheiro poliglota PHAR, é essencial injetar metadados serializados maliciosos no manifesto do ficheiro.
Quando o ficheiro PHAR é acedido através do invólucro PHAR (phar://) em determinadas funções PHP (PHP ≤7.x) associadas a operações de ficheiros - como file(), file_exists(), file_get_contents(), fopen(), rename() ou unlink() - a função unserialize() é acionada para os metadados serializados. Em última análise, ao utilizar o PHPGGC, uma ferramenta amplamente utilizada para construir cadeias de gadgets PHP, os agentes de ameaças podem explorar a vulnerabilidade de desserialização através de um ficheiro poliglota PHAR, comprometendo assim o servidor de aplicações Web.
A combinação de ficheiros poliglotas PHAR/JPEG e vulnerabilidades de desserialização permite que os atacantes se infiltrem num servidor de aplicações Web, mesmo quando estão implementados filtros de carregamento de ficheiros. Em particular, este comprometimento pode ocorrer mesmo durante o processamento de um ficheiro de imagem.
Ao utilizar ficheiros poliglotas para contornar os filtros de carregamento de ficheiros e anexar o invólucro PHAR (phar://) à localização do ficheiro, os atacantes podem manipular o servidor Web para que este trate o ficheiro como um arquivo PHAR. Esta manipulação pode subsequentemente desencadear uma vulnerabilidade de desserialização, levando à execução remota de código através de funções de operação de ficheiros.
Para transmitir os riscos associados aos ficheiros poliglotas na sua aplicação, simulámos um ambiente em que a aplicação emprega filtros rigorosos de carregamento de ficheiros para impedir o carregamento de ficheiros maliciosos ou de shells da Web. Apesar destas salvaguardas, uma imagem poliglota pode contornar o processo de validação e, em determinados contextos, pode levar à execução remota de código, comprometendo, em última análise, o servidor de aplicações Web vulnerável.
Este exemplo ilustra uma aplicação Web convencional que permite a partilha de ficheiros entre clientes, parceiros e organizações:
MetaDefender Core e MetaDefender ICAP Server protege as suas aplicações Web contra estas ameaças e reforça a segurança da sua rede e infraestrutura.
MetaDefender ICAP Server e MetaDefender Core trabalham em conjunto para proteger o seu servidor Web contra ataques sofisticados que envolvem ficheiros poliglotas PHAR/JPEG maliciosos das seguintes formas:
Quando um arquivo poliglota PHAR/JPEG é carregado para a aplicação web, ele é primeiro encaminhado para MetaDefender Core através de MetaDefender ICAP Server para um processo de sanitização abrangente usando nossa tecnologia Deep CDR ™. Ao contrário de simples verificadores de tipo de ficheiro, Deep CDR analisa minuciosamente a estrutura do ficheiro carregado, removendo scripts, macros e conteúdo fora da política, reconstruindo o ficheiro JPEG para incluir apenas os dados necessários.
Este processo remove o conteúdo PHAR prejudicial anexado após o marcador final JPEG(0xFF 0xD9), garantindo que o ficheiro higienizado é estritamente um JPEG. Como resultado, a aplicação Web está protegida contra ataques poliglotas PHAR/JPEG; mesmo que um atacante possa alterar o esquema de processamento de ficheiros para injetar um invólucro PHAR, não pode explorar o servidor Web.
As organizações com infra-estruturas de segurança de rede estabelecidas - quer utilizem WAFs (firewalls de aplicações Web), proxies ou controladores de entrada - podem agora melhorar os seus mecanismos de defesa através de MetaDefender ICAP Server .Esta solução cria uma interface entre os servidores Web existentes e MetaDefender Core , estabelecendo um ponto de controlo de segurança transparente para todos os ficheiros recebidos. Qualquer conteúdo encaminhado através da interface ICAP será analisado e processado antes de chegar ao seu servidor Web, garantindo que apenas o conteúdo seguro e legítimo entra na sua rede e chega aos utilizadores finais.
Esta abordagem significa que as organizações podem aproveitar os seus investimentos de segurança existentes, acrescentando uma camada de proteção adicional e poderosa. As organizações que utilizam o controlador de entrada NGINX podem integrar o MetaDefender ICAP Server na sua infraestrutura existente através da configuração de proxy.
OPSWATvai além da deteção tradicional de ameaças. Em vez de simplesmente assinalar ficheiros suspeitos, MetaDefender Core neutraliza ativamente potenciais ameaças, transformando ficheiros perigosos em conteúdos seguros e utilizáveis. Quando integrado no seu servidor Web, o MetaDefender ICAP Server fornece uma proteção abrangente contra ameaças de dia zero e ataques poliglotas.
Com o poder de "Não confiar em nenhum ficheiro. Não confie em nenhum dispositivo. ™", OPSWAT resolve os desafios dos clientes em todo o mundo com tecnologias patenteadas em todos os níveis da sua infraestrutura, protegendo as suas redes, dados e dispositivos, e prevenindo ameaças conhecidas e desconhecidas, ataques de dia zero e malware.
