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

Transcrição

1 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 Vila Real, 2013

2 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: Vila Real, 2013

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

4 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. i

5 Capítulo 1 Introdução 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. ii

6 Capítulo 1 Introdução 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. iii

7 Capítulo 1 Introdução Índice Agradecimentos... i Resumo... ii Abstract... iii Índice... iv Índice de Figuras... vi Índice de Tabelas... viii Siglas e Acrónimos... ix 1. Introdução Contexto Objetivos Estrutura Contextualização Malware Botnets Estratégias de infeção Deteção de malware Soluções com honeypots Risco de deteção Emulação e Virtualização Deteção de Virtualização Técnicas de deteção e dissimulação de ambientes virtualizados Máquinas virtuais em HVM Análise de malware Análise estática Análise dinâmica Técnicas para análise dinâmica de malware Frameworks de análise dinâmica Trabalho desenvolvido Análise do problema iv

8 Capítulo 1 Introdução 4.2. Proposta de arquitetura para deteção de malware Caso de estudo Resultados do trabalho Período analisado Serviços atacados Análise das amostras Discussão de resultados Conclusões e trabalhos futuros Bibliografia Anexos Anexo 1 Querys SQL Anexo 2 Análise de similaridade Anexo 3 Análise de Cuckoo Anexo 4 Relatórios Cuckoo Anexo 5 Regras de classificação de malware Anexo 6 Identificação de malware v

9 Capítulo 1 Introdução Índice de Figuras Figura 1 Posicionamento de um NIDS distribuído na rede Figura 2 Classificação de honeypots adaptado de enisa[40] Figura 3 Arquitetura do sistema híbrido surdids[119] Figura 4 Posicionamento tradicional de um honeypot Figura 5 Posicionamento interno de um honeypot Figura 6 Arquitectura genérica de máquinas virtuais Figura 7 Técnica de deteção baseada na instrução SIDT Figura 8 Técnica de deteção baseada na instrução STR Figura 9 Alterações para impedir a deteccao de VMware retirado de Liston[65] 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] Figura 12 Funcionamento genérico da biblioteca detours adaptado de Galen [34] Figura 13 Arquitectura CWSandbox adapdata de Provos[90] Figura 14 Arquitetura Cuckoo adaptada de Rodriguez[95] Figura 15 Utilizacao JMP para hooking Figura 16 Hooking efetuado pelo chook utilizando a instrução MOV EAX,JMP EAX.42 Figura 17 Rede tradicional Figura 18 Arquitetura proposta Figura 19 Algoritmo de alto nível da arquitetura Figura 20 Estrutura da BD dionaea Figura 21 Arquitetura desenvolvida Figura 22 Total de ligações e downloads de amostras capturados durante o período estudado Figura 23 Visão global da atividade dos ataques vi

10 Capítulo 1 Introdução Figura 24 Número de ligações por porto Figura 25 Número de ataques no serviço MSSQL Figura 26 - Número de hosts que estabeleceu ligações ao serviço MSSQL Figura 27 Listagem dos drivers mais utilizados nos ataques ao serviço MSSQL Figura 28 - Número de ataques ao serviço SMB Figura 29 - Downloads e número de hosts no serviço SMB Figura 30 Análise dinâmica Cuckoo para a amostra Figura 31 gráfico comparativo sobre a distribuição de packers nas amostras vii

11 Capítulo 1 Introdução Índice de Tabelas Tabela 1 Requerimentos para monitorização de tráfego por largura de banda Tabela 2 Tabela comparativa de funcionalidades de IDS opensource Tabela 3 Tabela comparativa de honeypots de propósito geral adaptada de Grudziecki[40] Tabela 4 Listagem dos usernames mais utilizados nos ataques ao serviço MSSQL Tabela 5 Listagem das passwords mais utilizadas nos ataques ao serviço MSSQL Tabela 6 Vulnerabilidades utilizadas contra o protocolo SMB Tabela 7 Lista das 4 amostras capturadas mais frequentes Tabela 8 Número de amostras para as 4 amostras capturadas mais frequentes Tabela 9 Capacidades detetadas nas amostras viii

12 Capítulo 1 Introdução Siglas e Acrónimos API ACL CIFS CSIRT DGA DHCP DLL DMZ DNS IP I/O IRC PE SIEM SQL IDS IPC IPS LAN Application Programming Interface Access Control List Common Internet File System Computer SecurityIncident Response Team Domain Generation Algorithm Dynamic Host Configuration Protocol Dynamic Link Library Demilitarized zone Domain Name System Internet Protocol Input/Output Internet Relay Chat Portable Executable Security Information ad Event Managemnt Structured Query Language Intruson Detection System Inter Process Comunication Intrusion Prevention System Local Area Network ix

13 Capítulo 1 Introdução MD5 Message Digest 5 NFS OS P2P PCAP SMB SSH VM VMM TLS TCP SSL VoIP VPN Network File System Operating System Peer to Peer Packet Capture Server Message Block Secure Shell Virtual Machine Virtual Machine Monitor Transport Layer Security Transport Control Protocol Secure Sockets Layer Voice over IP Virtual Private Network x

14 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 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. 1

15 Capítulo 1 Introdução 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 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 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 opensource, e definido um cenário para efetuar o caso de estudo. No Capítulo 5 são 2

