Informe Ejecutivo PDF

Reto de Análisis Forense
INFORME EJECUTIVO
31 de diciembre de 2003
La misión de este documento es comentar brevemente los motivos por los cuales se ha pro-
ducido la intrusión en el sistema objeto del reto y el tipo de análisis realizado. Finalmente
se darán unas recomendaciones breves sobre las normas de actuación recomendables para
evitar este tipo de incidentes.
1. Introducción
El sistema propuesto para la realización del presente reto de análisis forense es un sistema
RedHat Linux, versión 7.1, con núcleo Linux, versión 2.4.2-2. La información aportada para la
resolución del reto por parte de los organizadores del mismo está compuesta por las imágenes
binarias (o crudas, como se dice en el argot técnico) de cada una de las particiones de disco que
el sistema estaba utilizando bajo formato ext2. También se ha aportado la imagen cruda de la
partición de swap del sistema operativo.
El sistema objeto del reto, que en adelante llamaremos ”redhat71”, fue instalado el día 21
de Agosto de 2002 con una versión estándar de la distribución RedHat Linux 7.1, hasta donde
hemos podido comprobar. La instalación se realizó a través de la red, utilizando el servidor ftp
de rediris (ftp.rediris.es). La fecha exacta de comienzo de la instalación es el 21 de agosto
de 2002 19:01:35 (fecha estándar del sistema en zona horaria CET, correspondiente a Madrid,
como el resto de las fechas mientras no se indique expresamente lo contrario), mientras que la
finalización de la instalación, configuración y puesta en funcionamiento del servidor se realiza
a las 20:57:13 del mismo día. Todas las fechas relacionadas o relativas al incidente son del año
2002, por lo que en adelante se obviará por razones de brevedad.
2. Inicio del incidente

El sistema redhat71 fue atacado con éxito entre las 00:21:04 y las 00:22:47 de la madrugada
del día 23 de Agosto desde la dirección 200.47.186.114, presumiblemente aprovechando una
1
vulnerabilidad del servidor ftp. Sin embargo, el sistema instalado no sólo era vulnerable a través
de su servidor wu-ftpd (RHSA-2001:157-06), sino también por su servidor openssh (RHSA-
2001:154-06), glibc (RHSA-2001:160-09, RHSA-2002:056-05), núcleo (RHSA-2002:007-16/
17/28), zlib (RHSA-2002:026-35/39/49), y nss_ldap (RHSA-2002:084-17/22).
Las fechas y la dirección ip del atacante se pueden inferir de la información recabada en los
logs del sistema, que -tal como hemos podido observar mediante el análisis técnico- no ha sido
modificada más que burda y parcialmente por el atacante.
Tampoco hemos considerado realizar mayor invesigación sobre la dirección ip del atacante,
dado que al haber pasado más de un año (confiando en que las fechas del sistema sean correctas)
desde el incidente, mucha de la información sería errónea, obsoleta o falta de interés.
Aún así, hemos podido comprobar que la dirección ip del atacante parece pertenecer en
la actualidad (Diciembre de 2003) al dominio comsat-internacional.net, hospedado por
el operador Pair Networks (www.pair.com), con sede en el 2403 de Sydney Street, Pittsburg,
Pennsylvania, Estados Unidos. Así mismo, la dirección ip del atacante está en el rango asignado
para la organización ”Latin American and Caribbean IP address Regional Registry” (LACNIC),
que a su vez la ha asignado a la empresa COMSAT Perú S.A., con dirección en la calle Martir
Olaya 129, Miraflores, Lima, Perú.
El atacante, al conseguir romper el sistema, utiliza un rootkit ligeramente elaborado que
se encarga de avisar al atacante por correo y realizar unas modificaciones en el sistema que
permitirán, entre otras cosas, que las tareas lanzadas por el atacante en el servidor, pasen lo más
desapercibidas posible para los usuarios y administradores de redhat71. El atacante, no destruye
datos del sistema, aunque sí realiza ciertas tareas poco depuradas de scaneo del host, así como
de usuarios y claves del sistema (mediante un script llamado sysinfo).
Los detalles del script de instalación del rootkit se darán en el informe técnico. Baste co-
mentar en este informe que entre las diversas tareas que realiza el atacante a través del rootkit
que instala en el sistema redhat71, están las siguientes:
Recopilación básica de datos del sistema
Recopilación de usuarios y claves
Búsqueda de películas, imágenes y paquetes
Búsqueda de información de posibles tarjetas de crédito
Modificación de ejecutables para ocultación de tareas ilícitas
Detención de los sistemas de registro automático de eventos
Búsqueda de indicios de que el host haya sido previamente atacado
Securización básica del sistema para evitar que sea atacado nuevamente
Envío por correo electrónico de la información recabada
Creación de una puerta trasera para la entrada al sistema a través de un puerto TCP es-
pecífico
El atacante utiliza el rootkit y la puerta trasera para poner en marcha los siguientes servidores:
proxy IRC, para la anonimización de las conexiones IRC (psybnc, emech).
sniffer de red, para recabar usuarios y passwords que circulen en claro por la red (linsnif-
fer).
scanner de servidores ftp, para detectar otros sistemas vulnerables, atacarlos y obtener
nuevas máquinas bajo su control (aw).
3. Congelación del incidente

