Crie uma sandbox melhor

Transcrição

1 White paper Crie uma sandbox melhor Uma estratégia funcional para uma proteção abrangente contra malware

2 Sumário A evolução conjunta do malware e da análise de detecção 3 Análise dinâmica x estática 3 O imperativo do desempenho 3 Nível um: detecção de ataques conhecidos 4 Nível dois: defesas comportamentais em tempo real 4 Nível três: análise dinâmica 5 Sandbox específica para os alvos 5 A importância da interação 5 Interpretando as análises dinâmicas 5 Nível quatro: análise estática de código 6 Compactação, descompactação e engenharia reversa 7 Uma estratégia de eliminação seletiva para a superioridade da sandbox 9 2 Crie uma sandbox melhor

3 A evolução conjunta do malware e da análise de detecção Os criminosos cibernéticos e os estrategistas de segurança de TI estão presos em uma corrida armamentista crescente. Conforme o malware usado para invadir ambientes de TI se torna cada vez mais sofisticado e evasivo, novas tecnologias estão surgindo para encontrar a agulha no palheiro, não importa o quanto esteja bem camuflada. Um dos desenvolvimentos mais promissores para a defesa está ocorrendo na área de detecção de análise dinâmica, conhecida popularmente como sandboxing. Há vários produtos disponíveis atualmente e outros estão em vários estágios de comercialização. Compreensivelmente, as abordagens arquitetônicas adotadas pelos principais desenvolvedores variam muito, assim como as formas em que esses novos produtos se integram a estratégias de segurança mais amplas. No momento, é difícil fazer comparações entre tecnologias com confiança, ou mesmo ter certeza de que a terminologia básica é aplicada de forma consistente. Este documento propõe uma estratégia de design lógica para a análise dinâmica de malware que otimiza a eficácia, a eficiência e a economia da detecção. Tentaremos identificar os limites da detecção dinâmica e os métodos complementares necessários para garantir uma segurança robusta. Por fim, vamos sugerir algumas distinções importantes que geralmente são obscurecidas por uma terminologia imprecisa. Análise dinâmica x estática A distinção entre análise dinâmica e estática é, talvez, a informação de contexto mais importante para qualquer discussão sobre soluções de sandbox para malware avançado. A análise dinâmica busca identificar arquivos executáveis maliciosos carregando-os em um ambiente de tempo de execução protegido, geralmente virtualizado, e observando seu comportamento durante um intervalo predeterminado. Para comparar adequadamente essa tática com a análise estática, precisamos primeiro resolver uma discrepância comum no uso desse último termo. A verdadeira análise estática (às vezes chamada de análise estática de código) prevê os possíveis comportamentos de um executável com base em uma avaliação detalhada do seu código. O termo análise estática é frequentemente usado de forma incorreta, referindo-se a técnicas mais simples e menos reveladoras (às vezes chamadas de análise estática de arquivos) que só analisam uma parte do cabeçalho do arquivo ou só podem acessar conteúdo que não tenha sido ocultado. Elas têm utilidade limitada na identificação de malware avançado. Por isso, todos os usos do termo análise estática neste documento referem-se a técnicas que são capazes de extrair, interpretar e analisar o código completo de um arquivo. Tanto as técnicas dinâmicas como as verdadeiras técnicas estáticas possuem vantagens e desvantagens. A análise dinâmica pode identificar o malware com um grau de confiança muito alto, com base na observação direta de seu comportamento. Essa é a forma mais confiável de identificar com precisão as ameaças escondidas em executáveis complexos, mas pode ser facilmente derrotada por vários estratagemas. Um arquivo pode simplesmente esperar até que o período de observação acabe, atrasando o início de qualquer comportamento revelador por um intervalo predeterminado que seja mais longo do que uma inspeção economicamente viável por sandbox. Um arquivo também pode ser programado para reconhecer um ambiente protegido detectando a ausência (ou presença) de certos recursos, executando somente um conjunto limitado de operações enganosamente inofensivas. A inspeção estática identifica código malicioso com um grau menor de confiança do que a análise dinâmica, pois depende de inferência em vez de observação, mas também oferece uma visão da natureza do código latente (que não está em execução), para a qual a análise dinâmica é completamente cega. Por exemplo, a análise estática de código identifica similaridades estruturais entre o código latente e amostras conhecidas de malware. Ela quantifica a porcentagem do código executada durante uma avaliação em sandbox e até mapeia os caminhos lógicos de execução de um arquivo complexo, sem executar de fato qualquer parte do código. É surpreendente como as vantagens e desvantagens das análises dinâmica e estática são complementares. Embora as técnicas normalmente associadas a uma sandbox para malware sejam dinâmicas, é improvável que uma detecção precisa e confiável possa ser obtida, a menos que tanto uma análise dinâmica quanto uma autêntica análise estática de código sejam aplicadas em um processo bem integrado. Uma sandbox eficiente deve ser, ao mesmo tempo, dinâmica e estática. O imperativo do desempenho Uma característica compartilhada pelas análises dinâmica e estática de código é que ambas consomem muitos recursos computacionais, de forma que nenhuma delas pode ser aplicada aos fluxos de tráfego de rede em tempo real, e ambas precisam ser aplicadas seletivamente para não prejudicar o desempenho da rede e do aplicativo. Pode levar vários minutos ou até horas para concluir esse tipo de análise, dependendo do produto e do fornecedor. Uma abordagem racional é usar tecnologias mais eficientes na utilização de recursos como front-end, a fim de eliminar de forma rápida e econômica as ameaças facilmente identificáveis. Acreditamos que é possível criar uma sandbox altamente eficiente e eficaz contra malware, dispondo em camadas vários tipos de mecanismos de análise em uma pilha sequencial de intensidade computacional crescente. Todos os arquivos desconhecidos interceptados pelos sensores de segurança de rede podem ser encaminhados a esse serviço para avaliação. 3 Crie uma sandbox melhor