16 Capítulo 1 Introdução 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. 3

17 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 4

18 Capítulo 2 Contextualização dois ou mais grupos [122]. Segue-se uma apresentação dos que consideramos principais 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 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]. 5

19 Capítulo 2 Contextualização 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 apresentamse 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] 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] 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. 6

20 Capítulo 2 Contextualização 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 rootkits 1 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] 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 Também denominados bootkits. 7

21 Capítulo 2 Contextualização 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 malware. 8

22 Capítulo 2 Contextualização 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] 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 9

23 Capítulo 2 Contextualização despercebidos pois não é necessário interação nem permissão do utilizador[18]. Estes ataques podem recorrer a 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 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. 10

24 Capítulo 2 Contextualização 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] 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 11

25 Capítulo 2 Contextualização 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: MSE 2, 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 Microsoft Security Essentials. 12

26 Capítulo 2 Contextualização 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 13

27 Capítulo 2 Contextualização 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 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. 14

28 Capítulo 2 Contextualização 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] 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]. 15

29 Capítulo 2 Contextualização 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 16

30 Capítulo 2 Contextualização 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]. 17

31 Capítulo 2 Contextualização 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 18

32 Capítulo 2 Contextualização 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 s 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 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-day 3, 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 Block 4 ) 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 Protocolo de partilha normalmente utilizado para acesso a ficheiros impressoras e portas série. 19

33 Capítulo 2 Contextualização 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] 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] 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]. 20

34 Capítulo 2 Contextualização 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. 21

35 Capítulo 2 Contextualização 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 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. 22

36 Capítulo 2 Contextualização 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 23

37 Capítulo 2 Contextualização (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] 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 real 5. 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 Depende das capacidades de hardware e se a arquitetura tem extensões como VT-x. 24

38 Capítulo 2 Contextualização 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 6 6 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 Apesar de estar representado virtualização do tipo 1 bare metal a virtualização descrita ao longo do documento foi tipo 2 hosted. 25

39 Capítulo 2 Contextualização 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] 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]; 26

40 Capítulo 2 Contextualização 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, 27

41 Capítulo 2 Contextualização 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 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 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 28

42 Capítulo 2 Contextualização 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 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. 29

43 Capítulo 2 Contextualização 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] 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. 30

44 Capítulo 2 Contextualização 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]. 31

45 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. Na Figura 11 é possível de se observar como é efetuada a separação de privilégios 32

46 Capítulo 3 Análise de malware Figura 11 Modo de funcionamento do user mode e kernel mode no sistema windows, retirado de MSDN[76]. O malware que seja executado em user mode necessita de invocar system calls, assim torna-se trivial analisar system calls que o malware efetua, podem existir casos que o malware tenha privilégios de execução em kernel mode e nesse caso evade métodos de análise que utilizem hooks as system calls. Para percebermos melhor que tipo de funcionalidades o OS expõe iremos ver que funções é que o Windows utiliza, normalmente os sistemas operativos providenciam uma API para que os programas se possam abstrair, em sistemas Windows é providenciada a WinAPI 7 que é tão extensa que normalmente os desenvolvedores de Windows não necessitam de bibliotecas externas[77]. As funcionalidades da WinAPI que normalmente são utilizadas por malware podem ser classificadas em 7 categorias[108]: 7 A WinAPI engloba varias API s como é o caso da Win32 API. 33

47 Capítulo 3 Análise de malware Kernel32.dll providencia acesso a recursos fundamentais de um sistema Windows tais como o sistema de ficheiros, dispositivos, processos, threads e o tratamento de exceções; Advapi32.dll providencia acesso a funcionalidades adicionais tal como criação de serviços, administração de contas de utilizador e acesso ao registo do Windows; Gdi32.dll providencia funcionalidade para o output de conteúdo gráfico, para o suporte de kernel existe o win32k.sys que comunica diretamente com os drivers gráficos; User32.dll contém todos os componentes do user interface, tais como botões, scroll e outros componentes para controlar e responder a ações dos utilizadores; Ntdll.dll este DLL é a interface para o kernel do Windows. Os executáveis normalmente não importam esta DLL diretamente mas é quase sempre importado indiretamente pelo kernel32.dll. Se um executável importa este ficheiro significa que o autor precisa de funções não disponíveis em programas normais tais como manipular processos; Wsock32.dll/Ws2_32.dll estas são DLL responsáveis pela comunicação de rede. Um programa que aceda a estas DLL irá, muito provavelmente, efetuar tarefas relacionadas com networking; Wininet.dll este DLL serve para implementar protocolos tais como FTP, HTTP, NTP. Com o conhecimento de quais destas API o malware importa, é possível deduzir as suas funcionalidades Análise estática A análise estática de malware é um processo de análise em que a amostra de software não é executada. Assim as ferramentas de análise estática permitem a um analista recriar a representação de um programa compilado e extrair informação útil de um binário, providenciando gráficos das chamadas de funções (calls), uma visão global das estruturas de dados e das funções utilizadas. 34

