1988 – The Internet “Worm”
Muitos já me questionaram qual a fonte de motivação que me inspirou para me aprofundar no assunto de segurança de redes.
Eu sei que desde que vi um computador pela primeira vez que fiquei super intrigado em saber como operá-lo, como a maioria de vocês. Agora foi numa palestra sobre segurança de redes, ministradas na faculdade onde estudei, a UFPE, que tive a convicção que a área de segurança de redes era apenas o início dos meus objetivos finais.
O artigo que irei apresentar agora resume o que assisti daquela palestra bem como outras fontes de informações que coletei para completar as lacunas em aberto que foram deixadas na palestra. Espero que sirva de motivação para alguém assim como serviu para mim.
Novembro de 1988 – O Início
Aos 34 minutos do dia 3 de Novembro de 1988, uma mensagem intrigante e aparentemente sem sentido é lida pelos usuários de um grupo de discussão na Internet:
“Parece que há um vírus à solta na Internet”
Andy Sudduth (MIT)
O Internet Worm
Ø Código gerado por Robert Tappan Morris, estudante na Univ. Comell /NY
Ø A Rotina principal consistia de menos de 100 linhas de códigos escritos em linguagem C
Ø Atingiu quase 6.000 computadores da rede, só nos EUA, causando: Infecção, sobrecarga e incapacitação
Ø Levantou uma questão básica: as redes são vulneráveis!
O Internet Worm – Método de Ataque I
Sendmail
– O Worm abre uma conexão TCP com outro host com serviço sendmail ativado (SMTP)
– Invoca o modo debug e emite um comando RCPT TO
– Envia uma solicitação que seus dados sejam canalizados através de um shell
– Os dados (um shell script), cria um arquivo x$$,l1.c ($$ é o identificador do processo criador)
– Este programa possui apenas 40 linhas codificadas em C
– O Shell compila o código C e o executa com alguns parâmetros identificando a máquina de origem
– Identifica o S.O. do host atacado e obtém um programa chamado x$$,vax.o ou x$$,sun3.o do host fonte, efetuando um link com a biblioteca correspondente
– Gera um arquivo chamado /usr/tmp/sh (aspecto do Bourne Shell)
O Internet
Worm – Método de Ataque II
Firgerd
– O Cliente finger envia para o servidor finger da máquina atacada um parâmetro que consiste de uma string com 536 bytes.
– O Tamanho da string enviada pelo cliente extrapolava o tamanho do buffer do servidor finger, sobrepondo dados gravados na sua pilha
– O bug consistia na falha do daemon fingerd em tratar corretamente a condição de overflow do buffer
– Quando o daemon
retornava da procedore que recebia a solicitação do cliente, não retornava para
a rotina principal (main), mas para a procedore dentro da string de 536 bytes na
pilha
– A procedure da pilha tentava executar o /bin/sh
O Internet
Worm – Método de Ataque III
rsh / rexec
– Obtém informações do .rhosts e /etc/hosts.equiv para futuras migrações
– Para usar o .rhosts seria necessário obter contas de usuários, já que o worm não está sendo executado como root (e sim como um deamon). O Worm tenta então quebrar senhas de usuários
– Lê o /etc/passwd e tenta então combinar senhas como username, primeiro nome, último nome, último+primeiro e apelidos
– Tenta também a partir de senhas consideradas “populares” tais como: aaa, guntis, noxious, simon, academia, hacker, simples, 1234, 1111, senha, senha00, etc
– Se as tentativas falharem, faz outra tentativa pelo dicionário /usr/dic/words
– Obtendo uma senha, busca o r.hosts e executa “rsh” e/ou “rexec” para outro host e busca os arquivos que necessita, executando o /usr/tmp/sh, iniciando assim novamente o ciclo
Código Principal do Worm
#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <sys/resource.h>
long currente_time;
struct rlimit no_core = (0,0);
int
main (argc, argv)
int
argc;
char *argv[];
{
int n;
int parent = 0;
int okay = 0;
/*
change calling name to “sh” */
strcopy(argv[0], “sh”);
/*
prevent core files by setting limit to 0 */
setrlimit(RLIMIT_CORE, no_core);
current_time = time(0);
/*
seed random number generator with time */
srand48(current_time);
n = 1;
while (argv[n]) {
/*save process id of parent */
if
(!strcmp(argv[n], “-p”, 2)) {
parent = atoi (argv[++n]);
n++;
}
else {
/* check for 1l.c in argument list */
if (!strcmp(argv[n], “1l.c”, 4)) okay = 1;
/* load an object file into memory */
load_object (argv[n]);
/* clean up by unlinking file */
if (parent) unlink (argv[n]);
/* and removing object file name */
strcpy (argv[n++], “”);
}
}
/* if 1l.c was
not in argument list, quit */
if (!okay) exit
(0);
/* reset process
group */
setpgrp (getpid());
/* kill parent
shell if parent is set */
if (parent) kill
(parent, SIGHUP);
/* scan for
network interfaces */
if_init();
/* collect list
of gateways from netstat */
rt_init();
/* start main
loop */
doit();
}
int
doint()
{
current_time =
time (0);
/* seed random
number generator (again) */
srand48(current_time);
/* attack
gateways, local nets, remote nets */
attack_hosts();
/* check for a
“listing” worm */
check_other ();
/* attemp to send
byte to “emie” */
send_message ();
for (;;)
{
/* crack some passwords */
crack_some ();
/*
sleep or listen for other worms */
other_sleep (30); crack_some();
/*
switch process id’s */
if
(fork()) exit (0);
/*
attack gateways, known hosts */
attack_hosts(); other_sleep(120);
/*
if 12 hours have passed, reset hosts */
if
(time (0) == current_time + (3600*12)) {
reset_hosts();
current_time = time(o); }
/*
quit if pleasequit is set, and nextw > 10 */
if
(pleasequit && nextw > 10) exit(0);
}
}
Resumo Cronológico do Worm
|
Data |
Acontecimento |
|
02/11 18:00h |
Morris dispara o worm a partir do host prep.ai.mit.edu, um VAX 11/750, no Laboratório de Inteligência Artificial do MIT |
|
02/11 18:24h |
Primeira infecção conhecida na costa oeste: o host rand.info da RAND Corp em Santa Monica/CA |
|
02/11 19:04h |
O host csgw.berkeley.edu (UC Berkeley) é infectado. Mike Karels e Phil Lapsey (administradores Unix) logo descobrem a infecção |
|
02/11 19:54h |
O host do Dept. de Comp. da Univ. de Maryland mimsy.umd.edu é infectado através do servidor fingerd |
|
02/11 20:00h |
O Cluster de servidores Sun no MIT AI Lab são infectados |
|
02/11 20:28h |
Primeiro ataque via sendmail a partir do mimsy |
|
02/11 20:40h |
Administradores de Berkeley descobrem como os ataques via sendmail e rsh ocorrem, encontrados os bugs do telnet e do finger. Desativados serviços |
|
02/11 20:49h |
O host cs.utah.edu (VAX 8600) é infectado. O ataque a este host provoca outros ataques a muitos outros hosts importantes espalhados pelo país |
|
02/11 21:09h |
Primeiro ataque via sendmail a partir de cs.utah.edu |
|
02/11 21:34h |
A carga média de CPU no cs.utah.edu alcança 5.0. |
|
02/11 21:41h |
A carga de CPU no cs.utah.edu alcança 7.0 |
|
02/11 22:01h |
A carga de CPU no cs.utah.edu alcança 16.0 |
|
02/11 22:06h |
O número máximo de processos permitidos em cs.utah.edu é alcançado. O sistema está inutilizável |
|
02/11 22:20h |
Jeff Forys em Utah “mata” todos os worms no cs.utah.edu. Outros servidores Sun em Utah já estão infectados |
|
02/11 22:41h |
Nova infecção em cs.utah.edu faz a carga alcançar 27.0. Forys efetua shutdown |
|
02/11 23:21h |
Nova infecção em cs.utah.edu faz a carga alcançar 38.0, a despeito dos esforços de Forys para “matar” os processos worms |
|
02/11 23:28h |
Peter Yee no NASA Ames Reseach Center libera mensagem na Usenet: “Estamos sob ataque de um vírus Internet. Já infectou UC Berkeley, UC San Diego, Lawrence Livermore, Stanford e NASA Ames”. Ele sugere desativar os serviços telnet, finger, ftp, rsh e SMTP, mas não menciona o rexec. |
|
03/11 00:34h |
Andy Sudduth em Harvard posta um aviso anônimo na Usenet: “Parece que há um vírus à solta na Internet”. Esta é a primeira mensagem que descreve como funciona o ataque via finger, descreve como anular o ataque via SMTP e explicitamente menciona o ataque via rexec. Sudduth assuma a autoria desta mensagem numa outra mensagem postada dois dias depois |
|
03/11 02:54h |
Keith Bostic envia uma atualização do sendmail pela rede para vários administradores conhecidos na Internet, solicitando divulgação imediata |
|
03/11 09:00h |
A conferência anual Berkeley Unix Workshop é esvaziada pois os inscritos (admins. de sistemas Unix de todo o país) estão em pânico, tentando controlar o ataque do worm |
|
03/11 16:26h |
Dave Parre obtem um código do worm por desassembly. No MIT outro grupo trabalha com o mesmo intuito e trocam informações |
|
04/11 04:00h |
Keith Bostic libera atualização do servidor finger |
|
04/11 12:36h |
O MIT e Berkeley anunciam terem efetuado disassembly completo do worm |
|
04/11 17:00h |
Uma apresentação do worm é feita na conferência de Berkeley |
|
08/11 09:00h |
O National Computer Security Center reúne-se para discutis o worm |
|
11/11 00:38h |
O código fonte completo, totalmente decompilado e comentado é instalado em Berkeley |
Lições do Worm
§ Os Sistemas Operacionais são vulneráveis e possuem “bugs”
§ Numa rede um ataque pode ser devastador
§ Paradigmas : redes homogêneas versus redes heterogêneas
§ Necessidade da criação dos “Response Teams”
§ Importância da auditoria
§ Segurança deve ser criada e mantida como necessidade
The End
§ Morris foi pego quando Sudduth entrou em contato com Jonh Markoff, jornalista do NY Times, tentando convencê-lo de que o Worm era inofensivo, tudo foi um acidente, e o autor pedia desculpas. Sudduth deixou escapar que o login name do autor era rtm.
§ No outro dia a história estava na primeira página do NY Times, apesar da eleição presidencial que iria acontecer 3 dias depois
§ Morris foi julgado e condenado a uma multa de dez mil dólares, 3 anos de condicional e 400 horas de trabalho comunitário. As custas legais excederam cento e cinquenta mil dólares
Para refletir....
“Este artigo descreve como o design do protocolo TCP/IP e a implementação do 4.2BSD Unix permitem um usuário em um host distante e não credenciado, mascarar-se como um usuário legítimo em um host credenciado.”
Robert T. Morris (o próprio)
“A Weakness in the 4.2BSD Unix TCP/IP Software”
AT&T Bell Labs Technical Reports, 1985
“Existe uma fronteira muito tênue entre ajudar administradores a protegerem seus sistemas e prover um livro de receitas para pessoas sem escrúpulos. ”
Robert H. Morris (o pai)
“Unix Operating System Security”
AT&T Bell Labs Techical Journal, 1984
Para dúvidas, críticas ou sugestões, mande um e-mail para o autor da coluna: