Informe Reto Forense v.2.0. Resumen técnico

Informe Reto Forense v.2.0. Resumen ejecutivo.
1. Introducción
Este documento pretende dar respuesta a las preguntas más importantes que se realizan sobre las
imágenes que los organizadores del Reto Forense 2.0 ponen a disposición de los participantes. Todas
las fechas dadas en el presente documento se encuentran en el horario local de la máquina, ya que no
se puede confirmar su sincronización con ningún medio externo.
2. Resultados del análisis
El análisis de las imágenes confirma que la máquina ha sido comprometida al menos en dos
ocasiones en el periodo de tiempo comprendido entre las 14.57 horas del 29 de enero y la
desconexión de la máquina el día 31 de enero.
La primera intrusión, de la cual tenemos más detalles, tiene la duración máxima que hemos detallado,
mientras que la segunda se simultanea con esta durante un periodo menor. Ambas logran obtener
privilegios administrativos en la máquina y descargar y ejecutar herramientas que ambos intrusos
intentaron usar en beneficio propio.
Del primer intruso se conoce que proviene de la IP: 64.202.43.190, perteneciente a asiahotels.net y
que probablemente se halle comprometido. Respecto a su modus operandi podemos decir que posee
al menos un par de "almacenes" de herramientas (de cracking) en dos dominios rumanos
(http://www.plus.factory.home.ro/ y http://www.zetu.as.ro/) y que su nivel de conocimiento del
sistema es mínimo (sería lo que se viene a llamar un script-kidie).
Del segundo intruso podemos aportar la dirección de su almacén particular: http://xhack.150m.com/
(se trata de un hosting gratuito) y la sensación de un mayor grado de conocimiento, ya que al menos
uno de los binarios tiene su firma, lo que confirmaría que ha sido al menos compilado por él.
A partir de toda la información recuperada de las imágenes se puede crear una línea temporal de
hechos que detallamos a continuación.
2.1 Resumen temporal de actividades no autorizadas
29 de enero, 14:57:44:
Se recibe el primer impacto desde la IP 64.202.43.190 por parte de una herramienta automatizada que
se encarga de detectar servidores Apache usando versiones antiguas de OpenSSL.
29 de enero, 15:10:49:
El primer intruso haciendo uso de la misma herramienta obtiene acceso no autorizado con las
credenciales del usuario "apache", grupo "apache" a una shell del sistema. Procede a descargar y ejecutar
varias utilidades con la intención de mantener acceso a la línea de comandos abierta y elevar sus
privilegios para tener control total. Entre los ejecutables que descarga se encuentra el "zbind" que pone el
puerto 4000 a la escucha y asocia un interprete de comandos al mismo. Una vez conectado a esta puerta
trasera descarga también un exploit de elevación de privilegios basado en una vulnerabilidad del núcleo
(PTRACE) a la que el sistema es vulnerable.
29 de enero, 15:17:
Ya con privilegios de administrador, procede a añadir el usuario "weed" al sistema con el que acceder
remotamente mediante SSH (secure shell). Tras esto decide hacer uso de un rootkit con el que eliminar
huellas y tener igualmente acceso seguro (SSH) sin mostrar rastros en el sistema. El nombre que da el
autor a su script es "CyComm Lamm3rz Rootkit For all versions of linux". No obstante la inestabilidad
que ha producido la explotación de la librería OpenSSL evita que el backdoor SSH llegue a instalarse, en
cambio, varios binarios importantes del sistema han sido sobrescritos, los registros (logs) han sido
eliminados y ha el syslog ha sido detenido.
29 de enero, 15:21:50:
Reintenta la instalación del rootkit anteriormente nombrado sin éxito. Tampoco consigue acceder
adecuadamente por ssh estándar con su usuario "weed" así que decide eliminarlo.
29 de enero, 15:22:
Simultáneamente a las acciones que nuestro atacante principal realiza se recoge una traza de
actividad que presenta rasgos de deberse a un individuo diferente al que estamos tratando hasta ahora.
Sus acciones parecen puntuales y su vector de entrada es distinto del utilizado por el otro, la aparición
de sus huellas en el historial de acciones del administrador y la confirmación de las descargas en la imagen
del disco duro nos llevan a pensar que ha debido usar una vulnerabilidad en OpenSSH (prioritariamente,
aunque podría también haber explotado alguno de los restantes servicios que igualmente usaban versiones
sin parchear). Ha accedido a la cuenta de administración he intentado infructuosamente instalar un kernel
rootkit (en memoria) y activar un bouncer de IRC.
29 de enero, 15:25:
Volvemos al primer atacante, que descarga un nuevo backdoor, en este caso se trata de una
herramienta que a la vez que cuelga un interprete del puerto 5608 (silenciosamente) envía un correo
electrónico con los datos del sistema a radautiteam@yahoo.com, cuenta que puede no pertenecer al
atacante ya que probablemente él haya recibido este exploit de otra persona.
29 de enero, 15:27:
Destruye la puerta trasera (zbind) por la que había entrado y desconecta.
29 de enero, 15:36 - 17:53:
Entra de nuevo y descarga sus herramientas en el sistema con la intención de buscar equipos
vulnerables a problemas en el servidor samba, al no encontrar equipos en la clase B intenta fallidamente
activar un bouncer de IRC.
30 de enero, 04:10 - 05:36:
Se entretiene intentando explotar de nuevo desde la misma IP la vulnerabilidad de OpenSSL con la
que consiguió acceso. Es probable que pensara que se encontraba ante una máquina nueva.
31 de enero, 11:35:
Esta vez descarga y ejecuta el escaner que busca servidores Apache con mod_ssl vulnerables al
mismo problema con el que entró en este equipo y con el que probablemente también accedió al sistema
desde el que realizó el ataque.
3. Motivos de la intrusión
En ambas ocasiones los intrusos intentaron activar sobre la máquina bouncers de IRC (programas que
permiten conectarse anónimamente a los servidores de IRC y mantener las conexiones indefinidamente).
Ambos atacantes intentaron tener y mantener el control total de la máquina, el primero lo consiguió.
Con las pruebas obtenidas puede determinarse que el motivo último de la intrusiones era el de tener
una máquina más a sus ordenes (zombies) con las que realizar cualquier tipo de actividades delictivas,
vease guerras de IRC, ataques DoS, servidores de phishing, etc.
4. Recomendaciones
Es necesario tener las máquinas actualizadas y parcheadas, la máquina debe tener instalado un
firewall a medida y que sea lo mas restrictivo posible. Respecto al administrador del sistema, debe
comprobar al menos diariamente los logs del sistema y realizar backups de la información de cara a un
posible desastre.
Tal como hemos visto un solo servicio de nuestra máquina que no esté actualizado puede permitir la
entrada a sujetos con pocos conocimientos pero con medios, estos le permiten tomar el control del sistema
donde no solo entran si no que intentando obtener la máxima cantidad de permisos destrozan el sistema
instalando todo tipo ejecutables. De hecho podemos comprobar en este caso que al pisar los binarios más
importantes del sistema la máquina ya no consigue volver a iniciar.
Como recomendación final esta máquina no debería ser usada sin antes formatear el disco duro e
instalar una distribución más actual.
En el caso de los honeypots es recomendable poner a cero el disco duro antes de realizar la
instalación, esto tiene varias ventajas de cara a un posterior análisis. Entre otras cosas permitirá al forense
no tener datos de anteriores sistemas operativos contenidos en el disco (en este caso en concreto se
descubrió al menos un linux y un windows que fueron instalados en el pasado), y de cara a la transmisión
de las imágenes la carencia de esos datos permitirá obtener mayores ratios de compresión.
11 de marzo de 2005.
Francisco Santos.