4 Cada arquivo passa pelos mecanismos de inspeção empilhados, começando pelo mais rápido e que consome menos recursos. Os arquivos identificados como maliciosos em cada nível são bloqueados imediatamente e removidos do fluxo de inspeção, reduzindo a carga para as análises seguintes, que consomem mais recursos. Abordagem abrangente em camadas equilibra o desempenho e a proteção Sandbox avançada Análise dinâmica e análise estática de código Listas locais Assinaturas de antivírus Reputação global de arquivos Mecanismo de emulação Figura 1. Processo de inspeção de malware com múltiplos mecanismos e eliminação seletiva. Embora a composição da pilha de inspeção deva ser expansível para incorporar novas técnicas de detecção conforme elas surgirem, os avanços tecnológicos de hoje podem ser bem representados por uma sequência que começa com a detecção de ataques conhecidos (assinaturas e serviços de reputação), seguida pela detecção comportamental em tempo real (heurística e emulação), a análise dinâmica e a análise estática de código. Chamamos isso de arquitetura de inspeção com eliminação seletiva. Vamos examinar a sequência desse processo estratificado nível a nível. Nível um: detecção de ataques conhecidos As duas técnicas de detecção de malware usadas na inspeção de primeiro nível são as mais antigas e mais amplamente distribuídas. Elas também estão entre as técnicas de aplicação em tempo real mais leves, em termos computacionais. A inspeção com base em assinaturas, que é a tecnologia básica de todos os produtos antivírus, oferece uma identificação positiva rapidamente, com base em comparação de padrões com uma biblioteca de amostras de código malicioso conhecidas. Os serviços de reputação coletam informações sobre fontes conhecidas de ataques anteriores, incluindo hashes do próprio malware, localizações geográficas, domínios, URLs e endereços IP, fornecendo uma base para identificar ataques conhecidos, desconhecidos e de dia zero, recebidos a partir de vetores maliciosos conhecidos. Essas duas técnicas são rápidas, computacionalmente econômicas e oferecem identificação de ameaças em tempo real e com alta confiança. Seus atributos essenciais são (1) uma biblioteca abrangente de assinaturas de ameaças conhecidas e fontes, e (2) uma infraestrutura rápida e confiável para adquirir informações sobre novas ameaças de forma global e distribuí-las para os sensores locais. Como ambas as tecnologias e, em menor grau, as tecnologias incluídas no nível dois (abaixo) são amplamente distribuídas nos produtos de segurança existentes, é muito útil quando os nossos recursos de gerenciamento de sandbox incluem a capacidade de definir separadamente os mecanismos de inspeção por sandbox a serem aplicados aos arquivos referenciados por cada tipo de sensor. Como resultado, uma inspeção com base em assinaturas executada por um serviço IPS, por exemplo, não será repetida na sandbox. Nível dois: defesas comportamentais em tempo real Dois tipos diferentes de detecção também são aplicados na segunda camada de inspeção: a heurística e a emulação. A identificação heurística usa a análise de padrões de comportamento e regras para criar construções genéricas e distinguir as similaridades entre um arquivo suspeito e grupos ou famílias de ameaças conhecidas relacionadas. A emulação simula a execução do arquivo em um ambiente de host reduzido e registra os comportamentos resultantes. O ambiente de emulação pode incluir um subconjunto dos recursos de CPU, memória e APIs do sistema operacional. A emulação também é descrita como meio caminho até a análise dinâmica ou sandbox leve, mas consome menos recursos, o que permite fornecer resultados em tempo real. A heurística e a emulação fornecem identificação em tempo real de ameaças previamente não observadas, e são apenas um pouco menos confiáveis do que as técnicas baseadas em assinaturas. Elas envolvem alguma descompilação e descompactação do código, mas como esse processo é em tempo real, há poucos recursos distribuídos aqui para descompactar ou fazer a engenharia reversa de arquivos ocultados. Devemos notar que emuladores diferentes, específicos para linguagens, são necessários para diferentes tipos de conteúdo (executáveis, código shell, JavaScript, HTML e Java). A confiabilidade e a eficácia de um mecanismo de emulação estão diretamente relacionadas à abrangência de seus recursos. 4 Crie uma sandbox melhor

