Captura, análise e identificação de malware: caso de estudo

Captura, análise e identificação de

malware: caso de estudo

DISSERTAÇÃO DE MESTRADO

EM TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO

Ricardo Sérgio Freitas Ferreira

António Manuel Trigueiros da Silva Cunha

Universidade de Trás–os–Montes e Alto Douro

Captura, análise e identificação de

malware: caso de estudo

Dissertação de Mestrado em

Tecnologias de Informação e Comunicação

Ricardo Sérgio Freitas Ferreira

António Manuel Trigueiros da Silva Cunha

Composição do Júri:

_______________________________________________________

_______________________________________________________

_______________________________________________________

“Somewhere, something incredible is waiting to be known.” Carl Sagan

i

Agradecimentos

Pela disponibilidade e contributo que prestaram durante a realização deste trabalho, gostaria de expressar o meu agradecimento a algumas instituições e pessoas:

À Universidade de Trás os Montes e Alto Douro, agradeço o acolhimento que me foi dispensado como aluno integrado nesta instituição.

Este projeto não teria sido possível sem o apoio e colaboração do orientador Professor Doutor António Cunha, por isso, em primeiro lugar, agradeço-lhe toda a ajuda que disponibilizou para a realização das diversas fases desta dissertação.

Aos amigos do mirque pelo lulz colectivo e a toda a minha família e amigos que sempre se disponibilizaram para me ajudar.

ii

Resumo

Atualmente a proliferação de software malicioso (malware) é enorme, tornando o

malware num dos maiores problemas da Internet. Os sistemas tradicionais de segurança

em redes de computadores, compostos por firewall e IDS, têm perdido eficácia devido ao atraso entre o surgimento das ameaças e o seu registo. Este atraso deve-se ao elevado número de novas ameaças e das suas variantes e também às técnicas de evasão cada vez mais sofisticadas, que dificultam a sua deteção. Neste contexto, foi efetuado um estudo sobre ferramentas baseadas em virtualização todas elas open source, que permitem a captura, análise e identificação de software malicioso. Foi também proposto e implementada uma solução composta pelas ferramentas dionaea, YARA, ssdeep e Cuckoo. Esta implementação foi testada durante 4 meses, registando os ataques numa base de dados. Os dados obtidos foram objeto de análise e conclusões foram retiradas.

Palavras-chave: Malware, Honeypots, Virtualization, Dynamic Analysis, Incident Response, SIEM.

iii

Abstract

Nowadays one of the big problems of the Internet is malware. Even more malware is incorporating advanced evasion techniques that make the analysis even harder. In that context a study is proposed that shows the design and implementation of a solution that is able to capture, analyze and observe malware. The solution studied was based on

opensource software and therefore demonstrates that opensource is a good choice in

network security even though there a small steep learning curve in the beginning the benefits from it far outweigh the initial configuration. It’s also advocated that the systems should be unified. In this dissertation technology pertaining to the capture and analysis of the malware is based on virtualization so that topic it’s also discussed techniques that identify virtualized environments and their counter attacks are also discussed. After the initial study we configured and build architecture that was shown to help organizations or individuals to improve their security from the information obtained from a proactive architecture, so that we can better and more efficiently respond to threats and incidents. The data provided by this architecture is easily integrable with other systems for instance monitoring solutions or IDS, improving the process of responding to incident and monitoring the infrastructure therefore improving the general security.

Keywords: Malware, Honeypot, Virtualization, Dynamic Analysis, Incident Response, SIEM.

iv

Índice

Índice de Tabelas ... viii

Siglas e Acrónimos ... ix 1. Introdução ... 1 1.1. Contexto ... 1 1.2. Objetivos ... 2 1.3. Estrutura ... 2 2. Contextualização ... 4 2.1. Malware ... 4 2.2. Botnets ... 7 2.3. Estratégias de infeção ... 9 2.4. Deteção de malware ... 10

2.5. Soluções com honeypots ... 20

2.6. Risco de deteção ... 22

2.7. Emulação e Virtualização ... 24

2.8. Deteção de Virtualização ... 25

2.9. Técnicas de deteção e dissimulação de ambientes virtualizados ... 28

2.10. Máquinas virtuais em HVM... 30

3. Análise de malware ... 32

3.1. Análise estática ... 34

3.2. Análise dinâmica ... 35

3.3. Técnicas para análise dinâmica de malware ... 37

3.4. Frameworks de análise dinâmica ... 38

4. Trabalho desenvolvido ... 44

v

4.2. Proposta de arquitetura para deteção de malware ... 48

4.3. Caso de estudo ... 54

5. Resultados do trabalho ... 55

5.1. Período analisado ... 55

5.2. Serviços atacados ... 56

5.3. Análise das amostras ... 64

5.4. Discussão de resultados ... 69

6. Conclusões e trabalhos futuros ... 71

Bibliografia ... 74

Anexos... 82

Anexo 1 – Querys SQL ... 82

Anexo 2 – Análise de similaridade ... 84

Anexo 3 – Análise de Cuckoo ... 88

Anexo 4− Relatórios Cuckoo ... 89

Anexo 5 – Regras de classificação de malware ... 92

vi

Índice de Figuras

Figura 1 – Posicionamento de um NIDS distribuído na rede. ... 13

Figura 2 – Classificação de honeypots adaptado de enisa[40]. ... 16

Figura 3 – Arquitetura do sistema híbrido surdIDS[119] ... 18

Figura 4 – Posicionamento tradicional de um honeypot. ... 21

Figura 5 – Posicionamento interno de um honeypot ... 22

Figura 6 – Arquitectura genérica de máquinas virtuais. ... 25

Figura 7 – Técnica de deteção baseada na instrução SIDT. ... 28

Figura 8 – Técnica de deteção baseada na instrução STR. ... 29

Figura 9 – Alterações para impedir a deteccao de VMware retirado de Liston[65]. ... 30

Figura 10 − Método de funcionamento do rootkit Bluepill retirado de Rutkowska[100].31 Figura 11 − Modo de funcionamento do user mode e kernel mode no sistema windows, retirado de MSDN[76]. ... 33

Figura 12 − Funcionamento genérico da biblioteca detours adaptado de Galen [34]. ... 36

Figura 13 − Arquitectura CWSandbox adapdata de Provos[90]. ... 39

Figura 14 − Arquitetura Cuckoo adaptada de Rodriguez[95]. ... 41

Figura 15 − Utilizacao JMP para hooking. ... 42

Figura 16 − Hooking efetuado pelo cHook utilizando a instrução MOV EAX,JMP EAX.42 Figura 17 − Rede tradicional. ... 45

Figura 18 − Arquitetura proposta. ... 49

Figura 19 – Algoritmo de alto nível da arquitetura. ... 49

Figura 20 − Estrutura da BD dionaea. ... 50

Figura 21 − Arquitetura desenvolvida. ... 54