48 Capítulo 3 Análise de malware Assim o analista consegue perceber o funcionamento do software, mesmo em casos que o código fonte não esteja disponível[103], pois o código fonte das amostras maliciosas normalmente não está disponível, trazendo mais desafios aos analistas, outros dos problemas é os binários encontrarem-se comprimidos (packed) ou mudarem o código mantendo o algoritmo (polimórficos), que faz com que a análise estática apresente resultados ambíguos, por exemplo quando o malware necessita de aceder a valores que não podem ser obtidos estaticamente, tais como saltos indiretos e quando estão comprimidos. Sabendo que a maior parte do malware empregam técnicas contra a análise estática[122] tornando o processo de investigação mais demoroso e propenso a erros, assim o conhecimento das técnicas usadas e a forma como se conseguem evadir os métodos utilizados pelo malware são importantes de se perceber Análise dinâmica A análise dinâmica no contexto da análise de malware é um processo de análise efetuado enquanto a amostra de software é executada. Existem várias técnicas para implementar esta análise, sendo uma das mais utilizadas a intercetação das chamadas das funções, o processo de intercetar chamadas de funções é denominado de hooking[34]. O hooking é efetuado no programa para que além da função original é invocada outra função, sendo esta última a responsável pela funcionalidade de monitorização ver Figura Implementação de hooking Em ambientes Windows existe uma biblioteca providenciada pela Microsoft Research que nos permite monitorizar funções do Win32[34]. A biblioteca intercepta funções rescrevendo o código em memória para as funções que queremos e providencia ferramentas para carregar DLL em qualquer binário Win32. O método de funcionamento passa pela introdução de outras funções que providenciam a utilidade desejada, a função responsável pelo desvio também tem a responsabilidade de voltar a redirecionar para a função original como se pode ver na Figura

49 Capítulo 3 Análise de malware Figura 12 Funcionamento genérico da biblioteca detours adaptado de Galen [34]. A diversão do flow da função é efetuado através do redireccionamento da função para o trampolim que depois chama a função original. Assim é possível implementar hooking nas funções desejadas e determinar no contexto do malware que chamada foi efetuada Desafios da análise de malware capturado Na análise de malware visto que não existe acesso ao código fonte existem alguns desafios a ter em conta, normalmente considera-se que a análise efetuada em binários sofra dos seguintes problemas: Complexidade O primeiro desafio é a complexidade da tarefa, quando se efetua engenharia reversa numa amostra de malware dependendo da arquitetura o assembly mostrado é completamente diferente, cada instrução pode ter semânticas complexas, instruções que se comportam de maneira diferente dependente dos operadores ou efeitos colaterais da utilização de opções no compilador[26]; Falta de representação de alto nível Trabalhar com assembly introduz outros desafios, não existem funções, são utilizados jumps que tornam o código mais complexo e difícil de perceber. Também não existem construtores, os únicos tipos existentes são os registos e a memória, para além disso o código binário não tem buffers[26]; 36

50 Capítulo 3 Análise de malware Vista global Para o tipo de trabalho efetuado é necessário a perceção do sistema como um todo, monitorizar um sistema é claramente um grande desafio comparativamente a análise tradicional onde apenas uma subsecção do programa é analisada[26]. Existe uma grande diferença na análise de malware amador e profissional e aí é que está a grande diferença em termos de análise, se o autor de malware possuir grande conhecimento técnico vai utilizar técnicas de ofuscação, criptografia e outras técnicas para que a análise do malware seja difícil e demore anos [113] Técnicas para análise dinâmica de malware API/function hooking Esta técnica de análise consiste em se efetuar o hooking às instruções, assim, efetuamos um salto (JMP) para uma função a nossa escolha, existem algumas precauções a ter em conta para o processo ser transparente e não alertar o malware. Existem vários métodos para o hooking, a CWSandbox utiliza o método in-line code overwriting [109], que faz o overwrite do processo na memória, assim não interessa se a API foi chamada de forma implícita (loading do DLL antes da execução) ou explícita pois vai ser redirecionada para o novo código. Os passos para se efetuar são os seguintes: Criação Criar a aplicação no modo suspenso, assim o Windows irá fazer o load inicializando a aplicação e todos os DLL que foram linkados implicitamente; Análise Quando a aplicação é suspensa o Windows não consegue executar a main thread por isso não será executado nenhum código, efetuada a inicialização, é efetuada uma análise de quais as funções que irão ser chamas e que terão de ser redirecionadas (hooks). Guarda-se o código original, para mais tarde se reconstruir as instruções; Patch As primeiras instruções da API têm de ser rescritas com um JMP ou uma call para localização do nosso código. Para o hooking à API ser funcional é necessário um hooking as funções LoadLibrary e LoadLibraryEx assim é 37