5 Nível três: análise dinâmica O terceiro nível do nosso modelo de arquitetura de sandbox marca a fronteira entre as análises feitas em tempo real e aquelas feitas com técnicas que consomem mais recursos e que, inevitavelmente, impõem uma latência um pouco maior. Aqui, permitimos que os arquivos que não foram identificados de forma conclusiva como maliciosos em inspeções anteriores sejam executados em um ambiente virtual isolado e protegido. A análise dinâmica real difere da emulação porque instancia um ambiente de tempo de execução totalmente operacional, que é virtualizado e isolado para permitir com segurança a execução de código possivelmente malicioso e que registra ou classifica todos os comportamentos observados. Sandbox específica para os alvos Há duas abordagens comuns para a configuração dos ambientes virtuais usados em uma sandbox para malware. As diferenças são importantes porque a maioria dos ambientes de TI são compostos por uma variedade de plataformas de hardware e software, e a maioria das amostras de malware ataca um ambiente de operação ou aplicativo específico. A primeira abordagem é virtualizar um único ambiente genérico e usá-lo na análise de todas as amostras. Essa abordagem oferece o risco de não detectar comportamentos maliciosos que dependem de recursos específicos ou parâmetros de configuração que podem não estar disponíveis na imagem genérica, mas usa os recursos de forma econômica, pois somente uma passagem de análise é necessária. A segunda abordagem é virtualizar múltiplos ambientes (várias plataformas de servidores Windows e configurações, mais uma seleção de imagens de plataformas móveis e PCs). As amostras suspeitas são executadas em cada um desses ambientes. Porém, essa estratégia ainda corre o risco de não incluir o ambiente de alvo verdadeiro, pode produzir mais falsos positivos e também é muito mais cara em termos computacionais. Uma estratégia muito mais eficaz e eficiente é executar um arquivo suspeito em um ambiente virtual que corresponda exatamente ao sistema visado pelo arquivo. Essa abordagem requer que uma ampla gama de opções de sistemas operacionais esteja disponível, ou que imagens de referência de todas as plataformas de terminais no ambiente possam ser importadas. A sandbox deve ser capaz de identificar o ambiente do host visado de forma dinâmica e lançar rapidamente uma VM (máquina virtual) correspondente. Isso não é uma atividade de rede, mas requer a integração com sistemas de terminais. Se essas condições puderem ser cumpridas, a probabilidade de identificar e observar a gama completa de possíveis comportamentos de um arquivo suspeito e avaliar de forma precisa suas intenções aumenta muito. A importância da interação Para que a inspeção por sandbox possa avaliar completamente a intenção de um executável, o ambiente virtual deve responder de forma interativa ao comportamento do arquivo, assim como um sistema host normal faria. Especificamente, a sandbox deve emular de forma automática a resposta normal do host às solicitações de conexões de rede. A ausência dessas respostas esperadas pode informar ao malware que ele está sendo analisado em uma sandbox, permitindo que adote ações evasivas. Os serviços de reputação também devem estar disponíveis na sandbox, de forma que solicitações de acesso de alto risco para endereços IP maliciosos conhecidos, URLs e arquivos possam ser imediatamente identificados como indicadores de alta probabilidade de ameaça. Além da interatividade que deve estar disponível para inspeções de arquivos em linha executadas automaticamente, um modo totalmente interativo deve estar disponível para que os analistas de segurança executem análises manuais off line. Nesse modo, um analista deve ser capaz de iniciar manualmente uma VM e carregar uma amostra executável com funcionalidade completa de máquina virtual baseada em kernel. Frequentemente, é apenas com a capacidade de iniciar sessões de navegador e outros aplicativos normais de trabalho que comportamentos específicos de ameaças podem ser acionados e observados. Interpretando as análises dinâmicas Os primeiros dois níveis da nossa pilha de inspeção produzem resultados claros e em tempo real. Um arquivo desconhecido é identificado rapidamente como uma ameaça conhecida por meio de uma correspondência de assinatura, ou percebido como suficientemente malicioso em ambientes de emulação em tempo real. Em ambos os casos, uma decisão binária de bloquear ou permitir é feita rapidamente. Em contraste, a entrada inicial de uma análise dinâmica é um arquivo de registro que só se torna útil com a correlação. Eventos comportamentais específicos precisam ser identificados e agregados, e seu significado, avaliado no contexto de outros eventos. A saída de uma sandbox pronta para uso corporativo não é um registro longo e complicado, nem uma simples decisão de bloqueio ou liberação. Uma ferramenta de sandbox útil para a empresa deve fornecer um relatório agregado e organizado que identifique e classifique comportamentos relevantes e atribua uma pontuação geral. Essa pontuação pode ser suficiente para ativar uma decisão de bloqueio, ou pode exigir mais informações de apoio de análises estáticas subsequentes. De qualquer forma, ela oferece informações úteis que podem ser utilizadas pelos operadores de segurança. 5 Crie uma sandbox melhor