Figura 22 – Total de ligações e downloads de amostras capturados durante o período estudado. ... 55

vii

Figura 24 – Número de ligações por porto. ... 57

Figura 25 − Número de ataques no serviço MSSQL. ... 58

Figura 26 - Número de hosts que estabeleceu ligações ao serviço MSSQL. ... 59

Figura 27 – Listagem dos drivers mais utilizados nos ataques ao serviço MSSQL. ... 60

Figura 28 - Número de ataques ao serviço SMB ... 62

Figura 29 - Downloads e número de hosts no serviço SMB. ... 63

Figura 30 – Análise dinâmica Cuckoo para a amostra 1. ... 66

viii

Índice de Tabelas

Tabela 1 − Requerimentos para monitorização de tráfego por largura de banda. ... 47

Tabela 2 − Tabela comparativa de funcionalidades de IDS opensource. ... 47

Tabela 3 − Tabela comparativa de honeypots de propósito geral adaptada de Grudziecki[40]. ... 48

Tabela 4 – Listagem dos usernames mais utilizados nos ataques ao serviço MSSQL. .. 59

Tabela 5 – Listagem das passwords mais utilizadas nos ataques ao serviço MSSQL. .. 60

Tabela 6 – Vulnerabilidades utilizadas contra o protocolo SMB ... 63

Tabela 7 – Lista das 4 amostras capturadas mais frequentes. ... 64

Tabela 8 – Número de amostras para as 4 amostras capturadas mais frequentes. ... 65

ix

Siglas e Acrónimos

API Application Programming Interface

ACL Access Control List

CIFS Common Internet File System

CSIRT Computer SecurityIncident Response Team

DGA Domain Generation Algorithm

DHCP Dynamic Host Configuration Protocol

DLL Dynamic Link Library

DMZ Demilitarized zone

DNS Domain Name System

IP Internet Protocol

I/O Input/Output

IRC Internet Relay Chat

PE Portable Executable

SIEM Security Information ad Event Managemnt

SQL Structured Query Language

IDS Intruson Detection System IPC Inter Process Comunication IPS Intrusion Prevention System

x

MD5 Message Digest 5

NFS Network File System

OS Operating System

P2P Peer–to–Peer

PCAP Packet Capture

SMB Server Message Block

SSH Secure Shell

VM Virtual Machine

VMM Virtual Machine Monitor

TLS Transport Layer Security TCP Transport Control Protocol

SSL Secure Sockets Layer

VoIP Voice over IP

1

CAP 1

1. Introdução

Esta dissertação de Mestrado tem como tema a utilização de plataformas de virtualização no contexto da segurança informática, de forma a detetar e prevenir ataques de software maligno (malware). O tema proposto engloba conceitos de redes de computadores, sistemas operativos, análise de binários.

Segue-se a contextualização da problemática que motivou este projeto e a definição dos objetivos propostos.

1.1. Contexto

Atualmente, a rápida expansão da Internet e dos seus utilizadores, criaram oportunidades para pessoas mal-intencionadas conseguirem ter proveito financeiro, escudando-se na anonimidade permitida pela Internet.

Em resultado disso, a proliferação de malware tem tido aumentos significativos[47, 111, 121], tendo evoluído a partir de um simples hobby para uma indústria que se dedica à infeção computadores a troco de compensações financeiras[49].

O malware tornou-se assim o veículo privilegiado de ataque nas redes de computadores e tornou-se num dos maiores problemas atuais da Internet[121].

O malware Stuxnet e o Flame, extremamente sofisticados, foram desenhados para impedir o programa nuclear Iraniano[126] causando elevados atrasos e prejuízos. Em consequência, surgiu uma pressão crescente de obter proteção contra este tipo de ameaças. Tradicionalmente, esta era assegurada por soluções compostas por firewall e IDS. No entanto, com a evolução e massificação das ameaças, estas soluções perderam alguma eficácia devido ao atraso entre o surgimento das ameaças e os seus registos. Este atraso deve-se ao elevado número de novas ameaças e das suas variantes, e também às técnicas de evasão mais sofisticadas que dificultam a sua deteção.

Para colmatar este problema surgiram novos métodos automáticos, baseados em virtualização, que permitem fazer frente a estas novas ameaças.

2 Esta dissertação pretende estudar e propor soluções de segurança, utilizando métodos automáticos baseados em virtualização, opensource, que permitam a um administrador de rede identificar e compreender as ameaças à sua rede.

O método de deteção permite criar informação sobre o método de infeção e o seu comportamento, tornando assim mais eficaz a resposta a incidentes.

As estratégias de segurança são compostas por um processo iterativo ente a “análise das ameaças” e “implementação de soluções” sucessivamente.

1.2. Objetivos

Com este trabalho é pretendido uma proposta de um sistema baseado em ferramentas

opensource capaz de capturar amostras de software potencialmente maligno, fazer a sua

análise e nos casos em que for considerando maligno, análise do seu vetor de infeção. Nesse sentido para atingir os objetivos propostos, destacam-se os seguintes objetivos:

 Análise e seleção de ferramentas opensource, baseadas em virtualização, capazes de capturar, classificar e identificar software malicioso (malware);  Projeto e implementação de um sistema, composto por ferramentas opensource

capazes de capturar, classificar e identificar malware;

 Realização de um caso de estudo, que permita validar o sistema proposto, nomeadamente, capturar, classificar e identificar malware;

 Publicação das principais características das amostras consideradas malignas, em motores de vírus, e.g., virustotal.com e comunidades cooperativas, e.g. honeynet.org.

1.3. Estrutura

No presente Capítulo, foi introduzido o tema e descritos os objetivos, contribuições e enquadramento da dissertação. No Capítulo 2, é efetuada a contextualização ao leitor onde são dados a conhecer as tecnologias de análise e também apresentados os principais conceitos abordados. No Capítulo 3 é explicado os tipos de análise de

malware (estática e dinâmica), técnicas utilizadas e as framework de análise. No

Capítulo 4 é apresentada uma arquitetura para um sistema baseado em ferramentas

3 apresentados os resultados obtidos e a sua análise. Finalmente, no Capítulo 6, são apresentadas as conclusões finais e propostos desenvolvimentos para trabalho futuro.

4

CAP 2

2. Contextualização

Neste capítulo faz-se uma contextualização dos conceitos de segurança, nomeadamente dos softwares malignos, os seus vetores de infeção, as implicações das infeções, é depois dada uma descrição dos sistemas de segurança existentes, o seu método de funcionamento e das ameaças dos dias de hoje

2.1. Malware

O malware pode ser definido como um software com propósitos malignos, seja a comprometer a privacidade dos utilizadores ou destruir informação. O malware é um termo muito abrangente que engloba um conjunto de características presentes em

software malicioso tais como: recolha de informação privada, acesso a recursos restritos

ou apenas para causar danos.

