| ____________________________________________________________ Guia Para Hacking (essencialmente) Inofensivo Volume 8: Através
do espelho: Encontrar provas do teu cracker por Chris Kuethe Subscreveste a Bugtraq e a lista Happy Hacker, compraste uma cópia do livro "The Happy Hacker", e leste "The Cuckoo's Egg" algumas vezes. Foi um natal muito feliz, com a chegada de um modem e um monte de dinheiro para ti, por isso desandas e vais fazer compras para começar o teu próprio laboratório hacker. Cerca de uma semana mais tarde notas que uma das tuas máquinas está demasiado lenta (Boa! Sherlock!) e não tens espaço de disco. Adivinha lá -- foste crackado, e agora é altura de limpar a porcaria. A única maneira de teres a certeza que fazes tudo bem é restaurar a partir de um backup limpo -- usualmente pacotes de instalação e código fonte canónico -- mas vejamos o que o cracker deixou para nós estudarmos. No fim de Outubro deste ano, nós sofremos uma série de ataques a algumas workstations aqui no Departamento de Ciências Matemáticas da Universidade de Alberta. A maioria das nossas máquinas da faculdade correm o RedHat 5.1 (aqui está uma boa plataforma para aprender como tentar proteger...) já que é barata e fácil de instalar. As workstations são muitas vezes dual-boot com o Windows 95, mas ultrapassaremos isso logo que instalemos o Citrix WinFrame. Esta dissertação é uma análise do comprometimento da máquina de um professor. Um dia eu fui informado que tínhamos sofrido mais um arrombamento, e era altura para eu mostrar aos meus chefes alguma da minha magia. Mas como um hábil tubarão das cartas que é forçado a usar um baralho não marcado, a minha vantagem de estar na consola tinha sido viciada. O nosso cracker tinha usado um rootkit decente e quase cobriu as suas pisadas. Usualmente um rootkit é uma colecção de utilitários que um cracker instalará de forma a manter o seu acesso root. Coisas como versões de ps, ls, passwd, sh, e outras utilidades essenciais serão substituídas por versões com backdoors. Desta forma, o cracker pode controlar quantas provas ele deixa para trás. O ls é substituído para que os ficheiros do cracker não apareçam, e o ps para que os seus processos também não sejam mostrados. Geralmente, depois de um crack, podes apostar que uma coisa importante como um sniffer foi instalado. Os packet sniffers - programas que podem guardar tráfico de redes - não são propriamente parte de um rootkit, mas são quase tão amados pelos hackers como uma cópia do ls com bugs. Quem não tentaria cheirar as passwords de outros utilizadores? Em quase todos os casos, podes confiar na cópia do ls na caixa crackada para ficar deitada como um tapete. Não apostes em encontrar quaisquer ficheiros suspeitos com ela, e não confies no tamanho ou datas de ficheiros que relata; há uma razão porque um binário toolkit é geralmente maior do que o verdadeiro, mas já lá vamos daqui a bocado. Para encontrar algo interessante, terás de usar o find. O find é uma versão hábil de 'ls -RalF <w> | grep <x> | grep <y> | ... | grep <z>'. É uma sintaxe poderosa para permitir especificação precisa de onde e o que procurar. Não estava a ser picuinhas - tudo cujo nome começasse por um ponto valia a pena ser verificado. O comando: find / -name ".*" -ls. Metido no meio de uma tonelada de ficheiros temporários inúteis e os habituais ficheiros '.coisarc' (configurações como o .ini do MSDOS) encontramos '/etc/rc.d/init.d/...'. Sim, com três pontos. Um ponto apenas não é estranho, nem dois, Brinca um bocado no DOS e verás porquê: '.' significa "esta directoria" e '..' significa "uma directoria acima". Existem em todas as directorias e são necessárias para o funcionamento correcto do sistema de ficheiros. Mas '...'? Isto não tem uma razão especial para existir. Bem, estava a ficar tarde, e eu estava queimado depois de um dia de aulas e os meus contactos estavam a esgotar-se, por isso listei /etc/rc.d/init.d/ para ver este objecto. Nada. Apenas os usuais ficheiros init do System V / RedHat 5.1. Para ver quem estava a mentir, eu mudei a minha directoria para /tmp/foo, depois ecoei a data actual para um ficheiro chamado '...' e experimentei o ls nele. '...' não foi encontrado. Tinha encontrado o primeiro binário rootkit: uma cópia do ls escrita para não mostrar o nome '...'. Agora que nós sabíamos que '...' não fazia parte de uma distribuição canónica, eu mudei-me para dentro dele e dei uma olhada. Só havia dois ficheiros: linsniffer e tcp.log. Vi o tcp.log com o more e fiz uma lista do pessoal que receberia algumas notícias más. O ps não mostrava o sniffer a correr, mas o ps não deve ser acreditado neste caso, por isso tinha de verificar de outra maneira. Estávamos a correr em tcsh, uma shell de sintaxe C melhorada que suporta execução de trabalhos assíncrona (background). Digitei './linsniffer &' que disse à tcsh para executar o programa chamado linsniffer nesta directoria, e mandá-lo para o background. A tcsh disse que era a tarefa #1, com o ID de processo 2640 . Altura para outro ps - e nada de linsniffer. Bem, isto não era demasiado chocante. Ou o ps foi hackado ou o linsniffer mudou o nome para outra coisa. O choque: 'ps 2640' disse que não havia processos disponíveis. Foi o suficiente. O ps tinha sido hackado. Este era o segundo binário rootkit. Fazer um kill ao sniffer. Agora verificamos o óbvio: /etc/passwd. Não havia entradas estranhas e todos os logins funcionavam. Isto é, as passwords não foram mudadas. De facto a única coisa estranha era que o ficheiro tinha sido modificado mais cedo durante o dia. Uma invocação de last mostrou-nos que o 'bomb' tinha feito o login por pouco tempo cerca das 2:35am. Esse tempo mostrar-se-ia significativo. Não há aqui ninguém a não ser nós, as galinhas, e nenhum de nós se chamava 'bomb'... Eu fui buscar o meu disco de detecção de cracks - uma disquete fechada com binários em que eu confio -- e montei o CD RedHat. Usei o meu ls limpo e descobri que o verdadeiro ls era de cerca 28K, enquanto que o da rootkit tinha mais de 130K! Será que alguém me poderia explicar o que é que aqueles bytes a mais são supostos ser? O comando file tem a resposta: 32-bit LSB executable, Intel 80386, versão 1, ligado dinamicamente, não despido. Aha! Então quando ele compilou-o, o nosso script kiddie esqueceu-se de despir o ficheiro. Isto significa que o gcc deixou toda a sua informação de debugging no ficheiro. Realmente, despir o programa diminui o seu tamanho para 36K, que é razoável para a funcionalidade extra (esconder certos ficheiros) que foi acrescentada. Lembraste que eu mencionei quão importante é o aumento do tamanho do ficheiro? É aqui que descobrimos porquê. Primeiro, novas características foram acrescentadas. Segundo, os binários têm tabelas de símbolos verbose, para ajudar a fazer o debug sem ter de incluir todo o código debug. E terceiro, muitos script kiddies gostam de compilar coisas com o debugging activado, pensando que lhes dará mais backdoors no modo debug. Certamente o nosso kiddie foi ingénuo o suficiente para pensar assim. A sua cópia do ls tinha uma tabela de símbolos completa, e fonte, e foi compilada a partir de /home/users/c/chlorine/fileutils-3.13/ls.c - que é informação útil. Podemos buscar distribuições canónicas e comparar essas contra o que está instalado para obter mais uma pista sobre o que ele pode ter danificado. Eu ingenuamente dirigi-me para os ficheiros logs, que estavam, claro, puros como a neve, mas mesmo assim ainda descobri algo útil: esta caixa parecia ter TCP wrappers instalados. OK, estes devem ter falhado de alguma maneira porque ele entrou no nosso sistema. No RH5.1, os TCP wrappers estão alojados em /usr/sbin/in.*. Então o que é que este in.sockd está a fazer em /sbin? Está a ser maroto, é o que é. Eu esprimi o in.sockd à procura de strings, e encontrei algumas strings muito interessantes. Cito: You are being logged (Estás a ser registado), FUCK OFF (VAI-TE FODER), /bin/sh, Password:, backon. Duvido que isto faça parte de um pacote oficial da RedHat. Rapidamente verifiquei os outros TCP wrappers, e descobri que o in.rshd da RedHat tem 11K, e o que estava no disco duro tinha 200K. OK, dois wrappers falsos. Parece que, olhando para as datas do ficheiro, este wrapper crackado saiu no dia a seguir ao lançamento do RH5. Fantasmagórico, não? Notei que estes binários, embora ligados dinamicamente, usavam o libc5, não o libc6 que é o que nós temos. Claro, o libc5 existe, mas nada, mesmo nada o usa. Puro código de compatibilidade background. Depois de verificar os outros binários suspeitos, eles também usavam o libc5. É aí que strings e grep (ou um pager) são usados. Já estou a ficar aborrecido de procurar à mão, então vamos diminuir a nossa busca um pouco usando o find. Tenta tudo de Outubro deste ano... Duvido que o nosso cracker fosse do tipo paciente - olha para os seus erros até agora - por isso ele provavelmente não entrou antes do início do mês. Não reclamo ser um mestre da sintaxe do find, por isso fiz isto: find / -xdev -ls | grep "Oct" | grep -v "19[89][0-7]" > octfiles.txt Em português: começa pela raiz, e não verifiques outras drives, imprime todos os nomes dos ficheiros. Passa isto pelo grep que filtra tudo excepto "Oct" e depois outro grep para filtrar anos que não me importam. Claro, os anos 80 produziram alguma música boa (Depeche Mode) e bom código Unix/BSD, mas esta não é a altura para estudar história. Um dos ficheiros que o find referiu foi /sbin/in.sockd. Interessantemente, o ps disse que havia um processo sem nome com um id de processo baixo (76) possuído pelo uid=0, gid=26904. Esse grupo é desconhecido aqui no campus – de quem é? E como é que este ficheiro foi executado tão cedo de forma a ter um PID tão baixo? O in.sockd tem esse par uid/gid... estranho. Tem de ser chamado a partir dos scripts init já que este processo aparece no startup, com um baixo PID consistente. Aplicando o grep ao ficheiro rc.sysinit para o in.sockd, as duas últimas linhas deste ficheiro são: #Start Socket Deamon Sim, pois... Isto não é parte da instalação normal. E Deamon está mal soletrado. Deve um corrector ortográfico ser incluído como um detector de cracks? Bem, o RedHat não é famoso por documentos pobres e toneladas de erros, mas é possível acrescentar palavras a um dicionário. Assim, o nosso cracker tentou instalar uma backdoor e tentou disfarçá-la ao metê-la junto com alguns problemas relacionadas. Isto acrescenta credibilidade à minha teoria que o nosso cracker, até agora, confinou as suas habilidades a pesquisas na Net para exploits já feitos. O segundo daemon que foi contaminado foi o rshd. Cerca de dez vezes maior do que a cópia standard, não pode estar com boas intenções a não ser causar problemas. O que significa o rsh aqui? RemoteShell ou RootShell? A tua opinião é tão boa quanto a minha. Até agora o que nós encontramos foram versões comprometidas do ls, ps, rshd, in.sockd, e a festa só está a começar. Eu sugiro que logo que acabes de ler isto, faças uma pesquisa web de 'rootkit' e ver quantos consegues reunir e derrotar. Tens de saber o que procurar para conseguires removê-lo. Enquanto os ficheiros de registo estavam todos limpos, a consola ainda tinha alguns erros impressos nela, uns poucos depois de 0235h. Um deles foi uma recusa de servir acesso root a / através de nfs às 0246h. Isso coincidiu perfeitamente com o último tempo de acesso à manpage do NFS. Então o nosso script kiddie encontrou algo fixe, e tentou montar este computador via NFS, mas não o montou correctamente. Todos os crackers, acho eu, cometem erros. Se fizessem tudo de modo perfeito nunca os notaríamos e não haveriam problemas. Mas são os problemas que surgem das suas falhas que nos causam um pouco de aflição. Por isso lê os teus manuais. Quanto mais pormenorizadamente conheceres o teu sistema, mais hipóteses tens de notar anormalidades. Uma das coisas úteis (para parar um cracker) do NFS é que se o servidor fôr abaixo, todos os clientes NFS com directorias ainda montadas ficarão pendurados. Terás de reiniciar a máquina para recuperá-la. Mmmm. Isto apresenta uma oportunidade de ferramenta interessante: escreve um script para detectar um hack do NFS, e se uma máquina remota entrar, expulsa essa interface através do ifconfig. Certo, isso representa um possível DoS se utilizadores autorizados forem expulsos. Mas ainda é útil se não quiseres que a tua workstation seja comprometida. Nesta altura desisti. Aprendi o que tencionava aprender - como encontrar o lixo deixado para trás por um cracker. Como a proprietária deste sistema tinha todos os seus ficheiros em meios removíveis não havia perigo de estes estarem de alguma maneira comprometidos. A directoria ~janedoe era montada a partir de um disco jaz, que ela tinha levado para casa de noite, então limitei-me a pôr o CD na sua drive e reinstalei tudo. É por isto que se mantêm ficheiros de utilizadores numa partição separada, que se mantêm sempre backups e porque é um bom plano apontar onde obter o código fonte das coisas que descarregaste para o computador, se não fores capaz de manter os arquivos originais. Agora que já acumulamos provas suficientes e somos apenas tipos animados a pulverizar um cadáver equíneo, é tempo de considerar a resposta apropriada. Similarmente aos avisos podes-levar-um-murro e podes-ir-para-a-cadeia da Carolyn, eu sugiro que um hack de resposta perverso não é apropriado. No Canada, o RCMP tem a sua cabeça colectiva fora da areia. Não sou um advogado, por isso não faças nada baseado nesta palavras excepto arranjar um advogado para ti próprio. Com isto fora do caminho, é suficiente dizer que damos muita importância à protecção de propriedade por estas bandas. Juntamente com arranjar um advogado, o meu conselho aqui é para ligares para a polícia nacional, quem quer que sejam. Pessoas como o RCMP, FBI, BKA e o KGB provavelmente não se importarão com uma chamada de telefone amigável, especialmente se estás a telefonar para ver como é que podes tornar-te um melhor cidadão cumpridor da lei. Talvez te dêem algumas dicas realmente boas, ou pelo menos algumas referências úteis. E é claro que conhecerás alguém que ajudar-te-á a processar o responsável. A minha comunicação com a unidade de Crimes Comerciais do RCMP (que incluí roubo de serviços informáticos e/ou de rede) pode ser resumido assim: o email não tem expectativa de privacidade. Gostarias que o email fosse secreto, mas acorda e nota que é mais arriscado do que um postal. Como um administrador de sistemas, podes fazer TUDO o que quiseres com o teu computador - já que é da tua responsabilidade ou porque é tua propriedade ou porque és o seu guarda nomeado - desde que avises os utilizadores primeiro. Por isso posso monitorizar todo e qualquer byte que todos os meus utilizadores enviam ou recebem, desde que tenham sido avisado verbalmente, electronicamente e por escrito, da minha intenção de o fazer. A minha visita ao site do FBI mostra coisas semelhantes. Mas isso foi só uma visita. Não entres em colisão com leis provinciais ou estatais que também regulam a intercepção de comunicações electrónicas. NOTA: Enquanto que eu tentei fazer esta reconstrução dos eventos tão correcto quanto possível, há sempre uma hipótese de eu ter interpretado mal um registo ou outra coisa. Além disso, este artigo é somente a minha opinião, e não deverá ser lido como a posição oficial do meu empregador. Apêndice A: Programas
que queres ter num kit de detecção de cracks Estes deverão estar todos ligados estatisticamente. Os itens separados por vírgulas significa "todos estes", itens separados por barras significam "escolhe o teu favorito".
RedHat 5.1 Sobre o sistema de ficheiro LEA and Computer Crime ----------------------------------------------------------------- Esta é uma lista devotada ao hacking *legal*! Se planeias usar qualquer informação neste Digest ou no nosso website para cometer um crime, vai-te embora! Ganha vergonha na cara! Para questões
sobre o Windows, envia um email a keydet89@yahoo.com
ou a editor@techbroker.com Grande Chefe do Happy
Hacker: Carolyn Meinel <cmeinel@techbroker.com> ****************************************************************************** |