6 Oculta o arquivo alterando seus atributos. Conteúdo executável detectado, criado pela amostra. Criou conteúdo executável no diretório temporário do Administrador. Da Microsoft: CreateURLMoniker pode produzir resultados que não são equivalentes à entrada; seu uso pode resultar em problemas de segurança. Reservou uma região de memória dentro do espaço virtual de endereços de outro processo. Tentou conectar-se a um provedor de serviços específico. Criou conteúdo no diretório de sistema do Windows. Manipulou conteúdo ativo no diretório temporário do administrador. Obteve e usou o ícone de um aplicativo de sistema legítimo. Criou conteúdo executável no diretório Windows. Executou conteúdo ativo da pasta de sistema do Windows. Definiu função de comunicação de retorno para controlar eventos do sistema e do hardware do computador. Fez download de dados de um servidor da Web. Fez (ou desfez) o registro do nome do serviço em uma DDE (dynamic data exchange, troca dinâmica de dados) suportada pelo servidor. Figura 2. Um relatório de classificação e resumo comportamental da análise dinâmica. Nível quatro: análise estática de código A última eliminação seletiva na nossa sandbox expandida de estágios múltiplos é a verdadeira análise estática de código, que podemos designar mais descritivamente como análise de código assembly desmontado. Esse processo é iniciado com a análise dinâmica de terceiro estágio e incorpora algumas saídas da inspeção dinâmica conforme elas se tornam disponíveis. Mencionamos anteriormente que nossas técnicas sugeridas de inspeção de segundo estágio (heurística e emulação) dependem do acesso ao código-fonte de um arquivo, mas que poucos recursos são fornecidos em uma análise em tempo real para extrair código ocultado ou compactado. Esse tipo de exame forense profundo é exatamente o objetivo do quarto estágio. Figura 3. Sozinha, a análise dinâmica é incompleta. 6 Crie uma sandbox melhor

