[wml] portuguese/News/2003/20031202.wml
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)
<gpastore@colband.com.br>
#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 press@debian.org />.</p>
Reply to: