Informe de la investigación tras los compromisos de los servidores de Debian

2 de diciembre de 2003

El equipo de administración y los expertos de seguridad de Debian pueden finalmente precisar el método usado para entrar ilegalmente en cuatro máquinas del proyecto. Sin embargo, aún no se ha descubierto el responsable de la intrusión

El intruso no alteró los paquetes de los archivos.

Los equipos de seguridad y de administración de Debian comprobaron estos archivos (security, us, non-us) en primer lugar y luego continuaron con la investigación y el proceso de reinstalación. Éste es el motivo por el que el proyecto ha podido volver a abrir el archivo de seguridad de nuevo y confirmar que la actualización estable (3.0r2) no estaba comprometida.

Si el proyecto hubiera podido anticipar el compromiso mientras se implementaba la actualización estable, las personas implicadas en el desarrollo lo habrían retrasado. Sin embargo, los paquetes actualizados ya estaban instalados en el archivo estable y los servidores de réplica cuando se descubrió la intrusión, de tal forma que no fue posible retenerlo más.

Se usaron varios métodos basados en diferentes datos de control para verificar los paquetes y asegurar que el atacante no alteró los archivos:

Cronología

Debajo hay una cronología con el decubrimiento y recuperación de las máquinas comprometidas. Todas las horas están en formato UTC. Algunas horas son sólo estimaciones, porque nuestra conversación no tenía marcas temporales exactas.

Descubrimiento

El martes 20 de noviembre de por la tarde (GMT) el equipo de administración se percató de varios oopses del núcleo en master. Como había estado sin problemas durante mucho tiempo, el sistema se puso en mantenimiento para una investigación más concienzuda sobre potenciales problemas de hardware. Sin embargo, al mismo tiempo una segunda máquina, murphy, estaba experimentando exactamente los mismos problemas, lo que provocó las sospechas de los administradores.

klecker, murphy y gluck tenían el «Entorno Avanzado de Detección de Instrusión - Advanced Intrusion Detection Environment» (paquete aide) instalado para monitorizar cambios en el sistema de archivos y más o menos al mismo tiempo comenzó a alertar de que /sbin/init había sido reemplazado y que los valores de mtime y ctime habían cambiado para /usr/lib/locale/en_US.

Una investigación más minuciosa mostró que la causa de ambos problemas era el root-kit SucKIT (1.3b). Incluía robo de contraseñas (esnifado) y detección de capacidades de evasión (p. ej., herramientas para ocultar procesos y archivos), que estaban instalados directamente en el núcleo, lo que causaba que se tuviera noticia de los oopses.

Análisis detallado del ataque

El miércoles 19 de noviembre, a las 5pm GMT aproximadamente, se usó una contraseña robada (esnifada) para ingresar en una cuenta de desarrollador sin privilegios en la máquina klecker (.debian.org). El atacante recuperó luego el código fuente mediante HTTP para un aprovechamiento local del núcleo desconocido (en ese momento) y obtuvo permisos de root mediante este aprovechamiento. Tras esto, se instaló el root-kit SucKIT.

Se usó la misma cuenta y los mismos datos para ingresar en la máquina master, para obtener permisos de root con el mismo aprovechamiento y también para instalar el root-kit SucKIT.

El atacante intentó más tarde obtener acceso al host murphy con la misma cuenta. Pero falló porque murphy es una máquina restringida y su único propósito es actuar como servidor de listas de correo y sólo un pequeño subconjunto de los desarrolladores puede ingresar allí. Ya que falló el intento de ingreso inicial, esta persona usó su acceso como root en master para acceder a una cuenta administrativa que se usaba para propósitos de copia de seguridad y obtener acceso también a murphy. También se instaló en esta máquina el root-kit SucKIT.

El día siguiente, el atacante usó una contraseña robada (esnifada) de master para ingresar en gluck, convertirse en root allí e instalar también el root-kit SucKIT.

El análisis forense reveló las fechas y horas exactas en las que se sobreescribió el programa /sbin/init y se instaló el root-kit. El análisis también descubrió el archivo ejecutable que se usó para obtener acceso como root en las máquinas, que estaba protegido y ofuscado con Burneye. Tras desenvolver y desensamblar el aprovechamiento, los expertos de seguridad descubrieron qué error del núcleo se había utilizado.

Se había aprovechado una llamada al sistema brk para sobreescribir la memoria del núcleo (cambiando los bits de protección de página). Al hacer esto, el atacante obtuvo control pleno sobre el espacio de memoria del núcleo y podía alterar cualquier valor en memoria.

Aunque este código del núcleo lo mejoró en septiembre Andrew Morton y lo copió en una versión previa de los núcleos de octubre, no se habían considerado las implicaciones de seguridad de esta mejora. Por tanto, ningún vendedor publicó avisos de seguridad. Sin embargo, tras haberse descubierto que se usó como aprovechamiento local de root, el proyecto «Common Vulnerabilities and Exposures - Exposiciones y Vulnerabilidades Comunes» le asignó a este problema el identificador CAN-2003-0961. Está corregido en Linux 2.4.23 y se publicó el fin de semana pasado en el aviso de seguridad de Debian DSA 403.

Linux 2.2.x no es vulnerable a este aprovechamiento porque antes se hacía la comprobación de límites. También se cree que los núcleos para Sparc y PA-RISC no son vulnerables porque las direcciones del núcleo y del usuario se guardan en diferentes espacios de direcciones en estas arquitecturas.

Por favor, comprenda que no podemos hacer público el aprovechamiento usado a gente que no conocemos. Así que, por favor, no nos lo pida.

Recuperación

Después de haber echado abajo las máquinas, se crearon imágenes de los discos duros comprometidos y se almacenaron en una máquina distinta. Se distribuyeron a los encargados de hacer el análisis forense. Se reinstalaron las tres máquinas de los EE.UU. (master, murphy, gluck) y se fueron configurando los servicios uno a uno tras la investigación de los administradores de los servicios más relevantes.

En klecker, sin embargo, esta tarea se pospuso hasta un mantenimiento de seguridad para que el archivo de seguridad se pudiera poner en línea antes que los otros servicios. En esos momentos tampoco teníamos acceso por consola a klecker, por tanto la recuperación se tenía que hacer remotamente. Tras haber ingresado por consola vía puerto serie a una máquina local en una conexión de red con cortafuegos, se eliminó el root-kit, se cambió y se comprobó el núcleo, se comprobaron dos veces los binarios y el archivo de seguridad se verificó con respecto a varias fuentes externas distintas. Esta máquina se volverá a instalar en las próximas semanas.

Como precaución de seguridad, se desactivaron todas las cuentas de los desarrolladores en LDAP y se eliminaron las claves SSH de las máquinas más importantes, para que no se pudieran comprometer más máquinas. Esto, sin embargo, desactivó de forma efectiva cualquier trabajo que implicara subir archivos y acceder a los depósitos CVS.

Todas las contraseñas usadas en quantz (p. ej., todas las contraseñas de Alioth, arch y subversion) también se invalidaron. También se han eliminado todas las claves SSH autorizadas. Por favor, use el sistema para las contraseñas perdidas para recibir una contraseña nueva.

Cuando todos los servicios estén funcionando de nuevo y se hayan asegurado suficientemente las máquinas, LDAP será reconfigurado para que todos los desarrolladores puedan crear una contraseña nueva otra vez. Sin embargo, no se puede predecir cuándo ocurrirá esto.

Tras la recuperación, se reinstalará SSH en todas las máquinas comprometidas. Por tanto, habrá nuevas claves RSA y huellas dactilares de claves para esas máquinas. Las claves se incluirán en LDAP tan pronto como se creen y se podrán recoger desde aquí.

Consecuencias

Renueve sus contraseñas

Ya que las contraseñas fueron esnifadas de las máquinas comprometidas, cualquier conexión saliente en la que haya una contraseña se considerará también comprometida (p. ej., se considera que el atacante conocía la contraseña). Por tanto, se debería cambiar inmediatamente.

Además, si alguien tenía acceso a una máquina de Debian y estaba usando la misma contraseña o frase de paso en otras máquinas o claves le recomendamos encarecidamente que cambie la contraseña o frase de paso respectivamente tan pronto como le sea posible.

Si se había generado un clave SSH o se había guardado en una de esas máquinas y se usaba para ingresar en otras máquinas (p. ej., instalándola en .ssh/authorized_keys), también se debería eliminar.

Las claves GnuPG/PGP que se encuentren en máquinas de debian.org también se eliminaron de los anillos de claves de Debian y, por tanto, se desactivaron.

Los desarrolladores que estén preocupados por sus propias máquinas deberían al menos lanzar chrootkit y observar su salida. Matt Taggart mantiene una migración de la versión actual para woody en la siguiente dirección:

Además, Wichert Akkerman y Matt Taggart mantienen una lista detallada de tareas por precaución.

Root-Kit SucKIT

SucKIT es un root-kit presentado en el número 58 de Phrack, artículo 0x07 ("Parcheo de Linux al vuelo sin LKM", por sd y devik). Éste es un root-kit completo que se carga a través de /dev/kmem, p. ej. no necesita un núcleo con soporte para carga de módulos. Proporciona una shell respaldada por una conexión de acceso remoto protegida por una contraseña, que se inicia con un paquete específico (saltándose la mayoría de configuraciones de cortafuegos), y puede ocultar procesos, archivos y conexiones.

Normalmente, SucKIT se lanza como /sbin/init en el arranque del sistema, se divide (haciendo un fork) para instalarse en el núcleo, inicia una puerta trasera y lanza una copia del binario original «init» desde el padre (con pid 1). Cualquier ejecución sucesiva de /sbin/init se redirige al «init» original.

Protección Burneye de TESO

Burneye es un modo de ofuscación de los binarios ELF en la plataforma UNIX presentado en el número 58 de Phrack, artículo 0x05 ("Armando el ELF: Cifrado binario en la plataforma UNIX", por grugq y scut). Usando herramientas como Burneye de TESO, un atacante puede modificar un programa ejecutable para que cifre su verdadero propósito, ocultándolo de los filtros de los cortafuegos, sistemas de detección de intrusión, software antivirus y de los entrometidos ojos de los investigadores

Agradecimientos

Respuesta de la prensa

Información de contacto

Para más información puede visitar las páginas web de Debian o enviar un correo-e a press@debian.org.