UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO EXPLORANDO FALHAS DE SEGURANÇA EM SOFTWARE PEDRO ROURE MALTA DE SÁ GOIÂNIA 2007

2 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO EXPLORANDO FALHAS DE SEGURANÇA EM SOFTWARE Trabalho de Projeto Final de Curso apresentado por Pedro Roure Malta de Sá à Universidade Católica de Goiás, como parte dos requisitos para a obtenção do título de Bacharel em Ciência da Computação aprovado em 07 / 12 / 2007 pela Banca examinadora: Professor Cláudio Martins Garcia, UCG Orientador Professor Ulisses Rodrigues Afonseca Professor Iwens Gervásio Sene Júnior

3 EXPLORANDO FALHAS DE SEGURANÇA EM SOFTWARE PEDRO ROURE MALTA DE SÁ Trabalho de Projeto Final de Curso apresentado por Pedro Roure Malta de Sá à Universidade Católica de Goiás, como parte dos requisitos para obtenção do título de Bacharel em Ciência da Computação. Professor Claúdio Garcia Orientador Professor Jeovah Martins Coordenador de Projeto Final de Curso

4 RESUMO De acordo com o CERT, a maior parte dos ataques realizados com sucessos resultam da exploração de vulnerabilidades em software conhecidas, cuja uma correção não foi desenvolvida e se foi desenvolvida não foi aplicada ao software, e devido a configurações inseguras do software, como opções de configurações padrões amplamente conhecidas pelos atacantes e que não são alteradas pelo administrador do sistema. Softwares devem ser desenvolvidos com a segurança deste em mente. É impossível desenvolver software que sejam totalmente ausente de falhas, no entanto, é possível minimizar a ocorrência destas no software e/ou minimizar o impacto que elas terão uma vez que foram encontradas. Vulnerabilidades em software podem ser introduzidas neste durante diferentes fases do ciclo de vida do software. No entanto, as fases mais comuns são: Design: Quando você esta pensando sobre o software. Implementação: Quando você está escrevendo a aplicação. Manutenção: Depois que a aplicação está em produção. Como uma regra geral, as vulnerabilidades em software mais difíceis de serem consertadas, são aquelas provenientes de decisões na fase de design do software. Por exemplo, vamos supor que durante o design de uma aplicação cliente-servidor que será utilizada para transferir dados sigilosos entre uma empresa matriz e suas filiais via Internet, o engenheiro de software opte por não utilizar nenhum tipo de criptografia ( nem para os dados, nem para

5 autenticação que permitira acesso ao sistema ). Essa decisão de design pode ter grandes impactos no futuro. Pois os dados que trafegarem pela rede poderam facilmente serem interceptados por um hacker, utilizando de um sniffer. Dependendo dos dados que são manipulados por essa aplicação, o prejuízo pode ser de milhares de dólares. Uma mudança nessa decisão de design ( a não utilizaçao de criptografia ) depois que esse software estivesse pronto, poderia exigir tantas alterações no software, inclusive na implementação deste, que talvez fosse necessário recomeçar todo o ciclo de desenvolvimento do software. As vulnerabilidades introduzidas durante a fase de implementação são as mais comuns de serem encontradas, e são dependentes da linguagem na qual a aplicação será escrita. O que implica que a escolha da linguagem na qual a aplicação será escrita, implicará na conjunto de técnicas utilizadas para exlorar vulnerabilidades introduzidas nesta fase. Vulnerabilidades também podem ser introduzidas no software mesmo depois que esse se encontra em operação, quando alterações são feitas a esse. São comuns os casos onde vulnerabilidades foram introduzidas no software durante a fase de manutenção do software, quando correções ( patches ) são aplicadas ao software. Ou seja, uma correção aplicada ao software com o intuito de corrigir uma vulnerabilidade existente acaba por introduzir uma outra vulnerabilidade. Ou seja, a segurança de um software não pode ser incorporada a este depois que este estiver pronto assim como se fosse um plugin. Para que um software seguro seja construído, a segurança deste deve ser pensada em todas as fases do ciclo de desenvolvimento do software, e mesmo depois que este for entrege e estiver em operação, quando manutenções forem feitas a este.