Atendendo às suas características e particularidades estes são passíveis de se organizar por classes tais como: crimeware, vírus, worms, backdoors, spyware entre outros. Para esta dissertação os grupos escolhidos foram cinco, estes grupos foram escolhidos devido importância que representam para a análise de botnets e assim verificar como os criminosos operam. Também é abordada no capítulo a seguir (botnet) a implicação que a infeção por malware acarreta.

Apesar da origem do primeiro programa malicioso ser questionável, existem referências que apontam o primeiro espécime para volta de 1987[135].

As primeiras instâncias de malware foram os vírus, sendo os seus criadores motivados pela necessidade de expor vulnerabilidades ou a demonstração das suas habilidades técnicas[113, 135]. À medida que o tempo avançou, estas motivações mudaram, atualmente a maior parte do malware existente tem propósitos criminosos, alimentando um pequeno ecossistema que prospera devido a proliferação de malware[49, 71]. Podem ser identificados vários grupos de programas maliciosos, que não sendo mutualmente exclusivos, permitem que alguns deles exibam características comuns a

5 dois ou mais grupos [122]. Segue-se uma apresentação dos que consideramos principais.

2.1.1. Worms

Prevalente em ambientes interligados, a definição descreve–o como “um programa que corre de forma independente e capaz de se propagar para outras máquinas”[122].

O primeiro worm conhecido foi o Morris[84] que devido ao impacto na perceção de insegurança da Internet, veio dar origem aos atuais centros de coordenação de resposta a incidentes de segurança CSIRT (Computer Security Incident Response Team)[21]. Nos últimos anos o malware tem aparecido cada vez mais sofisticado como é o caso do Conficker[63] [24] que utiliza DGA (Domain Generation Algorithms) para que possa contactar o servidor remoto[20], o Zeus utiliza comunicação P2P[66] e o Flame que utilizou novos métodos em ataques criptográficos ao MD5[117].

Os criminosos recorrem à utilização de worms, porque esta classe de malware está associada a criação botnets, que é uma rede de dispositivos infetados (bots) que comunicam com um servidor para efetuar as ações que lhes são instruídas[63].

As botnets normalmente são construídas através da propagação de worms para propósitos maliciosos tal como o envio de spam[52], este normalmente contendo links para páginas maliciosas[124], que perpetuam o ciclo de infeção.

2.1.2. Vírus

Um vírus informático é programa malicioso que anexa o seu código a ficheiros executáveis, documentos ou até o sistema operativo (OS). A sua capacidade de replicação é uma característica importante[110], e normalmente não se executam de forma autónoma[113].

Nos últimos anos temos assistido a um elevado número de vírus sofisticados como é o caso do Kenzero que utiliza como propagação o serviço P2P[30].Outras variantes utilizam como vetor de infeção as partilhas de rede conseguindo assim um efeito similar ao dos worms[122], como é o caso do vírus Shamoon que tem como alvo o sector da energia[94].

6

2.1.3. Trojan

Baseado na epopeia de Homero, onde Ulisses utiliza um cavalo gigante de madeira para se infiltrar dentro das muralhas de Troia, os cavalos de Troia normalmente apresentam-se como software legítimo mas que efetuam atividades maliciosas em background. Normalmente o trojan disfarça-se de plugin, jogos, screensavers ou programas de forma a infetar o sistema. Depois de executado ou instalado pode efetuar o download de programas maliciosos, modificar chaves do registo ou infetar outros ficheiros[122]. Está categoria é das que tem mais prevalência na Internet, representando 30% do

malware existente[45].

2.1.4. Spyware

Esta classe de software, bastante utilizado nos últimos anos, costuma estar disfarçada de

software legítimo para recolher preferências e dados do utilizador. A maior parte deste malware é utilizado devido a falta de instrução dos utilizadores[86], pois normalmente

são distribuídos de forma legal em programas freeware e shareware.

O spyware envia para o atacante informação do utilizador, informação bancária, histórico das páginas, documentos e e–mails[49].

A tecnologia utilizada nos spywares, tal como os trojans, têm mecanismos que permitem ações como keylogging, screenshots do ecrã, recolha de estatísticas e websites visitados[86].

2.1.5. Rootkits

Um rootkit é um conjunto de técnicas e programas maliciosos que utiliza tecnologia

stealth para manter uma presença não detetável na máquina[49]. A sua característica

diferenciadora é o facto que este malware preocupa-se com a persistência e dissimulação acima de tudo.

Pode dizer-se que um rootkit é um software maligno que procura manter o acesso remoto a máquinas, efetuar a monitorização do host infetado e dissimular a sua presença, utilizando técnicas que envolvem a simulação de utilização de CPU, de memória e de dispositivos de I/O, conseguindo assim evadir suspeitas sobre a sua presença.

7 Os rootkits conseguem esconder-se de mecanismos de segurança do sistema tais como os antivírus e software de deteção de intrusão em alguns casos chegam ao ponto de alterar o firmware das placas de rede[22], persistindo mesmo após a reinstalação do OS. Estes rootkits1 para além de permitirem a comunicação remota através da rede, permitem manter-se online mesmo com o host desligado[22].

No passado esta tecnologia foi utilizada para impedir que os utilizadores fizessem cópias ilegais de música, sendo distribuído em CD de música Sony que continham

rootkits[10].

Atualmente com o aumento de tecnologia de virtualização que permite a uma máquina física alojar vários sistemas operativos virtuais, os rootkits para estes ambientes tem vindo a crescer nos últimos anos tanto para ações malignas como benignas[23, 28, 56, 98, 99].

2.2. Botnets

Um bot é um dispositivo de rede (host) infetado que permite o seu controlo remoto via um servidor, este com o nome de Command and Control (C&C) envia comandos para o

bot, sem precisar de intervenção física nem do consentimento do legítimo utilizador.

Assim o host infetado passa a fazer parte de uma botnet tornando-se num zombie.

Assim, através das Botnets os criminosos conseguem anonimidade [27] uma vez que os sistemas que efetuam o ataque não são do atacante tornam os ataques difíceis de localizar devido às mudanças de IP, e ao facto de não haver fronteiras geográficas. A sua flexibilidade designa as botnets como “o canivete suíço” do malware[49] pois permitem a atualização e introdução de novas funcionalidades nos sistemas infetados, tornando os sistemas infetados no que for mais lucrativo.

A maneira como o malware se propaga e se instala é denominado de vetor de infeção, os vetores de infeção podem incluir a engenharia social, ou então vulnerabilidades de segurança[6] que estão presentes nos protocolos de comunicação mais populares: SMTP, HTTP P2P, IRC, IM, etc.

1

8 De acordo com Jakobsson[49]as atividades criminosas mais frequentes, levadas a cabo pelos donos das botnet (bot herders) são:

 Ataques DDoS – Ataques DDoS – efetuados de forma distribuída para atingir as proporções de trafego necessário para tornar os recursos de um sistema

