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:

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.

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:

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

Repostas de Imprensa

Informações de Contato

Para mais informações, visite as páginas web do Debian ou envie uma mensagem para press@debian.org.