Minha primeira tradução aqui... Perdoem-me se estiver fazendo algo errado (e avisem, por favor :)
Mas antes eu queria pedir uma coisa pra vocês... Um pouquinho mais de cuidado. A tradução do relatório da invasão e restauração dos servidores do Debian depois da invasão tava cheia de erros sérios. Os de regência e técnicos (parent->parente) são perfeitamente compreensíveis, mas alguns como "armazendo, invovlia, adminitração, inclue, obfuscado, sanhas, seram, comptadores, etc" poderiam ter sido evitados com uma simples verificação do arquivo com qualquer corretor ortográfico (ispell, por exemplo). Não que seja mais importante que qualquer arquivo da página, mas chama muita atenção, e algumas medidas poderiam ser adotadas pra evitar coisas assim: facilmente evitáveis. Segue anexo o .wml corrigido. []s! -- Guilherme de S. Pastore (fatalerror) <[EMAIL PROTECTED]>
#use wml::debian::translation-check translation="1.4" <define-tag pagetitle>Relatório de Investigação do Debian após o comprometimento de servidores</define-tag> <define-tag release_date>2003-12-02</define-tag> #use wml::debian::news <p>A equipe de administração do Debian e especialistas em segurança finalmente podem descrever o método usado para invadir quatro computadores do projeto. No entanto, o indivíduo que o fez ainda não foi descoberto.</p> <h3>Os repositórios de pacotes não foram alterados pelo intruso</h3> <p>As equipes de administração e segurança do Debian checaram estes repositórios (security, us, non-us) no início do processo de investigação e reinstalação. Portanto, o projeto pode abrir o repositório de segurança novamente e confirmar que a atualização estável (3.0r2) não foi comprometida.</p> <p>Se o projeto tivesse antecipado que seria comprometido no mesmo tempo que a atualização estável foi implementada, as pessoas envolvidas a teriam adiado. No entanto, os pacotes atualizados já estavam instalados no repositório estável e servidores espelho no momento que a invasão foi descoberta. Assim, não foi possível segurá-la mais.</p> <p>Vários métodos baseados em dados de controle diferentes foram usados para verificar os pacotes e para certificar que os repositórios não foram alterados pelo atacante:</p> <ul> <li> listas de somas MD5 armazenadas externamente acumuladas nas últimas semanas em computadores que não foram comprometidos <li> arquivos .changes assinados digitalmente de arquivos debian-devel-changes externos em computadores que não foram comprometidos <li> arquivos .changes assinados nos servidores de arquivos respectivos <li> arquivos de log de espelhos 0 externamente </ul> <h3>Linha do Tempo</h3> <p>Abaixo está a linha do tempo da descoberta e recuperação dos computadores comprometidos. Todos os tempos estão em UTC. Alguns tempos são estimativas uma vez que nossas conversas não continham horas precisas.</p> <blockquote> <br />28 Set 01:33 Linus Torvalds lança o 2.6.0-test6 com a correção do_brk() <br />02 Out 05:18 Marcelo Tosatti aplica testes de limite ao do_brk() <br />19 Nov 17:00 Atacante entra em klecker com uma senha obtida por 'sniff' <br />19 Nov 17:08 Root-kit instalado em klecker <br />19 Nov 17:20 Atacante entra em master com a mesma senha obtida por 'sniff' <br />19 Nov 17:47 Root-kit instalado em master <br />19 Nov 18:30 Atacante entra em murphy com conta de serviços de master <br />19 Nov 18:35 Root-kit instalado em murphy <br />19 Nov 19:25 Oopses em murphy começam <br />20 Nov 05:38 Oopses em master começam <br />20 Nov 20:00 Descoberta dos Oopses em master e murphy <br />20 Nov 20:54 Root-kit instalado em gluck <br />20 Nov 22:00 Confirmação que debian.org fora comprometido <br />21 Nov 00:00 Desativação de todas as contas <br />21 Nov 00:34 security.debian.org desligado <br />21 Nov 04:00 gluck desligado (www, cvs, people, ddtp) <br />21 Nov 08:30 www.debian.org apontado para www.de.debian.org <br />21 Nov 10:45 Anúncio público <br />21 Nov 16:47 Informações para desenvolvedores atualizada <br />21 Nov 17:10 murphy (lists) e master desligados <br />22 Nov 02:41 security.debian.org de volta online <br />25 Nov 07:40 lists.debian.org de volta online <br />28 Nov 22:39 Linux 2.4.23 lançado </blockquote> <h3>Descoberta</h3> <p>Na madrugada (GMT) de quinta-feira, 20 de novembro, a equipe de administração notou vários oopses do kernel em master. Uma vez que o sistema estivera rodando sem problemas por um longo tempo, a máquina estava próxima de ser levada para manutenção, para investigação aprofundada sobre possíveis problemas de hardware. No entanto, ao mesmo tempo, um segundo computador, murphy, estava passando por exatamente os mesmos problemas, o que levantou suspeitas dos administradores.</p> <p>Além disso, klecker, murphy e gluck têm o "Advanced Intrusion Detection Environment" (Ambiente Avançado de Detecção de Intrusão, pacote <a href="http://packages.debian.org/aide";>aide</a>) instalado para monitorar alterações no sistema de arquivos, e começaram a alertar que por volta da mesma hora, <code>/sbin/init</code> havia sido substituído e que os valores mtime e ctime do <code>/usr/lib/locale/en_US</code> tinham mudado.</p> <p>Investigações posteriores revelaram que a causa de ambos os problemas era o root-kit SucKIT (1.3b). Ele 2 sniffing de senhas e capacidade de evasão de detecção (ferramentas para esconder processos e arquivos) que são instalados diretamente no kernel, o que causou os oopses que foram notados.</p> <h3>Análise Detalhada do Ataque</h3> <p>Na quarta-feira, 19 de novembro, aproximadamente às 17:00, uma senha obtida por sniff foi usada para entrar em uma conta de desenvolvedor não-privilegiada em klecker (.debian.org). O atacante pegou então o código-fonte via HTTP para um exploit local desconhecido (naquele momento) do kernel, através do qual ganhou permissões de root. Por fim, o SucKIT foi instalado.</p> <p>A mesma conta e senha foi usada para entrar no computador master, para ganhar permissões de root com o mesmo exploit e também instalar o root-kit SucKIT.</p> <p>Então, o atacante tentou obter acesso a murphy com a mesma conta. Isso falhou, já que murphy é um computador restrito, e seu único propósito é agir como um servidor de listas, ao qual apenas um pequeno subconjunto de desenvolvedores tem acesso. Uma vez que a tentativa inicial de login falhou, o indivíduo usou seu acesso root em master para acessar uma conta administrativa que era usada para propósitos de backup e ganhou acesso a murphy também. O root-kit SucKIT também foi instalado neste computador.</p> <p>No dia seguinte, o atacante usou uma senha obtida por sniff em master para entrar em gluck, obteve root lá e instalou o root-kit SucKIT.</p> <p>A análise revelou as datas e horas exatas nas quais o programa <code>/sbin/init</code> foi sobrescrito e o root-kit instalado. Os analistas também descobriram o arquivo executável que foi usado para obter acesso root nos computadores, que estava protegido e 0 com Burneye. Após o desencapsulamento e desassembling do exploit, especialistas em segurança descobriram qual bug do kernel foi utilizado.</p> <p>Um estouro de inteiro na chamada de sistema brk foi explorada para sobrescrever a memória do kernel (alterar bits de proteção de página). Fazendo isto, o atacante ganhou controle completo sobre o espaço de memória do kernel e pôde alterar qualquer valor na memória.</p> <p>Apesar deste código do kernel ter sido melhorado em Setembro por Andrew Morton e copiado em um pré-lançamento recente do kernel desde outubro, as implicações de segurança do melhoramento não foram consideradas. Assim, nenhum alerta de segurança foi feito por nenhum distribuidor. No entanto, depois que seu uso como exploração root local foi descoberto, a projeto de Vulnerabilidades e Exposições Comuns destacou o CAN-2003-0961 para este problema. Ele foi corrigido no Linux 2.4.23 que foi lançado neste final de semana e no alerta Debian <a href="$(HOME)/security/2003/dsa-403">DSA 403</a>.</p> <p>O Linux 2.2.x não está vulnerável a este exploit porque a checagem de limites é feita antes. Também acredita-se que os kernels Sparc e PA-RISC não são vulneráveis, uma vez que os endereços do kernel e do usuário são armazenados em diferentes espaços de endereços nessas arquiteturas.</p> <p>Por favor, entenda que nós não podemos dar o exploit utilizado para pessoas que não conhecemos. Portanto, não nos pergunte sobre ele.</p> <h3>Recuperação</h3> <p>Depois que os computadores foram desligados, imagens dos discos rígidos comprometidos foram criadas e armazenadas em um computador separado. Elas foram distribuídas para pessoas que fizeram as análises. Os três computadores nos EUA (master, murphy, gluck) foram reinstalados e os seus serviços 1, um por um, após a investigação pelo respectivo administrador.</p> <p>Em klecker, no entanto, isso foi adiado para priorizar uma manutenção marcada, para que o repositório de segurança pudesse ser colocado online antes dos outros serviços. Naquele momento nós também não tínhamos acesso ao console de klecker. Assim, a recuperação teve que ser feita remotamente. Depois que uma imagem do disco foi feita, através de login por console serial, em um computador local através de conexão de rede protegida por firewall, o root-kit foi removido, o kernel trocado e "endurecido", binários duplamente checados e o repositório de segurança verificado contra várias fontes externas diferentes. Esse computador será reinstalado nas próximas semanas.</p> <p>Como medida de segurança, todas as contas de desenvolvedores foram desabilitadas no LDAP, e as chaves SSH foram removidas dos computadores mais importantes para que nenhum outro sistema fosse comprometido. Isso, no entanto, efetivamente desabilitou praticamente qualquer trabalho público Debian que envolvesse o upload de arquivos e acesso aos repositórios CVS.</p> <p>Todas as senhas usadas em quantz (todas as senha do Alioth, arch e subversion) também foram invalidadas. Todas as chaves SSH autorizadas também foram removidas. Use o sistema de senhas perdidas para <a href="https://alioth.debian.org/account/lostpw.php";>receber</a> uma senha nova.</p> <p>Quando todos os serviços estiverem rodando novamentei e os computadores estiverem suficientemente seguros, o LDAP será resetado para que os desenvolvedores possam <a href="http://db.debian.org/password.html";>criar</a> uma senha nova. No entanto, não é possível prever quando isso irá acontecer.</p> <p>Durante a recuperação, o SSH foi reinstalado nos computadores comprometidos. Assim, há novas chaves de host RSA e fingerprints de chaves para estes computadores. As chaves serão incluídas no LDAP assim que forem criadas, e podem ser pegas <a href="http://db.debian.org/machines.cgi";>aqui</a>.</p> <h3>Conseqüências</h3> <p><strong>Renove suas senhas!</strong></p> <p>Uma vez que senhas foram obtidas por sniff nos servidores comprometidos, qualquer conexão que envolveu uma senha deve ser considerada comprometida também. Ou seja: a senha deve ser considerada como conhecida pelo atacante. Assim sendo, ela deve ser alterada imediatamente.</p> <p>Além disso, se alguém tinha acesso a um computador Debian e estava usando a mesma senha ou frase secreta em outros computadores ou chaves, nós fortemente recomendamos a alteração das mesmas o mais rápido possível.</p> <p>Se uma chave SSH foi gerada ou armazenada em um destes computadores e usada para entrar em outros (instalando-a em <code>.ssh/authorized_keys</code>), ela também deve ser removida.</p> <p>As chaves secretas GnuPG/PGP que estavam em computadores debian.org também foram removidas dos chaveiros do Debian e, assim, desativadas.</p> <p>Desenvolvedores que estão preocupados com seus computadores devem ao menos rodar o chkrootkit e observar sua saída. Matt Taggart mantem um backport da versão atual para woody no seguninte endereço:</p> <blockquote> <br />deb http://lackof.org/taggart/debian woody/chkrootkit main <br />deb-src http://lackof.org/taggart/debian woody/chkrootkit main </blockquote> <p>Adicionalmente, uma lista detalhada de <a href="http://www.wiggy.net/debian/developer-securing/";>precauções</a> foi feita por Wichert Akkerman e Matt Taggart. <h3>Root-Kit SucKIT</h3> <p>SucKIT é um root-kit apresentado na Phrack, edição 58, artigo 0x07 ("Linux on-the-fly kernel patching without LKM", por sd & devik). Ele é um root-kit completamente funcional que é carregado via /dev/kmem. Ou seja, ele não precisa de um kernel com suporte a módulos de kernel carregáveis. Ele possui um shell para acesso remoto protegido por senha, iniciado por um pacote com spoof (passando pela maioria das configurações de firewall) e pode esconder processos, arquivos e conexões.</p> <p>Geralmente, o SucKIT é rodado como /sbin/init na inicialização do sistema, usa fork para se instalar no kernel, inicia uma backdoor, e roda uma cópia do binário "init" original do pai (com pid 1). Quaisquer execuções subseqüentes ao <code>/sbin/init</code> são redirecionadas para o init original.</p> <h3>Proteção Burneye do TESO</h3> <p>Burneye é um modo de ofuscar binários ELF na plataforma UNIX, apresentado na edição 58 da Phrack, artigo 0x05 ("Armouring the ELF: Binary encryption on the UNIX platform", por grugq & scut). Usando ferramentas como Burneye do TESO, um atacante pode alterar um programa executável para criptografar seu propósito real, escondendo-o de filtros de firewall, sistemas de detecção de intrusão, software anti-vírus e os olhos dos investigadores.</p> <h3>Agradecimentos</h3> <ul> <li> James Troup e Ryan Murray por seu trabalho geral em todos os servidores <li> Adam Heath e Brian Wolfe por seu trabalho em master murphy <li> Wichert Akkerman por seu trabalho em klecker <li> Dann Frazier e Matt Taggart por seu trabalho em gluck <li> Michael Stone e Robert van der Meulen por seu trabalho de análise <li> Marcus Meissner por fazer o desassembling do exploit usado <li> Jaakko Niemi por seu trabalho na checagem e reabilitação de lists.debian.org <li> Colin Watson por seu trabalho na checagem e reabilitação de bugs.debian.org <li> Josip Rodin por seu trabalho na checagem e reabilitação dos arquivos web das listas </ul> <h3>Repostas de Imprensa</h3> <ul> <li><a href="http://slashdot.org/articles/03/11/21/1314238.shtml";>Slashdot</a>, 21 Nov, 2003 <li><a href="http://www.eweek.com/print_article/0,3048,a=113091,00.asp";>eWeek</a>, 21 Nov, 2003 <li><a href="http://www.internetnews.com/dev-news/article.php/3112551";>InternetNews</a>, 21 Nov, 2003 <li><a href="http://www.heise.de/newsticker/data/odi-21.11.03-001/";>Heise Newsticker</a>, 21 Nov, 2003 (Alemão) <li><a href="http://www.pro-linux.de/news/2003/6205.html";>Pro-Linux</a>, 21 Nov, 2003 (Alemão) <li><a href="http://www.linux-community.de/Neues/story?storyid=10821";>Linux-Community</a>, 21 Nov, 2003 (Alemão) <li><a href="http://barrapunto.com/articles/03/11/21/1527220.shtml";>BarraPunti</a>, 21 Nov, 2003 (Espanhol) <li><a href="http://www.newsforge.com/article.pl?sid=03/11/21/1319258";>Newsforge</a>, 21 Nov, 2003 <li><a href="http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci938279,00.html";>SearchEnterpriseLinux.com</a>, 22 Nov, 2003 <li><a href="http://www.debianplanet.org/node.php?id=1011";>Debian Planet</a>, 22 Nov, 2003 <li><a href="http://www.pcworld.com/news/article/0,aid,113636,00.asp";>PC World</a>, 24 Nov, 2003 <li><a href="http://news.zdnet.co.uk/internet/security/0,39020375,39118062,00.htm";>ZDNet UK</a>, 24 Nov, 2003 <li><a href="http://www.enterprise-linux-it.com/perl/story/22748.html";>Enterprise Linux IT</a>, 24 Nov, 2003 <li><a href="http://www.theage.com.au/articles/2003/11/24/1069522516071.html";>The Age</a>, 24 Nov, 2003 <li><a href="http://www.smh.com.au/articles/2003/11/24/1069522516071.html";>Sydney Morning Herald</a>, 24 Nov, 2003 <li><a href="http://www.winnetmag.com/windowspaulthurrott/Article/ArticleID/40957/windowspaulthurrott_40957.html";>Windows & .NET Magazine</a>, 24 Nov, 2003 <li><a href="http://www.infoworld.com/article/03/11/24/HNdebianhacked_1.html";>Infoworld</a>, 24 Nov, 2003 <li><a href="http://www.linuxinsider.com/perl/story/32240.html";>Linux Insider</a>, 24 Nov, 2003 <li><a href="http://www.ecommercetimes.com/perl/story/32240.html";>eCommerce Times</a>, 24 Nov, 2003 <li><a href="http://www.technewsworld.com/perl/story/32240.html";>TechNewsWorld</a>, 24 Nov, 2003 <li><a href="http://www.theregister.co.uk/content/4/34149.html";>The Register</a>, 28 Nov, 2003 <li><a href="http://newsvac.newsforge.com/article.pl?sid=03/11/28/1545237";>Newsforge</a>, 28 Nov, 2003 <li><a href="http://slashdot.org/articles/03/11/28/050232.shtml";>Slashdot</a>, 28 Nov, 2003 <li><a href="http://developers.slashdot.org/developers/03/12/01/2133249.shtml";>Slashdot</a>, 1 Dez, 2003 <li><a href="http://www.theage.com.au/articles/2003/11/24/1069522516071.html";>The Age</a>, 1 Dez, 2003 <li><a href="http://www.smh.com.au/articles/2003/12/01/1070127318372.html";>Sydney Morning Herald</a>, 1 Dez, 2003 <li><a href="http://www.pro-linux.de/news/2003/6240.html";>Pro-Linux</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.heise.de/newsticker/data/jk-02.12.03-000/";>Heise Newsticker</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.golem.de/0312/28747.html";>Golem</a>, 2 Dez, 2003 (Alemão) <li><a href="http://lwn.net/Articles/60948/";>LWN</a>, 2 Dez, 2003 <li><a href="http://www.theregister.co.uk/content/55/34285.html";>The Register</a>, 2 Dez, 2003 <li><a href="http://www.zdnet.de/news/security/0,39023046,39117906,00.htm";>ZDnet DE</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.linux-community.de/Neues/story?storyid=11004";>Linux-Community</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.heise.de/security/artikel/42546";>Heise</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.heise.de/newsticker/data/anw-02.12.03-005/";>Heise Newsticker</a>, 2 Dez, 2003 (Alemão) <li><a href="http://www.symlink.ch/articles/03/12/02/1820248.shtml";>Symlink</a>, 2 Dez, 2003 <li><a href="http://www.pro-linux.de/news/2003/6245.html";>Pro-Linux</a>, 3 Dez, 2003 (Alemão) <li><a href="http://www.heise.de/newsticker/data/ju-04.12.03-000/";>Heise Newsticker</a>, 4 Dez, 2003 (Alemão) <li><a href="http://www.symlink.ch/articles/03/12/04/0123247.shtml";>Symlink</a>, 4 Dez, 2003 (Alemão) <li><a href="http://www.internetnews.com/dev-news/article.php/3116231";>Symlink</a>, 4 Dez, 2003 <li><a href="http://newsvac.newsforge.com/article.pl?sid=03/12/04/1448206";>Newsforge</a>, 4 Dez, 2003 <li><a href="http://newsvac.newsforge.com/article.pl?sid=03/12/05/1635231";>Newsforge</a>, 5 Dez, 2003 <li><a href="http://www.osnews.com/comment.php?news_id=5362";>OSnews</a>, 10 Dez, 2003 <li><a href="http://news.com.com/2100-7344-5117271.html";>Cnet</a>, 10 Dez, 2003 <li><a href="http://newsvac.newsforge.com/article.pl?sid=03/12/30/1435210";>Newsforge</a>, 30 Dez, 2003 </ul> <h3>Informações de Contato</h3> <p>Para mais informações, visite as <a href="$(HOME)/">páginas web</a> do Debian ou envie uma mensagem para <email [EMAIL PROTECTED] />.</p>