indisponíveis aos seus utilizadores, o alvo são os servidores web.

Normalmente o ataque tem dois propósitos, o de consumir todos os recursos da vítima, tais como memória ou CPU de forma que não consiga executar a tarefa de forma correta, ou então a obstrução da comunicação entre a vítima e os utilizadores. Os Serviços de DDoS normalmente são vendidos em fóruns clandestinos com preços que vão das dezenas as centenas de euros, o preço vai depender da duração do ataque[83].

 Spam – Designado por correspondência eletrónica não desejada, é economicamente viável pois as barreiras a entrada são baixas, para os

operadores das botnets é uma atividade lucrativa. Atualmente as botnets são o coração da indústria de spam[13], de acordo com as estatísticas[67] a

percentagem de mail identificado como abusivo em 2011 anda na ordem dos 88%.

Em 2011 as maiores botnets eram capazes de mandar 100 mil milhões de mensagens spam por dia, em 2011 a capacidade de enviar spam foi afetada em cerca de 30%, este decréscimo é explicado pelo fecho de uma botnet a Rustock[80]. Apesar do decréscimo de spam as atividades de phishing, que tem como propósito enganar os utilizadores fazendo-se passar por uma entidade confiável tem vindo a subir[53].A categoria do spam nos últimos tempos tem sofrido mudanças, o spam farmacêutico desceu de ranking e todas as outras categorias tais como: produtos de dietas, serviços de dating, apostas e jogos

online e artigos de relojoaria tiveram um aumento[121].

 Roubo de identidade – Consiste na utilização de informação alheia para obter vantagem ou para prejudicar terceiros. Nestes casos os bots têm um papel limitado pois as informações obtidas da vítima pelo malware são posteriormente vendidas[49]. Os métodos utilizados para o roubo de identidade envolvem a captura de teclas e outros dispositivos ou através do download adicional de

9  Extorsão – A maior parte das vítimas que são alvo de DDoS são atacadas ou por rivalidade ou por motivos financeiros, os criminosos preferencialmente atacam serviços online que devido a natureza comercial das organizações, tem perdas financeiras quando o website sofre de indisponibilidade. Muitas vezes os ataques causam prejuízos que podem ascender a milhares de euros, para além que a organização fica com má reputação[141]. Em certos casos as empresas cedem à chantagem e pagam o que os criminosos pretendem, não existem grandes referências pois as organizações não falam sobre isso.

Apesar do grande foco das botnets ser o DDoS e o spam, a distribuição de spyware e

adware rapidamente se tornou numa das atividades mais lucrativas[13]. Este facto leva

a uma guerra constante com investigadores que tentam desligar as botnets, resultando numa rivalidade muito agressiva[25].

2.3. Estratégias de infeção

Os atacantes utilizam várias estratégias para a infeção dos hosts, destacando-se aqui as que exploram vulnerabilidades dos serviços, as de (Drive–by) e as de engenharia social.

 Vulnerabilidades de serviços− Após a instalação, os Sistemas Operativos (OS) atuais têm imensos serviços ativos por defeito, e necessitam de ser acompanhados por uma gestão e atualização metódica. É frequente a descobertas novas vulnerabilidades em OS ou políticas relaxadas que criam oportunidades para os atacantes infetarem hosts. Um host para comunicar em rede tem um conjunto de serviços conhecidos que executa, como por exemplo o serviço de DNS, ou partilha de rede (CIFS, NFS),expondo assim superfície de ataque. Para além disso existem serviços que providenciam mecanismos de autenticação que podem ser abusados por ataques de dicionário[17]. A atual utilização massiva de redes sociais tornou mais fácil a obtenção de informação que é usada para refinar os dicionários[87] e aumentar as probabilidades de sucesso do ataque[112].

 Drive by− Neste tipo de ataque, a infeção é obtida pela visualização de páginas

web, onde o alvo é o browser. A anatomia de um ataque deste género passa pelo

atacante montar uma página web que contém javascript malicioso assim quando o utilizador visitar essa página será infetado, normalmente estes ataques passam

10 despercebidos pois não é necessário interação nem permissão do utilizador[18]. Estes ataques podem recorrer a email ou outra forma de divulgação, onde redirecionam o utilizador para uma página web que contém vulnerabilidades para os browsers. Ao contrário dos ataques a serviços vulneráveis, este tipo de ataque segue um esquema “pullbased”[91] assim as conexões que normalmente são protegidas por firewall neste tipo de ataque tornam-se mais difíceis de mitigar[134].

 Engenharia Social− Os ataques por engenharia social consistem em enganar os utilizadores de forma a fazê-lo executar código malicioso[48] e a revelar segredos. Todas as técnicas que consistem em enganar os utilizadores a executar código malicioso enquadram-se nesta categoria[48]. Não há limites a criatividade nesta categoria os criminosos podem usar modas, como por exemplo embeber malware em vídeos supostamente virais ou de acontecimentos importantes aumentando assim a probabilidade de infeção passando pela recomendação de instalação de codecs, para ver vídeos no browser, ou inclusive ataques de engenharia social físicos deixando pen drives infetadas[116] perto da organização são apenas alguns dos exemplos.

2.4. Deteção de malware

Atualmente, a principal estratégia para parar o malware é a utilização de ferramentas com base em assinaturas que assim conseguem identificar a presença de programas malignos.

Os analistas recolhem (ou recebem) amostras de programas potencialmente malignos (malware) que analisam de forma manual à procura de indícios de comportamentos nocivos, cabendo-lhe a palavra final. Se a amostra for maliciosa o analista tenta encontrar um padrão que a permita identificar, este padrão deve ser genérico o suficiente para identificar a família da variante, mas ao mesmo tempo não ser genérico o suficiente para criar alertas em conteúdo legítimo (falsos positivos).

Com a proliferação de software maliciosos e das suas variações, o número de amostras de malware é enorme e por isso necessário proceder a uma abordagem que sirva para diferenciar entre as amostras que necessitem de atenção por parte de um analista e as que são apenas uma variante do que já existe, não sobrecarregando o analista.

11 Durante o processo de análise de malware, o analista pode optar por uma estratégia de análise dinâmica e ou estática, para a criação das assinaturas[41]. Na análise dinâmica, a amostra (programa malware) é executada num ambiente contido e as suas ações “gravadas”. Estas ações podem passam pela: criação de ficheiros, comunicações de rede, alteração de processos. Assim é possível inferir o comportamento do malware amostrado. Na análise estática o código da amostra é analisado por padrões, trechos de texto entre outras técnicas mas não é executada.