6 As vulnerabilidades introduzidas durante a fase de implementação é que serão o foco de nossos estudos. Mostraremos vulnerabilidades comuns de serem encontradas em aplicações escritas em linguagem C. Focaremos nas vulnerabilidades que permitem aos atacantes controlarem a execução da aplicação sendo explorada e possivelmente executar códigos arbitrários no sistema sendo atacado. No capítulo 1, mostraremos como o os códigos arbitrários que serão executados no sistema sendo atacado, uma vez que a execução da aplicação for controlada, são constrúidos pelos atacantes. Esses códigos arbitrários, são comumente chamados de shellcodes. No capítulo 2, mostraremos como algumas técnicas de programação segura e a utilização de firewalls podem ser usadas para evitar que shellcodes simples, como os mostrados no capítulo 1, sejam inseridos e executados com sucesso no sistema sendo atacado. Mostraremos também técnicas mais avançadas para escrita de shellcodes, que podem ser usadas para burlar as técnicas de programação descritas e a proteção oferecida por firewalls. No capítulo 3, falaremos sobre estouro de buffer, um tipo comum de vulnerabilidade de implementação encontrada em aplicações escritas em linguagem C. Estouros de buffer podem ocorrer em diferentes áreas de memória no espaço de endereçamento do processo, discutiremos técnicas para exploração de vulnerabilidades de estouro de buffer que ocorrem na área de pilha e heap do processo. Mostraremos também alguns avanços nessa área, tanto por parte da comunidade de segurança, quanto por parte dos atacantes. Palavras-Chave: Shellcode, Exploits, Estouro de Buffer, Estouro de Pilha, Estouro de Heap, Segurança em Software.

7 ABSTRACT In accordance with the CERT, most of the attacks carried through with successes results of the exploration of vulnerabilities in software known, whose a correction was not developed and if it was developed was not applied to software, and had the unsafe configurations of software, as standard configurations options widely known by the aggressors and that they are not modified by the system administrator. Softwares must be developed with the security of this in mind. It is impossible to develop software that is total absent of flaws, however, it is possible to minimize the occurrence of these in software and/or to minimize the impact that they will have a time that they had been found. Vulnerabilities in software can be introduced in this during different phases of the software life cycle. However, the phases most common are: Design: When you are thinking about the software. Implementation: When you are writing the application. Maintenance: Later that the application is in production. As a general rule, the most difficult vulnerabilities in software to be fixed, are those proceeding from decisions in the phase of design of software. For example, we go to assume that during design of an application client-server who will be used to transfer secret data between a first company and its branch offices using Internet, the software engineer opts to

8 not using no type of cryptography (nor for the data, nor for authentication that allows access to the system). This decision of design can have great impacts in the future. Because the data that pass through the network could be easily be intercepted for hacker, using a sniffer. Depending of the data that are manipulated by this application, the damage can be of thousand of dollars. A change in this design decision (the no use of cryptography) later that this software was ready, could demand as many alterations in the software, also in the implementation of this, that perhaps was necessary to recommence all the software development cycle. The vulnerabilities introduced during the implementation phase are most common to be joined, and are dependents of the language in which the application will be written. What it implies that the choice of the language in which the application will be written, will imply in the set of used techniques to explore vulnerabilities introduced in this phase. Vulnerabilities also can be introduced in the same software later that this if finds in operation, when alterations are made to this. It is common to happen cases where vulnerabilities had been introduced in software during the phase of maintenance of software, when corrections (patches) are applied to software. That is, a correction applied to software with intention to correct an existing vulnerability finishes for introducing one another vulnerability. That is, the security of a software cannot be incorporated later when the job is done as it was a plugin. So that a safe software is constructed, the security of this must be thought about all the phases of the software development cycle, and same later that this will be entrege and be in operation, when maintenances will be made to this. To write a secure software, the

