Kernel x Seguranҫa
Propaganda
Kernel x Seguranҫa Rodrigo Rubira Branco [email protected] [email protected] http://www.kernelhacking.com OBJETIVOS Demonstrar recursos existentes no kernel do Linux ➢ Explicar estruturas internas do kernel do Linux ➢ Explicitar possíveis melhorias de seguranca para o kernel ➢ Exemplificar recursos de segurança e de ataques ➢ Exemplificar recursos de módulos / injeção de código em kernel ➢ http://www.kernelhacking.com CIDAL C onfidencialidade I ntegridade D isponibilidade A utenticidade L egalidade LEMBRAR-SE SEMPRE DISTO NO DECORRER DA AULA! http://www.kernelhacking.com Vida Real Trabalhamos em um mundo real de sistemas mal configurados: * Bugs de Software * Empregados Insatisfeitos * Administradores de Sistemas Sobrecarregados * Acomodação de necessidades empresariais * Falta de educação em segurança * B2B,B2C,B2E,C2C,X2X? * Tempo disponível para desenvolvimento * Linguagens de 3 e 4 gerações http://www.kernelhacking.com Camadas - Softwares sempre terão falhas - Falhas inerentes ao sistema operacional, se não previstas pelo software causam problemas (vide race condition do /tmp) - Fortificações possiveís no sistema operacional, poderiam tornar as aplicações “livre de falhas” (vide Win2003, OpenBSD e patchs para o kernel do Linux) Quando pensar em Segurança pense em uma CEBOLA. http://www.kernelhacking.com Problemas com a Seguranҫa Atual ● ● ● Evitar / Identificar / Corrigir O estado atual da seguranҫa é uma corrida sem fim Ciclo sem fim de descobrimento/correҫão de vulnerabilidades http://www.kernelhacking.com “O” Problema http://www.kernelhacking.com Seguro por “default” (*) ● A função deve ser segura por si própria, e não contar com “testes” antes de sua chamada ● Ex: funcao insegura: strcpy() ● char teste[10], teste2[12]; ● if ( ! (strlen(teste2) > strlen(teste)) ) – strcpy(teste,teste2); http://www.kernelhacking.com Function Hook (*) ● Para testarmos códigos prontos, podemos utilizar hook de funcoes ● Consiste em interceptarmos a chamada da funcao feita pelo nosso software e passarmos novos argumentos http://www.kernelhacking.com GNU/Linux http://www.kernelhacking.com STDLIB (Standard Library) ● ● ● ● ● Chamadas de sistema são os métodos utilizados por programas de usuário para pedirem aҫões do sistema operacional Esta chamada é efetuada através de um trap: – Mudanҫa do modo usuário para modo kernel – Controle dos parâmetros corretos – Execuҫão efetuada pelo sistema operacional – Retorno ao modo usuário Como é impossível executar um trap em C, este é provido pela standard lib através de funҫões para cada system call. Estas funҫões são escritas em ASM e então chamadas a partir do C. A stdlib define um conjunto de funҫões através das quais as aplicaҫões podem interagir com o kernel, e implementa muitas funcionalidades do sistema operacional que não necessitam da interaҫão do kernel O padrão POSIX estabelece quais são as funҫões da biblioteca que o sistema necessita providenciar, seus parâmetros e tarefas. http://www.kernelhacking.com Kernel ● ● Responsável por manter as importantes abstraҫões do sistema operacional O kernel provê as principais funҫões da “máquina abstrata” (system calls, interrupҫões e traps). Estrutura Genérica de um Kernel Unix http://www.kernelhacking.com Kernel ● O Kernel do Linux possui um modelo monolítico e não o “novo” modelo cliente­servidor (ex: micro­ kernels, como minix). Isto por motivos de performance. – – ● O kernel é executado em modo kernel, com total controle aos recursos físicos do computador. Todo o código do kernel e os dados são mantidos em um único espaҫo de endereҫos. Embora o kernel execute como um simples processo em um único espaҫo de endereҫamento, este possui modularidade. http://www.kernelhacking.com Syscalls (chamadas ao sistema) http://www.kernelhacking.com Syscalls (chamadas ao sistema) http://www.kernelhacking.com Syscalls (chamadas ao sistema) extern void *sys_call_table[]; int (*o_getdents) (uint, struct dirent *, uint); o_getdents=sys_call_table[SYS_getdents]; sys_call_table[SYS_getdents]=(void*)h_getdents; http://www.kernelhacking.com Syscalls (chamadas ao sistema) (*) void *hacked_sys_call_table; hacked_sys_call_table=kmalloc(256*sizeof(long int), GFP_KERNEL); memcpy(hacked_sys_call_table, sys_call_table, 256*sizeof(long int)); (int)*((int*)ptr) =(int) hacked_sys_call_table; • PTR aponta para o endereҫo original da tabela (chamada pela funҫão system_call) http://www.kernelhacking.com VFS (Virtual File System) read() sys_read() ufs_read() disk_dev_read () http://www.kernelhacking.com VFS – Exemplo de Hooks (*) – Interceptando sem o uso das syscalls old_readdir_root = proc_root.FILE_OPS­>readdir; old_lookup_root = proc_root.INODE_OPS­>lookup; proc_root.FILE_OPS­>readdir = &new_readdir_root; proc_root.INODE_OPS­>lookup = &new_lookup_root; old_load_binary=elf_format­>load_binary; _elf_format­>load_binary = &h_load_binary; http://www.kernelhacking.com VFS Security ● Mecanismos de seguranҫa impostos pelo VFS e alguns file systems: – – – – – Mount flags (super_blocks_flags) File attributes (inodei_mode) Extended attributes (Kernel 2.6) File ownership (inodeu_uid) Restriҫões adicionais aos modelos existentes: ● ● Atributos extras ext2, ext3 Append­Only, Immutable http://www.kernelhacking.com VFS ­ Fraquezas Um atacante que ganhe acesso root, possui completo controle sobre o sistema de arquivos – Apagar entradas em logs ● – Ext2 append­only flag não impede o usuário root Insmod ● Checagens de seguranҫa do VFS/sistema de arquivos podem ser passadas – – – Interceptando­se chamadas de sistema ao VFS Substituindo­se operaҫões nas tabelas linkadas na criaҫão de arquivos/inodes Comunicando­se diretamente com o device driver (/dev) http://www.kernelhacking.com Stack Overflow - Falha muito comum (provavelmente a mais comum entre todas e a mais facil de ser explorada) - Existe grande dificuldade de detecçao por tratar-se de interaçoes e loops, uso de funçoes do proprio usuario - Provavelmente poderia ser detectada atraves de analise de funçoes perigosas e como estao sendo usadas, dando-se grande numero de FALSOS NEGATIVOS - Consiste da alocaçao de uma variavel com tamanho fixo e da tentativa de armazenar-se nela mais dados do que sua declaraçao continha (geralmente dado pelo usuario). - Sobrescreve-se na pilha o RET, que quando a funçao retornar sobrescreve o registrador EIP e permite execuçao de codigo arbitrario. http://www.kernelhacking.com Stack Overflow http://www.kernelhacking.com Integer Overflow (*) - Enquanto os programadores e auditores de codigo cada vez mais se atentam para falhas de Stack/Heap Overflow, uma nova modalidade surge - Integer overflow nada mais e do que a tentativa de armazenamento de valores maiores do que os possiveis em variaveis inteiras (short, long, etc) - Devido a um integer overflow, pode-se passar por testes de condiçoes e conseguir-se acarretar situaçoes de Stack/Heap overflows mesmo onde nao existiam, dai a dificuldade em detecçao automatizada deste tipo de procedimento http://www.kernelhacking.com Race Condition (*) - Uma das falhas mais dificeis de se detectar em auditorias manuais de codigo e em auditorias automaticas de fonte - Geralmente pode ser descoberta automaticamente atraves do uso do FUZZER, por acarretar a situaçao de condiçao de corrida com o stress do software - Consiste em se explorar condiçoes de acessos a recursos compartilhados, onde geralmente o resultado obtido consiste em execuçao de codigos com privilegios elevados (escalaçao de privilegios) http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa ● Windows 2000: #1 em bugs de kernel reportados [Murphy ’00] Os drivers não são controlados pelos Sistemas Operacionais, afetando e muito a seguranҫa dos mesmos Windows 2000 Other 3rd Party Kernel code 11% Drivers for HCL HW 7% Drivers for NonHCL HW 20% System Config 34% MSInternalCode 2% Other IFSDrivers 0% Anti­Virus 4% HW Failure 22% Source: Brendan Murphy, Sample from PSS Incidents http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa Podemos aumentar a seguranҫa do SO através de “tolerância” de erros de drivers de dispositivos Necessita manter­se compatibilidade com os drivers existentes Possível Soluҫão: Isolar os device drivers em uma “sandbox”, mantendo as APIs existentes http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa ● Performance do isolamento depende: – – – – Nível do isolamento requerido Custo das comunicaҫões entre isolamentos Custo das movimentaҫões de dados entre os isolamentos Custo da execuҫão do código isolado Problema: Necessita­se conhecimento dos drivers antes de se isolar os mesmos. http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa ● Diferenҫas ao lidarmos com drivers: – – – Já existem! Lidam com quantidade absurda de dados Possuem apelas recursos limitados de aplicaҫão http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa ● A maioria dos problemas em drivers são derivados de: [Chou ’01, Linux kernel Bugzilla] – – – ● Acesso ilegal a memória Uso inválido de locks Mantimento de interrupҫões desabilitadas Estes problemas podem ser detectados verificando­se os acessos a memória e as condiҫões anteriores/posteriores na execuҫão do driver. http://www.kernelhacking.com Drivers de Dispositivos e Problemas de Seguranҫa ● ● Kernel já suporta inicializaҫão/paralizaҫão de drivers dinamicamente Devido ao grande número de interfaces driver/kernel no Linux, temos muitas oportunidades de otimizaҫão: – – Muitos parâmetros read­only Maioria das funҫões são de inicializaҫão/limpeza http://www.kernelhacking.com Network Hacks http://www.kernelhacking.com Network Hacks http://www.kernelhacking.com Network Hacks http://www.kernelhacking.com Network Hacks http://www.kernelhacking.com Técnicas de Hook de Rede ptype_* handlers Adicionar novo handler de protocolo, que pode reconhecer determinados pacotes ou modificar conteúdo de pacotes on­ the­fly Netfilter hooks Adicionar novos hooks do NF, efetuando o mesmo que os handlers. Esta técnica também pode passar pelas regras locais de Firewall (ipfilter em Linux é implementado como um hook NF) http://www.kernelhacking.com Protocol Handlers http://www.kernelhacking.com Estrutura Utilizada: packet_type struct packet_type { unsigned short type; struct net_device *dev; int (*func) (...); void *data; struct list_head list; }; Funҫões exportadas pelo kernel para adicionar/remover handlers: void dev_add_pack(struct packet_type *pt) void dev_remove_pack(struct packet_type *pt) http://www.kernelhacking.com Adiҫão do Handler (*) struct packet_type myproto; myproto.type myproto.func myproto.dev myproto.data = = = = htons(ETH_P_ALL); myfunc; NULL; NULL; dev_add_pack (&myproto) http://www.kernelhacking.com Possível detectar? Listando todos os handlers de protocolo suportados? Checagem manual das listas: ptype_all ptype_base Não são exportadas pelo kernel (mesmo método que usado para exportar sys_call_table em kernel 2.6) http://www.kernelhacking.com Estrutura do Netfilter http://www.kernelhacking.com Estrutura do Netfilter http://www.kernelhacking.com Estrutura Utilizada: nf_hook_ops (*) struct nf_hook_ops { struct list_head list; nf_hookfn *hook; handler address int pf; family (AF_INET, AF_INET6, AF_IPX, ...) int hooknum; (NF_IP_*, NF_IP6_*, NF_IPX_*, ...) int priority; }; Funҫões exportadas pelo kernel para adicionar hooks NF: int nf_register_hook(struct nf_hook_ops *reg); void nf_unregister_hook(struct nf_hook_ops *reg); http://www.kernelhacking.com Listas de Hooks NF Registradas struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS]; AF_UNSPEC (0) AF_UNIX (1) AF_INET (2) AF_AX25 (3) AF_IPX (4) AF_APPLETALK(5) NF_IP_PRE_ROUTING (0) NF_IP_LOCAL_IN (1) NF_IP_FORWARD (2) NF_IP_LOCAL_OUT (3) NF_IP_POST_ROUTING(4) http://www.kernelhacking.com Possível detectar? O endereҫo de nf_hooks é exportado Sabendo tal endereҫo, apenas precisamos verificar toda a lista e encontrar hooks suspeitos Lê­se suspeito como, por exemplo: – Hooks que não pertenҫam a módulos existentes • Módulos que foram escondidos • Módulos que não “limparam” seus hooks ao serem descarregados • Código injetado via /dev/(k)mem http://www.kernelhacking.com Exemplos Finais (*) - Modificacao de modulos - Interceptacao de memoria de processos - Modificacao de memoria do kernel - Integridade interna de kernel - Acesso remoto via kernel (backdoor?) http://www.kernelhacking.com Agradecimentos - Eventos, Workshops, Seminários, Palestras, RoadShows, Conversas - Comunicação - Elo mais fraco da segurança da informação http://www.kernelhacking.com FIM! Será mesmo? DÚVIDAS ? Rodrigo Rubira Branco [email protected] [email protected] http://www.kernelhacking.com
