Relatório de Investigação do Debian após o comprometimento de servidores
2 de Dezembro de 2003
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.
Os repositórios de pacotes não foram alterados pelo intruso
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.
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.
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:
- listas de somas MD5 armazenadas externamente acumuladas nas últimas semanas em computadores que não foram comprometidos
- arquivos .changes assinados digitalmente de arquivos debian-devel-changes externos em computadores que não foram comprometidos
- arquivos .changes assinados nos servidores de arquivos respectivos
- arquivos de log de espelhos armazendos externamente
Linha do Tempo
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.
- 28 Set 01:33 Linus Torvalds lança o 2.6.0-test6 com a correção do_brk()
- 02 Out 05:18 Marcelo Tosatti aplica testes de limite ao do_brk()
- 19 Nov 17:00 Atacante entra no klecker com uma senha obtida por 'sniff'
- 19 Nov 17:08 Root-kit instalado no klecker
- 19 Nov 17:20 Atacante entra no master com a mesma senha obtida por 'sniff'
- 19 Nov 17:47 Root-kit instalado no master
- 19 Nov 18:30 Atacante entra no murphy com conta de serviços do master
- 19 Nov 18:35 Root-kit instalado no murphy
- 19 Nov 19:25 Oopses no murphy começam
- 20 Nov 05:38 Oopses no master começam
- 20 Nov 20:00 Descoberta dos Oopses no master e no murphy
- 20 Nov 20:54 Root-kit instalado no gluck
- 20 Nov 22:00 Confirmação que o debian.org foi comprometido
- 21 Nov 00:00 Desativação de todas as contas
- 21 Nov 00:34 security.debian.org desligado
- 21 Nov 04:00 gluck desligado (www, cvs, people, ddtp)
- 21 Nov 08:30 www.debian.org apontado para www.de.debian.org
- 21 Nov 10:45 Anúncio público
- 21 Nov 16:47 Informações para desenvolvedores atualizada
- 21 Nov 17:10 murphy (lists) e master desligados
- 22 Nov 02:41 security.debian.org de volta online
- 25 Nov 07:40 lists.debian.org de volta online
- 28 Nov 22:39 Linux 2.4.23 lançado
Descoberta
Na madrugada (GMT) de quinta-feira, 20 de novembro, a equipe de administração notou vários oopses do kernel no master. Uma vez que o sistema estvera rodando sem problemas por um longo tempo, a máquina estava próxima de ser levada para manutenção e 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.
Além disso, klecker, murphy e gluck tem o "Advanced Intrusion Detection
Environment" (Ambiente Avançado de Detecção de Intrusão, pacote aide) instalado para monitorar
alterações no sistema de arquivos e começaram a alertar que, aproximadamente
na mesma hora, /sbin/init
havia sido substituído e que
os valores mtime e ctime do /usr/lib/locale/en_US
tinham
mudado.
Investigações posteriores revelaram que a causa de ambos os problemas era o root-kit SucKIT (1.3b). Ele inclue 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.
Análise Detalhada do Ataque
Na quarta-feira, 19 de novembro, aproximadamente as 5pm, uma senha obtida por sniff foi usada para entrar em uma conta de desenvolvedor não-privilegiada no klecker (.debian.org). O atacante pegou então o código-fonte via HTTP para um exploit local desconhecido (naquele momento), através do qual ganhou permissões de root. Finalmente, o SucKIT foi instalado.
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.
Então, o atacante tentou obter acesso ao murpy com a mesma conta. Isto falhou, já que o murphy é um computador restrito, e seu único propósito é agir como servidor de lista, 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 no master para acessar uma conta administrativa que era usada para propósitos de backup e ganhou acesso ao murphy também. O root-kit SucKIT também foi instalado neste computador.
No dia seguinte, o atacante usou uma senha obtida por sniff no master para entrar no gluck, obteve root lá e instalou o root-kit SucKIT.
A análise revelou as datas e horas exatas nas quais o programa
/sbin/init
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 ofuscado
com Burneye. Após o desencapsulamento e desassembling do exploit,
especialistas em segurança descobriram qual bug do kernel foi utilizado.
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.
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 DSA 403.
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 espaços diferentes de endereços nessas arquiteturas.
Por favor, entenda que nós não podemos dar o exploit utilizado para pessoas que nós não conhecemos. Portanto, não nos pergunte sobre ele.
Recuperação
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) e seus serviços foram reinstalados, um por um, após investigação pelos seus administradores.
No klecker, no entanto, isso foi adiado para 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 do 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 uma conexão de rede protegida por firewall, o root-kit foi removido, o kernel trocado e "endurecido", binários foram duplamente checados e o repositório de segurança foi verificado contra várias fontes externas diferentes. Este computador será reinstalado nas próximas semanas.
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. Isto, no entanto, efetivamente desabilitou praticamente qualquer trabalho público Debian que envolvesse o upload de arquivos e acesso aos repositórios CVS.
Todas as senhas usadas no 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 receber uma senha nova.
Quando todos os serviços estiverem rodando novamente e os computadores estiverem suficientemente seguros, o LDAP será resetado para que os desenvolvedores possam criar uma senha nova. No entanto, não é possível prever quando isso irá acontecer.
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 aqui.
Conseqüências
Renove suas senhas!
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.
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.
Se uma chave SSH foi gerada ou armazenada em um destes computadores e
usada para entrar em outros comptadores (instalando-a em
.ssh/authorized_keys
), ela também deve ser removida.
As chaves secretas GnuPG/PGP que estavam em computadores debian.org também foram removidas dos chaveiros do Debian e, portanto, desativadas.
Desenvolvedores que estão preocupados com seus computadores devem ao menos rodar o chkrootkit e observar sua saída. Matt Taggart mantem um backporte da versão atual para woody no seguninte endereço:
- deb http://lackof.org/taggart/debian woody/chkrootkit main
- deb-src http://lackof.org/taggart/debian woody/chkrootkit main
Adicionalmente, uma lista detalhada de precauções foi feita por Wichert Akkerman e Matt Taggart.
Root-Kit SucKIT
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 carregáveis do kernel. 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.
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 /sbin/init
são
redirecionadas para o init original.
Proteção Burneye do TESO
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.
Agradecimentos
- James Troup e Ryan Murray por seu trabalho geral em todos os servidores
- Adam Heath e Brian Wolfe por seu trabalho no master e no murphy
- Wichert Akkerman por seu trabalho no klecker
- Dann Frazier e Matt Taggart por seu trabalho no gluck
- Michael Stone e Robert van der Meulen por seu trabalho de análise
- Marcus Meissner por fazer o desassembling do exploit usado
- Jaakko Niemi por seu trabalho na checagem e reabilitação do lists.debian.org
- Colin Watson por seu trabalho na checagem e reabilitação do bugs.debian.org
- Josip Rodin por seu trabalho na checagem e reabilitação dos arquivos web das listas
Repostas de Imprensa
- Slashdot, 21 Nov, 2003
- eWeek, 21 Nov, 2003
- InternetNews, 21 Nov, 2003
- Heise Newsticker, 21 Nov, 2003 (Alemão)
- Pro-Linux, 21 Nov, 2003 (Alemão)
- Linux-Community, 21 Nov, 2003 (Alemão)
- BarraPunti, 21 Nov, 2003 (Espanhol)
- Newsforge, 21 Nov, 2003
- SearchEnterpriseLinux.com, 22 Nov, 2003
- Debian Planet, 22 Nov, 2003
- PC World, 24 Nov, 2003
- ZDNet UK, 24 Nov, 2003
- Enterprise Linux IT, 24 Nov, 2003
- The Age, 24 Nov, 2003
- Sydney Morning Herald, 24 Nov, 2003
- Windows & .NET Magazine, 24 Nov, 2003
- Infoworld, 24 Nov, 2003
- Linux Insider, 24 Nov, 2003
- eCommerce Times, 24 Nov, 2003
- TechNewsWorld, 24 Nov, 2003
- The Register, 28 Nov, 2003
- Newsforge, 28 Nov, 2003
- Slashdot, 28 Nov, 2003
- Slashdot, 1 Dez, 2003
- The Age, 1 Dez, 2003
- Sydney Morning Herald, 1 Dez, 2003
- Pro-Linux, 2 Dez, 2003 (Alemão)
- Heise Newsticker, 2 Dez, 2003 (Alemão)
- Golem, 2 Dez, 2003 (Alemão)
- LWN, 2 Dez, 2003
- The Register, 2 Dez, 2003
- ZDnet DE, 2 Dez, 2003 (Alemão)
- Linux-Community, 2 Dez, 2003 (Alemão)
- Heise, 2 Dez, 2003 (Alemão)
- Heise Newsticker, 2 Dez, 2003 (Alemão)
- Symlink, 2 Dez, 2003
- Pro-Linux, 3 Dez, 2003 (Alemão)
- Heise Newsticker, 4 Dez, 2003 (Alemão)
- Symlink, 4 Dez, 2003 (Alemão)
- Symlink, 4 Dez, 2003
- Newsforge, 4 Dez, 2003
- Newsforge, 5 Dez, 2003
- OSnews, 10 Dez, 2003
- Cnet, 10 Dez, 2003
- Newsforge, 30 Dez, 2003
Informações de Contato
Para mais informações, visite as páginas web do Debian ou envie uma mensagem para press@debian.org.