7 Compactação, descompactação e engenharia reversa Há razões perfeitamente legítimas para esconder ou ocultar o código executável compilado de um programa, e a mais óbvia delas é a proteção da propriedade intelectual. Compreensivelmente, os desenvolvedores de software desejam impedir que os concorrentes façam a engenharia reversa de seus produtos, trabalhando de forma retroativa a partir do código assembly distribuído para chegar ao código-fonte. Como resultado, outros desenvolvedores com espírito empreendedor criaram várias ferramentas comerciais para tornar esse processo extremamente difícil. Essas ferramentas, conhecidas como compactadores (por exemplo, Themida, Armadillo), facilitam a aplicação de um arsenal de técnicas de mascaramento e aleatorização ao código compilado do programa, tornando extremamente difícil reconstruir o código assembly e acessar o código-fonte. Os criadores ou desenvolvedores de malware simplesmente adotaram as técnicas da própria indústria de software, tornando muito mais difícil separar seus ataques camuflados dos arquivos legítimos. Difícil, talvez, mas não impossível. Figura 4. O menu de ocultação no Themida, uma poderosa ferramenta de compactação para aplicativos Windows. No quarto estágio da nossa sandbox para malware, os arquivos compactados e ocultados passam por uma engenharia reversa para recuperar a versão intacta do código assembly compilado. Esse código é interpretado e analisado estatisticamente, fornecendo: Uma avaliação da similaridade com famílias conhecidas de malware. Uma mensuração do código latente que não foi executado durante a análise dinâmica. Um mapa lógico dos caminhos completos de execução do arquivo. As ameaças persistentes avançadas (APTs) modernas normalmente são adaptações de códigos de malware conhecidos e eficientes. Pequenas modificações são suficientes para evitar a inspeção por assinaturas, que exige uma correspondência exata para condenar o arquivo. Porém, a inspeção de todo o código, que é comparado a uma biblioteca de referências de famílias de malware conhecidas, geralmente descobre malware extremamente indetectável. Por exemplo, um arquivo suspeito com pequenos indicadores de comprometimento que não são graves o bastante para bloqueá-lo, mas que tenha uma similaridade maior que 70% com uma família conhecida de malware (por exemplo, conficker e voter_1), é um arquivo que deve ser bloqueado. Sem a análise estática de código, esse malware teria penetrado na rede. 7 Crie uma sandbox melhor