9 security of this must be thought in all the phases of the cycle of the development of the software, even when the software is delivered and in operation when maintenances will be made to this. The vulnerabilities introduced during the implementation phase is what will be the focus of our studies. We will show common vulnerabilities to be joined in applications written in language C. We Will focus in the vulnerabilities that allows the hackers to control the execution of the application being explored and to execute arbitrary codes in the attacked system being been. In chapter 1, we will show how the arbitrary codes that will be executed in the attacked system, once the execution of the application will be controlled, are constructed by the hackers. These arbitrary codes, are often called shellcodes. In chapter 2, we will show how some techniques of safe programming and the use of firewalls can be used to prevent that simple shellcodes, as the shown in chapter 1, can be inserted and executed successfully in the attacked system. We will also show more advanced techniques for writing of shellcodes, that they can be used to dupe the described techniques of programming and the protection offered for firewalls. In chapter 3, we will speak about buffer overflow, a common type of vulnerability of implementation found in applications written in language C. Buffers overflow can occur in different areas of memory in the addressing space of the process, we will argue techniques for exploration of vulnerabilities of buffer overflow that occur in the stack area and heap of the process. We will also show some advances in this area, as much on the part of the security community, how much on the part of the hackers.

10 Keywords: Shellcode, Exploits, Buffer Overflow, Stack Overflow, Heap Overflow, Software Security.

11 EXPLORANDO FALHAS DE SEGURANÇA EM SOFTWARE SUMÁRIO 1. SHELLCODE BÁSICO INTRODUÇÃO BÁSICO DE ASSEMBLER REGISTRADORES CHAMADAS DE SISTEMA BÁSICO DE SHELLCODE PROBLEMA DO ENDEREÇAMENTO TÉCNICA DO JUMP E CALL USANDO A PILHA PROBLEMA DOS BYTES NULOS ESCREVENDO SHELLCODES ESCREVENDO UMA MENSAGEM NA TELA REINICIANDO O SISTEMA OBTENDO UM SHELL LOCALMENTE OBTENDO UM SHELL REMOTAMENTE ENCONTRANDO O SHELLCODE SHELLCODE AVANÇADO ESCREVENDO PROGRAMAS SEGUROS MINIMIZANDO PRIVILÉGIOS USUÁRIOS GRUPOS E PROCESSOS PROGRAMAS SET-UID E SET-GID PRINCÍPIO DO MENOR PRIVILÉGIO CHAMADAS DE SISTEMAS RELACIONADAS RESTAURANDO PRIVILÉGIOS TEMPORARIAMENTE RETIRADOS 26

12 LIMITANDO OS ARQUIVOS DO SISTEMA VISIVEIS PELO PROCESSO QUEBRANDO UMA CHROOT USANDO A SYS_CHROOT DE FORMA SEGURA VALIDAÇÃO DE ENTRADA CENÁRIO CENÁRIO BLOQUEANDO SHELLCODES NA REDE FIREWALLS O QUE É UM FIREWALL FIREWALLS E O LINUX NETFILER E IPTABLES ESCOLHENDO UMA POLÍTICA PADRÃO BLOQUEANDO SHELLCODES COM FIREWALLS CENÁRIO CENÁRIO CENÁRIO CENÁRIO CENÁRIO ESTOURO DE BUFFER PRINCIPAIS CAUSAS ESPAÇO DE ENDEREÇAMENTO DE UM PROCESSO CÓDIGO DADOS INICIALIZADOS DADOS NÃO-INICIALIZADOS HEAP PILHA TIPOS DE ESTOURO DE BUFFER HISTÓRICO ESTOURO DE PILHA CHAMADAS DE PROCEDIMENTO VARIÁVEIS LOCAIS E PARÂMETROS DE UM PROCEDIMENTO 59