Normalmente para a deteção de malware as ferramentas comerciais utilizam algoritmos baseados em assinaturas, este método é razoavelmente rápido para a identificação de ameaças conhecidas, o problema é que as bases de dados das assinaturas envolvem uma transação comercial e não são disponibilizadas publicamente. Para além disso envolve trabalho por um operador humano para a construção da assinatura. Existem métodos a serem desenvolvidos por investigadores [33, 39, 92, 138], que envolvem a utilização de inferência estatística, a utilização de heurísticas e a criação automática de assinaturas mas o mais utilizado atualmente são algoritmos de identificação de assinaturas.

O processo de construção de assinaturas pelas empresas de antivírus passa por trabalho manual por parte de um analista. Se a amostra for maliciosa o analista tenta encontrar um padrão que a permita identificar, este padrão deve ser genérico o suficiente para identificar a família da variante, mas ao mesmo tempo não ser genérico o suficiente para criar alertas em conteúdo legítimo (falsos positivos). A análise de malware e a construção de assinaturas por um analista humano ainda é morosa e é possível de se introduzirem erros, daí a necessidade de criação de métodos que permitam a construção de assinaturas de uma forma automática[39].

2.4.1. Sistemas de deteção de intrusão

Os sistemas de deteção de intrusão, IDS (Intrusion Detection Systems) têm como objetivo alertar para a presença de possíveis intrusões. Perante a deteção de intrusões é possível utilizar ferramentas de prevenção de intrusão, IPS (Intrusion Prevention

Systems), estas ferramentas tomam ações reativas prevenindo a progressão da

intrusão.[97]

Hoje em dia o termo IDS é usado de forma igual pois a maior parte dos IDS atuais possuem extensões de IPS, como é o caso por exemplo do SNORT[139], embora

12 inicialmente os IDS não tenham sido desenvolvidos para prevenir ou proteger dos ataques, mas apenas para alertar, hoje em dia já têm essa capacidade e conseguem prevenir ataques, combinando as capacidades de filtragem de uma firewall com o poder de deteção que um IDS conseguia oferecer[46].

Para efeitos de categorização existem dois tipos de IPS, os que funcionam monitorizando o tráfego de rede (NIDS) e os que monitorizam o estado de um host (HIDS).

As capacidades dos IPS permitem uma maior flexibilidade e uma reação ativa em vez de passiva[97], melhorando assim o processo de monitorização.

Os problemas surgem quando tráfego que não deveria ser bloqueado acaba por ser, este problema é comum e surge com as capacidades de um dispositivo ser capaz de filtrar tráfego, por essa razão os falsos positivos são altamente indesejáveis em implementações de segurança que analisem tráfego, cabendo ao administrador avaliar a sua eficácia, e o “treinar”. Devido a este problema dos falsos positivos que o trafego legítimo é marcado como malicioso levando a que o operador perca a confiança no sistema, dando falsos alertas. Nos dias de hoje normalmente obtém-se taxas aceitáveis utilizando vários sistemas em simultâneo para a correlação[93, 107] e também já existem algumas implementações que tentam limitar a taxa de falsos positivos de assinaturas a valores muito baixos[39] mesmo assim as soluções normais “off the shelf” normalmente não fazem.

Os host IDS, ou HIDS (Host Intrusion Detection Systems) procuram identificar comportamentos maliciosos através da monitorização em tempo real dos processos, da memória RAM, dos ficheiros de sistema e logs do sistema[75]. Exemplos de HIDS incluem soluções constituídas por vários componentes como é o caso do OSSEC, que providencia uma plataforma centralizada de monitorização de logs e verificação da integridade dos ficheiros do sistema e os programas comummente designados por antivírus[42], e.g: MSE2, ClamAV, Avira.

Ao contrário dos NIDS que inspecionam todo o tráfego na rede, os HIDS estão mais preocupados em verificar comportamentos anómalos dentro de um host[75].

2

13 Uma das características dos HIDS é a monitorização dos componentes de um sistema operativo: processos, programas, acessos ao registo, muitas vezes os HIDS também efetuam o checksum de programas instalados, sabendo se houve alteração dos binários do sistema[54].

Os Network IDS (NIDS – Network Intrusion detection Systems) são IDS colocados em pontos estratégicos da rede procuram detetar atividades maliciosas através da análise do tráfego, por exemplo, pedidos anormais de ligações, tráfego malicioso. Os NIDS podem ser utilizados em arquiteturas com apenas um sensor ou então recorrer a uma arquitetura distribuída[119]. Os sensores monitorizam e filtram todo o tráfego da rede, enviando as informações para um servidor central, como se pode ver na imagem seguinte.

Figura 1 – Posicionamento de um NIDS distribuído na rede.

Os dois métodos de deteção mais populares nos NIDS são a correspondência de assinaturas (signature matching) e a deteção de anomalias (anomaly detection).

O método mais usado nos IDS comerciais é baseado em assinaturas, onde é feita uma correspondência entre o que o filtro verifica e as assinaturas, caso o IDS encontre similaridades gera um alerta e pode efetuar ações. Em termos de implementação o

14 problema é obter as assinaturas de programas maliciosos desconhecidos, se o criador de

malware modifica a assinatura ou o malware é polimórfico o NIDS não o irá detetar.

Outro problema que existe é o da sobrecarga de processamento causados pelos IDS felizmente já existem soluções que utilizam balanceamento de carga para distribuir a carga por vários sistemas[55] ou então processamento em paralelo, utilizando as capacidades de processamento dos CPU modernos[131] e a utilização de GPU[50, 130], assim conseguindo a performance necessária para a análise em redes com um elevado nível de tráfego.

Os NIDS baseados em análise de anomalias, necessitam de um período de aprendizagem (calibração) para determinar o comportamento normal do tráfego.

Após o período de aprendizagem verifica-se o comportamento do tráfego é desviante do que foi previamente configurado, alertando o administrador caso o trafego se desvie do que foi calibrado. Atualmente o estado da arte destes sistemas empregam técnicas de aprendizagem de máquina, com performance e taxas de deteção bastante apelativas[11, 104].

O problema é que os IDS não capturam o ataque apenas alertam para o ataque, assim sendo caso haja ataques desconhecidos o IDS não o irá conseguir detetar.

2.4.2. Honeypots

Um honeypot é um sistema monitorizado que se pretende que seja atacado, sendo definido por alguns autores como “um recurso, em que o seu valor está no seu uso ilícito não autorizado”[90]. O seu valor pode ser calculado com base na informação que dele se obtém[74].

A informação retirada de um ataque é cada vez menor pois os ataques estão cada vez mais sofisticados[101, 132] e utilizam cada vez mais protocolos obscuros[79] com recurso a criptografia para proteger o tráfego de rede[140], impedindo a sua correta análise, torna-se necessário recolher informação sobre os métodos utilizados e é nesse contexto que aparecem os honeypots , que são um sistema monitorizado que se pretende que seja atacado.

15 Alguns autores propõem a definição: “um recurso, em que o seu valor está no seu uso ilícito não autorizado”[90]. O valor de um honeypot pode ser calculado com base na informação que dele se obtém[74].