El administrador del sistema, hace login en el mismo el día 23 de Agosto, a las 12:33:18.
Lo primero que hace es realizar una consulta del fichero de claves (/etc/shadow) y al comprobar
que su servidor ha sido atacado (ve que hay dos nuevos usuarios: ssh y nerod, uno de ellos sin
clave de acceso) realiza mediante la herramienta netcat una copia de los sistemas de ficheros a
un servidor remoto de su misma red (a esta técnica se le suele llamar ”congelar” el sistema de
ficheros), en concreto a la máquina 192.168.3.14.
Mientras la copia se estaba realizando, el administrador realizó una revisión de la intrusión,
así como de las tareas lanzadas en el ataque, por lo que algunos archivos se han visto modifica-
dos en esa fecha.
La tarea de guardar los datos a través de la red tardó aproximadamente 3 horas (a unos 8
Mbps, desde las 12:40 de la mañana hasta las 15:36 de la tarde), después de lo cual el admi-
nistrador apagó la máquina de manera brusca con el fin de evitar la posible pérdida de datos al
realizar el apagado ordenado del servidor GNU/Linux.
La detección del ataque y la actuación inmediata por parte del administrador, así como la
ausencia total de datos de usuario en redhat71, entre otros factores, indican que probablemente
el servidor era un honeypot.
4. Análisis
El análisis realizado se ha basado en las evidencias dejadas en los diferentes sistemas de
ficheros de redhat71, así como en los contenidos de la partición de swap. No ha sido necesario
”revivir” el sistema en algún simulador de plataforma Intel (tipo VMware) para ver el compor-
tamiento del mismo, dado que con los datos recabados es más que suficiente para identificar la
problemática y los detalles que no se han podido esclarecer no saldrían a la luz al realizar una
simulación.
Para la ordenación de los datos y la recuperación de los archivos, así como para la búsqueda
de cadenas de texto se han utilizado diversas herramientas de análisis forense, la más importante
de las cuales es el frontend gráfico Autopsy versión 1.75, para el Sleuthkit versión 1.66.
También se han utilizado herramientas de GNU/Linux como strings, find, locate, awk, grep,
sed, sort, gdb y date, así como el RedHat Package Manager (rpm).
5. Recomendaciones
Parece que el ataque ha sido propiciado por varias circunstancias que deberían ser evitadas si
se desean realizar instalaciones seguras de servidores de red. En concreto y de forma resumida,
se puede decir que se realizó la instalación de un sistema GNU/Linux totalmente estándar y
obsoleto para la fecha de instalación, sin aplicar los parches disponibles (en Agosto de 2002
ya había salido la versión 7.3 de la distribución de RedHat GNU/Linux, así como la versión
2.6.1-20 del servidor wu-ftpd instalado y había actualizaciones para todos los paquetes software
sensibles a ataques).
Tampoco se utilizaron reglas de filtrado de paquetes para evitar que los servicios ofrecidos
alcanzasen más allá de las redes a las que se pretendía dar servicio. Esta técnica suele ser muy
efectiva para restringir los servicios de red a entornos de confianza.
En adelante, para evitar este tipo de sucesos, parece conveniente realizar una instalación
rápida de los parches de seguridad provistos por el fabricante o distribuidor del software, así
como dar formación a los administradores de sistemas para que puedan actuar de forma in-
mediata ante posibles vulnerabilidades y ataques. Así, entre muchas otras, se pueden mencionar
las siguientes fuentes de información:
Practical Unix & Internet Security, de Spafford y Garfinkel, publicado por O’Reilly.
www.cert.org,el sitio web del Equipo de Respuesta de Emergencias en Ordenadores

(CERT), que pone a disposición del público información relativa a las vulnerabilidades,
actividades y medidas preventivas en la gestión de este tipo de incidentes.
www.securityfocus.com, que dispone de amplia información sobre los desarrollos re-

cientes en el entorno de la seguridad informática.
www.honeynet.org, que provee de información sobre el proyecto Honeynet, centrado

en el análisis de seguridad de los sistemas y en las técnicas de ataque y análisis forense
disponibles.
his.sourceforge.net, homólogo en español del proyecto Honeynet.

Informe Ejecutivo PDF

Cargado por

Copyright:

Formatos disponibles

Informe Ejecutivo PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe Ejecutivo PDF

Cargado por

Copyright:

Formatos disponibles

Reto de Análisis Forense

2. Inicio del incidente

Recopilación básica de datos del sistema

Recopilación de usuarios y claves

Búsqueda de películas, imágenes y paquetes

Búsqueda de información de posibles tarjetas de crédito

Modificación de ejecutables para ocultación de tareas ilícitas

Detención de los sistemas de registro automático de eventos

Búsqueda de indicios de que el host haya sido previamente atacado

proxy IRC, para la anonimización de las conexiones IRC (psybnc, emech).

3. Congelación del incidente

www.cert.org,el sitio web del Equipo de Respuesta de Emergencias en Ordenadores

www.securityfocus.com, que dispone de amplia información sobre los desarrollos re-

www.honeynet.org, que provee de información sobre el proyecto Honeynet, centrado

his.sourceforge.net, homólogo en español del proyecto Honeynet.

También podría gustarte