13 COLOCANDO TUDO EM PRÁTICA LIBSAFE LIBVERIFY STACKGUARD POINTER SUBTERFUGE ALTERANDO PONTEIROS NOS ARGUMENTOS DE UMA FUNÇÃO ALTERANDO PONTEIROS PARA FUNÇÕES ALTERANDO PONTEIROS PARA DADOS STACK SMASH PROTECTOR ( SSP ) ESTOURO DE HEAP ALOCADOR DE MEMÓRIA DINÂMICA NO LINUX: DOUG LEA MALLOC CHUNKS DE MEMÓRIA BOUNDARY TAGS CAMPO SIZE BINS ADICIONANDO E REMOVENDO CHUNKS DE UMA BIN EXPLORANDO A MACRO UNLINK() SEÇÃO.DTORS GLIBC CONCLUSÃO REFERÊNCIAS BIBLIOGRAFICAS ANEXOS EXPLOIT PARA ESTOURO DE PILHA 101

14 LISTA DE FIGURAS Figura 1.1 Técnica do Jump e Call 04 Figura 1.2 Usando a Pilha Figura 1.3 Usando a Pilha Figura 1.4 Arquivo - write-push.s 08 Figura 1.5 Arquivo - test-write-push.c 09 Figura 1.6 Arquivo - reboot.s 11 Figura 1.7 Arquivo - test-reboot.c 11 Figura 1.8 Arquivo - execve-push.s 13 Figura 1.9 Arquivo - port-bind.s 15 Figura 1.10 Arquivo - test-port-bind.c 17 Figura 1.11 Seção NOP Sled Tradicional 19 Figura 2.1 Arquivo - test-setuid.c 24 Figura 2.2 Arquivo - setuid-execve.s 27 Figura 2.3 Arquivo - break-chroot1.c 29 Figura 2.4 Arquivo: break-chroot2.c 30 Figura 2.5 Arquivo test-toupper.c 35 Figura 2.6 Arquivo - execve-iptables.s 40 Figura 2.7 Arquivo - connect-back.s 42 Figura 2.8 Arquivo - test-connect-back.c 43 Figura 2.9 Arquivo port-bind-fork-stop.s 49 Figura 2.10 Arquivo - test-port-bind-fork.c 51 Figura 3.1 Espaço de Endereçamento de Um Processo 56 Figura 3.2 Protótipo das Instruções CALL e RET 59 Figura Arquivo vuln-buf.c 60 Figura 3.4 Estado da Pilha Durante a Chamada de um Procedimento 61 Figura 3.5 Arquivo - vuln-buf.c - Modificado 65 Figura 3.6 Estado da Pilha Durante a Chamada de um Procedimento Aplicação Protegida Pelo StackGuard 70

15 Figura 3.7 Funções do GCC Alterados pelo StackGuard 71 Figura 3.8 Arquivo pointer-subterfuge1.c 73 Figura 3.9 Arquivo pointer-subterfuge2.c 74 Figura 3.10 Arquivo heap1.c 77 Figura 3.11 Boundary Tag de um Chunk 80 Figura 3.12 Chunk de Memória Alocado 80 Figura 3.13 Chunk de Memória Livre 81 Figura 3.14 Macro Unlink() 85 Figura 3.15 Macro Frontlink() 85 Figura 3.16 Arquivo heap2.c 87 Figura 3.17 Buffer Utilizado Para Estourar buff1 89 Figura 3.18 Figura 3.18 Arquivo exploit_malloc.c 90

16 LISTA DE TABELAS Tabela 1 Subdivisões dos registradores EAX, EBX, ECX e EDX 02 Tabela 2 Chamadas de Sistema SYS_EXIT e SYS_WRITE Tabela 3 Chamadas de Sistema SYS_EXIT e SYS_WRITE Tabela 4 Chamadas de Sistema SYS_SYNC e SYS_REBOOT 1 10 Tabela 5 Chamadas de Sistema SYS_SYNC e SYS_REBOOT 2 10 Tabela 6 Opções de Ações Para SYS_REBOOT 10 Tabela 7 Chamadas de Sistema SYS_EXECVE 1 12 Tabela 8 Chamadas de Sistema SYS_EXECVE 2 12 Tabela 9 Chamadas de Sistema SYS_SOCKETCALL 1 14 Tabela 10 Chamadas de Sistema SYS_SOCKETCALL 2 14 Tabela 11 Sub-funções da Chamada de Sistema SYS_SOCKETCALL 14 Tabela 12 Chamadas de Sistema SYS_DUP Tabela 13 Chamadas de Sistema SYS_DUP Tabela 14 Minimização de Privilégios Chamadas de Sistemas 23 Tabela 15 Limitando os arquivos do sistema visíveis pelo processo Chamadas de Sistemas 28 Tabela 16 Chamadas de Sistema SYS_FORK 1 47 Tabela 17 Chamadas de Sistema SYS_FORK 2 48 Tabela 18 Sub-função SYS_SETSOCKOPT 48