A sua estratégia passa por ligar numa rede de computadores, um recurso (honeypot) que pareça interessante a um eventual atacante, não tendo qualquer valor de produção, todas as comunicações são suspeitas tornando todos os dados colecionados mais relevantes para a análise forense, para a resposta a incidente, e para a análise de malware, do que um simples NIDS[14]. Uma vez que os honeypots podem simular o número desejado de serviços, das mais variadas plataformas, proporcionam a deteção vetores de ataque propositados, os quais depois de atacados fornecem informação sobre os métodos e vulnerabilidade utilizados. Para além da informação recolhida, outra contribuição importante do honeypot é a capacidade de criar uma sessão interativa que permite capturar a sequência dos comandos efetuados pelo atacante, mesmo quando utilizados protocolos de comunicação encriptados.

Como já foi exposto, os ataques conhecidos são detetados pelos NIDS “off the shelf” através de algoritmos que procuram assinaturas dos malware. No caso de novos ataques, designados por 0-day, uma vez que ainda não existem registos das suas assinaturas, estes não são possíveis de ser detetados. Nesse aspeto uma solução de

honeypots faz toda a diferença, uma vez que ao registar atividade na máquina honeypot

(comunicações de entrada e/ou saída anormais) é possível detetar a presença de

malware sem assinaturas e o uso de vulnerabilidades ainda desconhecidas[14].

2.4.3. Classificação de honeypots

A classificação (taxinomia) dos honeypot tem vindo a sofrer alterações de acordo com vários autores[90], no entanto para este trabalho optou-se por utilizar a definição feita pelo CERT polaco (representado na Figura 2), que seguiu uma abordagem prática[40].

16

Figura 2 – Classificação de honeypots adaptado de enisa[40].

Como se pode ver na Figura 2, os honeypots podem ser classificados de acordo com o “tipo de recursos atacados” e com “o nível de interação”. Dentro dos classificados por “nível de interação”, os honeypots são designados de alta interação, baixa interação ou híbridos.

Um “honeypot de alta” interação é um sistema convencional, pode ser um dispositivo qualquer, um computador, um router, um smartphone. Este tipo de sistema não tem um papel ativo na rede, sendo que durante a sua operação normal não têm processos anormais nem tráfego na interface de rede. Assim quando existe uma intrusão todas interações com o honeypot são guardadas. A utilização de vários honeypots de alta interação com vários OS permite a recolha de informação com diferentes aspetos criando assim uma honeynet[14].

Uma honeynet não é constituída por apenas um sistema mas por uma rede interligada de vários tipos de honeypots. Um dos elementos chave neste tipo de arquitetura é a

17 segmentação por norma é recomendado um dispositivo de filtragem a nível da camada dois[105] assim é possível separar o tráfego e aumenta-se a segurança e reduz-se a sobrecarga de administração.

No caso dos “honeypots de baixa interação” são emulados serviços ou outros aspetos de uma máquina verdadeira, como por exemplo a stack de rede, esta estratégia permite economizar recursos computacionais, no entanto pode também introduzir problemas ao

malware que pode necessitar de funcionalidades não implementadas na simulação

levando ao impedimento do ataque. Este tipo de honeypots tem uma interação limitada e servem maioritariamente para obter uma visão global permitindo efetuar estatísticas e recolher amostras dos ataques da rede. Já a sua facilidade de configuração e instalação torna este tipo de honeypot bastante popular.[40]

Os honeypot híbridos procuram utilizar o melhor dos dois mundos de forma a conseguir o máximo de informação sobre o ataque[62]. Dos vários honeypots híbridos existentes, o mais conhecido é talvez o SurfCERT IDS(Figura 3) cuja configuração utiliza vários

honeypots de baixa interação em conjunção com o honeypot de alta interação Argus [40,

119]. Este sistema tem 3 componentes, o servidor de logging que regista a informação dos vários sensores centralizando o processo, o servidor de túneis que cria as ligações utilizando tecnologia VPN para assim se conseguir instalar sensores distribuídos, e finalmente os sensores que são configurados para enviarem o tráfego para os honeypots [119].

18

Figura 3 – Arquitetura do sistema híbrido surdIDS[119]

No caso da classificação “tipo de recursos atacados”, podem ser divididos em

honeytokens, honeypots de lado do cliente (client side) e honeypots de lado do servidor

(server side).

Os honeypots que têm a designação de server side honeypots, funcionam como um servidor, expõem as portas a aplicações e ficam a espera de comunicações de ingresso. São utilizados para a descoberta de malware, este tipo de honeypot é considerado o tradicional.

Em contraste os honeypot client side, que são usados para detetar ataques em aplicações cliente. Para isso, monitoriza as ligações efetuadas por um conjunto de aplicações cliente que possui, com vista à deteção de atividades maliciosas. Os que simulam o

browser, de entre os vários honey clients, são os mais populares [81], pois a arquitetura

do browser é bastante complexa apresentando uma grande superfície de ataque[123]. Os honeytokens ao contrário dos outros honeypots não são sistemas mas sim informação, neste caso informação falsa colocada de forma propositada para que seja acedida, sendo assim possível saber se foi acedida por alguém, sendo que a utilização dessa informação não é normal deteta-se assim comportamentos maliciosos, por exemplo a criação de um número de cartão de crédito numa base de dados ou num ficheiro, devido ao número ser único, é facilmente detetável com a utilização de uma

19 assinatura em IDS, permitindo assim verificar quando e por quem é que o recurso foi acedido[115]. Este conceito é facilmente expansível a outros tipos de dados, monitorizando com um IDS pelas assinaturas únicas do conteúdo dos honeytokens, é possível identificar vários problemas tal como ameaças internas, outro exemplo passa pela criação de emails com credenciais falsas e verificar a sua utilização na infra estrutura[115].

Os autores da taxonomia escolhida utilizaram as classes que já existiam, o nível de interação, o tipo de recursos atacados e introduziram outra característica nova a subclasse "especialização" permitindo agrupar honeypots com base na sua especialização, por exemplo honeypot para SSH, honeypot para VoIP, honeypot para USB. Tornando assim mais fácil a sua categorização por especialidade.

2.4.4. Problemas inerentes aos honeypots

Com já foi exposto, os honeypots de baixa interação emulam serviços e por melhor que seja a sua aproximação ao comportamento dos serviços reais existem sempre discrepâncias que permitem ao atacante determinar que se trata ou não de um serviço emulado[37].

Para a captura de ameaças 0-day3, estes honeypots não são adequados pois desconhecendo a ameaça não é possível realizar uma emulação precisa. Existem no entanto honeypots como o “dionaea” que providencia a implementação do protocolo SMB (Server Message Block4) em python, sendo possível desenvolver as operações não suportadas[2].