51 Capítulo 3 Análise de malware possível o carregar DLL de forma explícita, também existe malware que consegue carregar malware sem a utilização da LoadLibrary[43]. Uma maneira de se escapar ao hooking é utilizar funções do kernel diretamente e evitar a utilização da API, mas isto é incomum pois o programador teria de saber exatamente qual é a versão do OS e quais as patchs instaladas. A grande maioria do malware pretende infetar o maior número de utilizadores e não apenas um em específico por isso desenvolver malware com capacidade de chamar funções do kernel, tornar-se-ia demasiado específico Injeção de DLL Uma maneira reusável e modular de se implementar hooking a é a utilização de injeção de DLL, pode ser efetuado de várias maneiras, em ambientes Windows o próprio OS proporciona várias maneiras de se efetuar a injeção: Utilização de chaves de registo Utilizando a chave de registo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersi on\windows\appinit_dlls é possível definir o carregamento de um DLL para cada processo que utilize o User32.dll[60, 118] CreateRemoteThread Funções de processo tais como CreateRemoteThread podem ser usadas para injetar uma DLL num programa depois de já ter sido executado.[106] NtCreateThreadEx Utilizando a funcionalidades que o próprio Windows providencia: tais como: SetWindowsHookEx, ZwCreateThread ou NtCreateThreadEx. Esta última função é uma versão não documentada que funciona em todas as versões do Windows[106] Frameworks de análise dinâmica A análise dinâmica de malware é um tópico com bastante relevo[29, 33, 133], pois permite a um analista perceber o comportamento de uma amostra de uma forma rápida, segura e eficaz. Nas frameworks de análise dinâmica a amostra é executada e todo o seu comportamento é analisado, assim é possível determinar os propósitos da amostra e se é maliciosa. Esta secção irá abordar as técnicas de análise dinâmica normalmente utilizadas dando a 38

52 Capítulo 3 Análise de malware conhecer as suas capacidades, serão apresentadas duas plataformas de análise de malware, devido à importância histórica foi abordada a CWSandbox agora apelidada de GFISandbox que passou a ser um produto comercial, a outra plataforma denominada de Cuckoo tem sido alvo de atenção nos últimos tempos. Os criadores que estão por detrás do seu desenvolvimento são conhecidos no projeto honeynet e têm bastante reputação no campo de análise de malware, assim foi escolhida para o estudo nesta dissertação CWSandbox A plataforma de análise CWSandbox permite a execução de malware num ambiente simulado e assim deduzir se o comportamento de uma amostra é ou não malicioso. Para isso injeta um DLL no binário para efetuar a monitorização das system calls invocadas, depois do processo de malware terminar gera um relatório que permitirá ao analista uma melhor compreensão sobre a amostra. A CWSandbox utiliza várias técnicas desde o hooking a captura do tráfego de rede para ter uma melhor perceção do comportamento do malware. A sandbox é constituída por duas aplicações, o cswsandbox.exe e cwmonitor.dll, como se pode ver na Figura 13. Figura 13 Arquitectura CWSandbox adapdata de Provos[90]. O método de hooking que a sandbox utiliza passa por suspender o processo e injetar o dll. Depois da fase de inicialização o processo é resumido e executado durante o tempo que o malware corre. ODLL injetado (cwmonitor.dll) notifica o executável 39

53 Capítulo 3 Análise de malware (cwssanbox.exe) dos parâmetros utilizados nas calls, assim o DLL consegue comunicar quando o processo de malware cria novos processos, permitindo a instalação e injeção nesses processo do mesmo DLL que vai permitir a comunicação ao cwsandbox.exe[90]. O diagrama da Figura 13 representa a relação entre os DLL e a sandbox, para o método de comunicação entre processos é utilizado IPC, onde cada função com um hook envia uma notificação para informar a sandbox sobre a call e os parâmetros passados. Em alguns casos é enviada uma resposta por parte da sandbox para o DLL. Devido à grande comunicação entre os processos e ao número desconhecido de processos que o malware irá criar é necessário ter um método de comunicação fiável e que não pudesse ser modificado por isso foi implementado um mecanismo de comunicação entre processos IPC na CWSandbox[90]. O DLL esconde a sua presença do malware através de técnicas de rootkit, fazendo com que todos os objetos que pertencem a sandbox sejam escondidos do malware, tal como os processos, módulos, ficheiros, entradas de registo etc. O método de funcionamento da CWSandbox pode ser categorizado em 3 fases: Inicialização A fase de inicialização, onde é injetado o DLL e existe troca de informação inicial; Execução A fase de execução, esta fase dura tanto quanto o processo de malware, é também nesta fase que é efetuada a maior parte da comunicação entre os componentes; Relatório Os dados colecionados são analisados e é gerado um relatório XML que contém os protocolos acedidos, passwords utilizadas e vetores de infeção utilizados. O relatório deve ajudar o analista a classificar a amostra de uma forma rápida e eficaz, análises posteriores podem ser efetuadas pelo analista caso se verifique necessário Cuckoo A Cuckoo sandbox permite a execução de malware num ambiente virtualizado, tem como diferenciador o facto de ser opensource ser recente e os responsáveis pelo projeto estarem envolvidos em projetos de captura e análise de malware. 40

54 Capítulo 3 Análise de malware Relativamente as capacidade permite a monitorização dos processos e calls, suporta dumps de memória do processo de malware, captura do tráfego de rede num formato standard (PCAP), e outras funcionalidades que demonstram a extensibilidade, como por exemplo a captura de ecrãs durante a execução do malware. A arquitetura da framework Cuckoo é baseada num software central de gestão que lida com a execução, análise das amostras, e os hóspedes de análise. A maneira como a Cuckoo sandbox efetua o hooking foi baseada na biblioteca detours da Microsoft mas eventualmente foi rescrita e agora é apelidada de chook. A maneira como a amostra é analisada é feita com recurso à virtualização onde a amostra é lancada numa máquina virtual que é reposta ao estado inicial em poucos segundos depois da análise, o hospedeiro corre os componentes essenciais à análise e faz a gestão dos hóspedes onde a amostra é executada como se pode ver na Figura 14 Figura 14 Arquitetura Cuckoo adaptada de Rodriguez[95]. Como se observa na Figura 14, a aplicação Cuckoo.py comunica com o agent.py que irá comunicar com a DLL injetada (cuckoomon.dll) que é o responsável pelo hook das várias funções do malware e também é da sua responsabilidade providenciar comunicação através de um named pipe 8, assim a DLL consegue comunicar com o agente e enviar informação sobre os processos criados. O Motor do Cuckoo responsável pelo hooking foi reescrito, antigamente utilizava a biblioteca detours da Microsoft o que se revelou limitante e facilmente detetável, visto 8 Processo de comunicação entre processos. 41