17 1 CAPÍTULO 1 Shellcode Básico 1.1 Introdução Shellcode corresponde a um conjunto de instruções de máquina, normalmente, sem conter bytes NULOS que será inserido no espaço de memória de um processo em tempo de execução. Uma vez que, não é possível se determinar exatamente onde o shellcode se encontrara na memória, este deve ser escrito como um código de maquina independente de posição (PIC Position Independent Code). A técnica de escrita de shellcodes tem de desenvolvido bastante nos últimos anos, e isso se deve principalmente aos avanços concorrentes nas técnicas para impedir que shellcodes possam ser inseridos e executados em programas. O nome shellcode foi dado inicialmente, devido ao fato de que normalmente essas instruções visavam obter uma Shell (interpretador de comandos) no sistema sendo atacado, no entanto, essas instruções podem executar praticamente qualquer tarefa no sistema sendo atacado. Ataques de corrupção de memória que objetivam o ganho sobre o controle da execução do programa quando bem sucedidos fazem o uso do shellcode para executarem instruções no alvo comprometido com permissões do usuário sobre o qual o processo estava sendo executado. De forma geral, quando conseguimos controlar a execução do programa devemos desviar a execução deste para o nosso shellcode. Uma exceção a regra, é quando desviamos a execução do programa para instruções já se encontram na memória do processo, nesse caso o uso de shellcode não é necessário. 1.2 Básico de Assembler Os shellcodes aqui trabalhados serão escritos em Assembler, e posteriormente terão seus opcodes extraídos para então poderem ser utilizados. Introduziremos apenas os conceitos básicos necessários para escritas de nossos shellcodes. Conhecimentos avançados de Assembler serão introduzidos à medida que nossos shellcodes forem se tornando mais complexos. Uma vez que o shellcode é escrito em assembler, podemos concluir que este é

18 2 dependente da arquitetura sobre a qual o sistema está sendo executado, uma vez que o conjunto de instruções disponíveis é diferente entre arquiteturas diferentes. Nos concentraremos em shellcodes para a arquitetura x Registradores Os processadores Intel x86 possuem oito registradores de propósito geral de 32 bits. Apesar de serem chamados de registradores de propósito geral, algumas tarefas são especificas de cada um e não podem ser realizadas por nenhum outro. O uso correto desses registradores é que tornam os shellcodes eficientes e otimizados, veremos por exemplo, que o uso de registradores menores diminuem o tamanho do shellcode e evitam bytes NULOS em nosso shellcode. Desses oito registradores, os registradores EAX, EBX, ECX e EDX possuem subdivisões de 16 bits e 8 bits, como mostrado na tabela abaixo: 32 Bits 16 Bits 8 Bits ( Alto ) 8 Bits ( Baixo) EAX AX AH AL EBX BX BH BL ECX CX CH CL EDX DX DH DL Tabela 1 Subdivisões dos registradores EAX, EBX, ECX e EDX Os registradores EAX, AX, AH, AL são conhecidos como acumuladores, esses são utilizados principalmente em cálculos, muitas operações implicitamente fazem uso desses registradores, como por exemplo a instrução MUL que realiza uma multiplicação nãosinalizada do valor contido em um dos registradores EAX, AX, AL, com o valor de um operando que é passado para instrução. Esses registradores também são utilizados para armazenar o numero de uma chamada do sistema quando necessitamos de um recurso do kernel. Os registradores EBX, BX, BH, BL são conhecidos como registradores base. Normalmente, eles são utilizados para armazenar ponteiros. Os registradores ECX, CX, CH, CL são conhecidos como contadores, eles são utilizados implicitamente por instruções que realizam loops como, LOOP, LOOPZ, e

