Nas soluções de virtualização destacam-se duas componentes fundamentais da sua arquitetura:
O ambiente simulado, designado comumente por máquina virtual VM (Virtual Machine), que envolve o sistema convidado e a suas aplicações;
O controlador do ambiente simulado – VMM (Virtual Machine Monitor), que funciona como interface entre o sistema hospede e o sistema convidado, providencia as aplicações virtuais acesso ao hardware. como se pode ver na Figura 66
Figura 6 – Arquitectura genérica de máquinas virtuais.
Assim de uma forma geral, uma aplicação virtualizada, quando necessita de executa uma operação fá-lo (normalmente) através do seu sistema operativo. Este, acede ao
hardware de forma transparente, através do VMM.
Uma vez que os autores de malware têm conhecimento dos métodos de virtualização, eles também procuram detetar a presença de ambientes virtualizados de forma a melhorar a persistência do seu software. Porque a arquitetura destes sistemas é inerentemente detetável. Investigadores com especialização em virtualização afirmam que “… a construção de uma VMM indetetável é inviável como impraticável de um ponto de vista de performance e engenharia.” [35-37]
Assim os investigadores argumentam que as estratégias utilizadas se encontram organizadas nas seguintes três categorias[37]:
6
26 Discrepâncias lógicas− Diferenças nas interfaces de hardware real e virtualizado, por exemplo existem diferenças na execução de instruções não virtualizáveis tais como SIDT, SGDT e SLDT, que permitem a inspeção de estados privilegiados a partir do nível de utilizador (userlevel);
Discrepância de recursos− Devido ao facto que as VMM necessitam de partilhar recursos físicos a todos os sistemas operativos hóspedes, a disponibilidade de recursos não é sempre garantida ou distribuída de forma igual;
Discrepância de tempo− A evasão a este método é quase impossível quando as fontes de timing estão ao dispor do atacante. A diferença de tempo de leitura nas medições entre hardware real e virtual é diferente sendo possível verificar se estamos a correr em ambientes virtuais.
Um conjunto alargado de técnicas de deteção de plataformas de virtualização e emulação pode ser consultado no artigo do Peter Ferrie 2006[32].
2.8.1. Deteção de honeypots
As tecnologias de deteção e análise de malware usam normalmente sistemas virtualizados, pelo que muitos autores de malware passaram a introduzir no seu
software mecanismos de proteção no malware, assim procuram detetar se estão ou não a
executar em plataformas virtuais. Por exemplo, o “Citadel”, que em contexto virtualizado se comporta de maneira diferente evitando que seja estudado[102].
Deteção de honeypots de baixa interação
Os honeypots de baixa interação são virtualizados e podem ser detetados através de métodos de “Discrepâncias de tempo” tais como, “Medição do tempo de resposta”, “medição do enviesamento dos relógios dos hosts” e de “Discrepâncias lógicas” como o de “análise de particularidades nos protocolos”.
O método “observação dos tempos de resposta”− do sistema hospedeiro, passa pela estratégia de enviar uma grande quantidade de tráfego (flood) para o sistema e medir o tempo de resposta. Por comparação com atrasos conhecidos de outros hosts simulados, é possível estimar se se trata ou não de um sistema virtualizado [90];
27 O método de "medição do enviesamento”− tira partido das características dos relógios, que possuem pequenos enviesamentos. A técnica funciona através dos cabeçalhos do TCP (RFC l323) timestamp, que determina o enviesamento do sistema que devidas as particularidades do relógio é único para cada dispositivo e assim serve como identificação[58] esta técnica não só funciona em honeypots como também em sistemas reais e sistemas virtualizados, no artigo é efetuada a técnica em 200 hosts simulados pelo honeypot “honeyd” com resultados fiáveis; O método de “análise de particularidades de protocolos”− tem como
estratégia procurar identificar erros conhecidos de protocolos de comunicação. Por exemplo, a ferramenta “winnie” permite a deteção de honeypots “honeyd” através da deteção de um erro de assemblagem dos datagramas que este possui[82]. Este método também consegue detetar o honeypot “nepenthes” através de um scan de serviços. A presença de vários portos abertos denuncia serviços de sistemas Windows e Unix a correr simultaneamente, que é característico do sistema “nepenthes” [90].
Deteção de honeypots de alta interação
A maior parte dos honeypots de alta interação utilizam de tecnologia rootkit que lhes permite dissimular a sua presença, por exemplo o módulo “sebek” (tecnologia rootkit) pode ser detetado, através de várias técnicas neste caso utilizando “discrepâncias de recursos”, para efetuar a deteção:
Pesquisa de artefactos – Pesquisar artefactos na memória, uma vez que o módulo revelava na memória traços de estar a ser utilizado[16]. Por defeito, o sebek utiliza a opção de não utilizar símbolos (EXPORT_NO_SYMBOLS) de forma a não revelar a sua presença. No entanto, mesmo assim, permanecem alguns símbolos que que são necessários para o processo de linking dos módulos ao kernel. Assim, é possível através da consulta do ficheiro /proc/ksyms (OS Linux) identificar se o sistema é ou não um honeypot [16].
Tabela de syscalls do sistema – Verificar a tabela de calls do sistema, uma vez que o rootkit modifica a tabela de calls do sistema e substitui a função NR_read para a sua função [16]. Assim um sistema sem o sebek, a posição dos ponteiros das calls de sistema estariam próximas, já num sistema com o sebek instalado,
28 se os endereços de funções contíguas sys_read e sys_write tiverem uma discrepância superior a 4096 bytes pode-se concluir que a tabela de calls do sistema foi alterada com a presença do sebek.