55 Capítulo 3 Análise de malware que o hook apenas utilizava uma instrução para a função de trampolim. Assim a deteção passava por procurar um opcode[31] como se pode ver na Figura 16. Figura 16 Deteção do hook da biblioteca detours. Devido a isso o motor foi escrito de raiz, com o nome de chook este novo motor permite inline hooking para além que permite ao utilizador utilizar e desenvolver o código de trampolim desejado, sendo que atualmente o motor escolhe aleatoriamente a função de trampolim[31]. É possível ver na Figura 15 uma implementação de hooking utilizando a instrução JMP, à esquerda é o código original e na direita a utilização de um hook através da instrução JMP. Figura 15 Utilizacao JMP para hooking. O novo motor de hooking da Cuckoo fornece mais flexibilidade, permitindo ao analista especificar o seu próprio código de trampolim e assim utilizar varias técnicas como se pode ver na Figura 16. Figura 16 Hooking efetuado pelo chook utilizando a instrução MOV EAX,JMP EAX. 42

56 Capítulo 3 Análise de malware Na parte dos relatórios a framework providência bastante informação sendo bastante extensivos e modulares sendo possível escolher o formato de relatório e baseado na análise pretendida é dado um relatório específico, suporta output em JOSN, HTML, MAEC, MongoDB, HPFeeds. O tipo de relatório pode ser um das seguintes 6 categorias que se ajusta ao nível de informação que se pretende[68]: EXE É a análise por defeito a ser executada e serve para analisar executáveis do Windows; DLL Para a análise de DLL existe a possibilidade de poder instruir a framework qual a função a ser analisada também existe a opção para não injetar o processo rundll32; PDF Utilizada para análise de pdf ; DOC/EXCEL Análise de ficheiros de documento; IE Para analisar o comportamento do Internet Explorer quando abre o ficheiro fornecido, este modo é útil para a investigação de exploits para o browser; BIN Utilizado para analisar dados binários tais como shellcode. Como podemos constatar as frameworks de análise dinâmica providenciam ao analista uma visão sobre o processo de infeção e seu comportamento podendo determinar através as suas ações se a amostra é maliciosa e assim tornar mais fácil a construção de assinaturas e outros métodos que permitam a desinfeção e prevenção de malware de uma forma eficaz e eficiente. 43

57 CAP 4 4. Trabalho desenvolvido Uma solução de deteção de malware deve ser baseada no conhecimento aprofundado das várias ferramentas existentes, das tecnologias envolvidas e da configuração da infraestrutura. Nesse sentido, este capítulo inicia com o ponto 4.1., Análise do problema, em que é feita a definição um cenário hipotético representativo de redes reais, sujeito a ataques de malware oriundo da Internet. Segue-se o ponto 4.2, Proposta de arquitetura para deteção de malware, onde é proposta uma arquitetura adequada à deteção de malware baseada em software opensource e são apresentadas as opções feitas e as funcionalidades implementadas. Finalmente, no ponto 4.3, Caso de estudo, apresenta-se o cenário utilizado como caso de estudo para teste da solução proposta Análise do problema Atualmente devido a rápida expansão da Internet e dos seus utilizadores, surgiram novas oportunidades para pessoas mal intencionadas conseguirem ter proveito financeiro indevido. A ubiquidade das tecnologia de comunicação e dispositivos veio provocar um enorme uso maligno destes sistemas por parte de pessoas criminosas, que utilizam a Internet como um escudo de anonimidade, nos crimes que cometem. O carater lucrativo do malware contribuiu decisivamente para a sua rápida proliferação, evoluindo de um simples hobby para uma indústria [47, 49, 111, 121]. O impacto deste tipo de software pode tomar grandes proporções, podendo ter implicações políticos e financeiras, como foi o caso do Stuxnet e o Flame, que são muito sofisticados e foram desenvolvidos para impedir o programa nuclear iraniano[126]. A segurança em redes de computadores é tradicionalmente providenciada pelas firewall e IDS, que partem do princípio que as ameaças são conhecidas. No entanto o malware quando surge pela primeira vez (0-day 9 ) ou como uma variante nova, esta estratégia não é eficaz, sendo 9 Vulnerabilidades desconhecidas 44