19 3 LOOPNZ. Os registradores EDX, DX, DH, DL são conhecidos como registradores de dados, eles são utilizados em conjunto com os registradores acumuladores em instruções como MUL. Após uma instrução MUL a parte dos bits mais significativos do resultado é armazenado nesses registradores e a parte menos significativa é armazenada nos registradores acumuladores. O registrador ESP é utilizado para armazenar o topo da pilha. O registrador EBP é utilizado para armazenar o endereço do stack frame corrente. O registrador ESI e EDI são utilizados respectivamente como índices de origem e destino quando estamos trabalhando com strings. 1.3 Chamadas de Sistema Os processadores Intel x86 possuem 4 níveis de proteção, o nível 0 é nível de maior privilégios, também conhecido como modo supervisor, onde todas as instruções estão disponíveis ( incluindo instruções privilegiadas ), no Linux o kernel executa com este nível de proteção, enquanto os programas de usuários executam no nível 3, que é o nível com menor privilégios, onde certas instruções não estão disponíveis. Essa separação entre modo usuário e modo kernel utilizando-se de níveis do processador teve por objetivo tornar o sistema mais seguro e confiável, evitando que problemas em programas de usuários pudessem parar todo o sistema. Quando programas em modo usuário precisam acessar recursos de baixo nível oferecidos pelo kernel isso deve ser feito por meio de uma chamada de sistema. Normalmente, chamadas de sistemas não são realizadas diretamente por um processo, bibliotecas em C é que oferecem esse recurso, no Linux a glibc é que oferece funções para acesso a chamadas de sistema. Em arquiteturas x86 o Linux implementa as chamadas de sistemas usando interrupções de software. Para executar uma chamada de sistema o processo em modo usuário deve colocar o numero desta no registrador EAX e seus respectivos parâmetros nos demais registradores de propósito geral (EBX, ECX, EDX, ESI, EDI) e executar int 0x80. O funcionamento das chamadas de sistemas e seus respectivos números é dependente do sistema operacional em questão. Por exemplo, no FreeBSD os parâmetros devem ser

20 4 passados na pilha e exige-se a interrupção seja chamada dentro de outra rotina. Como vimos no Linux os parâmetros para a chamada de sistema são passados nos registradores de propósito geral. Chamadas de sistemas são fornecidas pelo kernel do sistema operacional, o que implica que diferentes sistemas operacionais possuem diferentes conjuntos de chamadas de sistemas e formas de a utilizá-las. 1.4 Básico de Shellcode Usaremos o NASM (Netwide Assembler), para montar nosso shellcode, e então, usaremos o NDISASM (Netwide Disassembler) para extrair os opcodes em hexadecimal. Quando desenvolvendo shellcodes usaremos chamadas de sistemas, não podemos usar funções de bibliotecas externas, pois o endereço destas são resolvidos dinamicamente, em tempo de ligação (compilação estática) ou em tempo de execução (usando bibliotecas compartilhadas). Estaremos desenvolvendo shellcodes para sistemas Linux em arquiteturas x Problema do Endereçamento Quando escrevemos shellcode muitas vezes será necessário fazer referências à strings e ponteiros, porém não é possível utilizar nomes de variáveis, muito menos endereços estáticos, pois como dissemos anteriormente, o shellcode deve ser um código de maquina independente de posição e que será inserido em tempo de execução. Existem duas técnicas que podem ser utilizadas Técnica do JUMP e CALL Está técnica explora o funcionamento das instruções JMP e CALL. Analisemos o código a seguir: 1: jmp short data 2: code: 3: pop esi