Já os honeypots de alta interação podem ser comprometidos de tal forma que o atacante pode escapar do sistema real[7] e atacar outros hosts[74]. Por outro lado, um honeypot de alta interação precisa de mais recursos devido à sua complexidade, o que limita a escalabilidade e performance da solução, outro inconveniente destes honeypots é que a sua configuração e instalação requerem um maior esforço de administração[90].

3

Vulnerabilidades desconhecidas.

4

20

2.4.5. Honeypots vs Sanboxes

No contexto da análise dinâmica de malware, as sandboxes são as ferramentas que permitem a automatização da análise de malware dentro de ambientes contidos. Regra geral uma sandbox executa o software malicioso e monitoriza as alterações ao sistema. Assim é possível verificar mudanças no sistema de ficheiros, registro, processos, bibliotecas e tráfego de rede[38]. Tipicamente as sandboxes analisam programas (binários) mas com o aparecimento de novos vetores de ataque em documentos (e.g. word, excel, pdf, html), as sandboxes modernas passaram a analisar também esses documento.

A distinção entre sanboxes e honeypots está nos objetivos para que se usam. Enquanto as sandboxes estão tipicamente focadas na análise aprofunda do processo de infeção e das ações levadas a cabo pelo malware, os honeypots procuram determinar se é ou não malicioso e opcionalmente identificar os mecanismos de infeção. Regra geral os

honeypots não monitorizam depois da infeção inicial[38, 44].

Dadas as diferenças apresentadas entre os honeypots e as sandboxes estas devem ser tratadas como duas técnicas complementares que capazes de cooperar entre elas[44].

2.4.6. Honeypots vs IDS

Um sistema IDS normalmente é um componente de software que monitoriza e analisa o tráfego de rede á procura de atividades maliciosas, existindo atualmente IDS que trabalham em modo reativo e são capazes de bloquear comportamentos maliciosos conhecidos. Os honeypots podem ser usados para a deteção de intrusão mas não são um substituto pois é um recurso que vai ser acedido por um atacante e não um sistema de monitorização de tráfego, assim é aconselhável a utilização complementar destes dois sistemas[40].

Uma das utilizações mais avançadas de monitorização é a configuração de um IDS/IPS como parte de um sistema segurança que baseado no tráfego desconhecido malicioso faz o redireccionamento do tráfego para ser analisado em honeypots [9, 119, 139].

2.5. Soluções com honeypots

A implementação de honeypots pode ser efetuada utilizando várias estratégias, passando pela utilização de um honeypot ou então uma rede de honeypots [89, 90, 114].

21 Relativamente ao seu posicionamento, o honeypot tipicamente é posicionado externamente à rede, de forma a ficar exposto à Internet. Este posicionamento permite a observação da atividade maliciosa da Internet e a recolha de amostras, esta configuração é a utilizada pela maioria dos utilizadores e equipas de investigação para obter informação sobre as infeções existentes e botnets.

Normalmente o honeypot é colocado numa LAN ou numa zona desmilitarizada (DMZ) sendo diretamente acessível pelo exterior[40], como se pode ver na Figura 4.

Figura 4 – Posicionamento tradicional de um honeypot.

A recomendação é a utilização de filtragem ao segundo nível para aumentar a segurança e reduzir a carga de administração.

No entanto, a utilização de honeypots posicionados internamente à rede, apresentam a vantagens de detetar infeções internas, Figura 5.

22

Figura 5 – Posicionamento interno de um honeypot

Os investigadores da ENISA propõem que os sistemas comprometidos sejam tornados em honeypots para o estudo dos utilizadores maliciosos e assim perceber qual a extensão do ataque. Apesar de este método necessitar de maior atenção da administração, é importante pois permite perceber o movimento que os atacantes efetuam na infraestrutura com as credenciais obtidas.

2.6. Risco de deteção

Todo o software complexo tem bugs, esses bugs podem ou não ser vulneráveis e permitirem ao atacante infetar a máquina que corre o software, assim é fácil perceber que os honeypots também terão as suas vulnerabilidades e que é possível ao atacante encontra-las, comprometer o sistema e introduzir-se na infraestrutura.

Para minimizar este risco, vários autores defendem que é necessário o planeamento da uma instalação de honeypots (honeynet) e que se deve reger por diretrizes tendo por base os seguintes quatro pontos[88]: Controlo dos dados, Captura de dados, Coleta de dados e Análise de dados.

23  Controlo dos dados: atendendo ao risco de ser possível ao atacante comprometer o honeypot durante a instalação e tenha acesso ao sistema, é necessário que a localização dos honeypots seja planeada e o tráfego de entrada (ingress) e saída (egress) dos honeypots seja controlada.

O ideal passa pela utilização de políticas preventivas, como por exemplo, o bloqueio de portas. Uma política como esta que fizesse o bloqueio da porta SMTP impediria que o honeypot possa ser usado para o envio de spam.

Políticas mais avançadas são possíveis através da utilização de proxies e outros serviços falsos[69] permitindo assim à equipa de segurança ter um maior de controlo sobre o ambiente[19, 78].

Para os honeypots não interferirem com o tráfego legítimo na rede de produção, deverá haver segmentação do tráfego[105] e utilização de endereçamento IP misto. A utilização de endereços de IP de produção nos honeypots, apesar causar alguma sobrecarga de administração, resulta numa melhor solução final, apresentando o benefício de mascarar os honeypots com os servidores reais de produção[19, 40, 88, 90, 114].

É possível utilizar outros mecanismos de controlo de dados como por exemplo a utilização de IDS/IPS [119], traffic shapping e firewall, a solução “honeywall” disponibiliza alguns destes controlos [12, 90].

 Captura de dados: de forma a perceber quais as técnicas utilizadas é necessário a captura de todas as atividades associadas com a honeynet, apesar de os

honeypots utilizarem os seus próprios logs, raramente estão completos, para se

estabelecer uma linha temporal forense, é necessário a utilização das ferramentas de sistema para a geração de logs de forma independente[44, 51]. Para além disso deverá também haver replicação e redundância para os dados[40].

 Coleta de dados: a regra de boas práticas é colocar os dados obtidos noutro local da rede que não seja possível ao atacante interagir, isto pode ser efetuado de uma forma distribuída ou para uma localização central. O foco é garantir a integridade dos dados, pois na análise forense a assinatura temporal (timestamps) dos acontecimentos são de extrema importância por isso a sincronização dos relógios dos sistemas através da rede com o protocolo NTP

24 (Network Time Protocol) ou PTP (Precision Time Protocol) ou outras soluções de sincronização é algo que se deve ter presente quando a implementação de um sistema de segurança, neste caso os honeypots[51].

 Análise dos dados: é essencial ter meios e ferramentas para analisar os dados colecionados. Um dos problemas apresentados pelos honeypots é que normalmente não tem forma de análise posterior dos dados, embora existem outras ferramentas externas disponíveis que suportam o necessário processo de análise [1, 15, 70].