58 Capítulo 4 Trabalho Desenvolvido necessário recorrer a outro tipo de ferramentas que nos permitam reconhecer uma ameaça. Programas tais como como o honeypot Dionaea, e de análise de software, como por exemplo, Yara e ssdeep. Na Figura 17 apresenta-se um diagrama de uma rede tradicional de computadores. Figura 17 Rede tradicional. Como se pode ver na figura, a ligação da Internet é efetuada por um router que encaminha tráfego de dados entre as diferentes redes. Este dispositivo dispõe de capacidade de firewall que permite filtrar os tráfegos com base em sessões estabelecidas, nos endereços IPs de origem e destino, e nos protocolos utilizados. Dentro da organização estão disponíveis recursos segmentados em redes diferentes. Um dos segmentos, normalmente designado por DMZ 10, que serve como camada adicional de segurança, normalmente os servidores dentro da DMZ conseguem interagir com a intranet e extranet servindo assim de stepping stone para serviços públicos que necessitem de interagir com conteúdos dentro da intranet contém recursos acessíveis de para o exterior da rede. Com esta arquitetura é possível proteger de ataques externos mas não tem qualquer peso para a segurança interna.[8] Normalmente na DMZ são colocados os serviços que os utilizadores podem aceder da extranet sendo os mais normais servidores HTTP, que devido a necessidade de 10 Zona Desmilitarizada 45

59 Capítulo 4 Trabalho Desenvolvido comunicarem com uma base de dados (BD) necessitam de aceder a uma que se encontram na rede interna, servindo assim o DMZ de uma zona intermediária de comunicação. No caso do SMTP 11 as mensagens e a base de dados dos utilizadores estão guardadas na rede interna sem acesso ao exterior sendo utilizado uma DMZ para os servidores alojados conseguirem aceder à rede interna outra das utilizações para controlo do tráfego é a utilização de uma reverse proxy, sendo assim possível a monitorização dos utilizadores. Os IDS também tem um papel importante por isso a sua escolha é um tópico interessante para complementar a arquitetura aqui proposta. As soluções opensource Snort, Suricata e Bro são as três grandes plataformas de IDS. A organização tem de ter presente que não existem soluções completas e que um IDS não é a solução para os problemas de segurança mas apenas mais uma camada. Tendo isso em conta deve ser capaz de responder a perguntas como: Número de interfaces a monitorizar? Localização dos links? Quantidade de tráfego a monitorizar? Método de captura? Conhecimento de OS por parte da equipa? Arquitetura de CPU utilizada? Framework de captura de tráfego baseada em software/hardware? Gestão do tráfego? Design e planeamento do hardware? Assim a empresa deverá dimensionar de acordo com o que pretende. Podemos é estimar baseado no existente e que na maior parte dos casos pode ser utilizado a seguinte configuração como se pode ver na Tabela Protocolo utilizado para o envio de correio eletrónico. 46

60 Volume de CPU RAM Hardware tráfego 12 Load Balancing Capítulo 4 Trabalho Desenvolvido Requerimentos extra <200Mbits/seg 1Core 8Gbytes Não Não Mbits/seg Mbits/seg 1-10Gbit/seg >2 Cores >8Gbytes Não Não é necessário, mas recomendável a utilização de uma framework de captura eg: PF_RING >4 Cores 10-20Gb Não PF_RING NAPI 1 Core por 4Gbytes por Sim 250Mbits/seg. 250Mbits/seg. Requer conhecimento especializado. TNAPI DNA+Libzero >10Gbit/sec Sim Requer Conhecimento especializado. Gigamon box Base de Dados Optimizada Tabela 1 Requerimentos para monitorização de tráfego por largura de banda. Como podemos ver da tabela é possível verificar o hardware necessário baseado na largura de banda do tráfego a ser analisado. A escolha pode recair sobre a utilização de várias distribuições, os principais são o Snort, Suricata e Bro as suas funcionalidades podem ser descritas na seguinte tabela: Funcionalidades Software de monitorização Bro Snort Suricata Processamento Multi Threading(SMP) Não Não Sim Suporte IPv6 Sim Algum Sim White/Black Listings Sim Sim Sim Identificação automática do protocolo Sim Sim Sim GPU Não Sim Sim Flowbits Sim Sim Sim Inline Windows Support Não Não Sim Pesquisa GeoIP Sim Sim Sim Gratuito Sim Partes Sim Tabela 2 Tabela comparativa de funcionalidades de IDS opensource. Como podemos ver hoje em dia as capacidades dos três grandes IDS opensource são similares recaindo a escolha sobre o administrador[4]. Fica a nota que que o Snort é o mais antigo e tem a melhor performance em instalações que tenham hardware com apenas um core, a grande diferença do Suricata é a sua escalabilidade em vários Processadores[4]. Caso a organização pretenda mais informação e melhorar a segurança pode implementar outro tipo de ferramentas[38, 44] que para além da monitorização de trafego capturam e 12 No máximo 2 links. 47