21 5.. 8: data: 9: call code db 'Hello World#' Figura 1.1: Técnica do Jump e Call Na linha 1 fazemos o desvio para o rótulo data ( linha 8), logo em seguida chamados a rotina code ( linha 9 ), quando chamamos essa rotina o endereço correspondente a instrução seguinte é colocada na pilha, esse endereço corresponde ao da string. Dentro da rotina code, usamos a instrução pop esi, para obtermos o endereço da string, que agora se encontra no registrador ESI. Podemos então trabalhar com a string utilizando o registrador ESI como um ponteiro para ela Usando a PILHA O problema da técnica descrita acima é que ela pode tornar o shellcode imenso, e o tamanho do shellcode é um fator importante quando o espaço em que o shellcode será inserido é relativamente pequeno. Para contornarmos esse problema usamos a pilha para armazenar as strings e ponteiros que utilizaremos em nosso shellcode. Veja o exemplo a seguir: push byte 0x00 push 0x21646c72 push 0x6f57206f push 0x6c6c6548 mov ecx, esp Figura 1.2 Usando a Pilha - 1 Repare que primeiramente inserimos um byte NULO que será o terminador da string, depois colocamos a string na pilha usando a instrução PUSH. Observe que a string é colocada em sua ordem inversa, isso se deve ao funcionamento da pilha. O problema do código acima é que a instrução em negrito leva à presença de um byte NULO em nosso shellcode e como

22 veremos em seguida isso pode impedir que o shellcode seja inserido corretamente no programa. Para resolver o problema, modificamos o nosso shellcode para: 6 xor eax, eax push eax push 0x21646c72 push 0x6f57206f push 0x6c6c6548 mov ecx, esp Figura 1.3 Usando a Pilha - 2 Observe, em ambos os casos que na última instrução ( mov ecx, esp ) o registrador ECX passa a armazenar o ponteiro para string Problema dos bytes NULOS Normalmente, o nosso shellcode será inserido no programa através de alguma função que faz manipulação de strings, essas funções normalmente param de processar a string quando um byte NULO é encontrado, pois este é considerado o delimitador de fim da string. Para evitarmos a presença de bytes NULOS alguns cuidados devem ser tomados. Seguem alguns exemplos: 1. Quando queremos zerar um registrador devemos usar a instrução XOR, ao invés da instrução MOV. Por exemplo, a instrução mov eax,0x0 coloca 4 bytes NULOS em nosso shellcode, enquanto a instrução xor eax,eax evita a presença destes. 2. Devemos evitar mover um valor pequeno para dentro de registradores grandes ( 32 bits ). Por exemplo, a instrução mov eax,0x01 coloca 3 bytes NULOS em nosso shellcode, enquanto a instrução as instruções xor eax,eax e mov al,0x01 tem o mesmo efeito mas sem colocar bytes nulos em nosso shellcode. 3. Normalmente, quando definimos uma string em Assembler fazemos da seguinte forma: db 'Hello World', 0x00 O problema é que desta forma um byte nulo será inserido no shellcode. O correto

23 7 seria: db 'Hello World#', e quando obtivermos o endereço da string ( como demonstrado acima ), nós zeramos o sustenido, xor eax,eax mov byte [esi + 11],al 1.5 Escrevendo Shellcodes Nesta seção serão vistos quatro exemplos básicos de shellcodes. O primeiro apenas escreverá uma mensagem na tela, o segundo se executado com privilégios de super-usuário reiniciará o sistema, o terceiro obterá uma shell no sistema quando usado localmente e o quarto obterá uma shell remota em um sistema. Shellcodes avançados serão discutidos no Capitulo Escrevendo uma mensagem na tela Para escrevermos uma mensagem na tela usaremos duas chamadas de sistema: sys_exit e sys_write. Analisemos a sintaxe de cada chamada de sistema, para entendermos como os parâmetros devem ser passados. Nome sys_exit sys_write Sintaxe int sys_exit(int status) ssize_t sys_write(unsigned int fd, const char * buf, size_t count) Tabela 2 Chamadas de Sistema SYS_EXIT e SYS_WRITE - 1 sistema: Agora, vamos ver como esses parâmetros devem ser passados para a chamada de Nome EAX EBX ECX EDX sys_exit 1 int status - - sys_write 4 unsigned int const char * size_t