2.7. Emulação e Virtualização

A emulação de um sistema computacional, convidado, assim com a sua virtualização permitem a outro sistema computacional, hospedeiro replicar as funções do primeiro sistema (convidado). No entanto o nível de abstração usado é diferente.

A emulação é possível para qualquer arquitetura de hardware uma vez que implementa uma simulação da arquitetura emulada.

No caso da virtualização, uma vez não há simulação da arquitetura do sistema hospedeiro, só é possível, se as arquiteturas de ambos os sistemas forem a mesma. Nesse caso, a virtualização escolhe e usa instruções equivalente nativas da arquitetura do sistema hospedeiro. Esta estratégia permite obter melhores desempenho do que os sistemas emulados.

Note-se que os sistemas virtualizados têm perdas estimadas de aproximadamente 2% a 7% relativo ao seu desempenho numa máquina real5. Já para os sistemas emulados, as perdas são estimadas entre~ 30% a ~70% relativo ao desempenho numa máquina real.[137]

Desta forma, a virtualização é escolha preferida para a implementação soluções de análise de malware, tais como sandboxes e honeypots, sendo que, há situações particulares podem justificam a utilização de emuladores[142].

5

25

2.8. Deteção de Virtualização

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.

2.9. Técnicas de deteção e dissimulação de ambientes virtualizados

Como já foi referido, investigadores desta área afiram perentoriamente que “é tecnicamente impossível evitar a deteção da virtualização”, sendo apenas possível recorrer a outras técnicas para procurar evitar a sua deteção.

Segue-se a apresentação de algumas às técnicas deteção de máquina virtuais de um ponto de vista prático e de técnicas usadas para esconder a presença de virtualização.

2.9.1. Técnicas de deteção de máquina virtuais

Utilizando discrepâncias logicas é possível utilizar instruções privilegiadas por exemplo o SIDT (Store Interrupt Descriptor Table Register)[57], para a identificação do contexto de execução, verificando se é virtual ou real. A instrução SIDT, armazena os descritores de interrupção (IDTR), assim é possível detetar se está a ser executado numa máquina virtual pois o primeiro byte retornado é superior a “0xd0” esta a ser executado numa máquina virtual, caso seja inferior ou igual está a ser executado numa máquina real[99], como se pode ver na Figura 7.

Figura 7 – Técnica de deteção baseada na instrução SIDT.

A técnica “Store Task Register” (STR) também baseada em discrepâncias lógicas foi desenvolvida por Alfredo Omella. Nesta técnica o investigador utilizou a instrução STR (Store Task Register) que guarda o segmento do registo TR no operando especificado[129]. Assim o valor retirado através da instrução STR é diferente em

29 sistemas virtualizados e sistemas nativos, o código que permite a verificação está Figura 8.

Figura 8 – Técnica de deteção baseada na instrução STR.

Como podemos verificar as técnicas são fáceis de implementar, sendo que é expectável que os autores de malware as utilizem no seu software.

2.9.2. Técnicas de dissimulação da presença de virtualização

Apesar de haver inúmeras técnicas de deteção de virtualização, existem funções não documentadas que permitem mitigar algumas técnicas de deteção de virtualização. Investigadores da SANS, empresa privada especializada treino de segurança na Internet, publicaram num dos seus cursos online, uma lista que mitiga a deteção máquinas virtuais VMware[65]. A Figura 9 ilustra as alterações necessárias a efetuar ao ficheiro de configuração “.vmx” da maquina virtual VMware.

30

Figura 9 – Alterações para impedir a deteccao de VMware retirado de Liston[65].

Com as alterações propostas é possível impedir que certas classes de malware detetem se estão a correr em ambientes virtualizados. Neste caso, a funcionalidade “canal de comunicação” entre o hóspede e hospedeiro perdem-se, pode haver também outros efeitos secundários[65].

2.10. Máquinas virtuais em HVM

Máquinas virtuais HVM (Hardware Virtual Machine) designam plataformas eficientes de virtualização, que utilizam as capacidades primárias de hardware, os seus CPUs têm implementado um conjunto de instruções otimizadas que permitem executar as máquinas virtuais com melhores performances[61].

Inicialmente os rootkits estavam focados na deteção de virtualização. Com o aparecimento das HVM surgiram os rootkits “Vitriol” para MacOSX e os rootkits

Bluepill[98] para sistemas Windows Vista. No primeiro caso, os rootkits “Vitriol”,

utilizando a tecnologia de virtualização da Intel (VT-x) nas plataformas Intel Core Duo/Solo e no segundo caso, rootkit Bluepill, para sistemas Windows Vista X64 utilizando a tecnologia de virtualização da AMD (AMD–V)[23]. Estes foram os trabalhos públicos percursores para uma nova era de rootkits HVM [56].

Na Figura 10 é possível visualizar, de forma simplificada, o funcionamento do Blue Pill.

31

Figura 10 − Método de funcionamento do rootkit Bluepill retirado de Rutkowska[100].

As extensões SVM (Secure Virtual Machine) são um set de instruções que servem para implementar máquina virtuais seguras na plataforma AMD64. O Bluepill explora esse conjunto de instruções de forma a poder mover o OS para uma máquina virtual “on the

fly”, providenciando um VMM, que é responsável pelo controle de eventos dentro do

OS hóspede, e assim conseguimos mover o OS para uma plataforma sendo o controlo efetuado pelo VMM que é controlado por nós.

Apesar de ser possível a deteção de virtualização e do número cada vez maior de técnicas capazes de o fazer[33, 85], a deteção de malware com honeypots e sandboxes, baseados em virtualização, continua a ser a melhor solução atualmente disponível. A virtualização providencia uma gestão eficiente de vários sistemas operativos, necessários para o estudo de malware[38].

32

CAP 3

3. Análise de malware

A maioria do malware atual, existe para plataformas Windows[103], pelo que neste trabalho se optou por focar neste tipo de malware, por outro lado, as assinaturas usadas pelos sistemas de antivírus são normalmente criadas manualmente, sendo que o

software depois quando considerado suspeito é analisado pelo analista de forma a

determinar se este é ou não uma ameaça.

Este capítulo apresenta a forma como se efetua a análise estática e dinâmicas de amostras de malware e as principais técnicas utilizadas.

O software que corre nas máquina normalmente esta dividido em duas partes. o

software “normal” como o processador de texto, visualizador de imagens, que são as

aplicações e são executadas em user mode. e o OS que como necessita de executar tarefas privilegiadas tais como aceder ao hardware e a drivers é executado em kernel

mode. Apenas o código executado em kernel mode tem acesso ao estado do sistema,

esta separação de privilégios previne que processos em user mode interajam com o sistema diretamente, um processo em user mode não consegue diretamente abrir ou criar um ficheiro, por isso o OS providencia uma API “system call“ para a aplicação pedir ao OS para efetuar ações privilegiadas.