61 Nome Escopo deteção. Precisão emulação. Qualidade dados. Escalabilidade performance. Fiabilidade. Extensibilidade. Facilidade utilização. Suporte. Custo. Capítulo 4 Trabalho Desenvolvido analisam ataques, este tipo de ferramentas como o Dionaea, Yara e ssdeep permitem a recolha de informação não obtida por um IDS mas pela utilização de um honeypot Como se pode verificar uma organização média que pretenda melhorar a sua segurança pode introduzir soluções de monitorização opensource. Para ajudar na escolha pode ser consultada a seguinte tabela 13 : Amun Multi $ Dionaea Multi $ KFSensor Multi $$ Honeyd Multi $ Honeytrap Multi $$ Nepenthes Multi $$ Tiny Honeypot Multi $$ Tabela 3 Tabela comparativa de honeypots de propósito geral adaptada de Grudziecki[40]. Com esta base comparativa é proposta uma arquitetura para deteção de malware no capítulo a seguir Proposta de arquitetura para deteção de malware Com base na tecnologia de análise de malware, apresenta-se uma proposta para fazer a análise das ameaças na Internet e retirar estatísticas sobre quais as vulnerabilidades mais utilizadas para diferentes protocolos e assim permitir uma resposta proactiva. As ferramentas utilizadas nesta dissertação foram escolhidas atendendo as suas funcionalidades e serem opensource. Na Figura 18 apresenta-se a arquitetura proposta para a deteção de malware utilizando captura baseado em honeypots, análise baseado em sanboxes dinâmicas e classificação baseado em fuzzy hashes e HIPS: 13 Escala de 1-5 sendo 5 o valor máximo. 48

62 Capítulo 4 Trabalho Desenvolvido Figura 18 Arquitetura proposta. Numa rede tradicional de computadores como a apresentada na Figura 17, propõe-se a instalação de um honeypot na DMZ de baixa interação, de forma a capturar as amostras de malware. Para a instalar das ferramentas de análise e classificação, recomenda-se a escolha de uma zona de rede segura. As amostras capturadas pelo honeypot serão transferidas através de uma ligação de rede, que funciona de acordo com o fluxograma da Figura 19. Figura 19 Algoritmo de alto nível da arquitetura. 49

63 Capítulo 4 Trabalho Desenvolvido Inicialmente o sistema faz a captura de amostra de malware no honeypot, caso a classificação determine que existe pouca informação sobre a amostra irá ser analisada. A classificação é feita com recurso a três programas, primeiro é comparada com um website que passa a amostra por 40 antivírus diferentes e dá o seu resultado assim determinando a taxa de deteção, depois é utilizado o programa ssdeep para verificar se existe similaridade com alguma amostra no repositório. Caso seja uma amostra com potencial então é analisada dinamicamente com a framework Cuckoo. Escolha justificação Ferramentas Assim a solução é constituída por 4 tecnologias, a utilização de honeypots para a captura, framework Cuckoo para a análise, ssdeep para a classificação e Yara para a classificação e procura. Assim esta configuração vem adicionar mais informação, no caso do honeypot ele para além dos binários também captura o tráfego associado e armazena-lo num repositório que permite o seu replay. Para além disso é complementado com uma BD que contém inúmeros campos valiosos como o IP do ofensor, tipo de malware. O resto das informações é guardado numa base de dados[5] com se pode ver na Figura 20 Figura 20 Estrutura da BD dionaea. 50

64 Capítulo 4 Trabalho Desenvolvido Com as ferramentas de identificação e classificação podemos agrupar e saber se a amostra é apenas uma variante ou uma nova ameaça. Existem vários métodos para a identificação para este caso recorreu-se a funções de hash, que são um algoritmo que permite transformar uma grande quantidade de informação num identificador único, assim podemos formar um catálogo de malware capturado. Para a análise existem várias sandboxes que são ambientes que tem por base a virtualização que correm a amostra num ambiente contido e assim permitem a um analista verificar que tipo de ações a amostra efetuou, sabendo o vetor de infeção e domínios de internet utilizados pela amostra[38]. Assim a arquitetura permite melhorar a segurança proactivamente, recolhendo informação sobre ataques tornando possível a criação de assinaturas para melhorar os métodos de segurança existentes, NIDS, HIDS conhecendo as suas ações, o malware ou ofensores efetuam num sistema é de informação valiosa na estratégia de defesa[40, 125].Propõe-se a utilização do OS Linux (Debian) uma vez não traz serviços desnecessários stripped não introduz vetores de ataques desnecessários sendo assim a sua administração efetuada de forma fácil melhorando a estabilidade do sistema, não é tao suscetível a vírus, o facto de o Debian ser opensource poupando dinheiro em licenças. Como a maior parte do malware e spyware é para sistemas Windows, o Linux não tem esse problemas e não é necessita a instalação de drivers, devido à própria arquitetura do OS, também não precisa do mesmo nível de manutenção[73]. Para ferramentas de classificação foi escolhido o método Context Triggered piecewise Hashes (CTPH) ou fuzzy hashes, através deste algoritmo é possível comparar o grau de similaridade de dois inputs. No contexto de análise de malware é útil pois permite verificar se as amostras são variantes de malware, permite detetar infeções na rede comparando extratos de memória de hosts infetados e hosts normais a deteção de malware com código mutante e comparar a amostras no disco com a amostra na memória. O conceito de hashing é um conceito bem conhecido no mundo da informática e uma função de hash pode ser definida por: uma função matemática que leva como parâmetro um campo variável chamado de pré-imagem e converte-a para uma string de tamanho fixo (normalmente menor) chamada de hash, este tipo de hashing é o tradicional ou hashing criptográfico, pode ser definido como uma função de hash com as seguintes propriedades[59]: 51