8 Figura 5. A similaridade familiar é uma poderosa evidência de potencial malicioso. De modo similar, as APTs buscam cada vez mais uma percepção do ambiente ou requerem uma sequência específica de interações para iniciar ações. Isso significa que muito do código do malware indetectável pode permanecer latente durante a análise dinâmica. Mesmo se o comportamento desse código latente não puder ser extraído, o fato de uma grande parte do código de um arquivo suspeito permanecer latente deve ser parte importante da investigação de um analista de segurança. Considere um arquivo suspeito que não mostra qualquer comportamento malicioso. Sozinha, a análise dinâmica concluiria que o arquivo é seguro. Porém, e se esse arquivo tiver uma similaridade maior que 70% com uma família conhecida de malware, e se mais de 40% do código do arquivo não tiver sido ativado ou analisado na sandbox? Essas duas evidências circunstanciais são suficientes para bloquear a distribuição desse arquivo, pelo menos até que um operador de segurança possa investigá-lo. Resumo do comportamento (cobertura de 57% do código): Oculta o arquivo alterando seus atributos. Conteúdo executável detectado, criado pela amostra. Criou conteúdo executável no diretório temporário do Administrador. Da Microsoft: CreateURLMoniker pode produzir resultados que não são equivalentes à entrada; seu uso pode resultar em problemas de segurança. Reservou uma região de memória dentro do espaço virtual de endereços de outro processo. Tentou conectar-se a um provedor de serviços específico. Criou conteúdo no diretório de sistema do Windows. Manipulou conteúdo ativo no diretório temporário do administrador. Obteve e usou o ícone de um aplicativo de sistema legítimo. Criou conteúdo executável no diretório Windows. Executou conteúdo ativo da pasta de sistema do Windows. Definiu função de comunicação de retorno para controlar eventos do sistema e do hardware do computador. Fez download de dados de um servidor da Web. Fez (ou desfez) o registro do nome do serviço em uma DDE (dynamic data exchange, troca dinâmica de dados) suportada pelo servidor. Figura 6. Partes significativas de código latente indicam falhas na análise somente dinâmica. Quando a investigação humana é necessária, um diagrama de operações do arquivo pode ser uma ferramenta forense extremamente útil. Diferente de arquivos de registro ou observações de comportamento (análise dinâmica), um diagrama ajuda os operadores de segurança a investigar áreas ocultas e a interação do código. Muitas vezes, isso é essencial para revelar código que de outra forma permaneceria latente, especialmente quando usado em conjunto com uma sandbox que permita interação manual com o arquivo suspeito dentro da VM. 8 Crie uma sandbox melhor

9 Iniciar mapa de código interativo As linhas azuis mostram o código que foi executado dinamicamente. As linhas vermelhas mostram o código que foi executado estaticamente. Figura 7. Visualizar os processos do arquivo permite que o operador estimule o código latente. Essas descobertas são então incorporadas às observações da análise dinâmica de terceiro estágio para fornecer uma pontuação geral, indicando o grau de certeza de que o arquivo ou executável de amostra é malicioso. Uma estratégia de eliminação seletiva para a superioridade da sandbox Um serviço de detecção de malware avançado que seja projetado e configurado conforme a estratégia de eliminação seletiva em pilha descrita acima fornecerá uma solução significativamente mais sofisticada, confiável e econômica do que qualquer coisa disponível no mercado atualmente. Ela impedirá a sobrecarga da sandbox eliminando ameaças conhecidas e facilmente identificáveis, usando a inspeção com base em assinaturas e serviços de informações sobre reputação, que oferecem alta porcentagem e baixa carga. Ela aumentará substancialmente a eficiência e a precisão da análise dinâmica com a execução em sandbox específica para o alvo. Por fim, a verdadeira análise estática de código irá remover o manto de ocultação para revelar a natureza real do código latente e evasivo. Pela primeira vez na conturbada história da evolução conjunta da segurança e do malware, a segurança está prestes a dar um salto proativo adiante. Saiba mais em McAfee do Brasil Comércio de Software Ltda. Av. das Nações Unidas, andar CEP São Paulo - SP - Brasil Telefone: +55 (11) Fax: +55 (11) McAfee e o logotipo da McAfee são marcas comerciais ou marcas registradas da McAfee, Inc. ou de suas afiliadas nos EUA e em outros países. Outros nomes e marcas podem ser propriedade de terceiros. Os planos, especificações e descrições de produtos aqui contidos são fornecidos apenas para fins informativos, estão sujeitos a alterações sem notificação prévia e são fornecidos sem garantia de qualquer espécie, expressa ou implícita. Copyright 2014 McAfee, Inc wp_build-sandbox_0214_fnl_ETMG