24 8 Tabela 3 Chamadas de Sistema SYS_EXIT e SYS_WRITE - 2 seguir: O nosso shellcode escreverá a mensagem Hello World! na tela. Veja o shellcode a BITS 32 xor eax,eax ; EAX = 0 xor ebx,ebx ; EBX = 0 xor ecx,ecx ; ECX = 0 xor edx,edx ; EDX = 0 mov al,0x0a ; AL = \n push word ax ; Inserimos o terminador da string push 0x21646c72 ;!dlr push 0x6f57206f ; ow o push 0x6c6c6548 ; lleh mov ecx,esp ; ECX = Ponteiro para string mov bl,1 ; BL = STDOUT mov dl,13 ; DL = Tamanho da String mov al,4 ; sys_write int 0x80 dec bl ; BL = status = 0 mov al,1 ; sys_exit int 0x80 Figura 1.4 Arquivo - write-push.s #nasm -o write-push write-push.s #ndisasm -u./write-push C0 xor eax,eax DB xor ebx,ebx C9 xor ecx,ecx D2 xor edx,edx B00A mov al,0xa A 6650 push ax C 68726C6421 push dword 0x21646c F20576F push dword 0x6f57206f C6C push dword 0x6c6c B 89E1 mov ecx,esp D B301 mov bl,0x1

25 F B20D mov dl,0xd B004 mov al,0x CD80 int 0x FECB dec bl B001 mov al,0x CD80 int 0x80 ficaria: Agora podemos extrair os opcodes referentes a cada instrução e o nosso shellcode "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x0a\x66\x50\x68\x72\x6c" "\x64\x21\x68\x6f\x20\x57\x6f\x68\x48\x65\x6c\x6c\x89\xe1\xb3" "\x01\xb2\x0d\xb0\x04\xcd\x80\xfe\xcb\xb0\x01\xcd\x80" Agora vamos testar nosso shellcode: char shellcode[] = "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x0a\x66\x50\x68\x72\x6c" "\x64\x21\x68\x6f\x20\x57\x6f\x68\x48\x65\x6c\x6c\x89\xe1\xb3" "\x01\xb2\x0d\xb0\x04\xcd\x80\xfe\xcb\xb0\x01\xcd\x80"; int main(void) { void (*func)(void); func = (void (*)(void))shellcode; (*func)(); } Figura 1.5 Arquivo - test-write-push.c #gcc test-write-push.c -o test-write-push #./test-write-push Hello World! # Reiniciando o Sistema Esse shellcode usa duas chamadas de sistemas: sys_sync e sys_reboot. A sys_sync é utilizada para forçar o sincronismo do sistema de arquivos no disco rígido com o estado

26 10 interno do sistema de arquivos, utilizaremos essa chamada de sistema para evitar perda de dados quando o sistema for reiniciado com a chamada de sistema sys_reboot. A sys_reboot pode ser usada tanto para reiniciar o sistema, quanto para habilitar/desabilitar o Ctrl+Alt+Del no sistema. Veja a sintaxe de ambas as chamadas de sistema a seguir: Nome Sintaxe sys_sync int sys_sync(void); sys_reboot int sys_reboot(int magic, int magic_too, int flag) Tabela 4 Chamadas de Sistema SYS_SYNC e SYS_REBOOT - 1 sistema: Agora, vamos ver como esses parâmetros devem ser passados para a chamada de Nome EAX EBX ECX EDX sys_sync sys_reboot 88 int int int Tabela 5 Chamadas de Sistema SYS_SYNC e SYS_REBOOT - 2 A página de manual da chamada de sistema sys_reboot especifica que magic e magic_too devem obrigatoriamente ter os respectivos valores, 0xfee1dead e Se as duas variáveis estiverem corretamente configuradas a variável flag especifica qual ação será realizada. Os possíveis valores para a variável flag podem ser: Flag Ação 0x Reinicia o sistema 0x89abcdef Ctrl+Alt+Del é habilitado 0 Ctrl+Alt+Del é desabilitado e um sinal é enviado para init. Tabela 6 Opções de Ações Para SYS_REBOOT Então, vamos escrever nosso shellcode.