65 Capítulo 4 Trabalho Desenvolvido Preimage é computacionalmente impraticável começar com o output h e encontrar o x de tal forma que H(x)=h. Second PreImage é computacionalmente inviável dado um input x encontrar o input y sendo x!= y e H(x) =H(y). Resistente a colisões ou seja é computacionalmente inviável encontrar o par (x,y) de tal forma que H (x)=h (y). As hashes são utilizadas para vários propósitos por exemplo, o de verificar a integridade de um ficheiro ou em algoritmos de assinaturas digitais. O hashing tradicional é a base do método fuzzy hashing que serve para identificar ficheiros similares dos métodos utilizados nesta dissertação.com fuzzy hashing é possível de identificar ficheiros similares sendo o processo o seguinte[59, 96]: Hashing tradicional em blocos variáveis do input. O valor dessa hash é adicionado ao valor total da fuzzy hash A string da hash tradicional mais metadados são utilizadas como o valor da fuzzy hash Os ficheiros similares são passíveis de ser identificados pela comparação, pois a mudança no ficheiro vai apenas afetar parte da fuzzy hash. O tamanho do pedaço em que as hashes tradicionais são utilizadas depende da implementação. Os pedaços não precisam de somar o ficheiro de input todo mas apenas secções do ficheiro ou partes o único critério a ter em conta é que não se podem sobrepor[96]. A implementação utilizada nesta dissertação foi a do programa ssdeep. Para a geração de assinaturas foi utilizado o software Yara que é um motor de classificação e identificação que permite criar regras que detetem strings, sequências de instruções, expressões regulares, padrões de bytes. É possível integrar este motor em código C ou então em python através da API da Yara que basicamente é um HIPS que permite a criação e teste de regras on the fly. No caso da framework de análise foi escolhida a Cuckoo pois permite a execução de malware num ambiente virtualizado, tem como diferenciador o facto de ser opensource e permitir a customização as nossas medidas, as suas funcionalidades envolvem a monitorização dos processos e calls, suporta dumps de memória do processo de 52

66 Capítulo 4 Trabalho Desenvolvido malware, captura do tráfego de rede num formato amigável (PCAP 14 ), é escrita em python assim tornando fácil a sua extensibilidade, e tem métodos como por exemplo a captura de ecrãs durante a execução do malware, que foi um método inovador nas sandboxes. No caso do honeypot foi escolhido a Dionaea pelo facto de ser um dos melhores server-side honeypot[40] sendo facilmente extensível através de módulos utilizando python como linguagem de scripting, suporta IPv6 e TLS 15 consegue correr sem privilégios especiais. Os Protocolos na Dionaea são implementados como módulos por isso é possível emular qualquer protocolo, a qualidade da emulação é muito boa e neste honeypot é dada ênfase a qualidade do protocolo SMB que normalmente e utilizado por worms e botnets para infetar hosts outro modulo também presente neste honeypot é o VoIP. Para a identificação de shellcode é utilizada a biblioteca libemu que consegue detetar shellcode desconhecido sem interação sendo o seu objetivo principal a obtenção do malware utilizado pelo ofensor, para além disso também é criado um log da sessão, que inclui parâmetros tais como: conexão, origem do incidente e as suas propriedades ver Figura 20, para além disso suporta ferramentas tipo o p0f que detetam o sistema operativo do atacante e a sua geo-localização, suportando também a análise externa utilizando frameworks de análise dinâmica e outros serviços como VirusTotal. A sua fiabilidade é excelente permitindo ao software correr durante longos períodos sem grandes problemas, outra vantagem é a partilha de amostras via XMPP, assim é possível melhorar o estado de segurança da Internet através da partilha mútua, sabendo que tipo de ataques estão a ser orquestrados e assim recolher informação que possa ajudar um analista a perceber as motivações e funcionalidades das amostras. É de referir que é possível criar um mecanismo de partilha de amostras por XMPP interno. E com as ferramentas utilitárias que acompanham o dionaea, por exemplo a ferramenta retry.py permite o replay de tráfego capturado pelo honeypot para o host que se designar, isto é atrativo para testar um novo ataque num honeypot de alta interação e verificar se existe uma vulnerabilidade desconhecida. 14 Formato de captura de tráfego de rede. 15 Transport Layer Security é um protocolo criptográfico que providencia seguranças nas comunicações na Internet vem substituir o SSL. 53

67 Capítulo 4 Trabalho Desenvolvido 4.3. Caso de estudo Como caso de estudo que considerou-se um cenário hipotético de uma empresa já com um sistema devidamente montado como a captura de malware e feita com honeypots, os honeypots não geram tráfego sendo a sua integração em redes já estabelecidas um processo trivial de adicionar recursos, a gestão de administração é mínima a arquitetura aqui aplicável é passível de se utilizar em redes de qualquer tamanho até sendo possível configurar vários honeypots por segmento e centralizar os dados obtidos num repositório central onde pode ser efetuado a sua análise posterior. Na Figura 21 apresenta-se o sistema implementado. Implementação Figura 21 Arquitetura desenvolvida. Foi utilizado um router com firewall baseado em tecnologia opensource de uma forma a segmentação o tráfego para as várias subnets. No segmento DMZ foi colocada a honeypot e assim foi efetuado uma implementação tradicional em que a honeypot fica exposta a Internet para assim obtermos informação sobre que tipos de ameaças estão presentes na ligação que estamos a utilizar. Depois do processo de captura as ameaças estas são acedidas por um analista que se encontra na LAN onde começa o processo de classificação e análise. 54