De:  rod-linux Para:  seguranca@distro2.conectiva.com.br Assunto:  [seguranca] =?iso-8859-1?q?Explica=E7=E3o?=sobre Rootkit Data:  03 Dec 2003 10:33:05 -0200 RESUMO GERAL da matéria Dormindo com o inimigo RootKits = O termo root kit vem designar uma série de ferramentas utilizadas por um invasor para modificar ou ocultar a sua presença em um sistema invadido. A idéia inicial é a de que uma série de programas disfarçados em arquivos do sistema pudesse realizar tarefas de roubo de informações, possibilidade de acesso não autorizado a qualquer momento e, em caso de necessidade, desativação da máquina hospedeira. Funcionamento dos rootkits 1a. Geração - Na primeira geração, os rootkits eram nada mais nada menos que programas de sistemas modificados. Um exemplo era o caso do programa ifconfig. Primariamente, a função deste programa é configurar/alterar dispositivos de rede presente no sistema. Além disso, por meio dele era possível visualizar as configurações de um dispositivo, e o mais importante era verificar se um dos mesmos se encontrava em modo promíscuo (presença de sniffers). Desenvolveram um ifconfig modificado, que retirava a função de detectar o modo promíscuo e substituíam este pelo original do sistema. A idéia foi sendo melhorada, e logo havia rootkits com a maioria dos programas do sistema modificados e executavam roubo de senha, abriam backdoors, impediam o log de conexões não autorizadas, etc. Essa primeira geração foi um sucesso durante algum tempo, mas foi neutralizada de maneira fácil. Foram criados programas que auditavam os arquivos do sistema, guardando em um banco de dados seu tamanho, sua data de criação e outras informações pertinentes. Caso um arquivo fosse alterado, o programa apontava esta mudança e assim era possível descobrir se um sistema estava comprometido ou não. Outra técnica foi desenvolver pequenos programas para detecção de sniffers e ainda a utilização de programas de auditória de tráfego de pacotes, para a detecção de backdoors. Em pouco tempo estas ferramentas só ficaram na mão de invasorres iniciantes e causavam pequenos estragos em sistena ainda não protegidos. Exemplo dessas ferramentas podemos usar o AIDE, chkrootkit do nosso amigo Nelson, entre outras. 2a. Geração - Na segunda geração os rootkits deixaram de lado a preocupação de modificar programas do sistema e começaram a modificar através de módulos de kernel (LKM's), as system calls do sistema que representam funções de baixo nível que o sistema operacional utiliza para executar determinadas operações. Os desenvolvedores de rootkits procuraram criar módulos de kernel que alterassem essas system calls e as substituissem por funções totalmente modificadas. Isso causava anomalias do tipo ocultação de processos, ocultação de arquivos e diretórios, carregamento de módulos de kernel que se ocultavam e encobriam outros módulos, entre outras características interessantes como sniffers, backdoors, etc. Mas graças a um recurso do kernel, podemos também detectar estar mudanças da system calls. Ao ser compilado, um kernel cria um mapa de símbolos com as system calls e seus respectivos endereços de memória. Este arquivo é chamado System.map e pode ser utilizado como elemento comparador das system calls atuais com as originas do sistema. Foram desenvolvidas várias ferramentas que utilizam esta técnica, como um auditor/verificador das system calls, mas assim mesmo os administradores ainda são vitimas destas ferramentas de ataques. Uma maneira mais radical e que também foi muito utilizada é retirar o suporte do kernel a carregamento de módulos. Com isso a maioria dos rootkits foi neutralizada. 3a. Geração - "I dev/kmem is our friend", assim cita o artivo "Linux on-the-fly kernel patching without LKM" (Sd e Devik, 2001), que trouxe à tona uma nova geração de rootkits. Na segunda geração dos rootkits, com a retirada do suporte a carregamento de módulois, foi neutralizada a sua ação quase em 95%; o administrador inibia uma função facilitadora, mas ganhava muito em segurança. Sd e Devik apresentaram uma solução que é complexa e extremamente criativa. O linux possui um dispositivo conhecido como kmem (/dev/kmem), que possui o diretório de escrita e leitura somente pelo root. Este dispositivo abstrato virtual utilizada pelo kernel para a memória real (/dev/mem) ou seja, o mesmo faz o endeçamento da memória real+swap. Sd e Devik apresentaram uma nova geração de rootkits, o programa suckit. O funcionamento do suckit é uma das coisas mais interessantes que exitem, basicamente podemos dizer que o mesmo cira um tabela particular de syscalls e desvia o entry point do kernel para a mesma. O resultado é que não é necessária a utilização de LKMs. O linux disponibiliza um meio de localizar qualquer símbolo exportado ou utilizado pelo kernel, conforme comentamos antes, isso é guardado no System.map. O que estes rootkits fazem de uma maneira mais complexa é criar uma tabela própria através de comparação de bytes das informaçoes da system calls e com isso redirecionar o kernel para um espécie de tabela de símbolos própria e reescrever o kemem. Esta técnica requer um conhecimento muito profundo de arquitetura de kernel e de sistemas operacionais, sendo a sua implementação muito complexa, mas extremamente funcional. O suckit faz isso e é virtualmente impossível a sua detecção. Contudo, uma solução encontrada para a detcção dos mesmos cai na velha técnica de auditoria de arquivos, ja que estes programas, ao serem instalados, criam arquivos e diretórios próprios. Outra maneira é auditar as conexões, já que o backdoor do mesmo possui um modus operandi, que permite determinar tentativas de conexão e algumas portas de serviços no sistema. Uma maneira de proteger servidores dete genero é prevenir o kmem contra escrita, o que representa em alguns casos um custo muito alto para a segurança de um servidor. Os próprios autores do suckit sugerem um patch para o kernel que faria isso. Bom galera os rootkits estão evoluindo e acredita-se que uma 4 geraçãoja esta sendo executada com modificações cada vez mais inerentes ao sistema operacional. Cabe ao administrador do sistema estar cada vez mais atento aos novos lançamentos e, acima de tudo, estudar e muito os logs em busca de estranhas atividades em seus servidores. Esse artigo não é de auditoria minha, pois eu o li e o achei muito interessante a explicação feita pelo autor. Abaixo segue o link onde pode-se baixar a matéria completa, sugiro a todos que acharam o resumo interessante ler a matéria completa. Nós administradores temos que compartilhar assuntos de segurança, estar sempre unidos pois sempre teremos novos desafios, temos tb de pesquisar e estudar os rootkits, exploits, fazermos sempre atualizações de segurança e ficarmos atentos a todas as falhas de segurança, aplicarmos os devidos patchs e fazermos os testes. Sugiro aos interessados nos rootkits, para podermos sempre estar disponibilizando análise desses rootkits, eu estarei estudando alguns novos e colocando onde eles agem para informações de todos. OK. A matéria completa esta em: http://www.honeypot.com.br/files/rootport.pdf -- __ _ Rodrigo / / (_)__ __ ____ __ ºvº / /__/ / _ \/ // /\ \/ / /( )\ /____/_/_//_/\___/ /_/\_\ ^ ^ ________________________________________________________ Lista seguranca seguranca@distro2.conectiva.com.br http://distro2.conectiva.com.br/mailman/listinfo/seguranca